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.
on February 10, 2004
I noticed that many of the reviewers listed above are noted SW testing professionals that have published books themselves. I also noticed that these same professionals tend to supply glowing reviews for each other. I think this might lead to a bit of a bias that could mislead ordinary folks looking for a good reference tool to help them do their job.
I've been in the SW test business for several years and have used Cem Kaner's "Testing Computer Software 2nd Edition" as a bible for many years. Mr. Kaner's "Lessons Learned in Software Testing" is a great help for both rookies and seasoned veterans alike, but mainly for anecdotal wisdom. I wish I had the opportunity to read this book early in my career, it would have prevented some of the painful lessons I've learned about the testing business. At the same time, portions of this book are opinions and observations, and should be read with an open mind, but not read as gospel. I often read sections of this book to reassure myself that my actions/decisions/processes are sound.
This book is not a "how to" guide with sample forms and processes to follow, but a very useful collection of wisdom from some of the best minds in testing. Think of this book as three wise people sharing their knowledge with anyone willing to listen (or ante up the bucks to buy the book).
on May 24, 2002
This book was praised by several colleagues as THE way to work on testing methods and thinking. After reading it and talking with each of them, it was apparent they were excited based on false credentials about ideas that were easy and comfortable but ineffective long term. This book is VERY dangerous to a serious testing organization because it focuses on minimal documentation (which means in 6 months when you're asked if you tested X and you can't remember, you'll get 5mins to get out of the building), downplays automation in regression testing (what!!?), and admits openly that it is proposing ideas that are NOT proven (contrary to what the title states) but rather are ideas that "seem to be working" (see pg 176) but no formal nor long term studies support their claims. Well, long term studies that have already been done directly contradict their findings: process is driven by a need to be effective and if you don't know what you're doing before you do it, then you don't know what you did when you're done. ... This is a book for those who advocate ad hoc testing to their own discredit and need a means of justificating their apathy and laziness to those who actually know effective testing techniques.
on March 25, 2002
When I am asked for suggested solutions to software-testing problems, my standard answer has always been "The solutions depend on the context of the problems, external variables such as technology, process, people, and politics, and the specific objectives one hopes to achieve." I've also wished that there were a reliable, experience-based resource that I could refer my testing friends to that had answers to these commonly asked questions. Thankfully, Kaner, Bach and Pettichord have made my wish a reality. Packed with hundreds of lessons gleaned from numerous testing contexts, Lessons Learned in Software Testing offers sound advice from the three authors and many of their colleagues. Whether you're confronting test project management issues, looking for fresh testing techniques, or hoping to improve your effectiveness in working with developers, you will find valuable ideas here. I enjoyed reading these lessons and take pleasure in sharing them with my fellow testers.
Today, I can confidently say to my colleagues that "Take a look in Lessons learned in Software Testing-You'll probably find your answers there."
on February 11, 2002
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.
on February 8, 2002
I received my copy of "Lessons Learned in Software Testing" last week. Although, I had seen parts of it before, I have now really enjoyed having this fantastic information source available.
The book contains a lot of lessons learned that I never thought about before, and for all the lessons I had thought about the write-up and examples are very useful.
Like the other day when I was preparing some course material about testing techniques, I had a pile of software testing books in front of me on my desk. After scanning them all, I turned to "Lessons Learned" and found the information I was looking for! I found a classification scheme of testing techniques and a lot of information useful to me while I was thinking about how to present this to other people. The same thing goes for test automation, bug reporting, test documentation and all the other sections in this book. It is not replacing the other testing books that I have, but it is a very useful supplement!
I might not agree with all the lessons in the book, but this is a book to enjoy, learn from and use!
on January 12, 2002
"Lessons Learned in Software Testing" is a great book for the experienced tester or test manager. The book is structured as a series of bite-sized lessons, with a few longer essays on the authors' favorite test techniques thrown in. In the lessons, the authors share their opinions (frankly presented as such), and then explain the reasoning behind those opinions. They concentrate on explaining how to apply the same sort of reasoning to your own situation. In a few spots, the authors actually present contradicting opinions and proceed to defend both.
The lessons cover a wide range of subjects vital to testing and test management - everything from test planning to career guidance to the role of the test group in the organization. I found lessons that presented new (and promising) ways to think about my current knotty problems, and a few that made me question practices that I'd considered tried-and-true for years. If you're faced with problems that are puzzling, hard to describe, vague and inchoate, there's probably a lesson in this book that will bring the problem into focus for you. You may walk away with more questions than answers, but they'll be good, crisp, probing questions.
I consider this book a "must-have" for anyone who's been in testing long enough to realize that the books aren't always right.
on January 10, 2002
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.)
on January 6, 2002
I had the good fortune to be asked by Dr. Cem Kaner, James Bach, and Bret Pettichord to review this book while they were working on it. It was a real pleasure to read, full of good ideas and insights, clearly expressed, pithy, and provocative. I agree with much of what the authors have to say. If you've read my book or some of my articles, you'll probably notice when you read this book that I also have a few disagreements. Those disagreements made this book even more worth reading for me, because I had to ask myself, "Why DO I do things the way I do?" That's a question practitioners should ask themselves, and this book helped me ask it.
People starting out in the field of software testing will probably help themselves avoid a good two or three dozen--if not gross--headaches by reading this book first. The authors do a great job of talking about the people issues. As software testers, our job is to effectively communicate an assessment of quality to the project team. This book will give you more than a few ideas about communicating with coworkers, peers, and managers.
As for the political correctness issue raised by another reviewer, as an author and speaker I understand the lengths that one must go to to avoid such problems. During the review process, I saw the diligent effort the authors made to be evenhanded in terms of gender and other bias issues. It would be unfortunate for this book to get passed over by anyone because of such concerns. I know the gentlemen who wrote this book personally, and I can say without hesitation that you would be hard-pressed to find a more unbiased, fair-minded, and thoughtful bunch. This book is a great book, brimming with wisdom on tap in the sphere of software testing.
Rex Black, Principal
Rex Black Consulting Services, Inc.
on December 25, 2001
This book contains a lot of good information especially for those further removed from the testing process. I'll let other reviews speak to these issues.
Unfortunately, the authors have polluted their work with politically correct opinions lightly sprinkled throughout the book. The most egregious example is in lesson number 235 on test team diversity.
After correctly pointing out the need for technical diversity and rewarding people based on results, the authors do a 180. Just after stating the dangers of racism, sexism and ageism, they authors engage in racist and sexist discrimination by bashing white males. They state that "...groups...dominated by white males...are particularly counter-productive in testing." Since testers (are supposed to) analyze things, and I'm a tester, let's analyze this statement.
If you're hiring white males just because they are white males and not for their technical ability, then you should expect problems. Ditto for any other race, gender (I'm waiting for this to encompass sexual orientation any day now) or age. In other words, this statement adds no value so why single out and bash white males, except to gain politically correct brownie points. You need to hire on diversity of skill, knowledge and experience, not race, gender or age.
Secondly, the authors imply that all white males think alike. I'm not sure how and where the authors were raised, but from my experience very few white males think alike. So this is defective thinking.
At least 2 of the 3 authors run their own companies. I wonder what their diversity distribution looks like? My guess: They probably have no employees, which may be viewed as "Do as I say, not as I do."
And for the height of hypocrisy, they should look in the mirror. All three authors are - you guessed it - white males. So while gender and racial diversity is good for your testing group, it's not necessary for writing a book on testing groups. The authors do not practice what they preach, another defect.
Don't let these ideological slips prevent you from buying and reading this book. It contains a lot of good information that is sure to surprise those not intimately familiar with software testing.
Notes: For those interested in fighting gender discrimination, see mensactivism.org
If you think that men (of any race) are given societal advantages, read "The Myth of Male Power" by Warren Farrell, Ph.D. You will quickly see that women are routinely given special privileges that men could only dream of having.