Customer Reviews

Lessons Learned in Software Testing

5 star:		(30)
4 star:		(11)
3 star:		(0)
2 star:		(0)
1 star:		(2)

 

 

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.)

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).

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.

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 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.

Through a series of nearly 300 "lessons", the authors share their accumulated wisdom about how to test application systems - not so much which buttons to press but more how to establish and manage a test team, plan the work and dynamically adjust the testing process according to what is found and how much time is left.

The chapter titles ably illustrate the book's scope: 1. Role of the tester; 2. Thinking like a tester; 3. Testing techniques; 4. Bug advocacy; 5. Automating testing; 6. Documenting testing; 7. Interacting with programmers; 8. Managing the testing project; 9. Managing the testing group; 10. Your career in software testing; 11. Planning the testing strategy; [Appendix] The context driven approach to software testing.

I would definitely encourage anyone who thinks `test automation' is a great idea and is perhaps contemplating the purchase and use of automation tools, to read chapter 5 before they commit the budget and finalize the project plans. The authors eloquently explain the advantages and disadvantages of common automation techniques such as user input replay tools, providing a real-world counter to the tool vendors' optimistic sales pitches. They don't say "Forget it", rather "If you can live with these significant drawbacks, automated testing may be useful for a certain subset of testing activities". This is a good example of the pragmatism and wisdom found throughout the book.

The book is not an academic treatise full of theoretical constructs/models and testing methodologies. Nor is it a step-by-step manual on how to test a system. It is an excellent read for testing practitioners who are seeking or at least open to advice on how to do their jobs more effectively and efficiently. "This book is for anyone who test software, anyone who manages testers, and anyone who has to deal with testers in their software development projects. That includes project managers and executives." The hints and tips plus career development advice are valuable for testers, especially if they have a few years testing under their belts already. The technical content is minimal and should be readily understood by any IT professional while the management advice should be appreciated by those with management experience or who aspire to become managers.

The book strongly encourages testers to work with developers and project managers, becoming an integral and valuable part of the team rather than an impediment to progress and a threat to delivery deadlines (lesson 12 is typically direct: "Never be the gatekeeper"!). The subtitle's reference to being `context driven' introduces a dynamic approach to testing, relating test activities to the development lifecycle and promoting those that will be of most help to the project at any point. The approach is described further in the appendix but is only subtly referenced elsewhere, unlike certain other books that insist on pushing their One Big Idea down the reader's throat at every possible opportunity.

All three authors clearly have solid testing experience, some 60 work-years between them. There are also numerous (but not intrusive) citations to other helpful resources, further demonstrating the authors' pedigree. Cem Kaner, a consultant and IT professor at Florida Institute of Technology, was the lead author of Testing Computer Software, 2nd Edition, one of my all time favorite IT books. Cem also practices law. James Bach is the founder of a software testing and QA company with silicon valley experience. Bret Pettichord is an independent consultant who edits the Software Testing Hotlist and founded the Austin Workshop on Test Automation.

The "lessons" format leads to a somewhat disjointed flow in places although overall the book is well-structured. At times, successive lessons are directly contradictory, again emphasizing the need for readers to be both alert and open-minded. This is another example of being `context-driven'. Which lesson you choose to follow depends on the circumstances facing you, a form of contingency planning if you will.
Unusually for a published book, several critical comments from reviewers of the draft, as well as occasional differences of opinion or approach between the three authors, are included as footnotes or asides. The authors openly acknowledge the ambiguities and leave the reader to think about them and make the final decision - I like that. This is a book for grown-ups. There are valiant attempts to describe and promote `the tester's nose', that seemingly innate ability of experienced and successful testers to sniff-out aspects of the system that are likely to harbor serious bugs and to design targeted tests that will reveal them. The advice on unstructured `guerilla testing' is not quite so useful, in my opinion, but I'm impressed that the book even tackles such ephemeral concepts.

Even if you only learn something new from a few of the lessons, this book is well worth the purchase price. Testers relatively new to the profession will learn more than grey-beards but even they will probably find some of the suggestions make them re-think long-established ways of working (habits) and subconscious assumptions (prejudices). In the main, the lessons are pragmatic. Some are a bit contentious, perhaps deliberately, and most are both thought provoking and helpful.

Bottom line: recommended for any thinking person involved in application testing including development project managers and IT auditors.

This book is a "must have" item for professional software testers and others who work in software development. As an experienced tester, I recognized many familiar issues and learned some new lessons. I wish this book had been available 25 years ago so I could have avoided learning my lessons the hard way.

The book covers the spectrum of topics important to software testing. Each lesson can stand alone, not requiring a cover-to-cover reading to get extremely valuable information from the book. The lessons are explained, including why the lesson is valuable and the context in which the lesson was learned. An extensive bibliography is also referenced so the reader can read further to understand the concepts and contexts.

Too often, testers ask questions such as "Should I use this test technique?" or "How should I plan my testing?", where the only real answer is "It depends". Successful testing and test planning depends on your context, and that's what Kaner, Bach, and Pettichord have described in this book. Each lesson briefly describes the context in which the lesson is useful. When conflicting practices are useful but in different contexts, such as whether to use IEEE Standard 829 to document testing, the lessons describe when you would want to use which practice and when you would not.

If you're thinking about your testing, and you're not sure what applies to you, this book will help clarify your thinking. This is not a book about how to test per se, but a well-written and useful book about how to think about testing for your organization.

I'm a programmer and this book looks like the mirror image of the wonderful The Pragmatic Programmer - about the same size too! - but from the QA side rather than the programmer side. Love it!

Great cross-training book for programmers.