We all have heard stories that go like this: A developer is going through her day, all fine until…
She receives a screenshot. With no other context. And a message: “This is an error, fix before today’s production release”.
But what is wrong? What’s the error? And is this production? Or Staging? And what were the steps to reproduce it? And this happens only in some accounts but not all? Plus a million other questions. If the other person stops answering our questions (the cherry on top of the cake 🎂), then the developer has to go through a long adventure of catch-a-bug.
Thankfully, most companies have an issue tracker like Jira where they share bugs, prioritize which ones should be worked on at each time, and hopefully provide some information. But this doesn’t stop at the relationship between business/QA and developers. We often don’t communicate very well the information between tech departments, or even inside our team, leading to hours of discussion in which each individual is pointing to a different problem.
There’s a clear problem here - the lack of communication and guidance from whoever reported the bug. But the question is: how can we fix this and ensure that we developers lose as little time as possible trying to decipher a bug?
The answer? Creating a proper Bug Ticket!
A good bug ticket, regardless of the platform it is hosted in (Jira, Github, e-mail, or a piece of paper), will need to have the following:
- A title - Here we can name the components, applications, or pages in which we have the problem, plus a very brief description
- Description - an overview of what is happening, plus a reference to the stories/requirements that this issue fails to solve
- Steps to reproduce - a list of very detailed steps needed to reproduce the bug, this can go into the small details of “open the app”, or “click on button X, wait for 2 seconds, and then tap on the second option”
- Expected Result - what was expected to happen?
- Actual Result - what happens? Aka the bug itself
- Screenshot/Video - if needed, a screenshot or a video showcasing the issue
- Version, platform, and environment - Does this happen in mobile but not on the web version? Is this in the development or production environments? And what version was this tested on?
(And, for some applications, it might also have “Pre-requisites”, if there are a series of well-known steps needed to start replicating the issue and Dataset where the QA shares all the data necessary to replicate the issue)
Imagine the following, we are working at Company Z in which we have a login screen. Each time that the user tries to login, an error occurs. The bug report could be the following:
**Title**
[Login] User cannot log in with valid credentials
**Description**
When a user tries to login with valid credentials, the website
throws an error stating “The credentials are not valid, please
try again later”. I have contacted the system admin and verified
that I have the correct account details, so this must be an
applicative error.
**Steps to Reproduce**
1. Go to company.com
2. On the top bar, click on the user profile
3. On the dropdown, select “Login”
4. On the email field, put “testmail@example.com”
5. On the password field, put “Pass90?”
6. Click on “Login”
**Expected Result**
I expect to be logged in and taken to the user’s dashboard
**Actual Result**
An error message appears stating “The credentials are not valid,
please try again later”
**Platform**
Web, with Chrome v90.0.1
**Version**
1.0.4
**Video**
`video showcasing the error`And with this information, the developer could:
- Verify if the login works with the given set of user/password combination
- Verify in the database if that user exists
- Verify if the backend calls are working with those fields
- Verify if this is an error on the frontend, for example, a serialization error.
This vastly reduces the investigation and debugging time in hours, instead of just saying “This is wrong, pls fix before prod release, thx”
So next time that you create a Bug in your company’s issue tracker, be mindful of what you are writing, you never know if the developer that’s going to take that is you… in 3 months from that point… when you have no clue what was the error anymore.
If you want to know more about QA, you can take a look into Black Box Testing from Guru99, and this list of the Best Issue Tracking Systems of 2020 from Brainhub - if your company doesn’t have one set in place, now’s the best time to implement one!
This week I ask one thing from you!
The next time you’re developing something and find a bug, create a bug report using the template from this article. Be sure to take a screenshot or create a video to showcase the bug! Then you can (remove all the confidential information) and share it with me via twitter! @gonpalma with the hashtag #FinalFormDev!