We have code smell and Smoke testing … who thinks of these terms?

Just when we thought we have the acronyms, TLA (three lettered acronyms) and FLA (four lettered acronyms) under control, we are faced with phrases such as “code smell” and “smoke testing”. While the former is a term for “a hint that something may be (not is) amiss (wrong) in the codebase”, the focus of this blog post is more around the smoke testing.

clip_image001… not the topic of today’s smoke test. Picture from https://www.toxel.com/inspiration/2008/07/11/20-brilliant-advertising-ideas.

Smoke testing is an integration testing approach … which in turn verifies a solution as components start interacting. Integration testing typically follows unit testing and precedes validation and system testing. See SDLC – Software Development Lifecycle … testing, the moment of truth (part 8 of many) for more information on the testing strategies.

The approach to smoke testing, could be compared to an observatory in a huge Canadian forest, watching the surrounding environment for plumes of smoke. Just as the observatory watches the surrounding forests for signs of trouble, the smoke testing in the information technology world continuously observes and assesses a project.

PA100092 … keeping an eye out for smoke to avoid raging forest fires at a later stage.

This is typically achieved by:

  1. Running solution build, which includes all the components, libraries, data repositories, nuts and bolts required to implement the implemented product features.
  2. Running a series of tests, for example units tests, intended to uncover and expose smoke and fires, or rather requirement mismatches and bugs.
  3. Running a minimum of a daily build, preferably gated, regular or continuous builds, which combines the actual build and the series of tests.

The benefits of this approach are probably worth a book, but we will cut it short and summarise them as:

  1. Transparency in terms of progress and problems.
  2. Integration risks are minimised by the regular build and test runs … he who integrates and tests everything only at the end will eventually see the light, or run out of candles for the last minute midnight debugging.
  3. Quality is improved early and ongoing … my mentor in the 80’s always used to say “the key ingredients of a good system can be summarised with one word … quality” … which means that quality is key!

Looking at Visual Studio 2010 and the new features that have been released with BETA-2, the above is not a dream, but reality. Make a point of visiting the following treasure caves for more information: