Dynamic Black-Box Testing: Testing the Software While Blindfolded

Testing software without having an insight into the details of underlying code is dynamic black-box testing. It's dynamic because the program is runningyou're using it as a customer would. And, it's black-box because you're testing it without knowing exactly how it workswith blinders on. You're entering inputs, receiving outputs, and checking the results. Another name commonly used for dynamic black-box testing is behavioral testing because you're testing how the software actually behaves when it's used.

To do this effectively requires some definition of what the software doesnamely, a requirements document or product specification. You don't need to be told what happens inside the software "box"you just need to know that inputting A outputs B or that performing operation C results in D. A good product spec will provide you with these details.

Once you know the ins and outs of the software you're about to test, your next step is to start defining the test cases. Test cases are the specific inputs that you'll try and the procedures that you'll follow when you test the software. Figure 5.1 shows an example of several cases that you might use for testing the addition function of the Windows Calculator.

Figure 5.1. Test cases show the different inputs and the steps to test a program.

NOTE

Selecting test cases is the single most important task that software testers do. Improper selection can result in testing too much, testing too little, or testing the wrong things. Intelligently weighing the risks and reducing the infinite possibilities to a manageable effective set is where the magic is.

The rest of this chapter and much of the rest of the book will teach you how to strategically select good test cases. Chapter 18, "Writing and Tracking Test Cases," discusses the specific techniques for writing and managing test cases.

USE EXPLORATORY TESTING IF YOU DON'T HAVE A SPEC

A professional, mature software development process will have a detailed specification for the software. If you're stuck in a big-bang model or a sloppy code-and-fix model, you may not have a software spec to base your tests on. That's not an ideal situation for a software tester, but you can use a workable solution known as exploratory testingsimultaneously learning the software, designing tests, and executing those tests.

You need to treat the software as the specification. Methodically explore the software feature by feature. Take notes on what the software does, map out the features, and apply some of the static black-box techniques you learned in Chapter 4, "Examining the Specification." Analyze the software as though it is the specification. Then apply the dynamic black-box techniques from this chapter.

You won't be able to test the software as thoroughly as you would if you had a specyou won't necessarily know if a feature is missing, for example. But, you will be able to systematically test it. In this situation, finding any bugs would be a positive thing.