Issue Tracking
Stinkbug includes a feature-rich issue tracking system. In Stinkbug, issues are used in two different (but related) ways —
- As a traditional bug-tracking system, keeping track of bugs, enhancement and/or feature requests, etc. sent in from field testers and users.
- As a to-do list. During the development life-cycle, you can enter work items for a project into the issue tracking system and they will appear as to-do items for the current version of the project. In this way, you can use the issue tracking system to guide and track your work.
Issues appear in three places within Stinkbug.
- Issues Tab. The Issues Tab displays an list of all issues – open or closed, and for all projects.
- Project > Issues. The Issues section of the Project Detail view displays all issues for that project, open or cloased.
- Project > Version > ToDo List. The ToDo List section of the Version Detail view for a project displays all issues (open or closed) which represent todo items for that version.
Issue List
An Issue List displays a sorted list of issues.
Project Issues and the Version ToDo List are sorted by date (most recent first). The Issues Tab provides the ability to sort by date, priority, project, or component.
Closed issues are shaded in the Issue List so that it is immediately apparent which issues are open or closed.
Adding a New Issue
You can add a new issue from any place issues are listed.
- On the Issues Tab, tap the + icon.
- On the Project Detail > Issues view, tap the Add Issue button.
- On the Project Detail > Version > ToDo List view, first tap Edut List, then on the subsequent view, tap Add ToDo Item.
The New Issue dialog appears.
Enter basic information about this issue:
- The Issue Number is assigned by Stinkbug and is date-based: year-number (2 digits) month-number (2 digits) day-number (2 digits) and item-number (2 digits). I.e., the format handles up to 99 issues per day, which will hopefully be plenty.
- The issue has a title and optional subtitle, which should be used to help identify what the issue is all about.
- The issue was reported for a specific project, version, target, and component. (Later, these values could change as the issue evolves.)
- Use the Add Reporters button to add contact information about one or more people who reported the issue.
- The issue has a category (uncategorized, feature, suggestion, comment, enhancement, bug, costmetic, and other).
- The issue has a priority (high, normal or Low).
- The issue has a state (reported, active, inactive, testing, and closed).
- Finally, enter a description of the issue as it was reported. (Later, the problem description may change as the issue as data is gathered and the problem is analyzed.)
Issue Summary
Tapping on an issue in the Issue List opens an Issue Detail view. It will initially open to the Summary section.
The summary view provides basic information about the issue:
- The issue number, title, and subtitle.
- The dates the issue was reported and closed.
- The project this issue is associated with. (All issues must be associated with a project.)
- The project version(s) the issue is associated with. This is a List of the versions for which the issue appears in their todo list.
- The component (either deliverable or dependency) to which the issue has been assigned. This indicates what part of the project needs to be changed to resolve the issue.
- The target(s) affected by the issue. A project may be deployed on multiple targets, but the issue may only be relevant for some of them. For example, for a project with a front-end/back-end architecture, an issue might only effect one of them. Or for a project which is deployed on iOS, iPhone and Macintosh, an issue might affect only one of these platforms or it could affect them all.
Tapping the Actions button on the Summary View (or the History view) displays a sidebar of actions you can take to add information about this issue.
Issue actions will be discussed below.
Issue History
An issue typically undergoes many changes from the time it is first entered into Stinkbug until it is ultimately closed. The issue tracking system regards each of these changes as an item which needs to be documented. The date-ordered set of these items represent the issue’s history.
Some history items are automatically generated by Stinkbug. For example, if you change the category or priority of an issue, Stinkbug will note that change as a history item automatically.
Other changes need to be handled manually. For example, when you analyze an issue and determine what needs to be done to resolve it, you document that work by adding a history item that describes your analysis. This makes sure that your thought process in resolving the issue is captured.
The “manual” history items are displayed in the Actions sidebar. They are:
- Gathering Data. Used to document the process of collecting data for problem analysis.
- Problem Analysis. Used to document the analysis of the issue. The results of the analysis should always be entered, but the thought processes involved are also of interest.
- Problem Restatement. Used in cases where the orignal statement of the problem turn out to be incorrect or incomplete.
- Comment. A catch-all for notes and comments that don’t fit in another category.
- Coding. A discussion of the coding changes made to resolve the issue.
- Documentation. A discussion of the documentation changes made to resolve the issue.
- Issue On Hold. If an issue is put aside (i.e., made inactive), this documents the reason.
- Merge Issue into …. When two issues turn out to be duplicates of one another or overlap (such that they really need to be solved as a single issue), this action performs the merge and documents why it was done. The current issue is closed and its information is copied into (merged with) another issue.
- Split into …. When it is determined that an issue is complex and multi-faceted and is best solved in pieces, it is possible to split an issue into multiple issues (which may then evolve independently). This action splits an issue into two pieces which (initially) contain the same information. You will need to modify the content of both so that the information is properly split between them.
- Issue Fixed. Documents that the issue has passed its tests for being completed.
- Issue Not Fixed. Documents that the issue has failed its tests for being completed.
- Issue Closed. Documents the closing of an issue. This action
also includes a close reason. Valid close reasons are:
- Open. The issue has not been closed.
- Fixed. The issue has been successfully resolved.
- Irreproducible. The issue was closed because it could not be reproduced.
- No Problem Found. The program was determined to be executing correctly.
- Not Fixed. The problem exists but it was decided not to fix it.
- Merged. The issue was merged with another issue.
- Other. A catch-all for some other close reason.
- Issue Reopened. Documents that the issue was closed prematurely. The issue is reactivated and put in either the active or inactive state (by user preference).
Selecting one of these actions will display a dialog for entry of the appropriate information.
History List
From the Issue Detail view, tap History to display the history list.
The history items for this issue are listed in reverse date order (i.e. most recent first). Tapping a list item displays the contents of that item. Also note that the Actions menu is available here.
Attachments
There are often attachments associated with an issue. For example, if a user sends in a bug report via eMail, then the text of the eMail (which includes their description of the problem) should be part of the issue. It can be saved as a text attachment. And if the user included a screenshot, you'd want to save it, too.
Moreover, you may want to attach the data (such as console logs, etc.) that you collect as part of your data gathering process as attachments to the issue. And once the issue is resolved, you might want to save a screenshot as an “after” image as a comparison with the “before” image sent by the user.
The issue’s Attachments view is the place to add and display attachments.
As you can see from the list, Stinkbug supports a rich complement of attachment formats.
Reporters
When someone spends the time and effort to communicate with you about something you can do to make your app better (be it a bug to be fixed or a new feature they'd like to see added, etc.), you will want to communicate with them — to thank them, to apprise them of progress on their issue, etc. Such people are rare; you should cultivate them.
Stinkbug helps you do that by helping you keep track of reporters – the people who report issues.
You can save contact information for each issue's reporter(s), and you can send them eMail from within the Stinkbug app.