So, what really is smoke testing? Doesn’t the term just sound a little funny to you? Is it like something has already been set on fire and now you have to test the smoke? What’s its significance and is it the same or different than sanity testing? Trying to understand all these different aspects? Don’t worry, we will be addressing all these questions in this post.
What is Smoke Testing?
Smoke Testing definition:
Smoke Testing is a simple test conducted to ensure that the software is working properly at a gross level so that further testing can be done. If the smoke test itself fails then no further testing can be done. It is also called Build Verification Testing (BVT) and is done for software build.
It is a subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertain that the most crucial functions of the program work, but not bothering with finer details.
How was the term coined?
The term originates in hardware repair and has been applied to software. It’s intended to be a quick test to see if the application “catches on fire” when run for the first time. As stated above it’s just to make sure you don’t waste a bunch of folks time by setting them loose on something that’s obviously broken.
Smoke Testing comes from hardware. After you’ve assembled/soldered/wired everything together, you connect it to mains and turn it on.
If you don’t see or smell smoke, the test is successful.
If there is smoke, disconnect power immediately! (and figure out the problem before re-test…)
http://www.wikipedia.com
Smoke Testing is an integration testing approach that is commonly used when “shrink-wrapped” software products are being developed.
It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a frequent basis.
In essence, the smoke testing approach encompasses the following activities:
- Software components that have been translated into code are integrated into a “build”. A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions.
- A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
- The build is integrated with other builds and the entire product (in its current form) is smoke tested. The integration approach may be top-down or bottom-up.
The daily frequency of testing the entire product may surprise some readers. However, frequent tests give both managers and practitioners a realistic assessment of integration testing progress.
McConnell describes the smoke test in the following manner:
The smoke test should exercise the entire system from end to end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.
Is It the same as Sanity Testing?
Sanity Testing covers more depth as compared to smoke testing. It is performed to verify whether the application functions according to specifications. This is typically a subset of regression and is performed before sending the release to the customer for testing.
Benefits of Smoke Testing:
Smoke testing provides a number of benefits when it is applied to complex, time-critical software engineering projects:
Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and other show-stopper errors are uncovered early, thereby reducing the likelihood of serious schedule impact when errors are uncovered.
The quality of the end product is improved. Because the approach is construction (integration) oriented, smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early, better product quality will result.
Error diagnosis and correction are simplified. Like all integration testing approaches, errors uncovered during smoke testing are likely to be associated with ” new software increments” that is, the software that has just been added to the build(s) is a probable cause of the newly discovered error.
Progress is easier to assess. With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Want to learn more about testing techniques? Please take a look at related posts.
