Build Verification Test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly.
The build acceptance test is generally a short set of tests, which exercises the mainstream functionality of the application software. Any build that fails the build verification test is rejected, and testing continues on the previous build (provided there has been at least one build that has passed the acceptance test).
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.
Pro-Tip: For more information on Quality Management in Software Testing, head over here for an informative article on 'Verification and Validation in Software Testing'.
So, build acceptance tests are a type of regression testing that is done every time a new build is taken. Build acceptance tests are important because they let developers know right away if there is a serious problem with the build, and they save the test team wasted time and frustration.
Pro-Tip: If you are looking to launch a career in Software Testing, consider a professional, accredited, globally recognized credential in the domain.
- It is a subset of tests that verify main functionalities.
- The BVT’s are typically run on daily builds and if the BVT fails the build is rejected and a new build is released after the fixes are done.
- The advantage of BVT is it saves the efforts of a test team to setup and test a build when major functionality is broken.
- Design BVTs carefully enough to cover basic functionality.
- Typically BVT should not run more than 30 minutes.
- BVT is a type of regression testing done on each and every new build.
- BVT cases & process should not implemented in hurry.
- Include only stable test cases, which have known expected results and don’t add unstable test cases.
What happens when BVT suite run
- The result of BVT execution is sent to all the email ID’s associated with that project.
- The BVT owner (person executing and maintaining the BVT suite) inspects the result of BVT.
- If BVT fails then BVT owner diagnose the cause of failure.
- If the failure cause is defect in build, all the relevant information with failure logs is sent to respective developers.
- Developer on his initial diagnostic replies to team about the failure cause. Whether this is really a bug? And if it’s a bug then what will be his bug-fixing scenario.
- On bug fix once again BVT test suite is executed and if build passes BVT, the build is passed to test team for further detail functionality, performance and other testes.
Build Verification Testing process
What is process to run the build verification tests?
- Build verification test case should be executed once new build is received.
- If BVT passes then Build should be ACCEPTED & start actual testing activities.
- If BVT fails then Build should be REJECTED.
- Results should be sent to Team Lead or Project Manager.
- Results should be analyzed by Team Lead or Project Manager.
- Find out the root cause of the problem (if any).
- If there is defect then relevant information should be send to respective developers to fix the problem.
- Bug should address to Developer & fix it as early as possible.
- Upon fixing defect, Build verification test case should be executed once new build is received (This is continuous process if build is failed again).
In Build Verification Testing, one needs to check for the integrity of various modules of the application. Checking the integration of various modules is important when different teams work on different modules.
Some Basic Checks
All the new and modified files are included in release,
All file formats are correct,
Every file version and language, and
Flags associated with each file.
Below are some tips to select Build Verification tests
- Include only critical test cases and they should be sufficient for application test coverage
- Add only stable test cases and all the test cases should have known expected results
- Do not include modules in BVT, which are not yet stable
- Set some standards and these standards shall be met only by analyzing major project features and scenarios
- BVT automation scripts needs to be maintained and modified time-to-time. Include test cases when there are new stable project modules available
- Try to automate this process as much as possible – automate everything
- Do not write BVT test cases scripts in hurry
Process for running the build verification tests
- The results are sent to the lead or manager
- Results are analyzed by lead or manager
- The person who runs the tests and lead/manager diagnoses the cause of failure (if any)
- If there is any defect, the relevant information is sent to respective developers
- Developer fixes the bug
Key point to success of BVT
- BVT test cases should not be written in hurry. Spend significant amount of time for writing BVT test cases scripts.
- Only stable test cases should be included to BVT, this will reduce the probability of failing BVT due to unstable area of software.
- BVT process should be automated, try to automate as much as you can.
- Add log details as much as you can so it helps to analyze the BVT pass or fails result. This log will further help developer to fix the defect.