Build Verification Test

Testing aimed at determining whether a released version meets the quality criteria for the start of testing. In its purpose, it is an analog of Smoke Testing, aimed at accepting a new version for further testing or operation. It can go deeper, depending on the quality requirements for the released version.

Build Verification Test (BVT), like smoke testing, is aimed at the preliminary verification of the software product being developed before launching full-scale testing of all parameters conducted by the QA team. It is carried out in order to know – whether the release is ready for a software development stage such as Testing, or whether it still needs further work.

Build verification testing consists of a set of short tests that determine the readiness of the build.

The main task of this type of testing is to save the testing team's time in case the release has serious problems with its readiness for the full testing cycle.

Build verification testing is a set of tests run with each new build to make sure the build is testable before it is handed over to the testing team for further testing. These test cases are test cases for the core functionality that ensure the stability and the ability to thoroughly test the application.

The build acceptance test is usually a short set of tests that checks the core functions of the application software. Any build that fails the build verification test is rejected, and testing continues on the previous build (provided that at least one build has passed the acceptance test).

This is a set of tests run for each new build of the product to make sure the build is testable before the build is handed over to the testing team.

So, build acceptance tests are a type of regression testing that is performed every time a new build is created. Build acceptance tests are important because they immediately tell the developers if there is a serious problem with the build, and they save the testing team time and frustration.

A software build is the initial working version of a software product, created by integrating the source code into a software artifact . This build may or may not need improvement, depending on its stability, in order to pass through the further testing process.

Build Verification Test (BVT) is a set of tests that is run for each new software build to assess and verify its readiness to withstand and pass more thorough and rigorous testing procedures. This type of test checks the core functions of the build and, accordingly, declares the status of the build in terms of acceptance or rejection for further testing actions.

Since BVT confirms the stability of the build and at the same time ensures the acceptance of the build, this testing is also known as Build Acceptance Testing . It is worth mentioning here that BVT is simply another name for smoke testing . Build verification testing, build acceptance testing, and smoke testing are three different names for the same testing methodology.

Why Is a Verification Test Needed?

It cannot be guaranteed whether a newly developed software build will be stable enough for further testing or not. The testing team invests a lot of effort and time in defining, preparing, and executing test plans and cases for the software build in order to improve its quality. However, all this hard work by the testing team is thrown off track when, at a later stage, it turns out that the build is unable to withstand the further rigorous testing process because it lacks stability and core functions.

BVT checks and confirms the stability of the build and ensures its acceptability for further testing. This helps avoid wasting the valuable time and genuine effort of the testing team working on a relatively unstable build.

How Is Build Verification Performed?

BVT consists of a small set of test cases, so that they can be executed in the shortest possible time in order to assess the basic and core functions of the build. It begins as soon as a new build is received. The step-by-step process for executing the build verification test is described in detail below:

• As soon as the build is received, BVT cases are prepared based on the specified core functions of the software application.
• The developed built-in verification test scenarios are executed on the build.
• If the build passes BVT, it is considered ready for further testing.
• If the build fails BVT, it is rejected and considered for further improvement.
• The BVT results are reported to the team lead or the project manager.
• These results are evaluated by the team lead or the project manager in order to trace the root cause (if any) of the build failure.
• If defects are found, the build is passed to the developer along with a report of the defects and issues.
• The developer needs to fix these defects or issues as soon as possible.
• After the bug is fixed, the new modified build is ready to be used for BVT again.

Key Points About Build Testing:

Some of the notable features of BVT:

• It is also known as build acceptance testing and smoke testing.
• It is performed with every new build.
• The software build is not handed over to the testing team for further testing until it passes BVT.
• Either the developer or the tester performs BVT.
• Sufficient time must be allocated for writing stable test cases, since unstable test cases will not perform better in this test.
• Automation is preferred for executing BVT cases.
• Test cases have a shorter duration and can be measured in minutes instead of an hour. Usually, the duration of most cases is about 30-45 minutes.
• In addition to build defects, other likely causes of failure can be infrastructure problems or hardware failures.

BVT Basics

• It is a subset of tests that check the core functions.
• BVT is usually run on daily builds, and if BVT fails, the build is rejected, and after the fixes are made, a new build is released.
• The advantage of BVT is that it saves the testing team's effort in setting up and testing the build when the core functionality is broken.
• Design BVT thoroughly enough to cover the basic functionality.
• Usually, BVT should not last more than 30 minutes.
• BVT is a type of regression testing conducted for each new build.
• BVT cases and the BVT process should not be implemented in a hurry.
• Include only stable test cases for which the expected results are known, and do not add unstable test cases.

What Happens When the BVT Suite Is Run

• The result of the BVT run is sent to all the email addresses associated with this project.
• The BVT owner (the person who runs and maintains the BVT suite) checks the BVT result.
• If BVT fails, the BVT owner diagnoses the cause of the failure.
• If the cause of the failure is a defect in the build, all the relevant information along with the failure logs is sent to the relevant developers.
• During the initial diagnosis, the developer responds to the team about the cause of the failure. Is it really a bug? And if it is a bug, what will its fix scenario be.
• Once the bug is fixed, the BVT test suite is run again, and if the build passes BVT, the build is handed over to the testing team for further detailed functionality, performance, and other testing.

The Build Verification Testing Process

What is the process for running build verification tests?

• The build verification test case should be executed after a new build is received.
• If BVT passes, then the build should be ACCEPTED and the actual testing activities should begin.
• If BVT fails, the build should be REJECTED.
• The results should be sent to the team lead or the project manager.
• The results should be analyzed by the team lead or the project manager.
• Find out the root cause of the problem (if any).
• If there is a defect, the relevant information must be sent to the relevant developers to resolve the issue.
• The bug should be brought to the developer's attention and fixed as early as possible.
• After the defect is fixed, the test case for build verification should be executed after a new build is received (this is a continuous process if the build fails again).

In Build Verification Testing, it is necessary to check the integrity of the various modules of the application. Verifying the integration of the various modules is important when different teams are working on different modules.

Some Basic Checks

All new and modified files are included in the release,

All file formats are correct,

The version and language of each file, and

The flags associated with each file.

Below are a few tips for selecting build verification tests.

• Include only critical test cases, and they should be enough to cover the application with tests.
• Add only stable test cases, and all test cases must have expected results
• Do not include modules in BVT that are not yet stable
• Set some standards, and these standards should only be followed by analyzing the core characteristics and scenarios of the project.
• BVT automation scripts need to be maintained and modified from time to time. Include test cases when new stable modules of the project become available
• Try to automate this process as much as possible - automate everything
• Do not rush when writing BVT test case scripts

The Process for Running Build Verification Tests

• Results are sent to the lead or manager
• The results are analyzed by the lead or manager
• The person who runs the tests and the lead/manager diagnose the cause of the failure (if any)
• When a defect is found, the relevant information is sent to the relevant developers.
• The developer fixes the bug

As soon as the bug is fixed; the BVT test suite is run again. This process is repeated for each new build.

Key Success Factor for BVT

• BVT test cases should not be written in a hurry. Spend a significant amount of time writing BVT test case scripts.
• Only stable test cases should be included in BVT, this will reduce the likelihood of BVT failing due to an unstable area of the software.
• The BVT process should be automated, try to automate as much as possible.
• Add as much detail as possible to the log, so that it helps analyze the result of BVT passing or failing. This log will further help the developer fix the defect.

See Also

• Smoke Testing
• Regression Testing