|Lessons Learned in Software Testing|
|Author: Cem Kaner/James Bach/Bret Pettichord|
|Pages: 352||Published: 2001|
|Publisher: John Wiley & Sons||ISBN: 0471081124|
|Click to Buy|
| || |
|Topics: Test Design / Test Execution / Test Management / Unit Testing / Test Automation / Test & Evaluation|
This book offers decades of software testing experience condensed into the most important lessons learned. The world's leading software testing experts lend you their wisdom and years of experience to help you avoid the most common mistakes in testing software. Each lesson is an assertion related to software testing, followed by an explanation or example that shows you the how, when, and why of the testing lesson. More than just tips, tricks, and pitfalls to avoid, Lessons Learned in Software Testing speeds you through the critical testing phase of the software development project without the extensive trial and error it normally takes to do so. This book has been selected as a finalist for one of Software Development Magazine's Jolt Product Excellence and Productivity Awards in the Books category.
| ||Review by Cathy Bell firstname.lastname@example.org|
Back to Top
Imagine yourself sitting in the gallery at a trial in the Supreme Court of Quality. Three men are brought forth to testify and each is sworn in to “tell the truth, the whole truth, and nothing but the truth.” The busy court recorder captures all the testimony, and the transcripts are released to the public in book form. This is how the book could have come about, because the authors have definitely told the truth, and nothing but the truth.
The authors think like testers. Testers are usually from many diverse backgrounds, but as they remind us in chapter 2, “Most people agree: testers think differently.” Think of it this way: generally when testers speak, you will notice others (nontesters) getting a puzzled look on their faces, and their heads tilt to one side or the other. It’s a puzzled, bewildered, where-is-this-coming-from look. While reading this book, you too may find your head tilting to one side or the other, but most often you will find yourself nodding in agreement. This is a truthful, no-nonsense collection of lessons learned in software testing that is “to stimulate thought, not only agreement.” Instead of just giving charts, graphs, and sample test plans, the authors have given us a personal as well as professional look at their experiences. They also give us charts, graphs, and sample test plans they have implemented over the years.
The book is based on a context driven approach to software testing. The authors advise us to read a lesson or two and then ponder how that lesson fits into our own context, our particular work. Aha! One-size testing does not fit all. (They may be stoned in the coliseum for such outrageous opinions!) Chapter 1 explores the role of a tester, and they even dare to mention that you will not find all bugs! Chapter 2 reveals there is such a thing as thinking like a tester. Lesson 32 points out “if you expect to receive requirements on a sheaf of parchment, stamped with the seal of universal truth, find another line of work.” But what follows is useful guidance on how we can gather enough information, from many sources, that we can use in place of or in addition to requirements.
Chapter 3 covers testing techniques and presents the five-fold testing system. There is guidance on how to create a test matrix. Chapter 4, bug advocacy, starts by telling us “a tester who can’t report bugs well is like a refrigerator light that is only on when the door is closed.” They admonish us to give thought to what we write and how we write, and remind us that our reputation is often based upon our bug analysis and reporting efforts.
Chapter 5 touches on the sacred cow of automated testing. They again recommend selection of both the automated tools and the tests you will automate based on your context, and not to be fast-talked by tool vendor salesmen. The day a test tool can run all my tests, require minimal set up, and keep my desk clean is the day I worry about test tools replacing testers. Some of the truths covered in this chapter include the following: a test tool is not a strategy; test automation is a development process; test automation is a significant investment; and test automation projects require skills in programming, testing, and project management. Chapter 6 covers documenting testing (or, how many trees will the testers kill on this project?). Remember, standard templates are only good in the context of your testing effort.
Chapter 7, interacting with programmers, is a must-read for anyone considering a career in testing. Programmers are experts at how machines think, but they are not machines. They have feelings and care about the work they do. Who knew? Chapter 8 deals with managing the testing project. Remember, testing is only a subproject of the development effort, and we have to negotiate with the developers the best course for testing. Other lessons in this chapter deal with how we do our job managing testing: don’t try to create a control culture; be prepared for the build; there is no universal formula for knowing how much testing is enough; try testing in pairs; and a suggested structure for a weekly status report. Chapter 9, managing a testing group, is a must-read for all test managers. If you’re not a test manager, copy this chapter and leave it for them to read. I would highlight lesson 226, the morale of your staff is an important asset.
So, what are my options if I choose a career in testing? Chapter 10 has some practical guidance that might surprise you: whatever path you take, pursue it actively; extend your career beyond software testing; and lots of other companies are as screwed up as yours. Chapter 11 is the final chapter, showing us how to plan a good test strategy—again, within the context of your work. The appendix is a short explanation of the context driven approach to software testing, just in case you are not sure what it’s all about.
The most valuable lesson to me was: build a portfolio. There no such a thing as a sure thing, and your wonderful fulfilling job could be gone tomorrow. Your resume cannot show all of the skill you possess, whereas your portfolio certainly could. If you are prepared with a portfolio of your past experiences, it will be much easier to convince new employers that you really are as good as you say you are.
Your experience will certainly vary from the authors’; however, you will probably find a lot in common as well. There are many lessons to be learned from this book, and you’ll find yourself nodding in agreement more often than not.
Throughout the book references are given to other resources for further information. The wealth of references reinforces the authors’ efforts to provide the most useful and practical information available to make your life easier and more rewarding as a tester.
| ||Review by Lee Copeland email@example.com|
Back to Top
Rather than write yet another testing tome, Kaner, Bach, and Pettichord have adopted a unique format through which to share their insights into testing. This book comprises 293 “lessons,” paragraph- to page-length discussions on a wide variety of testing topics grouped into categories such as “The Role of the Tester,” “Thinking Like A Tester,” “Testing Techniques,” “Automating Testing,” and “Your Career in Software Testing.” These lessons can be read start-to-finish or can be sampled based on the reader’s interests and needs. Each lesson discusses a very specific aspect of testing (and many also have catchy names): #1 – You are the headlights of the project; #11 – You don’t assure quality by testing; #14 – Beware of becoming a process improvement group; #23 – A tester is more than a tourist; #43 – Fresh eyes find failure; #58 – Your bug report is your representative; #106 – A test tool is not a strategy; #145 – Use the IEEE Standard 829 for test documentation; #146 – Don’t use the IEEE Standard 829; #151 – Develop programmer’s trust; #154 – Focus on the work and not the person; #162 – There are always late changes; #181 – Programmers are like tornadoes; #189 – There is no right ratio of testers to developers; #198 – There’s nothing more dangerous than a vice president with statistics; #227 – Don’t let yourself be abused; #229 – Don’t let your staff be abused; and finally, #252 – Lots of other companies are as screwed up as yours.
Each of these is a gem of wisdom, encapsulated in a very few words, giving useful guidance, not just theory and philosophy.
I recommend this book to all those involved in testing, from novices to experts. This book is delightful to read (especially for testers like me with a short attention span). As I perused the book I found myself underlining important sentences, drawing big stars by the lesson titles, circling key ideas, and writing YES! in the margins again and again.
Some of my favorites statements are: (1) “Negotiate your mission with your manager. If you can’t come to agreement on the mission, you won’t have a good foundation for anything you do.” As a consultant, this is the first and most important thing I do with a client. (2) “No matter what else it’s about, process improvement is always about feelings.” As such, it can be exciting work or a quagmire of no return. (3) “Your responsibility is not to make sure that all bugs are fixed. Your responsibility is to report bugs accurately and in a way that allows the reader to understand the full impact of the problem.” This is often a difficult concept for novice testers to accept. (4) “Test groups can make themselves more capable … by hiring people into the group who have diverse backgrounds.” It’s so easy to want to hire people just like ourselves. It is more important to hire people who have strengths where we have weaknesses to create a balanced, excellent testing team. (5) “A test documentation template is no substitute for skill.” Often we get caught up in the format rather than the content; the style rather than the contribution.
In addition to its numerous lessons, the book also contains a number of valuable but often overlooked techniques (such as all-pairs testing) and checklists to make our testing more effective and efficient.
And, just for fun, see if you can find the quotation from Chairman Mao in the Preface.