The term “Smoke testing” is familiar to all software testing professionals. All software testing professionals should know the history how the term smoke testing coined. It is the term actually used by the hardware designing/testing professionals. Once they assemble the electronic circuit elements in a board named PCB, they will connect the power supply to the board and switch on the power supply to check whether the circuit works fine at least at a very basic level or the circuit burns out emitting smoke due to some issues. If smoke is not seen then the smoke test is passed.Similarly in software testing smoke testing is meant for checking whether the software is working correct at its basic level.
Smoke testing is normally done by the testing team to take a firm decision on whether the build can be taken for further detailed testing or can be rejected back to the development team with valid reasons and data.
Smoke testing is also known as Build Verification Test (BVT) or Build Acceptance Test (please note that user acceptance testing is different from build acceptance testing) or intake testing.
Now it’s my turn to share my own perceptions on smoke testing. Testing team do the smoke testing to validate the minimum stability of the software. I would like to have development team also to do a smoke test kind of stuff before they deliver the build to the testing team. This may look like a foolish thought as of now but there are chances in near or far future that someone will follow this practice quoting like its development team’s duty also to ensure a minimum stable enough build have to go to testing team for testing. At that time even these practices may get new terms like “Developer’s smoke test” and “Tester’s smoke test”.(or like Outgoing smoke testing and incoming smoke testing.Hmmmm..How addicted we are with this communication/mobile technology!)
Also on the lighter side, in hardware testing one can see the real smoke when smoke test fails but in software testing the smoke cannot be seen but can be realized at development team’s desk like these poor testing guys rejected our build in their smoke testing.
Now it’s my turn to share my own perceptions on smoke testing. Testing team do the smoke testing to validate the minimum stability of the software. I would like to have development team also to do a smoke test kind of stuff before they deliver the build to the testing team. This may look like a foolish thought as of now but there are chances in near or far future that someone will follow this practice quoting like its development team’s duty also to ensure a minimum stable enough build have to go to testing team for testing. At that time even these practices may get new terms like “Developer’s smoke test” and “Tester’s smoke test”.(or like Outgoing smoke testing and incoming smoke testing.Hmmmm..How addicted we are with this communication/mobile technology!)
Also on the lighter side, in hardware testing one can see the real smoke when smoke test fails but in software testing the smoke cannot be seen but can be realized at development team’s desk like these poor testing guys rejected our build in their smoke testing.
