A lot of pros in the industry spend a good chunk of time talking about software testing tools; when they do, typically they mean programs or applications which enable certain aspects of the testing process. But have you ever thought about what the most important tool a software tester can use would be? To us, it seems kind of obvious that communication is the ultimate software testing tool.
Think about it. All of the test documents we use on a daily basis – such as our requirements, test cases, and bug reports – are a means to an end, and that end is enabling effective communication between testers, testing teams, and the client. In fact, from gathering the requirements to performing accessibility testing, much of the testing process is founded on the necessity of communication.
Communicating everything you need someone to do at once helps the person you’re speaking to keep track of what’s expected of them, but giving too much or too little instruction can be as damaging to productivity and efficiency as not saying anything at all.
To help you harness the power of effective communication for your software testing team, here are some helpful dos and don’ts:
DO: keep the stakeholders aware of the general situation (probably high-level weekly updates to team leads & management)
DON’T: send the minutiae to people who have neither time, interest, nor skills to understand what you’re saying.
Excluding stakeholders won’t go over well, but you don’t need to include them on everything that’s happening with the project; they aren’t going to understand, and for the most part, they just don’t care. It’s better to let them know when something important happens, but leave them out of smaller decisions.
DO: bring in relevant experts and resources when they are needed
DON’T: keep them in conversation once they are no longer active
There will probably be aspects of testing that need to be handled by outside parties, and those individuals should know everything necessary while they’re working for you. However, once their participation is no longer needed, there’s no need to keep them up to date with the project, such as the IT professionals after the access issues have been resolved.
DO: Send out actionable emails to people who need to act and people who are dependent on that actionable item being completed
DON’T: Maintain a mailing list that is large and fills everyone’s inboxes with emails they have no reason to read
The quicker you let people know what you need them to do, the quicker that task will get done, which is particularly important on time-sensitive projects. However, flooding their inboxes is an annoyance at best, and a great way to get completely ignored at worst.
DO: Give people all of the information they need to perform their duties in one go
DON’T: send people generic instructions with a direction and hope for a specific result
ALSO DON’T: trickle in information if you can help it – revisions are more expensive than clean design
Communicating everything you need someone to do at once helps the person you’re speaking to keep track of what’s expected of them, but giving too much or too little instruction can be as damaging to productivity and efficiency as not saying anything at all.
DO: Tailor the language of the messages to the audience
DON’T: Use jargon you know they won’t understand
ALSO DON’T: use vague similes and metaphors when there is a term the audience should know for what you are doing. For example:
Don’t tell your actual team that “We improved the speed of the program working by making tweaks to the core algorithm,” because they actually need the details of what’s been done, fixed, changed, etc. Similarly, don’t say, “We improved the O(n) of the tertiary search of the ‘findBk’ method in the ‘libBksManyBks’ class by 33% by utilizing a recursive implementation of Newton’s Method instead of the linear search we had in place previously. Note that this will break searching in unsorted libraries, so make sure all libraries are sorted before they are searched!” to the business managers, because they’ll have no idea what you’re talking about.
While these communication tips are meant for software testing professionals, at their core they’re simply examples of how to communicate well with anyone. Knowing who you’re talking to and giving them no more or less information than is necessary for whatever you need them to do is basically the core at every successful communication you’ll send, both as a tester and in the rest of your pursuits.
