A common problem area testers often struggle with is communicating testing practices, documentation and reasoning...
to non-testers. The language is different. Many of the ideas might seem alien to those who aren't testers. The only real common ground between testers and non-testers is a desire to release defect-free software on time. But how does one communicate the need for certain tests to someone who lacks formal testing experience and knowledge? The answer is modifying the language and establishing context.
"Testers talking among testers is a relatively simple task," Catherine Powell, Principal for ABAKAS and a tester with 10 years of experience, said as she began her morning session at the CAST 2010 conference, "but once you leave 'Testerville' you enter a serious gray area where communicating ideas quickly becomes laborious, sometimes impossible."
Testers need to know that non-testers have difficulty understanding testing concepts. They typically don't understand the tooling used to accomplish testing. All they know is that they want results – high-quality software that they can sell worry-free and rely on. To ensure this is the end result, "testers need to know how to communicate with clients, stakeholders, developers and managers that are not fluent in software testing," said Powell.
In order to overcome language and conceptual barriers, testers need to find ways of establishing context between test procedures and results-focused clients and managers. Powell uses a series of questions that she asks herself before attempting to explain a potential test problem to a manager and before she starts writing a test plan.
Powell's guiding questions list:
- Who will see this?
- What will the recipient get from the information I am presenting them with?
- How do I transmit this information in a relative way?
- What contextual information is included?
- What do I need to share with them? What can they do without?
- How can I differentiate certainty from uncertainty?
After finding a way to communicate with non-testers, the next trick is learning to write tests that meet the prescribed project needs as explained by the project's non-testers. "Here is the world around me," Powell explained, "in tester communities and to a certain extent outside of them, there are words that testers and non-testers understand. Everyone, tester or not, has an understanding of what "user story" pertains to, they know what a "user interface" is. The next step is organizing what needs to be done on the tester side to accommodate the requests of the product owner." Creating ties between how a negative result on a regression test might impact the final product is huge. If you can explain the problem without using tester lingo, then you are closer to finishing the product and closer to defining how you intend to do so.
Testers are the repository for all software-related questions that come from a variety of people with many different specialties and backgrounds, many of whom are not in the IT profession.
To help keep managers and other non-technical, non-tester types who are very important in the delivery of the product, on board with the status of projects, Powell's company uses JIRA to help track the completeness of projects. JIRA is an Atlassian product that allows all technical test documentation, problems and solutions, to be stored as a wiki and available to all registered users. They also use JIRA to help construct test plans for projects.
At ABAKAS, Powell uses the JIRA mapping technology to help create and disperse two-types of test plans. One is written in tester jargon, using links contained in the wiki to point to certain tests, solutions and other pertinent data. The other is a more simplistic version intended for non-testers to read.
"Being able to speak in both test and English is very important in today's software organizations," said Powell.