Don't Forget the DBU Test!

The test plan review had gone pretty well. There were a few yawns, some disagreements, but mostly there were heads nodding in agreement. We had defined a large, detailed set of tests to verify individual functions, system end-to-end performance, and non-functional aspects such as security, scalability, and usability. The review was just ending when someone mentioned: 

"Don't forget the DBU test."

My mind did a quick search of its RAM. "DBU test?" What could this be? Distributed Buffer Unit? Detached Binary Union? Dastardly Bad Unicode? Didn't Break Unix? Nothing made sense. What the heck is a DBU I thought to myself? Finally, I had to ask for an explanation of the what the term "DBU" meant.

The answer was simple:  "It's the Don't Blow Up test. You know, the first test you run to prove that the software under test is actually solid enough to be fully tested. Just try a few things and make sure that it doesn't blow up."

At that point, it dawned on me that we actually had a hole in our test planning. We had defined the CLASSES of tests that we wanted to execute, but we had failed to define the SEQUENCE in which we would run the tests. The DBU test was really another name for a smoke test or an acceptance test. The idea behind this is simple, before attempting a full cycle, where you may have to setup/install/configure a large number of systems, you first perform a small test to verify that the software under test is stable enough to support extensive testing. 

It's a good approach to follow, especially early in a product test cycle when new features are not yet stable, and when your test activities are moving from planning to execution. It may seem like an overly casual approach, but as is the case with exploratory testing, it does require forethought and organization. You don't want to randomly "try a bunch of things." You want to define a set of quick tests that will exercise a majority of the major features of the software under test. If the software can pass this initial wide, but shallow test, then it is at least stable enough to support deeper testing. 

So, a good first question to ask is, did it blow up? If the answer is 'no,' then you can move on. In other words, always start with the DBU test. 

Special thanks to Burr for inspiring the DBU!