Best Practices for Software Projects - Smoke Tests

A smoke test is a series of test cases that are run prior to commencing with full-scale testing of an application.  The idea is to test the high-level features of the application to ensure that the essential features work.  If they do not work, there is no need to continue testing details of the application, so the testing team will refuse to do any additional testing until all smoke test cases pass.  This puts pressure on the development team to ensure that the testing team does not waste valuable testing time with code that is not ready to be tested.

Once smoke tests are implemented as part of your software development life cycle, you will see the overall quality of the product improve and the sensitivity to producing high quality software increased.

Smoke Tests - How to Implement

To implement smoke tests, the quality assurance (QA) lead will develop a set of test cases that are run any time a new release is provided from the development team. These set of test cases are used to test the major functional areas of the system.  They are not nit-picky test cases that test low-level detail of the application, they are higher level test cases that test overall functionality.  Normally, a smoke test will consist of 20 to 30 high level test cases.

To ensure quality awareness, the smoke test cases are publicized to the development team ahead of time, so that they are aware of the quality expectations.  If a build fails a smoke test, it should not be taken lightly, as this may illustrate a discipline problem with the development team.  Each developer should be held responsible for ensuring that their code does not break the smoke test.  Under no circumstance should the QA team agree to continue testing the release until all the smoke test cases have passed.

Some fun ways to enforce smoke test quality is to hold developers to this quality standard by peer pressure.  For example, developers that break the smoke test may have their name posted on your department bulletin board in the "Hall of Shame" until the developer provides a good build.    Or you may consider taping a sucker to the door of the developer that broke the smoke test until the developer fixes the build.   Another good technique is to have the project manager allocate a budget for a team party upon the software being successfully implemented.  Then if teams break the smoke test, a fine is levied, decreasing the total budget for the team party with each infraction.