The most comprehensive, up-to-date, and practical introduction to software test design, "A Practitioner's Guide to Software Test Design" presents the most important test design techniques in a single volume and in a consistent, easy-to-understand format. This book was written specifically for: software test engineers who have the primary responsibility for test case design; software developers who, with the advent of Extreme Programming and other agile development methods, are being expected to do more and better testing of the software they write; test and development managers who must lead their staffs to more effective testing methods.
Numerous case studies and examples of test design techniques are included to help you understand and apply these methods. From well-established techniques such as equivalence classes, boundary value analysis, decision tables, and state transition diagrams, to newer techniques such as use-case testing, pair-wise testing, and exploratory testing, this book is an indispensable resource for anyone seeking to improve their software testing skills.
Learn the best test design techniques from the classics to the most modern. Create test cases that are more effective and efficient in finding defects. Deal effectively with the "too many tests" "too little time" dilemma.
Table of Contents Chapter 1 - The Testing Process Chapter 2 - Case Studies Chapter 3 - Equivalence Class Testing Chapter 4 - Boundary Value Testing Chapter 5 - Decision Table Testing Chapter 6 - Pair-wise Testing Chapter 7 - State-Transition Testing Chapter 8 - Domain Analysis Testing Chapter 9 - Use Case Testing Chapter 10 - Control Flow Testing Chapter 11 - Data Flow Testing Chapter 12 - Scripted Testing Chapter 13 - Exploratory Testing Chapter 14 - Test Planning Chapter 15 - Defect Taxonomies Chapter 16 - When to Stop Testing
Review By: Terry Stewart 08/31/2008Somehow, we have been led to believe there is a magical testing tool that does it all, and if we can get our hands on it, we will become "super testers." There is a book out there that leads us to believe this is not true. Near the end of his book "A Practitioner’s Guide to Software Test Design," Lee Copeland states, "My intent in writing this book was to help put more tools in your personal testing tool bucket and to help you know which tool to use in which situation."
By systematically identifying each tool we need, giving us a brief introduction to that tool, explaining to us the techniques for using the tool, defining its applications and limitations, Mr. Copeland has succeeded in reaching this intent. Mr. Copeland provides practical applications by giving us practice exercises. These exercises are further enhanced by two case studies that can be done via the Internet, which involve a factious university and a brokerage firm. Sounds too good to be true, doesn't it?
Near the end of his book Mr. Copeland writes, “Not every tool needs to be used every time.” When you understand that we do not have time to test every possible test-case combination out there and combine that with Mr. Copeland’s statements, we now understand the importance of this book. What Mr. Copeland is really saying is, “Allow me to assist you in putting more tools in your testing tool bucket, and let me assist you in identifying which tool is the right tool for the job.”
Even though the book is short, I enjoyed it. Due to the nature of the projects I am on, I have not been schooled in one particular area over another, so I have an opportunity to benefit from a broader tool bucket than some. I can see how each of the chapters in this book can be used specifically in areas I have been involved in, and if I would have had the book with me at the time, I could have used this book as a reference point for test design processes.
The way the chapters are set up makes the book very easy to follow. If the reader wants to know what a particular tool will do, he just needs to read the introduction. If a person is researching what tool to use, he needs only to scan the introduction to know where to stop and continue reading. He can set up scenarios to reflect the examples in the book until he feels comfortable moving on with actual test cases, or he can even do the case study first.
Now, there are some people who have been testing for a long time and have forgotten more than I will ever know. They should keep this book around as a handy reminder. Someday, when they least expect it, they will pick up this book and find a word, or a passage, or even a chapter, that contains something they have forgotten and they, too, will have added something to their testing tool bucket.
Review By: Peter Sage 08/31/2008It's about time someone wrote a practical guide about test design. In fact, I was planning to write such a book, but this is pointless as Lee has done an excellent job writing on the subject. Seldom do you get a combination of practical techniques, good tips, and humor at the same time in one book.
If you are beginning a software testing career or are an experienced test practitioner, I recommend you read this book. I also recommend you, your manager, and anybody who tests on your team always have a copy on hand.
The book covers basic techniques essential to any tester's toolbox, and also covers some of the newer ideas on the testing block. The reader will be able to easily adapt these techniques to real-life testing situations. The techniques discussed include:
Equivalence Class Partitioning,
Decision Logic Tables,
Control Flow Testing, and
Data Flow Testing.
The companion website provides examples of the testing techniques discussed in the book. The book--intended for various levels of testers--is easy to read, but also retains a good level of technical content.