In my 4 years as a software developer, I've worked on a sizable number of web-based applications, and I thought I should share some insights - even as I am in the middle of yet another web-based project at this writing. Once in great while, I come across a website that is not pleasant to visit, and I wonder what kind of testing such a website might have undergone. Even more common are ActiveX or Javascript issues that litter websites on the Internet - ones that when you visit a page, an error is displayed and asks you whether you want to debug (dumb!!). These are signs of poor testing for a web application.
Comprehensive testing can improve the quality of web apps and lead to better long-term support for the application. Before deployment, functional and performance testing must be done, including security and accessibility certification of the web application. All this testing is done by testers, automated scripts, and a representative group of end users. Developers of the web application should only participate to provide expert support.
TESTERS:
Tester selection depends on testing needs, complexity of the application, time needed to learn the application, number of test scripts and scenarios, and total time available for testing. Choose testers with a goal to provide a diverse skill set and experience levels. You will need 3 kinds of testers: functional testers, performance testers, and scenario/script testers (differences will be seen in testing description). Obviously individual testers can do all these, but it's advisable to separate the roles.
TEST MANAGEMENT SYSTEMS:
Helps organize test resources such as documentation and requirements, scripts or scenarios, defects, and test results. Such a system is easily accessible by all groups for progress reports and task or defect tracking. The system also provides traceability and can be harnessed to lighten the load of documentation.
TESTING:
(1) Functional testing determines if the web application works as designed, satisfying the requirements. Testers need to have an eye for anomalies and inconsistencies during such testing. Testing is manual, requiring a live person.
Automated tests should be applied to repeatable tasks that don't necessarily need human decision or observation skills. Scripts can help test more configurations in a consistent and predictable way, usually their course drawn from experiences of live testers. Functional testing also covers ideas like users entering bad data, no data, or unreasonably unrealistic data into the application.
(2) Performance testing for web applications focuses on response times. Tests may include spike (worst-case scenarios), stress (determine the failure conditions by subjecting it to increasing loads), and load (running 72-hour tests at near-breaking point - sustained high volume).
(3) Security testing tests user authentication and verification, and accessibility to restricted content. It also tests session management issues, user privacy, and the protection of user transactions. Banking applications, for example, need to make sure they support SSL and TLS for secure communication.
(4) Integration testing involves running the web application on various operating systems and web browsers. This is where the real difference between web browsers begins to show, and we've often had to write workarounds for web browsers that do not adhere to standards (IE is notorious for this ...). Also, all scripts and plugins are tested in more configurations at this point, resolving issues of when a browser doesn't support certain plugins, or the OS has to be configured to handle what we need.
(5) Accessibility and usability testing is geared towards those with disabilities. This is a much overlooked area of testing, but web applications should be able to support alternative input and output methods such as audio instructions, scanner input, and special keyboards. In fact, there exists laws on the books requiring government websites to support this feature (see Section 508 of the 1973 Rehabilitation Act).
TESTPLANS:
With all the testing considerations above, it is possible to write a comprehensive testplan that can cover all the aspects discussed. Just remember this plan should be adaptable enough for any changes to requirements and needs of the application.
Testcases should be prioritized such that when a regression needs to be done, high-priority and must-always-test testcases are done. Regression testing should always happen whenever a fix is applied to the application, patches are done to the environment, or new builds are deployed. The regression testplan should be more automated than regular testing, the results of which would guide live testers to focus on specific areas.
BEYOND DEPLOYMENT:
Ownership of the web application does not end after you hand it off to the client. At that point, you transition into a support role. In support, you deal with training the application's user community, providing help desk support, and facilitating knowledge transfer (documentation, knowledge base).
At a minimum, every website should have a help section that includes a user manual of sorts, frequently asked questions, application tips, and work-arounds for known inconveniences.
