Lessons Learned in Software Testing: A Context-Driven Approach

This is a book of combined wisdom and advice ranging from automated testing to how to think like a tester. What makes it unique is the way the wisdom is imparted and advice given by exhaustively dissecting key pitfalls in all of the key areas of testing, then reinforcing them with lessons and examples. As an individual tester seeking to improve professional knowledge you'll benefit from the combined wisdom, as well as the scope of the book's areas. The three authors have extensive experience in the profession - in fact, each is a leader in the profession - and each brings a different perspective to the practice of software testing. This guarantees that you will be exposed to a diverse set of challenges and ideas.If you teach testing, either in a class or set aside time for internal training within your testing group, this book is invaluable. In the classroom setting it will augment your primary text and material by providing discussion items and mini-cases with which to challenge your students. In the job setting it provides sufficient material from which to draw for conducting informal on-the-job training. More importantly, many of the lessons are bound to coincide with issues you and your group face in day-to-day work, which will allow you to reinforce lessons learned in your organization with the findings and advice contained within this book.Regardless of whether you are using this book to further your own professional knowledge or use as a training tool, it represents a valuable addition to the software testing body of knowledge and belongs on the bookshelf of everyone in he testing profession.

This is an excellent book for getting testers' heads straight about what software testing is and is not. The next time I head up a testing team, we'll grab copies of this book and work our way through it over lunch, a few sections each week.One of the strengths of "Lessons Learned" is that the authors know there is not just one answer. Wisdom is general, and then it has to be applied specifically to the specific situation. "Lessons Learned" helps testers get their passions up about the best, most efficient, most useful ways to understand and work with the project's code, and the clearest, must useful ways to transmit that information to programmers, management, and stakeholders.Oh, and it's humane and funny--a book you can read for fun, and get wise at the same time. A universe away from the understanding that thinks testing is just making lists and checking them off.

I had the pleasure of reviewing this book as it was being written. It is a real gem.This book is a tool that will be valuable throughout your career. It is filled with practical suggestions and observations based on decades of experience. You will not find religious wars here, just real-world experience with wide application. This book will pay for itself very quickly. I have used the weekly status report format on page 183 for several projects and found it to be much more effective than any previous formats.If you use pairwise testing, pages 52-60, the book has paid for itself. I've used pairwise testing to reduce an impossible number of combinations (864) to a small number of test cases that effectively covered what needed to be tested.If you want to get the bugs you find fixed, read Chapter 4. If you do automated testing, you can climb way up the learning curve by reading Chapter 5. If you're making decisions about how much test documentation to write, read Chapter 6. If you're involved in management, read Chapter 9. If you're interested in managing your career, read Chapter 10. I could go on. I've worked in diverse environments on wildly different products. This book has something for every work situation and test problem I've faced. On a scale of 10, I would give it 100 for greatly exceeding my expectations.

This book contains 293 "Lessons". Each seems to be meant for people with certain experiences and certain problems; some very broadly defined, others more tightly. So, how do I grade 293 lessons? One way would be to average them, another to pick on the worst (from my point of view). I choose to pick out the ones that hit me the hardest; the best from my point of view.I've been a developer, a tester, a test manager, and am now a grad student studying testing with Dr. Kaner. This book was the proximate cause of the last. If I had had this book a couple of years ago, I believe I would have done a much better job as test manager, and my project would have succeeded better with our customer. This is the second best book on testing that I've ever read.By the time I saw Lesson 31, I had already learned it the hard way. "A Requirement is a quality or condition that matters to someone who matters." It doesn't matter what the requirements document says; you ignore the opinion of someone who matters at your peril. I did.Lesson 57: "Make your bug report an effective sales tool." My bug reports developed a pretty good reputation with most of the developers, so I quit paying as much attention to putting convincing arguments in them. Then, we got some new senior developers. I was back at square one without quite realizing how I got there. Don't do that.Lesson 235: "Staff the testing team with diverse backgrounds." When I became test manager, I looked for people like me: computer science degree with developer experience. Well, such people don't work as testers, especially for the location and money we offered. I first hired a young woman with Army training. Later, I figured out how lucky I had been; she was one of the two best testers who worked for me. I learned a lot about my blind spots from her pointing them out to me. I'd hate to have tried to do the job without her or many of the other people very different from me (and her) that I hired.Lesson 240 "During the interview, have the tester demonstrate the skills you're hiring for." After having a lot of bad results from traditional interviewing, we wrote a series of tests and gave the appropriate one (testing, SQL, C++, etc.) to each candidate. Afer that, we found our rate of bad hires was down sharply. We hired several people whom we would not have hired based on our traditional interview questions; almost all turned out well.What am I learning? Lesson 17: "Studying epistemology helps you test better." I hope so; I'm studying it. Lesson 76: "Always report nonreproducible errors; they may be time bombs." I'm keeping more lists of these now. No good results yet. Lesson 266: "Learn Perl." Yep, there's more than one way to do it.(BTW, the best book on testing I've ever read is Testing Computer Software, 2nd. Kaner, Falk, Nguyen.)

If you test software, or depend on people who do, then read this book. Each page effervesces with hard-won advice for handling the practical problems you encounter every day. Software testing is an increasingly complicated discipline that suffers from too much liturgy, too little experience and too many conflicting theories. Kaner, Bach, and Pettichord balance this with a wealth of practical, empirical knowledge. In particular, their emphasis on the contextual factors of software testing brings out the value in understanding conflicting points of view. This book will help you be a better tester or test manager. I expect to refer to it every week.