Getting Started

Think back to the four development models presented in Chapter 2, "The Software Development Process": big-bang, code-and-fix, waterfall, and spiral. In each model, except big-bang, the development team creates a product specification from the requirements document to define what the software will become.

Typically, the product specification is a written document using words and pictures to describe the intended product. An excerpt from the Windows Calculator (see Figure 4.1) product spec might read something like this:

The Edit menu will have two selections: Copy and Paste. These can be chosen by one of three methods: pointing and clicking to the menu items with the mouse, using access-keys (Alt+E and then C for Copy and P for Paste), or using the standard Windows shortcut keys of Ctrl+C for Copy and Ctrl+V for Paste.

The Copy function will copy the current entry displayed in the number text box into the Windows Clipboard. The Paste function will paste the value stored in the Windows Clipboard into the number text box.

Figure 4.1. The standard Windows Calculator displaying the drop-down Edit menu.

As you can see, it took quite a few words just to describe the operation of two menu items in a simple calculator program. A thoroughly detailed spec for the entire application could be a hundred pages long.

It may seem like overkill to create a meticulous document for such simple software. Why not just let a programmer write a calculator program on his own? The problem is that you would have no idea what you'd eventually get. The programmer's idea of what it should look like, what functionality it should have, and how the user would use it could be completely different from yours. The only way to assure that the end product is what the customer requiredand to properly plan the test effortis to thoroughly describe the product in a specification.

The other advantage of having a detailed spec, and the basis of this chapter, is that as a tester you'll also have a document as a testable item. You can use it to find bugs before the first line of code is written.

Black-Box and White-Box Testing

Two terms that software testers use to describe how they approach their testing are black-box testing and white-box testing. Figure 4.2 shows the difference between the two approaches. In black-box testing, the tester only knows what the software is supposed to dohe can't look in the box to see how it operates. If he types in a certain input, he gets a certain output. He doesn't know how or why it happens, just that it does.

Figure 4.2. With black-box testing, the software tester doesn't know the details of how the software works.

TIP

Black-box testing is sometimes referred to as functional testing or behavioral testing. Don't get caught up in what the actual terms are, as your team may use something different. It's your job to understand their meaning and how they're used by your team.

Think about the Windows Calculator shown in Figure 4.1. If you type 3.14159 and press the sqrt button, you get 1.772453102341. With black-box testing, it doesn't matter what gyrations the software goes through to compute the square root of pi. It just does it. As a software tester, you can verify the result on another "certified" calculator and determine if the Windows Calculator is functioning correctly.

In white-box testing (sometimes called clear-box testing), the software tester has access to the program's code and can examine it for clues to help him with his testinghe can see inside the box. Based on what he sees, the tester may determine that certain numbers are more or less likely to fail and can tailor his testing based on that information.

NOTE

There is a risk to white-box testing. It's very easy to become biased and fail to objectively test the software because you might tailor the tests to match the code's operation.

Static and Dynamic Testing

Two other terms used to describe how software is tested are static testing and dynamic testing. Static testing refers to testing something that's not runningexamining and reviewing it. Dynamic testing is what you would normally think of as testingrunning and using the software.

The best analogy for these terms is the process you go through when checking out a used car. Kicking the tires, checking the paint, and looking under the hood are static testing techniques. Starting it up, listening to the engine, and driving down the road are dynamic testing techniques.

Static Black-Box Testing: Testing the Specification

Testing the specification is static black-box testing. The specification is a document, not an executing program, so it's considered static. It's also something that was created using data from many sourcesusability studies, focus groups, marketing input, and so on. You don't necessarily need to know how or why that information was obtained or the details of the process used to obtain it, just that it's been boiled down into a product specification. You can then take that document, perform static black-box testing, and carefully examine it for bugs.

Earlier you saw an example of a product specification for the Windows Calculator. This example used a standard written document with a picture to describe the software's operation. Although this is the most common method for writing a spec, there are lots of variations. Your development team may emphasize diagrams over words or it may use a self-documenting computer language such as Ada. Whatever their choice, you can still apply all the techniques presented in this chapter. You will have to tailor them to the spec format you have, but the ideas are still the same.

What do you do if your project doesn't have a spec? Maybe your team is using the big-bang model or a loose code-and-fix model. As a tester, this is a difficult position. Your goal is to find bugs earlyideally finding them before the software is codedbut if your product doesn't have a spec, this may seem impossible to do. Although the spec may not be written down, someone, or several people, know what they're trying to build. It may be the developer, a project manager, or a marketer. Use them as the walking, talking, product spec and apply the same techniques for evaluating this "mental" specification as though it was written on paper. You can even take this a step further by recording the information you gather and circulating it for review.

Tell your project team, "This is what I plan to test and submit bugs against." You'll be amazed at how many details they'll immediately fill in.

TIP

You can test a specification with static black-box techniques no matter what the format of the specification. It can be a written or graphical document or a combination of both. You can even test an unwritten specification by questioning the people who are designing and writing the software.