1

We usually do smoke tests to check critical functionalities whenever we receive a new build. After executing the smoke tests, we are sure to go to next stage (next level of testing). I heard from my colleagues that smoke tests are really useful when your team employs Continuous Integration and DevOps. Smoke tests are always beneficial, but how it will be more beneficial with the combination of CI and DevOps?

Matthew Schuchard
  • 25,172
  • 3
  • 47
  • 67
Aishu
  • 1,310
  • 6
  • 28
  • 52
  • 1
    I don't understand this question. Smoke tests are useful with CI because they are being automated in the code promotion process instead of manually kicking off the tests and then manually promoting the code. The difference is only manual versus automated. – Matthew Schuchard Nov 25 '16 at 13:16
  • @ Matt Schuchard - But not all the smoke tests are automated right – Aishu Nov 25 '16 at 13:30
  • They would be if they were part of CI. – Matthew Schuchard Nov 25 '16 at 13:31
  • you can’t always anticipate what will happen when your application is pushed live. Smoke tests are designed to reveal these types of failures early by running test cases that cover the critical components and functionality of the application. From https://circleci.com/blog/smoke-tests-in-cicd-pipelines/ – Michael Freidgeim Oct 18 '21 at 21:10

2 Answers2

1

Testing is interesting and every time a new challenge for QA which requires higher level of efforts in the final deployment of product. This consist of continuous delivery in continuous integration environment. In this continuous deployment process, requires testing to be followed in parallel in order to keep the process moving.

1

I've usually heard smoke testing used to refer to manual testing that you run to sanity-check builds. This article defines smoke testing as follows:

Smoke Testing, also known as “Build Verification Testing”, is a type of software testing that comprises of a non-exhaustive set of tests that aim at ensuring that the most important functions work. The results of this testing is used to decide if a build is stable enough to proceed with further testing.

First, I would certainly hope that people are doing this whenever they check code into the main branch to ensure that their changes didn't break the software in some obvious way. That holds whether you're doing continuous integration or not. (One of my personal pet peeves has always been people who check in code and then leave for the day without checking to make sure that it worked).

Also, keep in mind that in a typical CI cycle nowadays a build will often occur with every checkin to the main branch (or, at a minimum, there will be a nightly automated build; at my current company we have both), so you don't really have time to manually run your entire test suite for every build. One of the main purposes of CI is to have integration (and, as an extension, builds) occur much more frequently than is typical in other kinds of development cycles.

As one final comment: if you're doing continuous integration, I'd strongly encourage you to have some kind of automated testing (e.g. coded UI tests, unit tests, etc.) as part of that. Those can provide basic smoke/sanity testing and regression testing and reduce the burden of having to do all of it manually for every build.