It’s not quite utopia, but the spiral model (see Figure 2.7) goes a long way in address- ing many of the problems inherent with the other models while adding a few of its own nice touches.
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:
1. Determine objectives, alternatives, and constraints.
2. Identify and resolve risks.
3. Evaluate alternatives.
4. Develop and test the current level.
5. Plan the next level.
6. Decide on the approach for the next level.
FIGURE 2.7 The spiral model starts small and gradually expands as the project becomes better defined and gains stability.
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.
AGILE SOFTWARE DEVELOPMENT
A type of development process that has gained in popularity among a number of software companies is known as Agile Software Development. You might hear other names for it such as Rapid Prototyping, Extreme Programming, or Evolutionary Development, among others.
Final Product
Plan the Next Level
Identify and Resolve Risks
Develop and Test the Current Level
Evaluate Alternatives Decide on the
Approach for the Next Level Determine Objectives,
Alternatives, and Constraints
Cumulative Cost
START
The goal of Agile Software Development, as described in its manifesto at www.agilemani- festo.org, is:
“Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiations Responding to change over following a plan…
That is, while there is value in the items on the right, we value the items on the left more.”
Agile Software Development has developed a bit of a following and has had some successful projects but is far from main stream. It sounds like a great philosophy if you and your project seem to be bogged down in process and documentation but, in my opinion, it can too easily digress into chaos. It’s a method to watch and learn about and your team may consider using it. For now, however, I won’t be riding in a jet whose software was rapidly prototyped by an extreme programmer. Maybe someday.
For more information, check out: Agile Modeling,Teach Yourself Extreme Programming in 24 Hours, and Extreme Programming Practices in Action. All are published by Sams Publishing.
Summary
You now have an understanding of how software products are created—both what goes into them and the processes used to put them together. As you can see, there’s no definitive approach. The four models presented here are just examples. There are many others and lots of variations of these. Each company, each project, and each team will choose what works for them. Sometimes they will choose right, sometimes they will choose wrong. Your job as a software tester is to work the best you can in the development model you’re in, applying the testing skills you learn in the rest of this book to create the best software possible.
Quiz
These quiz questions are provided for your further understanding. See Appendix A,
“Answers to Quiz Questions,” for the answers—but don’t peek!
1. Name several tasks that should be performed before a programmer starts writing the first line of code.
2. What disadvantage is there to having a formal, locked-down specification?
3. What is the best feature of the big-bang model of software development?
4. When using the code-and-fix model, how do you know when the software is ready to release?
5. Why can the waterfall method be difficult to use?
6. Why would a software tester like the spiral model better than the others?
•Testing Axioms
•Software Testing Terms and Definitions
The Realities of Software Testing
I
n Chapter 1, “Software Testing Background,” and Chapter 2, “The Software Development Process,” you learned about the basics of software testing and the soft- ware development process. The information presented in these chapters offered a very high-level and arguably ideal- istic view of how software projects might be run.Unfortunately, in the real world you will never see a project perfectly follow any of the development models.
You will never be given a thoroughly detailed specification that perfectly meets the customer’s needs and you will never have enough time to do all the testing you need to do. It just doesn’t happen. But, to be an effective software tester, you need to understand what the ideal process is so that you have something to aim for.
The goal of this chapter is to temper that idealism with a reality check from a software tester’s perspective. It will help you see that, in practice, trade-offs and concessions must be made throughout the development cycle. Many of those trade-offs are directly related to the software test effort. The bugs you find and the problems you prevent all significantly affect the project. After reading this chapter, you’ll have a much clearer picture of the roles, the impact, and the responsibilities that software testing has and you’ll hopefully appreciate the behind-the-scenes decisions that must be made to create a software product.
The highlights of this chapter include
• Why software can never be perfect
• Why software testing isn’t just a technical problem
• The terms commonly used by software testers
Testing Axioms
This first section of this chapter is a list of axioms, or truisms. Think of them as the
“rules of the road” or the “facts of life” for software testing and software develop- ment. Each of them is a little tidbit of knowledge that helps put some aspect of the overall process into perspective.