Before diving into complex testing, it's crucial to ensure that the basics work. That's where smoke testing comes in – a quick, high-level check of the most essential features.
Let’s explore what smoke testing is, when to use it, and why it’s an essential part of the software development process.
What is smoke testing?
Smoke testing, often referred to as build verification testing or confidence testing, is a type of software testing conducted to determine whether the basic functions of a software build work as expected. It is often performed after a new build is created and before it is subjected to more rigorous testing.
What is smoke testing
Smoke testing is shallow by design, focusing on quickly checking the core functionality of a build. It covers a broad range of essential features, such as login or basic navigation, without diving deep into each one.
For example, smoke testing might include checks like
- Can the application launch?
- Is the homepage loading properly?
- Does the search bar return results?
- Does the system respond to a button click?
While smoke testing isn't exhaustive, it offers valuable insights into the software's overall stability and is a crucial component of any testing strategy.
The term "smoke testing" comes from the old practice of using smoke to detect leaks or defects in pipes and machinery. Common in plumbing and manufacturing, it highlighted problem areas by showing where smoke escaped.
Later, the term was jokingly used to refer to the first power-on test of new hardware in electronics, when a device was tested by powering it on and checking if smoke came out (indicating a major fault).
Why is smoke testing important?
Smoke testing is crucial because it quickly identifies major issues in the software, ensuring the build is stable enough for more detailed testing. By catching critical problems early and providing fast feedback, it saves time and resources, preventing deeper tests on a broken or unreliable build.
Think of it like planning to bake a cake and checking if the oven turns on. Before you spend hours mixing ingredients and perfecting the recipe, you want to make sure the oven is working. If it doesn't turn on, there's no point in continuing – just like in software testing, you check the basics before diving into the details.
Who does smoke testing?
The responsibility for smoke testing may differ depending on the team structure, project needs, and the development methodology in use.
Quality assurance testers. Typically, QA teams conduct smoke tests after a build is released to a testing environment to ensure the software meets basic stability requirements for further testing.
Software developers. In Agile and DevOps environments, developers can sometimes perform smoke tests on their own code to ensure core functionalities are not broken before committing the code.
IMHO developers 'should' ideally do it. It might be due to the fact that I have been a tester most of my life. It sucks when a system build reaches you and even the home page does not load. I think developers have a moral responsibility to at least turn on the engine once to see that the car starts.
Automated systems. Modern Continuous Integration/Continuous Deployment (CI/CD) tools can automatically execute predefined smoke test scripts, providing rapid feedback and blocking unstable builds from proceeding further.
When to do smoke testing?
Smoke testing should be performed as the first step of the QA process, before moving on to more detailed tests like regression or functional testing.
After a new build. This is the most common and important case. Whenever a new software build is deployed, whether a patch, feature update, or major release, do smoke testing to ensure the basic functionality works.
Post-bug fixes or feature additions. After developers fix bugs or add new features, smoke testing ensures that the core system is still working as expected and no major issues were introduced during the changes.
After system integrations or upgrades. When integrating new systems or upgrading existing ones, smoke testing checks that the integration works and doesn’t break essential system functionalities.
Before production deployments. Before releasing a new version of software to users, smoke testing checks that critical functionality is operational in the live environment. But again, it doesn’t replace other types of testing.
Always smoke test before going live. Source: ConfigCat Blog
Smoke testing vs sanity testing
Smoke testing is often confused with sanity testing, but there’s a difference. While smoke testing is used to check if the basic, critical features of the application work, sanity testing is done later, to ensure that the specific areas affected are working correctly after a particular bug fix or a new feature.
Both are shallow tests but differ in scope. Smoke tests check the overall system's core functionality, while sanity tests are more targeted, focusing on areas that have changed.
Smoke testing vs regression testing
Smoke testing is sometimes mistaken for regression testing as well, but that’s not correct. Regression testing involves thoroughly testing the application to ensure that new changes or features haven't introduced bugs or affected existing functionality.
Regression tests are more detailed and cover a broader range of scenarios to ensure the system behaves as expected after updates, whereas smoke testing is a quick, high-level check.
Smoke testing vs sanity testing vs regression testing
Automated vs manual smoke testing
Smoke testing is generally the first candidate for automation.
In modern environments, smoke testing is often automated and run on every new build or integration. Automated smoke tests are faster, more scalable, and more reliable, especially when testing needs to be repeated often for multiple versions or environments.
Manual smoke testing is most common in early-stage startups with small teams and without automation setup, for UI-centric apps with frequent design changes, or in cases of critical builds requiring human validation.
A hybrid approach is also possible. For example, it might make sense to automate core flows that don’t change often (e.g., login), but test new features or design updates manually.
How to implement smoke testing
Smoke testing is usually relatively straightforward. Here are the main steps.
Identify core features. Start by identifying the most important functions and workflows that the product must perform, such as
Create simple test scenarios. Develop test cases or scripts that test the basic functionality of each core feature. The tests should be simple and quick to execute.
For example, it can be testing whether all pages load correctly or whether a login form can accept valid credentials and redirect to the dashboard.
As Anna Pikula shared, “The number depends on the number of critical features (the complexity of the system) and whether testing is automated. For a simple app, it could be 5-10 scenarios.”
Automate smoke tests (if possible). If you operate in a CI/CD environment, once you’ve developed test scenarios, develop automated scripts to run your smoke tests automatically with each new build.
Log and track results. After running the tests, log the results and track any failures. Automated tools should generate clear reports, helping the development team quickly identify whether the build is ready for further testing or requires fixes.
Smoke testing example
To better understand how smoke testing works in practice, let's explore some real-world examples with typical applications.
For a messaging app, a smoke test might check:
- App launch: Does the app open without crashing?
- Login: Can the user successfully log in with valid credentials?
- Send message: Does the user successfully send a text message to a contact?
- Receive message: Can the user receive a message from another contact?
- Basic navigation: Can users navigate chat threads and settings without issues?
For an eCommerce app, a smoke test might check:
- App launch: Does the app open and load the homepage?
- Product search: Can the user search for products and view results?
- Add to cart: Can the user successfully add an item to the shopping cart?
- Checkout process: Can the user proceed to checkout and select a payment method?
- Order confirmation: Does the app display an order confirmation after purchase?
For a travel booking app, a smoke test might check:
- App launch: Does the app open and load the home screen without crashing?
- Search functionality: Can users search for flights, hotels, or rental cars?
- View search results: Does the app display relevant results for the selected criteria (e.g., flight dates, destination)?
- Booking process: Can the user successfully select a flight or hotel and proceed to the booking page?
- Payment process: Does the app allow users to input payment details and confirm bookings?
All these basic checks ensure the core functionalities are working before deeper testing is done.
Best practices of smoke testing
Summing up, here are a few final tips for the most effective smoke testing.
Do it early and often. Better safe than sorry. Smoke testing at the early stages can help save time later.
Keep it simple and fast. Smoke testing should be quick and easy to execute, with minimal setup. The goal is general validation, not exhaustive testing.
Focus on critical paths. Limit the test scope, and focus on the critical functionalities rather than trying to test every feature. Prioritize test cases that cover the most essential user journeys or high-risk areas.
Define clear pass/fail criteria. The outcome of a smoke test should be a clear "go" or "no-go" decision for further testing.
Automate whenever possible. Automation ensures that every new build is quickly checked without manual intervention and can be integrated seamlessly into the CI/CD pipeline.
Maintain and evolve the test suite. Regularly update tests to reflect changes and additions to the application's core features.
Smoke testing is an essential first step in software testing that helps identify major issues early on in the development process. It’s a cost-effective and quick way to verify a build's stability before spending time and resources on more comprehensive testing. By focusing on core functionalities and integrating smoke testing into a continuous integration pipeline, teams can ensure that only stable builds proceed to more rigorous stages of testing.
Maria is a curious researcher, passionate about discovering how technologies change the world. She started her career in logistics but has dedicated the last five years to exploring travel tech, large travel businesses, and product management best practices.
Want to write an article for our blog? Read our requirements and guidelines to become a contributor.