• Better facilitate communication between people working on a project.
• Provide a history of issues which have been encountered in a project and their progression and resolution in order to better support the system.
• Support a shorter product release cycle and manage interaction between development and testing (or generally Quality Assurance)
• Provide a snapshot into the issues being worked on in order to identify bottlenecks in the project.
I've been looking into issue tracking systems lately, BugZilla being the most bell known. I've looked at commercial ones like Jira and Gemini. I also read this very interesting article. All and all I've concluded on a simple tracking system called BugTracker.NET. It doesn't do half as much as most systems out there, but it does what i want it to do in the simplest way possible. Remember: Simple is your friend (as a wise senior software engineer in my old company used to tell me). The most important thing in the whole issue tracking ordeal I've decided is not the software you use, but the workflow, the roles of the users and the responsibilities they each have with respect to the issues. To that end, I've written up the following to describe these.
Primarily the attributes that are associated with issues are described. Next the workflow of an issue is presented with a description of each status the issue can be in. A description of the roles of users of the system is then presented and finally the responsibilities of each role with respect to what state an issue is in and the attributes is presented.
Issue Attributes
Issues are expected to have the following attributes for the purpose of capturing its state and history.Project
This is the project that the issue relates to. Different people will have different roles with respect to issues of different projects.Status
The status of an issue relates to where it is and who is responsible for it. The statuses of an issue are describes in the “Issue Workflow” section.Category
The category of an issue reflects the work that must be performed on it. Examples of category values are bug, enhancement, new feature, client issue, documentation. It is possible to change the category of an issue as more information is found out about it, but appropriate comments must be added at each change.Assigned To
This is the person that is in charge of dealing with the issue.Priority
Priority is an indication to the person that is assigned to the issue regarding how he must tread the issue with respect to other issues assigned to them.Resolution
This is the resolution given to an issue by the person in charge of the issue. Not all resolutions apply to all categories of issues. For example a bug may be fixed, unreproducible or not fixed. A client issue will be resolved and documentation will be drafted, reviewed or completed.Comments
This is possible the most important attribute of the issue. It must contain all the information about the issue added by the various people that have been assigned to the issue. It must contain fault reproduction techniques as well as verification techniques for the issue if it is a bug, logs and other information such as resolution details if it relate to a client issue and more.Issue Workflow
The diagram bellow shows the states that an issue within the issue tracking system takes.
New
When an issue is entered into the system, the default state is ‘New’. From this state an issue can go to either support, if it relates to a problem a client is having or to development if it is a bug.Support
When an issue is taken by support, then support staff will be in contact with a client collection information about an issue and resolving the issue when the can. If they manage to resolve an issue it is passed to Quality Assurance to verify that the resolution is satisfactory and in line with the project quality plan. If the issue cannot be resolved by support it is passed to development with all the information that has been collected.Development
When an issue is taken by development, then a developer will be put in charge of examining it and verifying if it is a bug and if so fixing it. If the developer needs more information in order to deal with the issue, they must add what they want in the comments and pass the issue back to support. Once a developer has fixed an issue then they move it over to Quality Assurance to verify that the issue had been dealt with (often this will be a case of testing).Quality Assurance
When an issue is taken by quality assurance, then a QA staff member will be in charge of verifying that the issue has been satisfactorily resolved. This will often require that a bug fix be tested, but may also require documentation to verified or accessed. If the QA member is satisfied with the resolution, then they will move the issue to a closed state. If they are not satisfied they will move it to development or support depending on where it came from.Closed
A closed issue is considered complete and is kept in the system for reference purposes and for helping future issues which may possible be similar to be resolved. In the event that after an issue is closed, it is discovered that the resolution was insufficient, then it is set to the reopened state with a comment on why it has been reopened.Re Opened
An issue in the re opened state similar to an issue in the new state in that it must be assigned to either development of support for it to progress.Roles
Users of the system can be grouped into the following groups or roles. A physical person may have more than one of the following roles in a given project and may have different roles in different projects. It is important for a user to know what their role is and what the responsibilities of these roles are.Users
All users of the system may add issues to the system. When a new issue is added to the system the user has the following responsibilities:1. Set the project of the issue
2. Set the Category of the issue if it is known
a. If the category is a bug, the user must add a reproduction procedure.
3. Set the status of the issue to ‘New’
4. Set a description of the issue
5. Set comments describing the issue
Users may also move an issue from closed to re-opened, in which case they must provide a comment describing why they have done so.
Development Managers
Development managers are in charge of the developers working on a project in that they are aware of the areas individual developers have worked on and have expertise in. Their responsibilities are1. To check the tracking system for new or reopened issues that relate to development and move them to development.
2. Review all unassigned issues in development and assign an appropriate developer to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or where a developer must start looking in order to resolve an issue thus giving the developer a jump start in solving the issue.
Developers
Developers are in charge of the issues assigned to them. Developers must work on issues based on the priorities given to them.When developers resolve an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. If issue is a bug, they must
a. Add a verification method to the comments instructing QA how they should go about verifying the fix.
b. State the version in which the fix will be available
4. Un-assign themselves from the issue and
5. Move the issue to Quality Assurance.
When a developer needs more information from support they must:
1. Add a comment stating what is needed and how it may be obtained
2. Un-assign themselves from the issue and
3. Move the issue to Support
Support Managers
Support managers are in charge of support staff in that they know what each staff member has expertise in supporting. Their responsibilities are:1. To check the tracking system for new or reopened issues that relates to support and move them to support.
2. Review all unassigned issues in support and assign an appropriate support staff member to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or how a support staff member must proceed in order to resolve an issue thus helping the support member.
Support Staff
Support staff members are in charge of issues assigned to them. They must work on issues based on the priorities given to them.When a support staff, member resolves an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. Un-assign themselves from the issue and
4. Move the issue to Quality Assurance.
When a support member cannot resolve an issue or has attained the information requested by development they must
1. Add a comment with all attained information regarding the issue
2. Add a fault reproduction technique if the issue is a bug.
3. Un-assign themselves from the issue and
4. Move the issue to Development
Quality Assurance Managers
Quality assurance managers are in charge of quality assurance staff in that they know what each staff member has expertise in supporting. Their responsibilities are:1. Review all unassigned issues in quality assurance and assign an appropriate quality assurance staff member to work on each of them.
Quality Assurance Staff
Quality assurance staffs are in charge of issues assigned to them. They are responsible for verifying that the resolution of an issue is in line with the project quality plan. This may involve testing bug fixes, reviewing documents checking comments added to the issue as sufficient.When an issue has been verified the quality assurance staff member must:
1. Add a comment describing the verification performed
2. Un-assign themselves from the issue.
3. Move the issue to closed state.
If the quality assurance staff member decides that the resolution does not meet quality standard (e.g. test fails, documentation is incomplete, Unit testing does not cover all the new code) they must
1. Add a comment describing why resolution does not meet quality standards
2. Un-assign themselves from the issue
3. Move the issue to support of development according to who put it up for quality assurance.
3 comments:
You say BugTracker.NET doesn't do half as much as you'd like. What are the most important things that it's missing?
No No.. I say BugTracker.NET doesn't do half as much as some other systems out there. For example, Bugzilla has a lot more fields (though I know you can add your own - and as a matter of fact I have added a couple). Gemini has customizable workflows which you can have enforced. I think maybe even define different roles for different people on different projects and define what each role can do with respect to the workflow.
However, I DO think all these extra features are just bells and whistles. Their only goal is to give the ability to an administrator to force people to use the issue tracking system in a particular way.
I think, (and this should be particularly true of small teams), if there is a document describing how the system should be used (like I've done), then its just a matter of people having the sense to follow the rules. Just generally think to themselves "what role am I playing at?" and "what are the responsibilities of that role?".
To that extent I think BugTracker.NET DOES in fact do everything I want it to do.
Okay, good. I agree with your philosophy.
But, just FYI for others reading this, if you do want BugTracker.NET to *ENFORCE* a workflow, and if you have some basic C# and SQL coding skills, then take a look at the sample code in the file workflow.cs.
Post a Comment