Tipo De Pruebas

Part II: Testing Fundamentals
Go out looking for one thing, and that's all you'll ever find.
Old prospector's saying
The most exciting phrase to hear in science, the one that heralds the most
discoveries, is not "Eureka!" but "That's funny..."
Isaac Asimov, science and science-fiction author
IN THIS PART
4 Examining the Specification
5 Testing the Software with Blinders On
6 Examiningthe Code
7 Testing the Software with X-Ray Glasses
Chapter 4. Examining the Specification
IN THIS CHAPTER

Getting Started

Performing a High-Level Review of the Specification

Low-Level Specification Test Techniques
This chapter will introduce you to your first real hands-on testingbut it may not be what you expect. You
won't be installing or running software and you won't be pounding onthe keyboard hoping for a crash.
In this chapter, you'll learn how to test the product's specification to find bugs before they make it into
the software.
Testing the product spec isn't something that all software testers have the luxury of doing. Sometimes
you might come into a project midway through the development cycle after the specification is written
and the coding started. If that'sthe case, don't worryyou can still use the techniques presented here to
test the final specification.
If you're fortunate enough to be involved on the project early and have access to a preliminary
specification, this chapter is for you. Finding bugs at this stage can potentially save your project huge
amounts of time and money.
Highlights of this chapter include
Part II. TestingFundamentals Page 1 of 67
file:///C:/Users/aacosta/AppData/Local/Temp/~hh5DE2.htm 08/10/2012

What is black-box and white-box testing

How static and dynamic testing differ

What high-level techniques can be used for reviewing a product specification

What specific problems you should look for when reviewing a product specification in detail
Getting Started
Think back to the four developmentmodels 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 excerptfrom 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.
[View full size image]
Part II. Testing Fundamentals Page 2 of 67file:///C:/Users/aacosta/AppData/Local/Temp/~hh5DE2.htm 08/10/2012
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? Theproblem 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...