Web Applications Testing
Introduction
The
instant worldwide audience of any Web Browser Enabled Application -- a Website
-- makes its quality and reliability crucial factors in its success.
Correspondingly, the nature of Websites and Web Applications pose unique
software testing challenges. Webmasters, Web applications developers, and
Website quality assurance managers need tools and methods that meet their
specific needs. Mechanized testing via special purpose Web testing software
offers the potential to meet these challenges. Our technical approach, based on
existing Web browsers, offers a clear solution to most of the technical needs
for assuring Website quality.
Websites
impose some entirely new challenges in the world of software quality! Within
minutes of going live, a Web application can have many thousands more users
than a conventional, non-Web application. The immediacy of the Web creates
immediate expectations of quality and rapid application delivery, but the
technical complexities of a Website and variances in the browser make testing
and quality control that much more difficult, and in some ways, more subtle,
than "conventional" client/server or application testing. Automated
testing of Websites is an opportunity and a challenge.
Dimensions of Quality
There
are many dimensions of quality; each measure will pertain to a particular
Website in varying degrees. Here are some common measures:
- Timeliness:
Websites change often and rapidly. How much has a WebSite changed since
the last upgrade? How do you highlight the parts that have changed?
- Structural
Quality: How well do all of the parts of the WebSite hold together? Are
all links inside and outside the WebSite working? Do all of the images
work? Are there parts of the WebSite that are not connected?
- Content:
Does the content of critical pages match what is supposed to be there? Do
key phrases exist continually in highly-changeable pages? Do critical
pages maintain quality content from version to version? What about
dynamically generated HTML (DHTML) pages?
- Accuracy
and Consistency: Are today's copies of the pages downloaded the same as
yesterday's? Close enough? Is the data presented to the user accurate
enough? How do you know?
- Response
Time and Latency: Does the WebSite server respond to a browser request
within certain performance parameters? In an e-commerce context, how is
the end-to-end response time after a SUBMIT? Are there parts of a site
that are so slow the user discontinues working?
- Performance:
Is the Browser --> Web --> ebSite --> Web --> Browser
connection quick enough? How does the performance vary by time of day, by
load and usage? Is performance adequate for e-commerce applications?
Taking 10 minutes -- or maybe even only 1 minute -- to respond to an
e-commerce purchase may be unacceptable!
Impact of Quality
Quality
remains is in the mind of the WebSite user. A poor quality WebSite, one with many
broken pages and faulty images, with Cgi-Bin error messages, etc., may cost a
lot in poor customer relations, lost corporate image, and even in lost sales
revenue. Very complex, disorganized WebSites can sometimes overload the user.
The
combination of WebSite complexity and low quality is potentially lethal to
Company goals. Unhappy users will quickly depart for a different site; and,
they probably won't leave with a good impression.
Browser:
The
browser is the viewer of a WebSite and there are so many different browsers and
browser options that a well-done WebSite is probably designed to look good on
as many browsers as possible. This imposes a kind of de facto standard: the
WebSite must use only those constructs that work with the majority of browsers.
But this still leaves room for a lot of creativity, and a range of technical
difficulties. And, multiple browsers' renderings and responses to a WebSite
have to be checked.
Display Technologies:
What
you see in your browser is actually composed from many sources:
- HTML.
There are various versions of HTML supported, and the WebSite ought to be
built in a version of HTML that is compatible. This should be checkable.
- Java,
JavaScript, ActiveX. Obviously JavaScript and Java applets will be part of
any serious WebSite, so the quality process must be able to support these.
On the Windows side, ActiveX controls have to be handled well.
- Cgi-Bin
Scripts. This is link from a user action of some kind (typically, from a
FORM passage or otherwise directly from the HTML, and possibly also from
within a Java applet). All of the
different types of Cgi-Bin
Scripts (perl, awk, shell-scripts, etc.) need to be handled, and tests
need to check "end to end" operation. This kind of a
"loop" check is crucial for e-commerce situations.
- Database
Access. In e-commerce applications you are either building data up or
retrieving data from a database. How does that interaction perform in real
world use? If you give in "correct" or "specified"
input does the result produce what you expect? Some access to information
from the database may be appropriate, depending on the application, but
this is typically found by other means.
Navigation: Users move to and from pages, click on links, click on images (thumbnails), etc. Navigation in a WebSite is often complex and has to be quick and error free.
Object Mode: The display you see changes dynamically; the only constants are the "objects" that make up the display. These aren't real objects in the OO sense; but they have to be treated that way. So, the quality test tools have to be able to handle URL links, forms, tables, anchors, buttons of all types in an "object like" manner so that validations are independent of representation.
Server Response: How fast the WebSite host responds influences whether a user (i.e. someone on the browser) moves on or gives up. Obviously, InterNet loading affects this too, but this factor is often outside the Webmaster's control at least in terms of how the WebSite is written. Instead, it seems to be more an issue of server hardware capacity and throughput. Yet, if a WebSite becomes very popular -- this can happen overnight! -- loading and tuning are real issues that often are imposed -- perhaps not fairly -- on the WebMaster.
Interaction & Feedback: For passive, content-only sites the only real quality issue is availability. For a WebSite that interacts with the user, the big factor is how fast and how reliable that interaction is.
Concurrent Users: Do multiple users interact on a WebSite? Can they get in each others' way? While WebSites often resemble client/server structures, with multiple users at multiple locations a WebSite can be much different, and much more complex, than complex applications.
Functionality Testing:
Test
for - all the links in web pages, database connection, forms used in the web
pages for submitting or getting information from user, Cookie testing.
Check all the links:
- Test
the outgoing links from all the pages from specific domain under test.
- Test
all internal links.
- Test
links jumping on the same pages.
- Test
links used to send the email to admin or other users from web pages.
- Test
to check if there are any orphan pages.
- Lastly
in link checking, check for broken links in all above-mentioned links.
Test forms in all pages:
Forms
are the integral part of any web site. Forms are used to get information from
users and to keep interaction with them. So what should be checked on these
forms?
- First
check all the validations on each field.
- Check
for the default values of fields.
- Wrong
inputs to the fields in the forms.
- Options
to create forms if any, form delete, view or modify the forms.
Cookies testing:
Cookies
are small files stored on user machine. These are basically used to maintain
the session mainly login sessions. Test the application by enabling or
disabling the cookies in your browser options. Test if the cookies are
encrypted before writing to user machine. If you are testing the session
cookies (i.e. cookies expire after the sessions ends) check for login sessions
and user stats after session end. Check effect on application security by
deleting the cookies.
Validate your HTML/CSS:
If
you are optimizing your site for Search engines then HTML/CSS validation is
very important. Mainly validate the site for HTML syntax errors. Check if site
is crawl able to different search engines.
Database testing:
Data
consistency is very important in web application. Check for data integrity and
errors while you edit, delete, modify the forms or do any DB related
functionality. Check if all the database queries are executing correctly, data
is retrieved correctly and also updated correctly. More on database testing
could be load on DB, we will address this in web load or performance testing
below.
Usability Testing:
Test for navigation:
Navigation
means how the user surfs the web pages, different controls like buttons, boxes
or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose. Main menu should be provided on each page. It should be consistent.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose. Main menu should be provided on each page. It should be consistent.
Content checking:
Content
should be logical and easy to understand. Check for spelling errors. Use of
dark colors annoys users and should not be used in site theme. You can follow
some standards that are used for web page and content building. These are
common accepted standards like as I mentioned above about annoying colors,
fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing
Other user information
for user help:
Like
search option, sitemap, help files etc. Sitemap should be present with all the
links in web sites with proper tree view of navigation. Check for all links on
the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.
Interface Testing:
The
main interfaces are:
Web server and application server interface
Application server and Database server interface.
Web server and application server interface
Application server and Database server interface.
Check
if all the interactions between these servers are executed properly. Errors are
handled properly. If database or web server returns any error message for any
query by application server then application server should catch and display
these error messages appropriately to users. Check what happens if user
interrupts any transaction in-between? Check what happens if connection to web
server is reset in between?
Compatibility Testing:
Compatibility
of your web site is very important testing aspect. See which compatibility test
to be executed:
- Browser
compatibility
- Operating
system compatibility
- Mobile
browsing
- Printing
options
Browser compatibility:
In my
web-testing career I have experienced this as most influencing part on web site
testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.
OS compatibility:
Some
functionality in your web application is may not be compatible with all
operating systems. All new technologies used in web development like graphics
designs, interface calls like different API’s may not be available in all
Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.
Mobile browsing:
This
is new technology age. So in future Mobile browsing will rock. Test your web
pages on mobile browsers. Compatibility issues may be there on mobile.
Printing options:
If
you are giving page-printing options then make sure fonts, page alignment, page
graphics getting printed properly. Pages should be fit to paper size or as per
the size mentioned in printing option.
Performance testing:
Web
application should sustain to heavy load. Web performance testing should
include:
Web
Load Testing
Web Stress Testing
Web Stress Testing
Test
application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.
Stress
testing: Generally
stress means stretching the system beyond its specification limits. Web stress
testing is performed to break the site by giving stress and checked how system
reacts to stress and how system recovers from crashes. Stress is generally
given on input fields, login and sign up areas.
In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,
In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,
Security Testing:
Following
are some tests for web security testing:
- Test
by pasting internal URL directly into browser address bar without login.
Internal pages should not open.
- If
you are logged in using username and password and browsing internal pages
then try changing URL options directly. I.e. If you are checking some
publisher site statistics with publisher site ID= 123. Try directly
changing the URL site ID parameter to different site ID which is not
related to log in user. Access should deny for this user to view others
stats.
- Try
some invalid inputs in input fields like login username, password and
input text boxes. Check the system reaction on all invalid inputs.
- Web
directories or files should not be accessible directly unless given
download option.
- Test
the CAPTCHA for automates scripts logins.
- Test
if SSL is used for security measures. If used proper message should get
displayed when user switch from non-secure http:// pages to secure
https:// pages and vice versa.
- All
transactions, error messages, security breach attempts should get logged
in log files somewhere on web server.
No comments:
Post a Comment