- 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
How to Read This Book
This book is laid out in the following order:
- Chapter 1 provides a general overview of the software development life cycle, and an overview of the concurrent testing life cycle. It also shows the need for a testing process model, and illustrates the Level 0 and Level 1 IPO diagrams for this model.
- Chapters 2 through 7 show decomposition of the Level 1 IPO diagram into a series of Level 2 and Level 3 diagrams, to show the tasks involved in the review of program plans, the creation of a test plan, the creation of test design (and other test documentation), the performance of formal test, and finally, the updating of test documentation. This set of tasks can be used as the basis for an estimate of a formal testing program on a particular development program.
- Chapter 8 provides some thoughts on how to use and customize this process model, which is a soup-to-nuts model. You may not be in a position to use such a model initially, but on a large program, putting this process in place should be your goal. Customizing the model should be your goal on a medium- or small-size project. Thus, this model provides a template for a testing process improvement program. To end the text itself, Chapter 9 provides a brief summary of the model in its entirety.
- To conclude the book, I’ve added four practical Appendices, a Glossary, a Bibliography, and, of course, an Index. Although most of these final sections are standard fare, the Appendices bear describing. Appendix A provides a brief description of the Capability Maturity Model for Software (CMM-SW) from the Software Engineering Institute at Carnegie Mellon University, as well as a brief description of the SEI’s more recent Capability Maturity Model Integration (CMMI). Appendix B provides templates for five preferred practices that are significant to a software development program, including a Program Management Plan (PMP), a Software Development Plan (SDP), a Software Quality Assurance Plan (SQAP), a Configuration Management Plan (CMP), and a Test Plan (TP). Appendix C provides a questionnaire you can use to evaluate the state of your testing process. Let this guide your use of the Formal Testing Process Model as a mechanism to help you improve your testing process. Appendix D contains guidelines for test execution.
To gain a detailed understanding of the tasks, inputs, and outputs involved in formal testing, you can simply read the book from front to back. For readers desiring to explore specific aspects of the testing process (for example, test execution), I would recommend skimming Chapter 1 (Introduction), reviewing Chapter 2 (The Formal Testing Process Model: Level 1 IPO Diagrams) to identify which process you want to explore in more detail, and then proceeding directly to that chapter (for one example, test execution, see Chapter 6, “Perform Formal Test,” and Appendix D). Though there are sections for each subprocess of the major processes (for example, subprocess Execute Test, major process Perform Formal Test), I would suggest there are enough interfaces between the various subprocesses that the entire section should at least be skimmed.
I don’t spend much time discussing the topic of testing tools and test automation, because these are really software development programs, not test processes. However, there are two subprocesses defined for Acquire Test Software in Chapter 5, which should be reviewed. One subprocess deals with building your own test software tools; the second subprocess addresses the activities involved in buying the tools you need.
I hope that this book will start you thinking about the following questions:
- Does our current testing process have all the tasks we need to identify defects in the products under test? If not, which tasks should we add first to improve our testing process?
- Have we identified the next step in our continuous process improvement plan?
- Do we have the necessary reviews in our testing process (for example, Test Plan inspection)?
- Are we writing all the test documentation we need to provide high-quality repeatable tests?
- Is testing and test coverage adequate for our program (for example, enough time, enough test points)?
If you can answer yes to all these questions, then you probably don’t need to read this book in its entirety. But are you sure that your test process is as good as it can be?
There is one additional caveat to keep in mind as you read this book: You will not find the term “bugs” used. I once heard a testing guru state at a conference that he didn’t like the term “bugs,” since the term implies that bugs have a life of their own. Those of you with a memory for computer trivia will remember that the term originated when workers on an early Navy computer found that a large moth had become trapped between the contacts of a relay, causing the computer to malfunction.3 Well, folks, in software, defects don’t jump in by themselves. Human beings, as software engineers, put defects in code. Now, the defects may not all be our fault, since we may just be doing what we were told to do when the customer gave us some incorrect requirements, but nonetheless, people put defects in; defects don’t just appear spontaneously. So, in this book, you’ll see the terms “defects,” “incidents,” and “problems,” but you won’t see the term “bugs.”