What are different characteristics of smoke testing?

Smoke testing is considered to be one of the preliminary software testing techniques to further testing that are intended to reveal simple failures that are simple enough to be a cause of a software project to be rejected. 

In the term “smoke testing”, smoke is used as a metaphor. All the test cases that are known to provide coverage to most important functionality of a component of the software system or application are selected and grouped under a set and later are run. This is basically done to ascertain that the most crucial functions and features of the software system and application are working as desired or not! 

One can understand smoke testing better by having a look at the below mentioned questions:

1. Does the program run?
2. Does clicking the start button do anything?
3. Does the program run?

Goals of Smoke Testing

- The primary goal of the smoke testing is to determine if the problem or fault in the software system or application is so worse that any further testing on that software system or application will be a waste. 

- To put it simply, the smoke testing can be considered to be a cheap and less time consuming way to broadly cover the features and functionalities of the software product in a limited period of time. 

- By carrying out smoke testing, you can easily find out if any of your software system’s or application’s key feature or functionality is broken at some point and so your development team would not spend further time on it fixing or recreating it. 

People often confuse between the two similar terms i.e., smoke testing and build verification test. No doubt both are one and same the only thing when the smoke testing is performed on a build it called build verification test.

When should smoke testing be performed?

- One of the best practices of software testing is that the smoke testing should be performed everyday without fail. 

- Furthermore, the smoke testing can also be performed by the testers before accepting a module or build for further testing.

- Some testing has been listed as the most cost effective method for the identification and fixation of the defects in a software system or application after the code reviews by the software giant Microsoft Corporation. 

- The smoke testing is deployed as a process for the validation of the changes that have to be in the code before they are passed on to the source control in the Microsoft Corporation. 

- The smoke testing has to be carried out either automatically or manually that is purely the choice of the tester.

- When the smoke testing is carried out manually, the process goes on normally but when the automated tools are used, the tests that have to be carried out are initiated during the same process through which the build is generated. 

Smoke tests have 2 types as mentioned below:

1. Unit tests: Smoke tests under this category are known to exercise the sub routines, object methods and individual functions and so on.
2. Functional tests: These types of smoke tests are known to exercise the complete program along with various inputs.

Both the above mentioned type of smoke testing tools together make up a third party product that falls out of the compiler suite. 

A scripted series of program inputs form a function test and some may also have an automated mechanism. On the other hand the unit tests may be formed out of the separate functions that lie within the code. They can even be a driver layer that might be linked to the code. The smoke testing in software can be compared to the smoke testing in hard wares. 

What are different characteristics of build verification test?

Build verification test is often abbreviated as BVT and can be defined as a set of tests that are carried out on all the builds that are newly built in order to verify if those builds are testable or not before they are transferred to the testing team for their further testing. 

Generally, the test cases used in build verification test are considered to be the core functionality test cases which are used to keep the stability of the software systems or applications in check and regulate their testing thoroughly. 

The whole process of build verification test takes a whole lot of efforts and time if carried out manually and therefore the whole process is usually automated. If a build fails the build verification, then the same build is again returned to the developer to fix the faults. 

There are other names also by which the build verification test is known as mentioned below:

1. Smoke testing
2. Build acceptance testing or BAT

In a typical build verification test, there are two aspects that are exclusively tested and are mentioned below:

1. Build acceptance
2. Build validation

Few basics of Build Verification Tests

1. Build verification tests are a sub set of tests that are used for the verification of the main functionalities.
2. Some build verification tests are created on a daily basis and some builds are daily tested and if those builds fail the build verification test, they are rejected and returned back to their developer for making the fixes and when the fixes have been done, a new build is released and is gain subjected to the build verification test.
3. The build verification test has an advantage that it saves the precious efforts of the testing team that are required for setting up a test and testing a build whenever there is a break in the major functionality of the build.
4. The test cases of the build verification test should be designed very carefully so that they provide the maximum possible coverage to the basic functionality of the build.
5.  A typical build verification test is run for 30 minutes maximum and not then this limit.
6. The build verification testing can also be considered as a type of regression testing that is done on each and every build that is new.

Aim of Build Verification Test

- The primary aim of the build verification test is to keep a check on the integrity of the whole software system or application in terms of its build or we can say modules.

- When several development teams are working together on the same project, it is important that the modules that they are developing individually have got good ability for integrating with each other since this is very important. 

Till now so many cases have been recorded in which the whole project failed miserably due to a lack of integration among the modules. There are some worst cases also in which the whole project gets scraped just because of the failure in the module integration. 

- The build release has got a main task i.e., file check in i.e., including all the modified as well as new project files associated with the corresponding builds. 

- Earlier checking the health of the building initially was considered to be the main task of the build verification test. 

- This is called as “initial build health check” and it includes:

1. Whether or not all the files have been included in the release or not?
2. Whether all the files are in their proper format or not?
3. Whether all the file versions and languages have been included or not?
4. Whether the appropriate flags have been associated with the file or not?

What is build verification testing technique?

Build verification test is often abbreviated to “BVT”. This test is more commonly known as “build acceptance test”. We can make out from the term itself that this test consists of test cases that are executed on the build of a software product in order to verify that the build of that particular software system or application is testable before the software product is passed on to the testing team for testing.

ABOUT BUILD VERIFICATION TEST
- The main build verification test consists of smaller test cases and these test cases exercise the functionality of the mainstream of the software system or application.
- Any further testing on a build is performed only if it passes the build verification otherwise it is simple rejected.
- In the place of this build, the testing is continued to be carried up on the previous one.
- There should be at least one build that should pass the build verification test.
- Build verification is important to be carried out prior to the commencement of the testing phase.
- It tells the software developers whether the build of the software has been rightly developed or not.
- It also tells if the build is having any major issue.
- A build verification test also avoids time being wasted by carrying out unnecessary testing on the faulty builds.
- A typical build verification test is usually automated.
- When a build is rejected during the build verification test, it is again revered back to the software developer for correcting it.

Build verification test is also called by another name “smoke testing”. In build verification testing two aspects are mainly checked:

1. Build acceptance
2. Build validation


BASIC THINGS TESTER SHOULD KNOW ABOUT BVT

1. A build verification test consists of many smaller sub tests and each one of these tests verifies one functionality of the software system or application.
2. Build verification tests are very effective in saving the efforts of the testing team.
3. The build verification testing methodology can be used to test a build even if its major functionality are not working or are broke.
4. The build verification tests are designed very carefully so as to make them cover a major part of the functionality and features.
5. A certain time limit has been set for the build verification test to 30 minutes.
6. The testing time for running build verification should not exceed this limit.
7. Build verification testing is somewhat similar to the regression testing in the way that it is carried out on each and every build.
8. Build verification test is a way to test the integrity of the software project.
9. It checks whether or not all the modules have been integrated well with each other or not.
10. Maintenance of integrity between the modules is very important since any lag in the cooperation can cause the whole system to go bizarre.
11. Initially, the build verification testing technique was employed to check whether or not all the new features, functionality and modules have been included in the project to be released or not.
12. It also checks for the correctness of the formats of the included files.
13. Even the flags associated with a file are checked.
14. You should be very careful while deciding what all the test cases have to be carried out under the build verification test.
15. Your build verification test must include all the critical test cases and these test cases should not be unstable.
16. Another point to be kept in mind is that you should have an idea of the result of the test cases that you are including in the BVT.