In Part 1 of this series, I provided a general summary of some of the key concepts of Rapid Application Testing. Today I would like to take a closer look at one of the more important aspects of RAT.... Smoke tests.

When developing a set of test cases to test an application the most important are smoke tests. Smoke tests can mean different things to different people. For me, smoke tests are the tests you choose to run each and every time you have a new version of the software to be tested. Because you are running them every time you want these tests to be high value. For me I select test cases for inclusion as smoke tests for one of two reasons:-

1. The failure of the smoke test would render a significant proportion of the test cases unable to be run, making it impossible to fully test the application. E.g. If the landing page for an application does not launch or an important navigation component such as a menu, action bar, or outline does not appear or does not work correctly.
2. The failure of the smoke test would cause you to seriously consider whether or not you would deploy the application. E.g. In a Travel Request application the  “Approve” action does not work.

Another criterion that can be used in selecting smoke tests is to say…  When I don’t have as much time as I would like to fully test my application, what are the tests I would always want to conduct to ensure the overall soundness of the application?

When testing an application without an existing test plan, the creation of smoke tests should be the highest priority. It is often not too hard to identify a wide range of “show stopper” items that can be included. The number of smoke tests will often vary based upon how selective decision makers are about what level of defect is acceptable. Every time a release is delayed because of the need to address “important” issues, these issues should be documented in the form of smoke tests. Conversely every time a decision is made to allow a release to proceed despite the failure of a smoke test consider lowering the priority of  the test case below that of a smoke test.

Because of their importance it is typical to run smoke tests first. If you have a separate QA role, share the details of the smoke tests with the developer(s) so that the developers can run the smoke tests prior to deploying the code for QA. This will help prevent lengthy delays caused by finding errors in smoke tests during the QA process.

When it comes to automation of tests scripts smoke tests are often a prime candidate. Smoke tests are the tests you are likely to run with the greatest frequency so the effort expended to record the test scripts using a product such as Selenium brings the greatest return. Recording smoke tests has a second key advantage. Automated scripts can be run against multiple scenarios for minimal additional cost. A web application can easily be tested against multiple browsers and even multiple versions of the same browser. Applications can be tested on different versions of domino and even with different resolution monitors.

If you hate documenting test cases at least consider taking the effort to document smoke tests. This will ensure the each time you have the need to test your application you will not embarrass yourself by forgetting to run one or two all important test cases.

Note: I will be presenting on the topic of Rapid Application Testing at Lotusphere. If you are fortunate enough to be attending this year and have an interest in this topic pencil in the following session:-

BP303: I Smell A RAT - Rapid Application Testing, Wednesday 10:AM-11AM Pelican I&II