“Perfection of means and confusion of ends seem to characterize our age.” So said Albert Einstein. I think that sentiment can be applied to tests and their role as a communication mechanism. When you get involved in projects that are focusing on “agile” approaches like behavior-driven development (BDD), I’ve found that you’ll want to make sure you keep focusing on how testing will have a focus on intent (what) as opposed to implementation (how). It’s easy for testers to fall into a group think mentality with developers, who are often pushing an agile focus with an emphasis on what amounts to quality of implementation rather than quality of intent. This means testers have to have a good answer to the question, “Why am I testing?”

Testing provides a service to any project. That service tends to focus on finding information, reporting bugs, indicating risks. That means testing is used for investigative purposes. We’re trying to find things out. But why do we do it? I know what you’re thinking: this seems like a really simple question. But think about it. Why do we actually test? What’s the goal? What are we hoping to get? Here’s my take on it.

• Testing is done for one major purpose: to find information.
• There’s really only one major reason to test: something that matters might fail to work in the way it was intended to work.
• The end result of testing is simple: communication.

I believe that testing works to prove that a shared notion of quality has been reached. So assuming that my primary task is to help my company make the right business decisions about a shared notion of quality, my effectiveness is limited if I can’t communicate my findings to the people in the business who are most affected by those issues that determine what the shared notion of quality is.

I encourage any tester to have a personal goal of becoming a credible, high-integrity reporter of information that people value.

Because testing is an information-gathering process, it seems obvious that you can stop testing when you’ve gathered “enough” information. But how much is enough? I came across the following sentiment in the excellent book Lessons Learned in Software Testing (emphasis added):

Stop testing when it is reasonably believed that the probability is low that the product still has important undiscovered problems.

What I like about that is that the “important undiscovered problems” may not be in the implemented working logic, but rather in the assumptions about how the implementation should be in the first place.

Your testing is there to identify what things might go wrong, to investigate how they might go wrong, and to report on risks. Risks are when certain things either did go wrong or could do so given certain conditions that are spelled out in your tests. The “important” qualifier in the quote above matches the “something that matters” wording I used in my second bullet point earlier. What matters and what is considered important will be rooted in the interests, goals, and even values of various people. Ultimately a test effort is attempting to appeal to people who make decisions. This will usually be the customers or the business acting on behalf of the customers.

So while testing is about communication, it’s not just about communication.

Important Point! Testing is all about communicating important information to important people so that important decisions can be made.

That sounds a little trite, so I usually say that the goal of testing is ultimately about supporting the business and thus supporting the customers. That’s why I test. It may sound simple, but I find many testers, particularly those working in a development-driven BDD environment, tend to say that they test in order to support development, or they test in order to make sure code is good, or they test in order to reduce bugs. Those all may be accurate, but to me those are just part of the means of getting to the end — providing what the business wanted to provide given the needs of its customers.

Given that focus, when I’ve found myself in a place where an agile approach is going to be practiced, regardless of worrying about what “variant” of agile I’m going to be working with, my first goal is to make sure that testers focus on their ability to use tests as a communication mechanism. All of our tests have to tell a story about an agreed upon, shared notion of quality.