When we run user interviews to understand how you folks use Dashcam, there’s a product name that gets often mentioned. That name is Jira. Jira by Atlassian seems to be the most loved Ticket management system. In Jira, tickets are called issues, which is the same term we developers use on GitHub.
An issue is a task that needs to be looked at and solved. Thus Jira can become a powerful ally, especially for issue tracking! Any software engineer should have a good understanding of how they should use it, specifically during a sprint!
Here are some best practices for tracking issues in Jira:
Create issue types
Set up different issue types, helps to understand an issue if you focus on issues by looking at it from the codebase-perspective!
Separate bug and defect issue types:
Have distinct issue types for “Bug” and “Defect” for clarity. Bugs are functional issues, defects are quality issues.
Categorize bugs
Different types of bugs can be grouped together! Create bug issue type categories like “Error“, “Crash“, “UI Issue“, “Performance“, etc. to assign specific types of bugs.
Prioritize bugs
Not all bugs are born equal! We mark high priority to be fixed immediately all bugs that cause data loss and crashes
Repro steps
We always include steps to reproduce – one of the main reasons why we’re building Dashcam is to make it super simple for anyone to provide clear repro steps to consistently replicate the bug. Attach a Dash, any time you can, it is really helpful!
Tag severity
Even within the same category of crashes, there might be some occurrences that are “Minor“, “Major“, or “Critical” to indicate the severity and help prioritization. For example, if the system that updates the app fails to update the app and crashes or times out, that might be less critical than the app not being able to record your screen and crashes instead!
Link bug and requirements
When we link bugs to related requirement issues, like user stories, this helps identify gaps between requirements and execution and helps better understand the root cause of the bug by reviewing the surrounding context
Assign bug issues immediately
As soon as a bug is created, we assign it to someone to look into it, to release a fix! We don’t want any scary bugs to ship with our product, as much as our users don’t want to face them!
Track bug status
It’s important to track the freshness of a bug using statuses, like “New”, “Assigned”, “In Progress”, “Fixed”, and “Closed” to track progress.
Verify through peer-reviewing
All bugs should be closed after someone else, other than the person who writes the fix, can verify and test that it has been resolved.
KPI / metrics.
As your team grows it becomes imperative to be able to run some sort of success metric over how many bugs were opened, worked on, and closed (or not!) during a certain period. This can lead to identifying internal engineering process issues related to bug fixing. This can scale as you can eventually micro-optimize by logging time spent on each issue for tracking costs (OpEx) and productivity.
Always look back
Always look at what work has been recently done, bug tickets that might be in triage or in a queue, and the ones that have been closed. Staying in the loop is important to understand and do micro-adjustments to your ways of working!