yellowpencil: The path to effective communication for software testers
A 5 minute read, written by Tallitha
June 17, 2015
Imagine that you’re booking a flight to Paris. If you don’t pay attention to the specifics, you might find yourself on a flight to Paris, Texas, instead of Paris, France. I’m sure you’d agree that those little details are essential.
It’s an example of how poor communication, especially when you’re not speaking to someone face to face, can cause confusion – and you might end up eating BBQ instead of a croissant.
Communication (noun): the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs.
Communication is one of the most important soft skills a software tester can have. Communication between testers and developers is crucial, and it is definitely the key to successful projects. Poor communication can lead to misinterpretation, impact productivity, and cause a lot of rework, especially when reporting defects and working with remote teams.
Yes, we’re all busy, but it usually takes more time to write a bad, defective description than a good one. Why? Initially, it can save you time when describing the problem, but it can create extra effort for you later on. Today I’ll show you how a small process change that helped us facilitate communication between our team members.
Keep information moving forward
It’s very common to have quality assurance (QA) team members working across different team projects. Here at Yellow Pencil it’s not different. The QA members work on more than one team project at a time with different individuals, different clients, and different technologies. It’s very important to communicate effectively when reporting a defect; otherwise the person assigned to fix it will likely ask you for additional information or instructions on how to replicate the problem.
What seems like a simple act can actually delay progress, and all those little delays can add up to a lot of wasted time. It’s worth entering all the necessary information on a bug report while everything is still fresh in your mind, no matter if you are a developer, a UX designer, or a tester.
Keep in mind that in a fast-paced work environment it’s typical for people to leave or join project teams. When that happens, the work should continue moving forward and whoever gets to work on bug fixing needs to understand what the actual problem is — and quickly. The person who had submitted the bug may be on vacation having a joyful time eating a croissant in Paris (or BBQ in Texas) so it’s probably not a good idea to call her asking for further instructions such as, “I can’t replicate this bug. In which environment did you find that problem?” Investing time writing a good bug report is a time-saver.
5 steps to writing a rock-solid bug report
We have created a basic template to guide us in reporting bugs. It’s very simple, efficient and widely used in the world of QA. But first, here’s the foundation for writing a rock-solid bug report, following five essential steps:
- Be specific: Clearly summarize what the problem is – get straight to the point.
- Be descriptive: Include every single step to reproduce the problem; add screenshots.
- Be focused: Pay attention to what really matters – the actual problem that needs to be fixed.
- Be organized: Report only one problem at time. If there’s more than one problem related to the feature you’re testing, split them into separate issues so they can be quickly fixed and tested.
- Take time: The title or subject is very important when triaging defects because it helps to instantly identify what the problem is without getting into details. So take time to write something specific; it will save you time in the long run. For example, saying that “the system is not working” is very vague and does not give developers enough information to help find the root cause in order to fix the issue.
The steps to reproduce the bug are meant to be “baby steps” so anyone can easily replicate the problem. If you can’t reproduce the problem by following your own steps, how will anybody else?
Here’s the template:
A brief summary of the bug.
STEPS TO REPRODUCE
- Describe the first step to reproduce the problem.
- And so on ...
Briefly describe what the actual problem behaviour is.
Briefly describe the expected behaviour based on the requirements or acceptance criteria.
Describe where the defect was found. Include the browser version, mobile device model, etc. If there’s more than one test environment, include the URL.
And finally, a real example of a completed bug report:
Cannot sign up for an account because I can’t enter a special character in the email field.
I tried to sign up for a new account at <URL> by entering my full name, email address and password, but then I got an error that prevents the account to be created. When I hit the “Sign-up” button, I got an error message saying that the email cannot contain special characters. That’s exactly the same error message displayed when I enter a password with special characters, so probably the same validation check is being applied to the email field. This problem only happens on desktop browsers, not mobile devices. See attached screenshots.
STEPS TO REPRODUCE
- Navigate to <URL>.
- On the “Sign up” page, enter full name, email address (e.g., firstname.lastname@example.org) and a password.
- Click “Sign up” button. The error message will be displayed because the email field contains special characters.
Cannot sign up for an account when I enter special characters in the email field (e.g., a valid email format).
Should be able to sign up for an account by entering a valid email format.
Safari 8.0.6, Firefox 38.0.1, Chrome 43.0.2357.81, and Internet Explorer 10.
Say what you mean — and get what you want
Getting to Paris, France instead of Paris, Texas involves investing a little time into finding the right flight code, and you can already imagine the benefit of making this extra effort. Investing time writing a good bug report isn’t that different. After all, it’s the main communication channel between the QA and development teams. It might seem like a lot of effort at first, but every second spent on that task will save you a lot of time down the road. Not to mention the productivity and high quality of the deliverables on your project team. There’s a huge chance of getting the things done faster and without any misunderstanding or rework. So say what you mean to get what you want.
Want to learn more about writing rock-solid bug reports or communicating effectively with QA teams? Have some tips of your own to share? Get in touch or leave a comment below.
As a QA analyst, Tallitha knows how to meet our customers’ needs by advocating for best practices and the finest quality in our work. She’s also the voice inside our heads that’s always telling us to do things the right way (because software development isn’t a unicorn wearing pearls).
After (and sometimes during) hours, Tallitha’s a serious foodie, frequenting the finest dines in town. Check her Instagram feed to find out what she’s eating now.
Source: The path to effective communication for software testers
© copyright 2015 by yellowpencil