- Objectives
- Intended Audience
- Prerequisites
- How to Read This Book
- Scope of Coverage
- Features
- Benefits to the Reader
This chapter is from the book
This chapter is from the book
This chapter is from the book
Benefits to the Reader
Why should you, the reader, care about a book that provides a detailed definition of a software testing process? A short answer is, because you need to learn more about how to do testing; this means knowing what the testing process should be. Another answer is, you believe the testing process you are now using could be improved and you need some guidance.
This book, and the model detailed in it, is designed to fill both needs.
If you are a new test engineer or test engineering manager who has not spent ten-to-twenty years in the testing arena, such a model can serve as a confirmation of the “good things you are doing” and a useful guide to “things you should be doing.” In Critical Testing Processes, testing expert Rex Black goes into a beautifully detailed set of steps for developing a testing estimate (Black, 2003). Use of a process model such as the one I define in this book can identify a list of tasks that form the foundation for such an estimate.
At the risk of repeating myself, I’d again like to note: My goal is to address testing activities and tasks that span the entire testing life cycle, from reviewing program plans, to developing the formal test plan, through developing the remainder of the test documentation (test design, test cases, test procedures) as well as acquiring any needed automated testing tools, through test execution, to final updating of the test documentation after test execution is complete. To do all this, you can use the technique of IPO diagrams shown in the following chapters to model your current testing process. This approach will provide you with a model of a software system that is an analog to the current logical model defined in the many seminars and books on the structured methods put out during the 1970’s and 1980’s by staff and consultants at Yourdon, Inc., and published by Yourdon Press.4 You could then take your current logical model and compare it with the model defined in this book, and decide whether any elements are missing from your process. Finally, you could start a process improvement activity to implement some of those missing elements, so that your process will be improved. An improved testing process should result in your identifying more defects prior to delivering your products, either by finding those defects prior to coding (through reviews associated with developing test documentation), or by finding defects during test execution because your improved procedures result in better testing.
Before you jump into the book, let me offer another advisory note: Read the Glossary. Currently, there is ambiguity in the testing industry regarding some of the terms we use on a daily basis, such as “test plan,” “test cases,” and “test procedures.” This book adheres to the terminology from IEEE-Standard-610.12, the Standard Glossary of Software Engineering Terminology. Many companies use the term “test plan” to encompass all test documentation. In such an instance, the IEEE-type test plan is the first chapter, and test cases and test procedures are contained in appendices. That isn’t what is meant by “test plan” in this book. Similarly for the term “test cases”—in some companies, test cases are considered to be the step-by-step instructions for executing tests. This book uses the term “test procedures” to cover those step-by-step instructions; in IEEE terminology, “test cases” contain the input data and expected results when input data are input to the system under test. So, keep this book’s Glossary handy to avoid confusion.
Now that you have finished this Preface, turn to Chapter 1, “Introduction,” and begin to read the book itself. Hopefully, you’ll enjoy reading it as much as I have enjoyed developing the model and writing the book.
August 2003
Columbia, Maryland
R.D.D.