Product Components

What exactly is a software product? Many of us think of it as simply a program that we download from the Internet or install from a DVD that runs on our computer. That's a pretty good description, but in reality, many hidden pieces go into making that software. There are also many pieces that "come in the box" that are often taken for granted or might even be ignored. Although it may be easy to forget about all those parts, as a software tester, you need to be aware of them, because they're all testable pieces and can all have bugs.

What Effort Goes Into a Software Product?

First, look at what effort goes into a software product. Figure 2.1 identifies a few of the abstract pieces that you may not have considered.

Figure 2.1. A lot of hidden effort goes into a software product.

So what are all these things, besides the actual code, that get funneled into the software? At first glance they probably seem much less tangible than the program listing a programmer creates. And they definitely aren't something that can be viewed directly from the product's CD-ROM. But, to paraphrase a line from an old spaghetti sauce commercial, "they're in there." At least, they should be.

The term used in the software industry to describe a software product component that's created and passed on to someone else is deliverable. The easiest way to explain what all these deliverables are is to organize them into major categories.

Customer Requirements

Software is written to fulfill some need that a person or a group of people has. Let's call them the customer. To properly fill that need, the product development team must find out what the customer wants. Some teams simply guess, but most collect detailed information in the form of surveys, feedback from previous versions of the software, competitive product information, magazine reviews, focus groups, and numerous other methods, some formal, some not. All this information is then studied, condensed, and interpreted to decide exactly what features the software product should have.

PUT YOUR FEATURES IN PERSPECTIVE WITH FOCUS GROUPS

A popular means to get direct feedback from potential customers of a software product is to use focus groups. Focus groups are often organized by independent survey companies who set up offices in shopping malls. The surveyors typically walk around the mall with a clipboard and ask passers-by if they want to take part in a study. They'll ask a few questions to qualify you such as "Do you have a PC at home? Do you use software X? How much time do you spend online?" And so on. If you fit their demographic, they'll invite you to return for a few hours to participate with several other people in a focus group. There, you'll be asked more detailed questions about computer software. You may be shown various software boxes and be asked to choose your favorite. Or, you may discuss as a group features you'd like to see in a new product. Best of all, you get paid for your time.

Most focus groups are conducted in such a way that the software company requesting the information is kept anonymous. But, it's usually easy to figure out who they are.

Specifications

The result of the customer requirements studies is really just raw data. It doesn't describe the proposed product, it just confirms whether it should (or shouldn't) be created and what features the customers want. The specifications take all this information plus any unstated but mandatory requirements and truly define what the product will be, what it will do, and how it will look.

The format of specifications varies greatly. Some companiesespecially those developing products for the government, aerospace, financial, and medical industriesuse a very rigorous process with many checks and balances. The result is an extremely detailed and thorough specification that's locked down, meaning that it can't change except under very extreme conditions. Everyone on the development team knows exactly what they are creating.

There are development teams, usually ones creating software for less-critical applications, who produce specifications on cocktail napkins, if they create them at all. This has the distinct advantage of being very flexible, but there's lots of risk that not everyone is "on the same page." And, what the product finally becomes isn't known until it's released.

Schedules

A key part of a software product is its schedule. As a project grows in size and complexity, with many pieces and many people contributing to the product, it becomes necessary to have some mechanism to track its progress. This could range from simple task lists to Gantt charts (see Figure 2.2) to detailed tracking of every minute task with project management software.

Figure 2.2. A Gantt chart is a bar chart that shows a project's tasks against a horizontal timeline.

The goals of scheduling are to know which work has been completed, how much work is still left to do, and when it will all be finished.

Software Design Documents

One common misconception is that when a programmer creates a program, he simply sits down and starts writing code. That may happen in some small, informal software shops, but for anything other than the smallest programs, there must be a design process to plan out how the software will be written. Think about this book, which required an outline before the first words were typed, or a building, which has blueprints drawn before the first concrete is poured. The same planning should happen with software.

The documents that programmers create vary greatly depending on the company, the project, and the team, but their purpose is to plan and organize the code that is to be written.

Here is a list of a few common software design documents:

• Architecture. A document that describes the overall design of the software, including descriptions of all the major pieces and how they interact with each other.

• Data Flow Diagram. A formalized diagram that shows how data moves through a program. It's sometimes referred to as a bubble chart because it's drawn by using circles and lines.

• State Transition Diagram. Another formalized diagram that breaks the software into basic states, or conditions, and shows the means for moving from one state to the next.

• Flowchart. The traditional means for pictorially describing a program's logic. Flowcharting isn't very popular today, but when it's used, writing the program code from a detailed flowchart is a very simple process.

• Commented Code. There's an old saying that you may write code once, but it will be read by someone at least 10 times. Properly embedding useful comments in the software code itself is extremely important, so that programmers assigned to maintain the code can more easily figure out what it does and how.

Test Documents

Test documentation is discussed in detail in Chapters 1720 but is mentioned here because it's integral to what makes up a software product. For the same reasons that programmers must plan and document their work, software testers must as well. It's not unheard of for a software test team to create more deliverables than the programmers.

Here's a list of the more important test deliverables:

• The test plan describes the overall method to be used to verify that the software meets the product specification and the customer's needs. It includes the quality objectives, resource needs, schedules, assignments, methods, and so forth.

• Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.

• Bug reports describe the problems found as the test cases are followed. These could be done on paper but are often tracked in a database.

• Test tools and automation are described in detail in Chapter 15, "Automated Testing and Test Tools." If your team is using automated methods to test your software, the tools you use, either purchased or written in-house, must be documented.

• Metrics, statistics, and summaries convey the progress being made as the test work progresses. They take the form of graphs, charts, and written reports.

What Parts Make Up a Software Product?

So far in this chapter you've learned about the effort that goes into creating a software product. It's also important to realize that when the product is ready to be boxed up and shipped out the door, it's not just the code that gets delivered. Numerous supporting parts go along with it (see Figure 2.3). Since all these parts are seen or used by the customer, they need to be tested too.

Figure 2.3. The software CD-ROM is just one of the many pieces that make up a software product.

It's unfortunate, but these components are often overlooked in the testing process. You've surely attempted to use a product's built-in help file and found it to be not so helpful orworsejust plain wrong. Or, maybe you've checked the system requirements on a sticker on the side of a software box only to find out after you bought it that the software didn't work on your PC. These seem like simple things to test, but no one probably even gave them a second look before the product was okayed for release. You will.

Later in this book you'll learn about these non-software pieces and how to properly test them. Until then, keep this list in mind as just a sampling of what more there is to a software product than just the code:

Help files	User's manual
Samples and examples	Labels and stickers
Product support info	Icons and art
Error messages	Ads and marketing material
Setup and installation	Readme file

DON'T FORGET TO TEST ERROR MESSAGES

Error messages are one of the most overlooked parts of a software product. Programmers, not trained writers, typically write them. They're seldom planned for and are usually hacked in while fixing bugs. It's also very difficult for testers to find and display all of them. Don't let error messages such as these creep into your software:

[View full width]
 Error: Keyboard not found. Press F1 to continue. Can't instantiate the video thing. Windows has found an unknown device and is installing a driver  for it. A Fatal Exception 006 has occurred at 0000:0000007.