Planificación y agentes

INTRODUCTION: THE REASON FOR THIS CHAPTER

Your primary task as a tester Is to find and report errors. The purpose of your work is improvement of product quality. This brief chapter defines "quality" and "software error." Then, because it helps to know what you're looking for before hunting for it, we describe thirteen categories of software errors.

The Appendix describes the error categories In more detail, and Illustrates them with over 400 specific types of errors.

USEFUL READING

Demlng (1982), Feigenbaum (1991), Ishlkawa (1985), and Juran (1989) are well respected, well written books with thoughtful discussions of the meaning of quality.

QUALITY

Some businesses make customer-designed products on order. The customer brings a detailed specification that describes exactly what he wants and the company agrees to make it. In this case, quality means matching the customer's specification.

Most software developers don't have such knowledgeable and precise customers. For them, the measure of their products' and services' quality is

the satisfaction of their customers, not the match to a specification.

If the customer doesn't like the end result, it doesn't matter if the product meets a specification, even if the customer agreed to the specification. For that customer, it's not good quality if he's not happy with it.

One aspect of quality is reliability. The more reliable the program, the less often it fails while the customer is trying to use it, and the less serious the consequences of any failures. This is very important, but testers who say that quality is reliability are mistaken. If the program can't do what the customer wants to do with it, the customer is unhappy. If the customer is not happy, the quality is not high.

A program's quality depends on:

• the features that make the customer want to use the program, and • the flaws that make the customer wish he'd bought something else.

Your main contribution as a tester is to improve customer satisfaction by reducing the number of flaws in the program. But a project manager who forces a particularly useful feature into the program at the last minute may also be improving the product's quality, even if the changed program is less reliable. Features and flaws both determine quality, not just one or the other. (For more discussion, read Juran, 1989.)

62

WHAT IS A SOFTWARE ERROR?

One common definition of a software error is a mismatch between the program and its specification. Don't use this definition.

A mismatch between the program and its specification is an error in the program if and only if the specification exists and is correct.

A program that follows a terrible specification perfectly is terrible, not perfect. Here are two better definitions:

• A software error is present when the program does not do what its end user reasonably expects it to do (Myers, 1976, p. 6).

•

• There can never be an absolute definition for bugs, nor an absolute determination of their existence. The extent to which a program has bugs is measured by the extent to which it fails to be useful. This is a fundamentally human measure (Beizer, 1984, p. 12).

Myers (1976) explicitly excluded "human factors errors" from his definition of software errors. We see these as just another group of errors and you should too. It may be harder to convince a programmer that a user interface error is an error, or that it's important, or that testers have any right to te ll him about it, but customers complain about serious human factors errors every bit as much as they complain about crashes.

CATEGORIES OF SOFTWARE ERRORS

We describe 13 major categories. Nothing is sacred about this categorization. Beizer's (1990), for example, is useful and quite different.

U

SER INTERFACE ERRORS

There are many ways to make a program a misery to work with. We lump them under the heading of "user interface." Here are some subcategories:

Functionality

A program has a functionality problem if it doesn't do something it should do, or does it awkwardly or incompletely. Specifications define a program's functionality for an implementation team, but the final definition of what a program is "supposed to" do lives in the mind of the user.

63

All programs will have functionality problems because different users have different expectations. You can't anticipate everyone's expectations.

You probably can't satisfy everyone's needs without losing the simplicity and conceptual integrity of the program.

A program has a functionality problem if something that a user expects the program to do is hard, awkward, confusing, or impossible. This problem is a functionality error if the user's expectation is reasonable.

Communication

How do you find out how to use the program? What information is readily available onscreen? Is there enough? Is it intelligible? Is it insulting? What are you told when you make a mistake or pTess <Help>? Is it useful? Is it accurate? Is anything irritating, misleading, confusing or poorly presented?

Command structure

Is it easy to get lost in the program? Are any commands confusing or easy to confuse with others? What errors do you make, what costs you time, and why?

Missing commands

What's missing? Does the program force you to think in a rigid, unnatural, or inefficient way? Can you customize it to suit your working style or needs? How important is customizability for a program like this?

Performance

Speed is of the essence in interactive software. Anything that makes the user/ee/ that the program is working slowly is a problem. (Especially if the competition's program feels faster.)

Output

Most programs display, print, graph, or save information. You use most programs to get these results. Are you getting what you want? Do the printouts make sense? Can you read the graphs? Will the program save data in a format that another program can read? Can you tailor the output to suit your needs? Can you redirect output to your choice of terminal, printer, or file?

E

RROR HANDLING

Errors in dealing with errors are common. Error handling errors include failure to anticipate the possibility of errors and protect against them, failure to notice error conditions, and failure to deal with a detected error in a reasonable way. Many programs correctly detect errors but then branch into untested error recovery routines. These routines' bugs can cause more damage than the original problem.

64

BOUNDARY-RELATED ERRORS

The simplest boundaries are numeric, like the ones discussed in the first example in Chapter 1. But the first use of a program is also a boundary condition. The largest and smallest amounts of memory that a program can cope with are boundaries. (Yes, some programs do die horrible deaths if you allow them too much memory.)

If any aspect of a program's use or functioning can be described as running from more to less, biggest to smallest, soonest to latest, first to last, briefest to longest, you can check boundaries at the edges of these ranges of values. Within the boundaries, the program works fine. At or outside the boundaries, the program may croak.

C

ALCULATION ERRORS

Simple arithmetic is difficult and error-prone in some languages. More likely, the program will misinterpret complicated formulas. It may also lose precision as it calculates, due to rounding and truncation errors. After many intermediate calculations it may claim that 2 + 2 is -1, even though none of the intermediate steps contains a logical error.

This category also includes computational errors due to incorrect algorithms. These include using incorrect formulas, formulas inapplicable to the data at hand, and breaking down a complex expression into components using incorrect rules. In algorithmic errors, the code correctly does what the programmer had in mind—it's just that his conception of what the code should do was a little batty.

I

NITIAL AND LATER STATES

A function might only fail the first time you use it. That first time, you may get odd displays, wrong calculations, infinite loops, or out-of-memory error messages. Some of these come back each time you restart the program. The most insidious programs save initializing information to disk and only fail the first time they're used—before they create the initialization file. After you use the program once, you can't find these bugs without a fresh copy of the program. This seems harmless until you realize that every one of your customers will start with a fresh copy of the program.

Programmers also sometimes forget that you might back up in the middle of a routine, to try to change something you did before. If everything is set to zero the first time you use part of a program, what happens if you return to that part? Does it reset everything to zero? Did you just lose all your data?

C

ONTROL FLOW ERRORS

The control flow of a program describes what it will do next, under what circumstances. A control flow error occurs when the program does the wrong thing next. Extreme control flow errors halt the program or cause it to run amok. Very simple errors can lead programs to spectacular misbehavior.

65

In document DEPARTAMENTO DE INFORMÁTICA Y AUTOMÁTICA (página 42-49)