The earlier a bug is found, the less expensive it is to fix it. OTIVO's Web Site Testing Process Phase 1 Project Kickoff: finalize objectives, bug reporting, testing specifications, list of browser configurations and other functionality requirements. We usually test using a variety of operating systems and browsers. Recently (in 2008), most of our projects have only required/requested testing in Firefox, Safari, MSIE, WinXP, WinVista, and MacOS10. We have older operating systems and browsers available for testing, such as WinNT, Win2000, Win98, WinME, and MacOS9. Commodore 64 testing and Amiga testing are not available. (tee-hee) Phase 2 Develop test plan and strategy: plus setup bug database project for managing bug reporting We use our own Web-based bug database or any available bug database that you are already using. Phase 3: Test Web site and application according to test plan Ð including browser compatibility testing. Report bugs in bugbase. Daily email status reports to client with information about testing completed, testing planned for next day, bugs reported and outstanding issues. Phase 4: Regress bugs as they are fixed to insure fix is complete hasn't created any new bugs. Phase 5: Develop and deliver test completion report. How much does it cost? What do I get? Most projects are done on an hourly basis with an estimated cost and number of hours determined upfront for a specific set of deliverables. OTIVO charges $80-130/hour for testing and bug reporting and $130-200/hour for testing management. We are very efficient. Sample statement of work for a Web QA project (PDF download; Acrobat Reader required) Why should we outsource instead of testing inhouse? Objectivity. When you work on and develop a project, you often can't see or find obvious bugs, omissions and errors. Our testers ramp up and become familiar with a Web site while they're testing so they have a fresh view of the application and elements and interface. Why not rely on developers to test their own pages and elements? Again, objectivity, and cross-platform-friendliness. Developers typically develop and test on the same platform while they are working. They also see the same page or element a bajillion times so if you put it in front of their face with a typo on the third line or an incorrect calculation they could easily miss it. Why rely on more lengthy (and costly) test plans to test a Web site instead of pounding on the site (gorilla testing)? Especially with content publishing and electronic commerce applications, it's important to test as much of the site and application's range of functionality as possible. Gorilla testing (pounding on a site or application in as many ways as the tester can think of without an organized test plan) is useful, but the methodical process that creates a test plan usually covers more of the possible functionality than randomly pounding on the site.