Sold to the fine

Software Testing Career Package
 
 
 
© 2015
By Software Testing Help 
 
Note 
–
Smoke testing could be subset of BVT tests. Smoke testing does not focus on finer details 
unlike BVT. 
BVT basics:
●
It is a subset of regression tests run on every new build to verify main functionality. 
●
Typically build verification tests should be executed on daily builds. Build should be rejected if 
BVT fails. A new build is released after the fixes are done. 
●
BVT saves test team efforts to deploy and test the build when major functionality is broken. 
●
Build verification tests should be designed carefully enough to cover basic functionality. 
●
Typically BVT should not run for more than 30 minutes. 
BVT is primarily important for checking for the project integrity and whether all the modules are 
integrated properly or not. Module integration testing is very important, as project development is 
generally divided into modules for different teams. I have seen many cases of application failure due 
to improper module integration.
Main task in build compile process
 
–
Code check-in i.e. including all new and modified project files 
associated with respective builds. BVT was primarily introduced to check initial build health i.e. to 
check whether all new and modified files are included in release, all file formats are correct, every file 
version and language, and flags associated with each file. These basic checks are worth running 
before build is released to test team for further testing. You will save time and money by discovering 
the build flaws at the very beginning using BVT. 
Which test cases should be included in BVT? 
This is very tricky decision to take before automating the BVT task. BVT success mainly depends on 
which test cases you include in it. 
Here are some simple tips to include 
test cases
in your BVT automation suite: 
●
Include only critical test cases in BVT. 
●
All test cases included in BVT should be stable. 
●
All test cases should have known expected result. 
●
All included critical functionality test cases are sufficient for maximum application test 
coverage. 
Do not include test cases in BVT for unstable modules. For some under-development features, you 
a
t predict expected behavior as these modules are unstable and you might have list of known 
failures for these modules. There is no point including test cases in BVT for such modules.