Speaking the Same Language in Software Testing
Arguments in software testing often revolve around language.
I had an article published last week about some problems with test cases. I talked about some of the problems test cases introduce because of the way they try to force abstraction and standardization into actual testing. A few days later, a reader emailed the editor claiming that test cases are a must-have for testers, and no professional tester would work in the way I described.
We had two problems: the reader and I were using the same words to describe very different things, and each of us thought our personal definition reigned supreme. There are ways to avoid (or at least reduce) these misunderstandings.
When people say test case, some mean an exact procedure for navigating a piece of software, some mean a checklist of what to look at in a product, and others are referring to a vague idea that might help guide testing for a specific part of a product. Testers like to use phrases, like test case, as shorthand. We have plenty of examples: exploratory testing, regression testing, smoke test, bug, etc. We use these phrases every day, but we can’t be sure that you and I mean the same thing when we do.
There are no standard definitions for terms we use in software testing, though some people have particular ideas. For example, the people that coined the phrase exploratory testing mean something very specific: simultaneous learning, design, and performance. But the rest of our language is specific to a small group of people within a company, at best.
Regression testing is a good example. With that phrase, some people mean retesting something, some people mean running through all the testing they did during a sprint after development is done, and others mean exploring to find risk introduced through a development cycle. This can work out with people who communicate frequently, but it’s not scalable. Two people might understand completely what each other means, but then a testing group might have only a vague agreement, and a company will be completely confused.
When I first meet a tester or start a project with a new group of people, I like to switch back to “longhand” communication. Instead of saying, “It’s time for some regression testing,” I say, “It’s time for regression testing, and what I mean by that is ...”
At this point there are a few options. The other person might respond that they understand and go to work. The other person might ask for clarification about what specifically was meant by regression testing, and how they should go about doing it. Or they might completely disagree with my definition and have a longer conversation about the meaning of that phrase.
This tactic is a lot like scrum. I start by making a statement that someone has a problem with. We talk through the disagreement, and then get to what matters: the work. The point is that a discussion is happening, and it’s this communication that gets us all on the same page.
