Serial Book Review: Lessons Learned In Software Testing, Chapter 1

A few weeks ago, a colleague queried me for advice regarding implementing a testing role on a project for which he is a product manager. Over the course of that discussion, one book frequently sprang to mind as an ideal tutorial for product managers and new testers, alike: the remarkable collaboration of James Bach, Brett Pettichord, and Cem Kaner, Lessons Learned In Software Testing.

Since then, it has occurred to me that businesses relying on tech for their bread and butter — especially startups and small ventures — are really suffering for lack of awareness of this book. All around me these days, I see the symptoms: profound ignorance, hubris, and contempt for the role of quality and testing in various organizations and projects. A chronic condition that, at the very least, might be treatable with books like this one.

In lesson fifteen of Lessons Learned In Software Testing, the authors state explicitly, …Don’t expect anyone else to read [this book]. It’s up to you to let your clients know what you need in order to do your job effectively… As a tester and an individual contributor on any team, I definitely take this to heart. I try always to raise the quality awareness of the team, and to be sure that our quality choices are conscious decisions.

But it seems to me that the lessons in this book would have far greater reach and far more impact if they were known to more than just a handful of good testers. It would broaden everyone’s understanding of the nature of quality, raise the standard for what is expected from a good tester, help to rein in ignorance-borne attitudes like those I’ve linked to above, and ultimately, improve the output of an entire industry.

So, I’ve decided to do a chapter-by-chapter review of this book in the hope that a public hearing might help to raise awareness and encourage conscious decisions about quality, not only for the teams in which I participate, but across the tech sector as a whole.

Over the next few months, I’ll cover a chapter per post, roughly once a week. This week, obviously, starts with chapter one. And its focus, appropriately, is perhaps the most pressing question for software development today:

The Role Of The Tester

No single question about testing could be more important than this one, or more misunderstood. As I noted above, we live in a world where the very notion of testing as a distinct role on a project is rapidly becoming synonymous with obsolescence. If testers do not find their voice in this new tech economy — out here on the startup frontier, where the death of the elderly vertical giants is not a mere speculation, but an active and ongoing project — then they will cease to have a voice at all.

Is it possible that this death is necessary, like buggy-whip manufacturers in the age of the automobile, or lamp oil distributors in the age of the electric light bulb? Maybe. Or maybe the discipline just needs to learn to be flexible, and to pivot with innovations when they come, the way IBM managed to transition from mechanical tabulating machines into computers in the 1930’s.

Lessons Learned In Software Testing doesn’t directly address these larger questions, but the implications are clear in the lessons discussed in chapter one. All throughout this chapter, the reader is constantly reminded to be mindful of his value to the organization. For example:

You serve the business… perform your work in a way that takes into account the short-term and long-term interests of the company… If you spend time and effort on requirements that your clients don’t care about, you risk being treated as irrelevant or counterproductive.

For testers to remain valuable and relevant to any team, therefore, they must be clear about their mission, understand their value, and work to negotiate these things as equal partners with their team members.


An essential prerequisite to understanding your value, according to the authors of Lessons Learned In Software Testing, is to understand that you are in a relationship with your team (whether they are your clients, your coworkers, or your colleagues). Good relationships are built on an exchange of shared value, and that shared value is discovered and defined by negotiation. This theme is an explicit and urgent one for the authors:

A role is a relationship. That means you don’t control your role, but you can negotiate it… If you can’t come to agreement on the mission, you won’t have a good foundation for anything you do… When you’re clear about your role – when you have negotiated it – you have a foundation for setting expectations in any situation that may arise.

The principle behind this lesson cannot be overstated. Every meaningful and lasting thing we do in life involves relationships, and requires our ability to engage in them and navigate them effectively. The more open, honest, and peer-oriented they are, the better we will understand what is expected, and the more satisfying and effective the relationship will be.

However, if you or your teammates misjudge or misunderstand the nature of your relationship, everything you attempt together will suffer a much lower chance of success. If you see yourselves as adversaries, trust will be almost impossible to achieve, and negotiations will be frought with suspicion and deadlock. If you treat the relationship as exclusively transactional, you will limit opportunities for collaboration and cooperation, and lengthen the duration of your feedback loop. If you are trapped in a hierarchical mindset, the project will be encumbered by leadership bottlenecks and “down time.”

One important factor to bear in mind is that all relationships are a two-way street. For negotiation to be successful, you must be as mindful of your negotiating partner’s goals and desires as you are your own. Empathy is an important tool here. And, though the authors of Lessons Learned… were not explicit about this, I think they show an intuitive understanding of this tool in tips like this:

Your success is measured primarily by how well you serve your clients’ desires and best interests. That might not be so hard, except that testing has many clients. They all have their own needs, and their collective needs don’t necessarily align…

Having a clear understanding of what the team wants to achieve means having a clear understanding of what motivates each role in the team, where the incentives and challenges lie, and how they all interact. All of this requires a good deal of empathy and curiosity. These are two traits I find indispensable as a tester, and two traits that have served me well in relationships outside of my profession as well.


Lastly, as I alluded to in the introduction to this post, the need to educate our peers — and ourselves — cannot be emphasized enough.

The last lesson in chapter one addresses this problem exclusively. The authors focus on insuring that you clearly communicate the needs of your particular role within the context of the project. But embedded within this task lies a much more important goal for all of us:

Salvaging software testing from the dustbin of ignorance and hubris.

So say the the authors:

An important part of the role of testing is to explain testing to our clients. Your explanations are like a flu vaccine — healthy and not that painful, but the effect wears off, so you have to do it over and over again.

This is one of the largest reasons why this blog exists. I want to explain testing to more than just my teammates. I want to explain it to as many people as I can reach. It is one of the least well understood roles of the software development process, and as a consequence, one of the most endangered roles.

This is also why I am eager to promote books such as Lessons Learned In Software Testing. Whether or not you necessarily agree with every position these authors take, what they’ve done with this book is to provide a plain-spoken manual, not only for the successful tester, but also for making the role of testing itself a success once again.


In keeping with this spirit, I will be continuing this series next week, with a review of chapter two from the same book, entitled, Thinking Like A Tester. Wherein, I’ll be enthusiastically bloviating on one of my own favorite subjects: Critical Thinking Skills. 😀