Smoke tests or build acceptance tests constitute a special family of tests that are traditionally used as early sanity checks by QA teams.
The use of the word smoke alludes to the old adage that wherever there is smoke, there is also fire. These checks are explicitly designed to identify early warning signals that something is wrong. It goes without saying that any issue uncovered by a smoke test is treated by the QA team as a show-stopper; if smoke tests fail, no further testing is performed. The QA team reports its findings to the development team and waits for a revised release candidate to be submitted for testing.
Once the smoke tests successfully pass, the QA team proceeds to run their suite of functional tests before giving the green light for release. The following diagram summarizes the process of running smoke tests for QA purposes:
When it comes to execution, smoke tests are the exact antithesis of functional tests. While functional tests are allowed to execute for long periods of time, smoke tests must execute as quickly as possible. As a result, smoke tests are crafted so as to exercise specific, albeit limited, flows in the user-facing parts of a system that are deemed critical for the system's operation. For example, smoke tests for a social network application would verify the following:
- A user can login with a valid username and password
- Clicking the like button on a post increases the like counter for that post
- Deleting a contact removes them from the user's friends list
- Clicking the logout button signs the user out of the service
The responsibility for authoring, evolving, and maintaining smoke tests usually falls on the shoulders of the QA team. Consequently, it makes sense for the QA team to maintain smoke tests in a separate, dedicated repository that they own and control. An interesting question here is whether the QA team will opt to execute the smoke tests manually or invest the time and effort that's required to automate the process. The logical, albeit slightly cliché, answer is: it depends...
At the end of the day, the decision boils down to the size of the QA team, the individual preferences of the team's members, and the test infrastructure that's available and is at the team's disposal. Needless to say, automated smoke tests are, hands down, the recommended option since the QA team can efficiently verify a plethora of scenarios in a small amount of time. On the other hand, if the build release frequency is low, you could argue that doing manual smoke tests has a smaller cost and makes better use of the QA team's time and resources.