The goal of a software application bug tracker template is to provide a structure for fixing bugs in the most efficient manner. All apps have bugs, and user experience is critical. Having no downtime of the application and having a minimal to no turnaround time for troubleshooting bugs is the ideal standard for any developer. However, software does not always work the way we would like. Oftentimes, users experience bugs and various errors that the developers are not aware of until they receive a report about the error. From the moment the developers receive a report with a bug, it’s critical to begin working and resolving the issue in attempts to reduce the time the user has to deal with the error. This template has a table for the issues, the team members, the pieces of code, and the features the code pertains to. Each of these tables play a critical role in reducing the time from the report date of the bug to the resolution. Once a team member is assigned an issue, they can change the status fro “assigned” to “in progress” to indicate to the rest of the team that they are actively working on the issue. The template identifies all possible team members, their areas of expertise, their experience with various programming languages, and what code they have either written themselves or have edited. Knowing a team member has resolved one issue for a specific piece of code can help the team decide to assign another issue to the same team member, assuming that having been exposed to the code previously, there is a working knowledge behind the functionality of the code. This can help reduce the learning curve behind understanding the functionality of each source code. Each table in this template unifies the different components of the bug identifying-resolution process. The primary goal of this table is to allow team members to identify issues, collaborate if necessary, troubleshoot, and resolve software bugs in a fast, efficient manner. Here are some template features and highlights, by table:

Issues

This table compiles all the current issues related to the software application. It identifies the severity level of the issues, the date it was reported, and a variety of other important details used to log the status of each individual issue.

Fields

• Bug. A very brief description of the issue.
• Date Reported. The date the issue was reported structured in month/day/year format.
• Severity level. The priority level of the issue on a scale of critical (level 3) to minor (level 1).
• Status. The status of the issue. Has it been assigned to a team member yet? If so, they should change the status to “in progress.”
• Assigned to. This field is linked to the Team table, indicating which specific team member the issue was assigned to address.
• Current behavior. A description of what the issue is, or the behavior of the application causing it to be an issue.
• Expected behavior. A description of what you would ideally expect the behavior of the application to be without the issue. In other words, the ideal outcome or functionality that is desired.
• Related code file(s). This field is linked to the Code files table, identifying which particular pieces of code pertain to the specific issue.

Views

• All issues. Displays all of the issues without any filters sorted by the most recent report date to the oldest.
• Critical. Displays the issues with a severity level of 3, critical sorted by the most recent report date to the oldest.
• Major. Displays the issues with a severity level of 2, major sorted by the most recent report date to the oldest.
• Minor. Displays the issues with a severity level of 1, minor sorted by the most recent report date to the oldest.
• In progress. Displays the issues with a status of “in progress” sorted by the most recent report date to the oldest.
• Not yet started. Displays the issues with a status of “assigned” but not yet in progress. This view is sorted by the most recent report date to the oldest.
• New issue. This is a form view that can be shared with team members to report a new bug. It includes a report date, current behavior, expected behavior, severity level, and bug name.
• By status. Displays all issues grouped by status.

Code files

This table serves as a library for all the different codes used for the application. Most often, issues with certain apps lie in different source code. This table provides a centralized location where all the code details are stored to be referenced as is needed for issues.

Fields

• File name. The name of the particular code.
• Function. The purpose of the code, the intended functionality.
• Current use. A drop down single select field identifying whether the code is in use or in development.
• Issues. This field links to the Issues table, identifying the particular issues that has been identified related to this piece of code.
• Programming language. The programming language the code is written in.
• Path to source. The pathway describing where the code is in the repository.
• Original creator. The developer that originally wrote the script. This field links to the Team table.
• Collaborating members. This field links to the Team table, identifying which team members have edited the script to address certain issues.
• Related feature. This field links to the Features table, identifying which particular feature the code pertains to.

Views

• All codes. Displays all codes without any filters.
• Powershell scripts. Displays all codes that have Powershell as the programming language.
• Python scripts. Displays all codes that have Python as the programming language.
• JavaScript scripts. Displays all codes that have JavaScript as the programming language.
• In use. Displays all codes that are identified to be “in use.”
• In development. Displays all codes that are identified as “in development.”
• By current use. Displays all codes grouped together by their current use status.
• Code gallery. Displays all codes in the form of a gallery view sorted in alphabetical order.

Team

This table identified all the different team members that would potentially be assigned a ticket. It includes their role and the different programming language they are well versed in. Having a list of all team members and their specialty can make troubleshooting or fixing bugs much more efficient.

Fields

• Name. The name of the team member.
• Photo. A photo of the team member.
• Issues working on. This field is linked to the Issues table, stating which issues the team member is assigned to.
• Role. The title the team member holds within the company.
• Programming languages. This is a multiple select field that identifies all the programming languages the team member is proficient in.
• Authored code. This field links to the Code files table, indicating which code was initially written by the specific developer.
• Code file(s) worked on. This field links to the Code files table, identifying the specific code the team members has worked on or edited in attempts to address issues.

Views

• All team members. Displays all team members associated with the app sorted in alphabetical order.
• Developers. Displays all team members with a developer role sorted in alphabetical order.
• By role. Displays all team members grouped together by their role.
• Team gallery. Displays team members in a gallery view.

Features

This table includes the different features the codes and issues pertain to. This helps provide a better overall view for how the issues and the codes impact the intended feature.

Fields

• Name. The name of the feature.
• Status. The status of the feature. Is it currently in production? This is a drop down single select field.
• Requirements. The pre-requisites the specific feature requires in order to properly function.
• Description. A brief description of the purpose of the feature or its intended functionality.
• Source code. This field links to the Code files table, **indicating which codes pertain to the feature.

Views

• All features. Displays a list of all features sorted in alphabetical order.
• In production. Displays a list of all the features with a status of “in production” sorted in alphabetical order.
• Ready for the next step. Displays a list of all features that are either ready for testing or ready for production sorted in alphabetical order.
• In development. Displays all features with a status of “in development” sorted in alphabetical order."
• By status. Displays all features grouped together by their status.