Software testers like software developers might be generally more introverted than extroverted. However, with Agile software development approaches like Scrum, communication between team members and with external stakeholders become a critical for project success. In this extract from her book “Guide to Advanced Software Testing”, Anne Mette Hass presents some general ideas about the communication issues for software testing teams.
Author: Anne Mette Hass
Testers need to communicate with people in all the organizational units involved in the testing. This means that testers have to communicate with many different people at many different organizational levels internally in their organization and externally, for example, with customers.
The first thing to remember is that communication is difficult. The perfect way of communicating where people understand each other absolutely perfectly and completely is not possible.
We are people and we are all “colored” by our personalities, our upbringing, and our experience – just to mention a few factors.
But we have to communicate and we have to make an effort to make it work. One of the things we can do is to understand the type of people we are dealing with, both in terms of their personality types, their education and background, and their responsibilities and working conditions.
Another thing is to accept that it is the “sender” of the information who is responsible for making it understandable to the audience. We as testers must learn that other teams talk in different languages: management speaks “money”; users (and marketing and sales) speak “functionality and quality,” developers speak “technique.” All of our communication must be targeted
to the audience.
The most important and perhaps the most difficult communication lines are those between the testers and
* Project management;
* Developers;
* Users.
Communication with project management is most often done by the test manager. Project management needs to inform about and discuss with testers aspects such as expectations, resources, constraints, quality criteria, and changes in plans. Testers for their part must inform project management about issues such as the progress of testing and the quality of the product under test. This communication is usually based on written documentation (i.e., test strategy, test plans, test progress reports, and test summary reports), but should also be accompanied by verbal communication.
The communication with development is usually done by test analysts and designers. Development needs to inform testing about issues like especially complex or difficult areas of the product, which areas are new development and which have “just” been updated, other areas that need special attention for various reasons, changes in requirements and/or design, changes in delivery schedule, specific difficulties during development, problems reproducing reported failures, and when and why new test objects are delivered for testing.
Testers need to inform development about failures found, problems arising during retesting of corrected defects, and problems concerning the number and/or types of failures.
These issues can be delicate to talk about. The information should be conveyed diplomatically as a means of improving the quality of the product — not as blame! Also here written documentation may constitute some of the communication, but verbal communication should not be eliminated completely.
The users may communicate with many different test roles depending on the organizational structure. Useful information can be provided by users to testers, for example, concerning their expectations regarding the new product, risk areas to the business in the product, assessment of the effect of identified risks, important areas in the product seen from the users’ perspective, and background information about the business and the business processes. This information can be used to support the risk analysis and the prioritization of the testing. Users will often receive or see test results. Users with little knowledge of testing may need help interpreting these results.
About the Author
This article is taken from Anne Mette Hass book “Guide to Advanced Software Testing” and is reproduced here with permission from Artech House. Anne Mette Hass is a Compliance Consultant at NNIT. She earned her M.Sc. in civil engineering from the technical University of Denmark and an M.B.A. in organizational behavior from Harriot Watt University, Edinburgh, as well as the ISEB Testing Practitioner Certificate.
This article is a very high overview of one of the key factor for software development projects: having people that are able to constructively talk to each others!