Testing applications before they go live is not optional, in my experience.  The reason I make this pompous sounding statement is because of all the pain I have seen over so many years in literally hundreds of web applications.  I can state, almost categorically, that had those applications been tested, using the guidelines shown below; the problems we were brought in to solve would not have occurred.  So without further ado, here is a list of tests that all applications should go through at some time or other, in their lifecycle.

• Unit-Developer Testing: This is each individual developer testing new or changed code to ensure it is bug free before submitting it for the next level of testing, Integration Testing.
• Integration Testing: Integration testing is where all code from all developers is integrated into a single development copy and tested as a whole to make sure that the code from one developer does not break anything when merged.  Any issues found here should be documented and the code fixed, ideally by the developer who first created it.
• Regression Testing: This is somewhat of an adjunct to testing as Regression Testing involves running the same set of tests before and after making changes to code to gauge the net effect.  If the changes break something or make things worse then of course this should be documented and the code fixed, ideally by the developer who first created it.
• Load Testing: Here we want to simulate a realistic level of load to meet some business requirement or simply to ensure the new code/application will perform with stability once released to production. The key phrase here is "realistic".  In Stress Testing we typically go beyond realism.
• Stress Testing: This sort of testing is typically used to determine the failure point of an application and is often used in scalability planning for medium to long term growth.  Load is applied using a load-test tool, as in Load Testing above.
• Functional-Usability Testing: This phase is when the stakeholders test the application to ensure that the functionality required is actually available in the application.
• Browser Testing: Here the application is tested in a series of Web Browsers to make sure it will perform as needed.  As more capability is required of the browser by the growth in usage of Web 2.0 paradigms such as Ajax and Flex.  Browser testing is growing in importance because of the gradual move away from total server centricity.
• Distributed Browser Testing: This is an emerging need and we were pleased to find a company offering this sort of testing using Cloud Computing.  In essence Load and Stress Testing, the tests are specifically aimed at the server infrastructure and typically involve no more than 5 test agents which in terms of networking at the Web Server level will look like no more that 5 users.  In addition, traditional Load-Stress test tools have great difficulty dealing with/capturing data passing from Web Browser to and from the Web Server in Web 2.0 centric sites (Ajax-Flex etc).  Mike Labriola and I were discussing this at BFusion-BFlex last year, how to simulate 1,000's of browser end-points coming from 1,000's of locations.  A company called BrowserMob are doing just that as mentioned above and we are very excited at the prospects of what they will achieve.

The main point of the blog piece is to re-inforce the need to test applications-code before deploying to production.