11 Quick Tips to Master Smoke Testing

Definition – “Smoke testing is a type of software testing in which the most important functions are tested to ensure that they work properly. Smoke testing, also known as ‘Build Verification Testing’, comprises a set of non-exhaustive tests that verify that the build is stable enough for further testing.”

Of all the varied and different software testing practices out there, Smoke Tests are my favourite.

You may be wondering why I picked Smoke Testing above all else.

I’ll tell you why in this post.

Before we get into that, however, let’s have a quick refresher about Smoke Testing. We’ll also then touch upon common tips and tricks to get the most out of your smoke test efforts.

What is Smoke Testing?

“If you plug it in, and smoke comes out…”

Well, this line pretty much sums up what a smoke test intends to do. Smoke Tests are a kind of basic, non-extensive software testing practice, where you put the code developed so far through fundamental, ‘happy path’ use cases to see if the system breaks.

If it does, you go back to fixing the system because it is in no way, shape or form ready for more extensive and scientific testing. And if it doesn’t, you know you’re on track and that the fundamental features the system is designed to provide, work.

That’s smoke testing in a nutshell for you, my friend. It’s as simple as – at any given point in time – putting the product built thus far through a rudimentary series of happy path tests, to help bring out the simple yet critical bugs.

“It’s as simple as – at any given point in time – putting the product built thus far through a rudimentary series of happy path tests, to help bring out the simple yet critical bugs.”

Smoke tests are designed to check (and check quickly) that the most critical functions work. Achieving a level of certainty about the basic but fundamental functions of a product or system enables the project team to move forward.

Understanding Smoke Testing

Smoke testing is a type of preliminary software testing that is used to test whether the software is stable or not. It is a subcategory of test cases that aims to assess the core functions of the software. This then determines whether the build is stable enough to run further, more in-depth tests on.

Smoke tests could also be a specific set of tests that are run on each new build of the software to ensure its functionality before the testers implement their other testing methods.

This type of testing is generally done manually, but it can be automated. Once completed, the software build is sent to the QA team who will perform tests on its critical functions. If the tests fail, it will be sent back to the development team for fixing. In automated smoke testing, pre-recorded tests run on the build and record whether the functions work or not.

Why is Smoke Testing my favourite?

Because of the inherent simplicity of this software testing practice. Within a short span of 30 to 60 minutes, you can in effect test and bring out the most impactful of bugs ailing a piece of code. The developer can quickly get back to their desk, and get on with fixing said bugs without having to wait for a long-drawn testing phase.

“Within a short span of 30 to 60 minutes, you can in effect test and bring out the most impactful of bugs ailing a piece of code.”

And, the clincher – anyone can do Smoke Testing.

Can be the tester, the BA, the Project Manager, and most importantly, can be the developer. So you don’t have to wait to schedule a test phase and for testing resources to be available. If you know how to interact with a PC or mobile device, you’re pretty much set to do smoke testing.

Now that we have established the basics about Smoke Testing, let’s dive in and take a look at some neat ways to master the smoke test, and maximise the value you get out of it.

 

#1 Use Smoke Tests during the early stages of a project or product

Now that’s quite self-explanatory. By nature, smoke tests help you nab the easy to find but critical bugs that block your team’s progress. And such issues usually occur during the first few Sprints of a project, or when you’re in the initial phases of building a new product.

You have other testing practices that can provide better value during the later phases of your product or project build. More on this later.

#2 Record all your smoke tests

Again, not much I need to say to explain. Record your smoke tests. It’s good practice. And it will provide you reliable data. Tips #6 and #7 will explain how recording helps.

#3 Smoke tests should be quick – less than 60 minutes at most.

The intention with Smoke tests is to catch those bugs that block development progress during the initial stages of a project. Your goal should be to get the developer to resume development as quickly as possible, without having to wait for complex, drawn out test phases.

“Your goal should be to get the developer to resume development as quickly as possible, without having to wait for complex, drawn out test phases.”

You need to be thinking about 30 minutes – or at most 60 minutes – as duration of Smoke Tests. Any longer, and you can be sure something is wrong. Either the code is of such poor quality, or your test cases aren’t simple enough.

