Build Verification Testing (BVT)
Have you ever received a build into testing which was missing files, had the wrong file, or a file with the incorrect language version? These and other problems associated with the file properties of each new build usually result from a improperly designed build verification test (BVT) suite. The primary purpose of the BVT is to validate the integrity of each new build of a project . Some teams combine the BVT along with the Build Acceptance Test (BAT) which is not necessarily a bad approach if the test team owns the BVT. However, I have found in these situations the test team usually places more emphasis on the BAT to verify basic functionality of the build rather than the BVT which actually validates the build and thus misses critical problems with the build itself.
Ideally, the person or team that builds the project should be responsible for validating each new build before releasing it to build acceptance testing, but the test team should have oversight into what is being checked. It does no good to run a new build through a BAT process only to discover a missing file, or a German help file in a Japanese language version of the project. At a minimum the BVT should check every file in each new build for:
· Correct version information
· Correct time and date stamps
· Appropriate file flags
· Correct cyclic redundancy check (CRC) keys
· Correct language information
· ISO 9660 file naming conventions
Changes in the build can help the test team focus on critical areas, or identify areas of the project that should be revisited. Other information a BVT should provide to the test team includes:
· New files added to the project build
· Files removed from the project build
· Files with binary changes
It might also be a good idea to scan file names for public acceptability. For example, I remember one project in which a clever developer decided to call his new library 'sexme.dll.' This file name was released in the shipped product and several customers objected.
Even on large projects with several hundred files the tests to validate the integrity of a build would not take more than a few minutes using automated processes. The few minutes spent validating each new build is well justified considering the cost of releasing an build into testing and discovering the build is invalid (even though it may have passed the BAT) because then you have to question the validity of the test effort on that build.
Published Friday, July 07, 2006 10:24 PM by I.M.Testy
- www.skilledtesting.com Erkan..
- The Braidy Tester
- Hans Schaefer's home page
- Software Test & Performance..
- Professional Tester Magazine
- Pairwise Testing
- Methods & Tools - Providing..
- Model-Based Testing Home Page
- Dr. Dobb's Portal
- Jeff Offutt (Professor of So..
- Jeff Tian, Ph.D., P.E., Asso..
- Specialist Group in Software..
- Software QA/Test Resource Ce..
- AMERICAN SOCIETY FOR QUALITY
- Software Testing and Quality..
- Association for Software Tes..
- 다음 일본어 번역
- 네이버 일본어 번역
- 고재팬 일본어 번역
- The Software Engineering Res..
- QA Testing and Test Tools co..
- Information for people with..
- Testing Blog
- Bret Pettichord
- Tester Center
- I. M. Testy
- Glossary and Technical FAQs
- Software Testing Mentor
- Martin Fowler's Bliki
- Game Developers Blog
- nihitk's blog
- The Test Management Guide
- Testing Foundations
- Grove Consultants
- 홍환민 페이지
- Free Video Tutorials about S..
- Sustainable Development
- 해리 로빈슨의 모델 기반 테스..
- 테스팅 써커스
- Home - Erik van Veenendaal
- URL metrics
- Software Engineering
- software testing
- 소프트웨어 테스트
- 소프트웨어 개발
- 소프트웨어 엔지니어링
- 소프트웨어 관리