Got a smoke? A smoke test, that is!
Since my last entry, I have busy working with customers. When I engage with them, I look to find the types of test suites they run. I have been pretty surprised that the majority of these customers don't have a smoke test. Further, a good portion of those customers never heard of a smoke test. Hence, I figured this would be a good topic for the blog.
The smoke test is actually derived from our hardware brethren. The test was actually pretty simple for them. They would power the hardware device up and if it smoked ... it wasn't working! Pretty simple stuff!. In the software world, we're looking at applying a series of tests to see if the software is working. The tests are derived from the larger regression suite we run. In fact, we try to pull one or two test cases from each major area of functionality (or Use Case). Once aggregated, these tests help to assess the architectural stability of the current build. The idea behind this is that if one of these test cases fail, then the build isn't worth testing because a core/architectural piece of functionality has an issue.
So what's the value behind this? Well -- it is a way for us to ensure we spend our time wisely. For instance, if the print portion of our application has an issue, do we really want to run all of the tests for that build? What if the issue was as simple as the application can't print. The good majority of our tests would focusing on printing from the application (e.g. different page counts, different layouts, different printers, etc...). Do we really want to run those test cases, creating defects for each thing -- even though they are all related to the fact that the application's printing functionality is broken? Or would we rather look to see if the core problem is that the app just can't print! We would only need to log one defect. The smoke test can save us time. It can make us more efficient.
A few entries ago, I talked about what to automate. I mentioned that there are a lot of thoughts and opinions on this. My opinion is that, if you can, automating a smoke test would be a valuable tool. You could add it into the build process. When the application gets built, your smoke test gets executed. If this is done overnight, you can come in the next day to see what the results are.
We all know that smoking is bad for our health. However, smoke testing is great for our QA efforts.
Plug it in ... Turn it on ... Does it Smoke?