Transcript
Hello and welcome back to Startup Curious, where we discuss things you should know if you’re thinking about working for or starting a startup.
Today we’re going to be talking about filing a good bug report. This is an important skill to have no matter what your role is. At an early stage startup, you may be asked to use the product or try out aspects of it, even if working with the product isn’t part of your core responsibilities.
Every startup is going to have a different way they like to go about things. Some will use ticketing systems like Jira. Others will track bugs in a general to-do list system like Asana, or a kanban style board like Trello. You may be asked to just write up your bug report in Notion or Google docs, or post it in a Slack channel.
No matter the method, you’ll want to be as clear and detailed as possible. If you just say “When I type text in, it doesn’t save” - that’s not that helpful to the developer trying to fix it. If you say “When I type text into any of the input fields on the Onboarding page and click ‘Save’, I don’t see my answers in the Profile page” it’s much better. This gives the developers enough information to try it out themselves.
You also usually want to include some information about your setup - it’s pretty common for bugs to only exist on certain browsers, operating systems, etc. If you want to make sure you’ve included enough relevant information you can hearken back to the 5 whys: who, what, where, when and why. A good bug report answers as many of these as possible.
Though the above format works for filing a bug report, it’s often better to break things down a little more. Sometimes people will divide their ticket into 3 sections: Current behavior, reproduction, and expected behavior.
For the example above, current behavior might be: “The Onboarding page isn’t saving my answers in Chrome on Windows.”
The reproduction part is usually broken into step-by-step instructions, so it would look something like:
1. Navigate to the onboarding page.
2. Enter any text into the fields
3. Click Save
4. Navigate to the Profile page.
Again, be as detailed as possible - if the issue is only when you enter certain types of text or on certain fields, note that.
And then the expected behavior would be “When I click Save on the Onboarding page, the answers should show up in the profile page.” Though it doesn’t make sense for this example, there will be cases where what you expected is actually not the intended behavior, and your bug report may surface a different issue around usability.
For simpler tickets, writing all of this up may feel unnecessary, but it can be good to get into the habit. That way, when you run into something that takes a lot of steps to reproduce, you’re already used to writing up your bug reports in this format.
In general, the thing to remember is that the developers are not mind readers. If you file a vague or sloppy bug report, they’re going to have to go solve the mystery of what you meant before actually fixing the bug. Writing good bug reports will save everyone time and make everyone more productive! Plus, no one wants to be the coworker people associate with annoying work - and trying to decipher a confusing bug report is definitely annoying work.
If your company is using a more advanced ticketing system, there may be other fields to fill in on top of the general description. Fill out as many of those as you can - it will make it easier for the report to get in front of the right person faster.
One field you may run into is the Priority field. Different companies will have different methods here, but a common one is to use P0, P1, P2 , P3 and P4 (Priority 0, 1, 2, 3, 4). P0s are the highest priority and are sometimes referred to as “Showstoppers” - in other words, things may need to pause until they’re fixed. P0 is usually reserved for security bugs or bugs impacting core functionality of the product.
P1s are next in line, then P2s, etc. It’s important to understand your company’s methods for prioritizing bugs. Constantly marking bugs as higher priority than they really are is a great way to get your tickets ignored - sort of a boy who cries wolf situation. At some places, they may ask you specifically not to pick a priority for a ticket because there’s someone who reviews all of them and decides.
While I spoke about all of this as if you’re the one running into the bug, you should also use this when recording a report from a user. If they’re being too vague, try to get as much information out of them as possible. Of course, sometimes this can be tricky, especially if they’re impatient or not a strong communicator.
In those cases, do your best to reproduce the issue before filing the report and include any extra details you figured out along the way. It can also be helpful to directly paste in what the customer is saying to you - sometimes someone else will be able to figure out what they meant even if you couldn’t.
My final tip is this: check for duplicates! There’s a chance your ticket has been filed before. Filing a new one just makes more work for whoever is in charge of curating the ticketing system - either they have to merge it with an existing ticket or they’ll stumble on it later, after it’s been fixed, and have to do a mini investigation into whether or not it’s been taken care of, has popped up again, etc.
Take a minute to check for duplicates to save them time! Of course, there’s no way to 100% avoid it - it can be tricky to figure out if something is a duplicate or not - but you should at least try!
And that’s where we’ll wrap up for today. If you found this episode useful, please remember to subscribe and share. Our goal is to make startups more approachable for everyone and the only way we can do that is to get the word out!
We’ll see you next time, where we’ll be discussing co-founders: why you need one and where you find them.
Suggestions
If you have a topic you’d like to learn more about, send me an email at v@thescrappyoperator.com.
