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.

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.

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 or—worse—just 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:

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.

One theory of the creation of the universe is the big-bang theory. It states that billions of years ago, the universe was created in a single huge explosion of nearly infinite energy. Everything that exists is the result of energy and matter lining up to produce this book, DVDs, and Bill Gates. If the atoms didn't line up just right, these things might all be just quivering masses of goop.

The big-bang model for software development shown in Figure 2.4 follows much the same principle. A huge amount of matter (people and money) is put together, a lot of energy is expended—often violently—and out comes the perfect software product…or it doesn't.

Figure 2.4. The big-bang model is by far the simplest method of software development.

The beauty of the big-bang method is that it's simple. There is little if any planning, scheduling, or formal development process. All the effort is spent developing the software and writing the code. It's a process that is used if the product requirements aren't well understood and the final release date is completely flexible. It's also important to have very flexible customers, too, because they won't know what they're getting until the very end.

Notice that testing isn't shown in Figure 2.4. In most cases, there is little to no formal testing done under the big-bang model. If testing does occur, it's squeezed in just before the product is released. It's a mystery why testing is sometimes inserted into this model, but it's probably to make everyone feel good that some testing was performed.

If you are called in to test a product under the big-bang model, you have both an easy and a difficult task. Because the software is already complete, you have the perfect specification—the product itself. And, because it's impossible to go back and fix things that are broken, your job is really just to report what you find so the customers can be told about the problems.

The downside is that, in the eyes of project management, the product is ready to go, so your work is holding up delivery to the customer. The longer you take to do your job and the more bugs you find, the more contentious the situation will become. Try to stay away from testing in this model.

The code-and-fix model shown in Figure 2.5 is usually the one that project teams fall into by default if they don't consciously attempt to use something else. It's a step up, procedurally, from the big-bang model, in that it at least requires some idea of what the product requirements are.

Figure 2.5. The code-and-fix model repeats until someone gives up.

A wise man once said, “There's never time to do it right, but there's always time to do it over.” That pretty much sums up this model. A team using this approach usually starts with a rough idea of what they want, does some simple design, and then proceeds into a long repeating cycle of coding, testing, and fixing bugs. At some point they decide that enough is enough and release the product.

As there's very little overhead for planning and documenting, a project team can show results immediately. For this reason, the code-and-fix model works very well for small projects intended to be created quickly and then thrown out shortly after they're done, such as prototypes and demos. Even so, code-and-fix has been used on many large and well-known software products. If your word processor or spreadsheet software has lots of little bugs or it just doesn't seem quite finished, it was likely created with the code-and-fix model.

Like the big-bang model, testing isn't specifically called out in the code-and-fix model but does play a significant role between the coding and the fixing.

As a tester on a code-and-fix project, you need to be aware that you, along with the programmers, will be in a constant state of cycling. As often as every day you'll be given new or updated releases of the software and will set off to test it. You'll run your tests, report the bugs, and then get a new software release. You may not have finished testing the previous release when the new one arrives, and the new one may have new or changed features. Eventually, you'll get a chance to test most of the features, find fewer and fewer bugs, and then someone (or the schedule) will decide that it's time to release the product.

You will most likely encounter the code-and-fix model during your work as a software tester. It's a good introduction to software development and will help you appreciate the more formal methods.

The waterfall method is usually the first one taught in programming school. It's been around forever. It's simple, elegant, and makes sense. And, it can work well on the right project. Figure 2.6 shows the steps involved in this model.

Figure 2.6. The software development process flows from one step to the next in the waterfall model.

A project using the waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they're ready to move to the next step. If the project isn't ready to progress, it stays at that level until it's ready.

Notice three important things about the waterfall method:

This may sound very limiting, and it is, but it works well for projects with a well-understood product definition and a disciplined development staff. The goal is to work out all the unknowns and nail down all the details before the first line of code is written. The drawback is that in today's fast moving culture, with products being developed on Internet time, by the time a software product is so carefully thought out and defined, the original reason for its being may have changed.

From a testing perspective, the waterfall model offers one huge advantage over the other models presented so far. Everything is carefully and thoroughly specified. By the time the software is delivered to the test group, every detail has been decided on, written down, and turned into software. From that, the test group can create an accurate plan and schedule. They know exactly what they're testing, and there's no question about whether something is a feature or a bug.

But, with this advantage, comes a large disadvantage. Because testing occurs only at the end, a fundamental problem could creep in early on and not be detected until days before the scheduled product release. Remember from Chapter 1, “Software Testing Background,” how the cost of bugs increases over time? What's needed is a model that folds the testing tasks in earlier to find problems before they become too costly.

It's not quite utopia, but the spiral model (see Figure 2.7) goes a long way in addressing many of the problems inherent with the other models while adding a few of its own nice touches.

Figure 2.7. The spiral model starts small and gradually expands as the project becomes better defined and gains stability.

The spiral model was introduced by Barry Boehm in 1986 in his Association for Computing Machinery (ACM) paper, “A Spiral Model of Software Development and Enhancement.” It's used fairly often and has proven to be an effective approach to developing software.

The general idea behind the spiral model is that you don't define everything in detail at the very beginning. You start small, define your important features, try them out, get feedback from your customers, and then move on to the next level. You repeat this until you have your final product.

Each time around the spiral involves six steps:

Built into the spiral model is a bit of waterfall (the steps of analysis, design, develop, test), a bit of code-and-fix (each time around the spiral), and a bit of big-bang (look at it from the outside). Couple this with the lower costs of finding problems early, and you have a pretty good development model.

If you're a tester, you'll like this model. You'll get a chance to influence the product early by being involved in the preliminary design phases. You'll see where the project has come from and where it's going. And, at the very end of the project, you won't feel as rushed to perform all your testing at the last minute. You've been testing all along, so the last push should only be a validation that everything is okay.