Return to site

TESTING: What is smoke testing? ๐Ÿšฌ

ยท devops
broken image

Smoke testing (also confidence testing, sanity testing, build verification test (BVT), and build acceptance test) is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release.

 

Smoke tests are a subset of test cases that cover the most important functionality of a component or system, used to aid โ›‘๏ธ assessment of whether the main functions of the software appear to work correctly.

 

When used to determine ๐Ÿค” if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test.

 

Alternatively, it is a set of tests run on each new build of a product to verify โœ… that the build is testable before the build is released into the hands of the test team.

 

In the DevOps paradigm, the use of a BVT step is one hallmark of the continuous integration maturity stage.

 

For example, a smoke test may address basic questions likeย 

๐Ÿ‘‰ "does the program run?",ย 

๐Ÿ‘‰ "does the user interface open?", orย 

๐Ÿ‘‰ "does clicking the main button do anything?"ย 

 

The process of smoke testing aims to determine whether the application is so badly broken as to make further immediate testing unnecessary.

 

As the book ๐Ÿ“š Lessons Learned in Software Testing puts it,ย 

"๐˜ด๐˜ฎ๐˜ฐ๐˜ฌ๐˜ฆ ๐˜ต๐˜ฆ๐˜ด๐˜ต๐˜ด ๐˜ฃ๐˜ณ๐˜ฐ๐˜ข๐˜ฅ๐˜ญ๐˜บ ๐˜ค๐˜ฐ๐˜ท๐˜ฆ๐˜ณ ๐˜ฑ๐˜ณ๐˜ฐ๐˜ฅ๐˜ถ๐˜ค๐˜ต ๐˜ง๐˜ฆ๐˜ข๐˜ต๐˜ถ๐˜ณ๐˜ฆ๐˜ด ๐˜ช๐˜ฏ ๐˜ข ๐˜ญ๐˜ช๐˜ฎ๐˜ช๐˜ต๐˜ฆ๐˜ฅ ๐˜ต๐˜ช๐˜ฎ๐˜ฆ ๐˜ช๐˜ง ๐˜ฌ๐˜ฆ๐˜บ ๐˜ง๐˜ฆ๐˜ข๐˜ต๐˜ถ๐˜ณ๐˜ฆ๐˜ด ๐˜ฅ๐˜ฐ๐˜ฏ'๐˜ต ๐˜ธ๐˜ฐ๐˜ณ๐˜ฌ ๐˜ฐ๐˜ณ ๐˜ช๐˜ง ๐˜ฌ๐˜ฆ๐˜บ ๐˜ฃ๐˜ถ๐˜จ๐˜ด ๐˜ฉ๐˜ข๐˜ท๐˜ฆ๐˜ฏ'๐˜ต ๐˜บ๐˜ฆ๐˜ต ๐˜ฃ๐˜ฆ๐˜ฆ๐˜ฏ ๐˜ง๐˜ช๐˜น๐˜ฆ๐˜ฅ, ๐˜บ๐˜ฐ๐˜ถ๐˜ณ ๐˜ต๐˜ฆ๐˜ข๐˜ฎ ๐˜ธ๐˜ฐ๐˜ฏ'๐˜ต ๐˜ธ๐˜ข๐˜ด๐˜ต๐˜ฆ ๐˜ง๐˜ถ๐˜ณ๐˜ต๐˜ฉ๐˜ฆ๐˜ณ ๐˜ต๐˜ช๐˜ฎ๐˜ฆ ๐˜ช๐˜ฏ๐˜ด๐˜ต๐˜ข๐˜ญ๐˜ญ๐˜ช๐˜ฏ๐˜จ ๐˜ฐ๐˜ณ ๐˜ต๐˜ฆ๐˜ด๐˜ต๐˜ช๐˜ฏ๐˜จ".

 

Smoke tests are typically run rapidly ๐Ÿƒ, resulting in speedier feedback, as opposed to performing more complete test suites, which would naturally take considerably longer.

 

The results of this testing are used to determine whether or not a build is stable enough to proceed with additional testing.