Final Report

Scope:

IS&T web applications contain complex browser-based user interfaces created with JavaScript, HTML and CSS.  The functional/regression test tool we currently use, QTP, only works in Internet Explorer, so it does not test IS&T’s set of supported web browsers. Therefore QTP cannot test individual browser issues.  Also, IS&T needs to evaluate its web applications against new web browsers and changes to the IS&T web application infrastructure (new database, new application server, new VM, etc.)

What we did:

1. We convened a committee with representation from the Help Desk, the Quality Assurance Team, Web Services, DCAD and Student Systems, and began studying the current web application testing landscape.
2. We looked at a list of approximately 82 different automated Test Tools (http://www.softwareqatest.com/qatweb1.html#FUNC) and choose 6 worthy of further evaluation, based on the following criteria:
   1. Support for all MIT operating systems
   2. Support for all MIT browsers
   3. Ability to playback tests in a browser (instead of testing via browser emulation)
   4. Ability to record tests (to make test creation easier)
   5. Some sort of gui (versus code only framework)
   6. Decent documentation
   7. Some sort of name in the industry
3. We created a test plan to evaluate these Test Tools (the test plan is here). The test plan was heavily weighted with DOM manipulation, AJAX and other JavaScript functionality. (expand)
4. We broke up into groups of 1 to 3 users to try each of the 6 Test Tools.
5. We modified the Test Plan as needed.
6. We found the following:

Lessons Learned

Record and play is a myth; it turned out that programming was needed with every tool to be able to reproduce the test case.

Comprehensive tests require if/else programming, looping, assertions and negative cases at the very least. Simply recording, sprinkling simple assertions and playing back does not create a comprehensive test.

Documentation for automated Test Tools is underwhelming.

Conclusions:

Automated Test Tools, in general, give the most 'bang for the buck' when used for regression testing. Due to the constantly changing browser/platform playing field no test tool can be expected to support the latest browser/platform combination. Therefore we conclude that automated Test Tools cannot be the sole method for testing MIT-supported applications.

The current browser space is expanding and changing and churning rapidly right now, making it even harder for Test Tools to catch up.

Also user and management expectations around browser support and platform are constantly expanding. Chrome, mobile in general and iPhone are the current issues, Windows 8 is looming on the horizon.

Therefore supporting constant rollout of the latest browsers requires manual testing resources. However, automated Testing Tools do improve the quantity and coverage and reduce time for testing Test Tool-supported browsers.

Recommendations:

Roll out Selenium to web developers with the following requirements and caveats:

1. No support for current version of Safari, may be restored in future.
2. Hardware requirements: need to be able to get to the all the OS/brower combos
3. Need someone who is the product evangelist, creates the docs, builds some baseline tests, shows handle problem items (type versus type keys), trains developers and help desk
4. Need dedicated hardware/software and test users (Touchstone and certificates)
5. Need someone to coordinate and maintain the environment
6. Management buyin and continued support
7. A project and a project plan and project manager

Further Study:

Once QTP 11 final ships, retest the Test Plan in QTP 11 for both IE 9 and Firefox.

What are other large institutions doing?