Emails, Meetings, Reports
Oftentimes people say communication is important and when employee satisfaction surveys are done, the end result is that employees want better communication in and from the company. Then we are told how the company has initiated improvements in communication – shortly after someone has mentioned how we use email, chat applications, quarterly meetings, etc., so communication is there already! (This is usually told by the same people who think a yearly team building has anything important to do with … team building.)
I used to think similarly, that it should be enough for everyone to read my bug reports and other artifacts to get a status update on testing. However, like I explain to companies how communication is not really about having a quarterly meeting or sending updates via email, I explain to testers how we can do better in communicating our work. One key is shortening distance and feedback loops in the discussions.
Going Back to Basics
Why do babies like toys that make sounds? Why do they hit the floor with a spoon and laugh? It’s not the spoon that is interesting, but because it makes a sound after an action, thus giving rapid feedback. Why did I fell in love with testing so fast after being a recreational coder for years? Because it sometimes took weeks to get any code “done”, whereas when testing, I got new ideas constantly and the systems I tested provided quick feedback.
It’s interesting how we actually know this innately. If we want to know how someone is feeling, we prefer to discuss face-to-face or give a call, instead of sending an email. When we are driving a car and petroleum is running low, we keep staring at the fuel gauge. We are shortening the distance and feedback loops in our private lives without thinking about it, so it would feel normal to do this also at work.
What, Where, When?
Scrum manages the communication issue with various events, such as The Sprint, Daily Scrum, and Sprint Review. A tester can use the same ideas: decide how much work you want to plan (a day, a week, a month…), find out who should be informed of your progress and how often (e.g. the rest of the development team could want a daily update), and after the work is done, present what you found and summarize what you learned. It’s important to not only communicate bugs, but also what you have planned/done/not done (yet), are there things slowing down the testing, could you use someone’s help, and so forth.
As an example, once I had problems executing our test automation for a product. After trying to solve it by myself, I asked a programmer to assist. Not that it was his problem, but a) he was sitting close to me and b) the system administrator was on vacation. I left a message on team chat channel, where I quickly described the issue and who is already working on it. I also put there the link to the ticket I had created. We could not fix it that day, so at the end of the day I sent out an email to stakeholders as an alert, where I explained the problem, impact, what we did and what we plan to do next, and what kind of help we would like to receive.
After the problem was fixed the next day, I left a comment on the team channel, closed the ticket, and dropped an email to the stakeholders. Then I took my notes and appended Lessons Learned, because we knew a similar problem might happen in the future. (We have no control over the DNS table, where a change initiated the snowball effect that broke our test automation.) The comment on the team channel was my way not to push information on the rest of the team, but to use a more gentle pull request which allows them to check the status when convenient. Even if the stakeholders could have seen I closed the ticket, I followed up with an email, because I thought some of them might otherwise miss the information.
I Communicate, So I Am
Sometimes it’s good to delay delivering a message. For example a developer who is struggling with a complex task doesn’t necessarily need to know about the bug you just found from a different part of the product. In this case, a message on a team chat is usually a good option. Sometimes it’s fine to use email, e.g. when you want to address a wide audience in multiple timezones – although IRC, Slack, etc. could be better than e-mail. There is context to everything, but often companies suffer from the lack of early and frequent communication, so at least do your part and let the people know what’s going on.