New development teams as well as seasoned developers sometimes, knowingly or unknowingly, record issues, bugs, improvements (or tasks or TODOs) in the source code instead of recording it at a central place for better visibility and recalling. The rationale given is that when the code will be revisited the next time, these issues or improvements would then be taken care of. This seldom happens, and the inefficacies are left unattended which stay there for long; and crop up bugs or critical performance issues when the code is pushed to production. It’s better to record these incidents (or instances) in a central Bug Tracking Software or Issue Trackers.
Need for Issue Tracker
Feature requests, tasks, code-changes or improvements, bugs reported by QA as well during dev testing should be recorded in some system for better tracking and filing, so that the progress & quality of the product can be visualised. An Issue tracker is a central board for listing, recording and tracking the health, progress and completeness of a product. This helps is planning and prioritizing tasks one over the other. Tasks that are more critical and important are taken up over the not-so-trivial ones.
All bug tracking systems have simple query commands, from where you can search, sort and filter issues based on different criteria. Using an issue tracker you can assign the work evenly and equivocally amongst the team members.
Demystifying How to use Issue Tracker efficiently
One should strive to provide the maximum information while opening an issue or task in the system. The number of fields in the tracker are configurable and can be changed based on the needs of the product. But the general features of an issue are:
- Title : A short title for the issue saying what the issue is all about.
- Description : A detailed description of the issue. Repro steps. What was expected. What was observed.
- Feature Area : In which part (or module) of the system the issue is present. eg. UI, service, DB, messaging bus, etc.
- Issue Type : Bug, improvement, RFC, feature, etc.
- Severity : Severity (or Priority) of the issue.
- Assigned To : For work distribution and tracking who is responsible for addressing it.
- Milestone : For targeting features (or issues) on a timeline. Can be time oriented or phase oriented (ex. beta release, redesign, etc).
- Attachment : For attaching any artifact related to the issue. ex. documents, log files, screenshots, events, etc.
You also get a comment tracking section for recording the discussion and updates on the issue which is visible to everyone. Lots of other fields are present in advanced and proprietary bug tracking system such as labels, open-reopened count, custom work-flows based on issue type, progress, time estimation, etc.
It is a good habit to report a detailed information in an issue. This includes, but not limited to:
- How was the issue caused (reproducing steps)? The conditions. Any special set up done? This helps in reproducing the bug easily.
- Attach the logs (if available), system events and logs (if relevant).
- In which build the issue was seen. Sometimes QA are testing on a old build, and the issue has already been fixed in recent newer builds. This avoids conflicts.
- It is a good practice to write the root cause of the bug in the issue, so that the QA can verify it easily the next time and it can help in creating a test case(s) around such scenario.
- The fix done. This also helps the QA in verifying what is the expected behaviour. Also he can cross check from the feature doc to verify the correctness of the fix.
Also when a fix is made, write the commit id when resolving the issue. This way when the QA verifies it in the next build, he can verify if the build on which they are testing contains the commit.
Issue Triages
In teams where there are separate Dev and QA members, sometimes there are conflicts over the severity and priority of a particular bug. The problem compounds when you have a long list to look at and it becomes difficult to rank one over the other. How do you classify one important than the others. For addressing such issues, it’s suggested to have daily, bi-weekly or weekly 15-minute triage meetings with the Dev, QA, Product Owner and Product Manager. In such meetings, after discussing the issue and the impact it has, both functional as well performance, the fix and scope of the changes needed to solve the issue, a better and wiser decision can be taken on the priority of the task and an appropriate time for taking it up.
Summary
To sum it up, issue tracker comforts the team on all the below fronts
- Prioritize work.
- Work Distribution within the team.
- Monitoring projects health and status.
- Tracking issues. Severity or Sprint status.
- Better planning.
- Generating a report of all changes and bugs fixed in a specific release or Milestone.
Many issue tracking tools like Jira, TFS etc also create charts and graphs which can be used to do a deep dive and find places for improvements in the process.
Have we missed on something that you think your team does better with its bug tracker? Some feature or utility that we may have missed. We would love to hear it from you.
