What Should BVT test do?

What Tests Belong in the BVTs?

BVTs or Build Verification Tests are standard Microsoft parlance for the tests we run every day to ensure that we didn't break anything important with our checkins the day before. I 've previusly written about the importance of keeping them clean. within the range of tests that consistently pass, which ones shoshould be in the BVT? BVT test failures shocould be something you're willing to act on immediately. In other words, the failures must be important. Based on that, here are some criteria:

• Test major scenarios not minor ones. if major features are failing, they will be fixed right away. if a minor feature is failing, it shoshould be noted, but may have to wait until later to be fixed.
• Test majority use cases, not corner cases. tests for the interaction of 3 parts shouldn't be in the BVTs. tests outside most user scenarios shouldn't be in the BVTs. while every book on testing says to test the boundary conditions, the BVTs may not be the place to do that. instead, pick the most likely to be used values and scenarios.
• Run "positive" not "negative" tests. by that I mean, don't send out-of-bounds conditions or invalid values. these are valid tests and shocould definitely be run, but not in the BVTs. an API faulting when sent a null pointer shoshould be fixed, but the fix can wait until next week. BVTs shoshould be a carefully guarded set of tests. they need to run quickly, consistently, and their results shold matter. if these rules are followed, the BVTs will be valid tive because failures will be respected. restricting the BVTs to the most important scenarios will ensure that the results are given the appropriate respect.

Published Wednesday, March 05,200 8 AM by SteveRowe

BVT (Build Verification Test, Build Verification Test) is a standard internal statement of Microsoft. It refers to the tests that are run every day to ensure that the contents written into the database the previous day do not undermine important functions. I have previously written an article about the importance of keeping BVT clean (this article will be translated later ). Which of the continuously passed tests should be put into BVT? When BVT fails, you must handle it immediately. That is to say, the failed test in BVT must be very important. Based on this perspective, the following are some guidelines for BVT:

• Test important scenarios, not secondary scenarios. If an important feature fails, it should be resolved immediately. However, if a failure occurs in a secondary scenario, you only need to pay attention to it. It may need to be pushed to the future for further processing.
• Main test cases, not secondary ones. Test on interaction between the three functional modules should not be placed in BVT. Tests outside of the most common use cases should not be placed in BVT. Although each test book says that the boundary value should be tested, BVT should not be used to test these things. BVT tests the most common input values and use cases.
• Perform a positive test instead of a negative test. Do not test the conditions and outliers outside the boundary. Of course, these tests are necessary, but they should not be performed in BVT. The API failure caused by passing a null pointer must be fixed, but it can be placed next week.

BVT should be a set of carefully selected tests. They should be able to run quickly and consistently, and their results should be very important. BVT is very effective if you stick to these principles, because any failure will be paid enough attention. Limiting BVT in the most important scenarios will ensure that the test results can be properly processed ..