Which by the way, if you have, will help you a lot in other life matters too.
While interviewing to hire a software tester, the interviewers almost always ask this one question:
“How do you log bugs?”
It can be rephrased as follows:
“How do you ‘communicate’ bug to the relevant stakeholders?”
The importance of attention to detail, choosing the right approach for testing etc. are very much talked about. Rarely, do we talk about the role of communication in software testing and QA.
Where do we need communication?
Right from the point where specifications are finalized, using your experience you are often able to tell before the system even goes into development if a specification might lead to a bug. You need to raise that issue right there and make your team aware of the risks involved.
You utilized all your skills while testing and found a bug in the software under test. Now, what? Now, you need to effectively communicate it to the relevant parties. It is very important to correctly identify and convey accordingly, the priority of the bug and whether the bug is in the software under test or the specifications or in some cases, it can be in the acceptability test.
How you log a bug is indeed the most integral part of the whole process. Your title should be explanatory enough to give an indication of the problem. The description should be detailed enough to provide the step by step guide to reproduce the problem and what the expected behavior should be. It is a very good practice to aid the description with pictures and videos demonstrating the problem.
Developers sometimes tend to forget to notify the QA team about a bug fix and hence you need to keep on coordinating with them about the status of the bug fix. This part can be tricky at times depending on your relationship with the developers or the development team. If there is the typical rivalry between the QA and dev people then this kind of communication, if not handled correctly, can raise conflicts. This is one of the reasons that the dev and QA teams should be on good terms.
What happens on communication failure?
Depending on the criticality of the software, the outcomes of communication failure can be fairly hazardous. The mishap of Mars Climate Orbiter is also attributed to miscommunication about the measurement unit among the engineers at NASA and Lockheed Martin.
So much goes wrong if you don’t handle your communication well.
That bug that should have been fixed long ago, but you failed to provide all the necessary details to the developer. Also, think of all the related functionality that is compromised because of that one bug.
That instability wouldn’t have been there, had you spoke up in time to convey the risks involved to your team.
Poor communication can lead to a delay in project progress, the team might miss deadlines and you can even end up with a failed project.
My Communication Routine
We follow agile practices and usually there is a very informal communication among the team. We use Asana for Task Management as well as Bug Tracking and Slack for team communication.
I am a strong believer in informal communication. If there is a small bug, like a little tweak in the UI or a small typo or any other issue like that, instead of spending time on logging it, I message the relevant developer on Slack and get it resolved.
“Don’t document the problem, fix it!”
– Atli Björgvin Oddsson
However, if the problem is relatively bigger or if it appears that you might see it again in the future even after fixing due to too many dependencies then it is better to log it, add all the stakeholders as followers, assign to the right person and carefully follow the progress.
A very underestimated strategy here is: Talking! Project Managers and relevant authorities should promote the team to talk about the software system under test and development. It can be very productive for the team and the product. You can use group chats, brainstorming session or anything that works in your environment. Have conversations about how the product is doing, which features can be improved if you were to finalize the specifications and how the progress is going. You never know, it might give you an idea to improve or accelerate the whole process.
A software tester is useless to the team if his communication skills are not up to the mark. Hence, it is very important to portray them in the interview. And given that you do have good comm skills, presenting yourself right shouldn’t be a problem. Good communication goes a long way, no matter what!