So, aim to conduct mainly ‘happy path’ tests that execute the fundamental customer journeys a product or the particular product feature aims to provide.

#4 You can conduct Smoke Tests every day, every sprint, every release

It’s as simple as that. And it all depends on how much ‘new’ stuff you’re putting into your product, and at what rate. In Extreme Agile environments, and if you have Continuous Integration and DevOps, well, go for as many smoke tests as you like or need.

The key determinant of your smoke testing frequency is how frequently you’re able to add substantially new stuff to your product.

#5 Difference between Sanity Testing and Smoke Testing

They’re not the same – no they’re not.

Sanity Testing is Smoke Testing’s cousin, once removed. That is, Sanity Tests happen slightly later in the product lifecycle, and mainly as a safety net to check whether intended enhancements and bug fixes have been completed as expected.

So Sanity Tests have a much more specific scope compared to Smoke Tests, and happen later in the project or product lifecycle. If you are interested to learn more, the link above describes the differences in greater detail.

#6 Maintain a test case repository

Chances are, 90% of your team are working on projects that bring new features to or transform an established product. They, and you, can help yourselves tremendously by maintaining a test case repository.

On Agile or Extreme Agile projects, this can amount to simply documenting test cases as you go, and organising them with regular reviews to ensure a lean but comprehensive repository exists to draw from.

When you do this, test planning becomes a breeze. You can simply ‘subscribe’ to the relevant test scenarios and test cases under them without having to go through the long and arduous process of creating new test cases from scratch.

#7 Automate where possible

The keyword is – ‘where possible’.

I’ve previously covered the benefits of robust Case Management in detail. And automation as well. When put together, good Case Management and adequate automation can help you get through some basic testing up to 50 times faster, saving your team a ton of time over the long run.

#8 Use Smoke Tests to decide whether the code is ready for more advanced testing.

“If your code is failing the most basic of tests, if the most fundamental journeys cannot be completed easily, then you don’t have a cat in hell’s chance of going through a productive test cycle.”

Smoke tests can help you provide a quick sense check of your code quality before you put it in front of testers.

If your code is failing the most basic of tests, if the most fundamental journeys cannot be completed easily, then you don’t have a cat in hell’s chance of going through a productive test cycle. So use quick Smoke Tests to determine if your code is good enough to move to the next stage.

#9 Use Smoke tests to test the most basic but critical functionality

We’ve covered this above. Still worth reiterating.

Smoke Tests help you check if the most fundamental but critical functionality before you can move any further – whether moving further implies writing more code, or passing on to testers for in depth testing.

For the more comprehensive tests, you have Traditional, Exploratory  and other tests to leverage.

#10 Traditional testing is necessary to deliver a finished (and polished) product to customers

Smoke tests do not cater to the finer details of a product. If you’re looking to make a system almost completely bug-free, then smoke tests aren’t the only course of action.

Traditional Test cycles help you catch most bugs, mainly by scientifically testing the code. They provide unmatched coverage and depth, and can help catch some of the most difficult to catch bugs in production – those that annoyingly (and surprisingly easily) surface during customer usage.

#11 Anyone can perform smoke testing

That’s the beauty of Smoke Tests. Anyone can do it. Smoke Tests take very less preparation and effort to plan and execute, but can provide a surprising bevy of benefits to speed up effective bug fixing.

“In a lot of cases, you are doing Smoke Testing – you just don’t address it by that name.”

A developer can perform smoke testing before releasing a build iteration to test. By testing the most critical functions before releasing the code to testing team, you can catch the most annoying but easy to fix bugs. This helps testers channel their skills into catching the more complex ones.

Smoke Tests are especially useful when your team employ Continuous Integration and DevOps. In a lot of cases, you are doing Smoke Testing – you just don’t address it by that name.

Now It’s Your Turn

Smoke tests offer a simple, straightforward yet supremely effective option to speed up your bug fixing efforts. Developers and others alike can use Smoke tests in software projects, and can dramatically improve code quality.

Consider Smoke Tests as a standard part of your software testing process. Your team will be better with it than without.

Share your views about Smoke Testing and give some smoke test examples in the Comments section below.