Smoke testing is just one of the most frequent conditions within a QA vocabulary. It involves doing mild (and frequently ad-hoc) tests of important features, typically before or after a release. While smoke testing is just one of the quickest and most basic forms of QA testing, it is also among the most important when time is tight.
To comprehend the purpose, it can be helpful to think of the term," when there is smoke, there's fire." A big part of smoke testing is keeping an eye out for red flags, which might indicate different instabilities in the software.
Smoke Testing Cases
Ideally, an app or website also has gone through more rigorous testing in other QA stages. But smoke testing is used as a back-up, to be extra careful, or if there is not enough time for the perfect degree of QA testing.
By way of example, state that you are about to launch a new version of a program. It passed QA, however you want some quick last-minute testing done before you print to the App Store, just to be safe. If you inquire QA to smoke check the login attribute, they may assess that logging in with valid credentials functions. They would also likely verify that attempting to log in using a wrong password constitutes an error message.
However, with smoke testing, QA wouldn't be quite as thorough as other kinds of testing.
Timing plays a major part. As mentioned, one of the common situations is when regression testing has already been finished, and to be safe, QA is doing one more last-minute sweep of essential areas.
A number of the other major cases include:
When time is tight, and product owners have to or insist on getting a launch out on a specific date. Developers commonly go over their deadlines, in that case, there isn't always enough time to complete regression testing services without delaying a discharge. In cases like this, QA must do the best they can with hazard assessment. This might help ensure that essential features like logging in, signing up, making a purchase, etc. are passing basic tests.
Right after a release. Every time a new variant goes out, QA should be certain the installation did not cause any difficulties. It's normal for QA to smoke test a new release for this objective. Perhaps the programmer (s) finished their initial pass at a new attribute, and are sending it to QA to get the first look. By smoke testing, QA provides faster feedback for any obvious difficulties.
Agile Smoke Testing
It's rare to come across an Agile Engineering team that does not use it on a normal basis.
Smoke testing is usually regarded as a manual testing project. But there will be automation also, to validate any substantial money-making flows of this program. Running automation scripts before starting manual smoke tests may also save time. If the automation finds any significant bugs, then it can go back to development before manual testers waste any moment. (See a listing of the Top 5 Test Cases to Automate.)
Smoke Testing Threats
Smoke testing is all about minimizing risk -- but it is doesn't come anywhere near eliminating it. This may seem like common sense. However, it's not strange for QA to get blamed for bugs that are missing.
So how do you put expectations within this scenario? If you get tasked with smoke testing a release that hasn't gone through regression testing, it's a good idea to double-check that your QA manager is apparent of the dangers entailed. You're able to keep professional and bring it up from the perspective of being helpful.
For example, you could tell your boss, "Sure! I'm happy to smoke test it. Given it will just be getting basic testing, there's a risk of bugs slipping through. I know that the timeline is tight, so I will cover as much ground as possible within the limited time."
Comments