An Admission Ticket to Testing

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

We’ve all been there. We receive a software drop from development that is ostensibly ready for testing then we spend the next three weeks trying to install that software and run it. The reasons why we can’t install, let alone run, the software cover the gamut from missing files and rogue DLLs to database structure incompatibilities and out-and-out bugs. It’s a battle that not only tries our patience but also burns up our test time: You know, the measly few weeks they give you for testing when you should have months.

We’ve all heard of the various types of testingunit, integration, system, compatibility, regression, acceptance, and so on; it is not, however, always clear which of these belong in development and which belong in testing. Even more to the point, it is not clear what test determines whether the software is ready to graduate from development and enter the test organization.

That’s what the Build Verification Test (BVT) is for. If you don’t have one, get one. It will make the difference between doing your job and doing someone else’s.

What is a BVT?

The BVT establishes that the software has sufficient integrity to be tested in the first place. That is, it confirms that the following are true: The software has all its required components, those components are properly linked together, they are accessible, and they are functional. The BVT should be designed to cover the system from beginning to end, but not in depth. When designing a BVT, think inch deep, mile wide,” and you get the idea.

The BVT is sometimes referred to as a smoke test, a nickname that has its roots in the early days of hardware testing. Back then, testers applied electric power to a hardware device to see if it would smoke, spark, or burst into flames. With a BVT, testers are not looking for smoke but for fundamental problems that prevent the software from operating or from performing a critical task. In many organizations, the development team creates smoke tests to ensure that new code has not broken the daily or weekly build.

In my experience, though, the BVT should be something more than a test for dramatic failure. It should ensure that major functions are present and operating as expected. Just because the software doesn’t blow up doesn’t mean it is ready to gosometimes the most dangerous errors occur quietly, without fanfare, such as a failure to make critical calculations or update the database. Moreover, the test organization should develop the BVT, not development, for the same reason you can’t issue your own diploma: If you don’t know what you don’t know, you won’t know it.

What a BVT is For

The test organization has to determine what constitutes an acceptable level of software quality to support the test process. This should not be an exhaustive test, but neither should it be cursory. The best approach is to select one test case out of each category or functional area, usually a positive case that will cause the program to create, retrieve, or update data. This focus on data will assure that the database or other data sources are in sync with the software, and that the test has touched most, if not all, of the underlying tables and files. This process should also invoke middleware and other components that all have to be in harmony.

In addition to making sure you have a test-worthy build, however, the BVT can serve anotherin some cases, more criticalpurpose. It is an embarrassing but undeniable fact that so-called hot fixes are a fact of life in some companies. A hot fix is a correction for a defect so severe that it cannot wait for a regular release cyclewhich also usually means it doesn’t have time to be tested. In that case, the BVT may be all that stands between correcting and exacerbating an already bad situation.

When used for hot fixes, though, the BVT should be applied to an installed system, not a new one, since the software will be shipped to an existing customer. Database conversions, whether of structure or content, can wreak major havoc and cause the loss or corruption of data. Because of this, it’s a good idea to perform a two-level BVT, one for a clean install and one for an existing one.

What It Means

The greatest benefit of a BVT is that it draws a clear line between the testing that is expected from development and that which is expected from the testing organization. Testers can’t cover for inadequate development test practices. That’s unreasonable and unworkable. Every issue found in testing that should have been removed in development takes away the scarce time and resources needed for testing.

While this may sound like a slam against development, it isn’t. In fact, it is a criticism of the rampant lack of definition as to what types of testing are required in development. By creating and executing a BVT, you establish an objective standard. If that standard is not met, at least you know where to look for answers.

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.