Disclaimer:
These pages about different languages / apis / best practices were mostly jotted down quckily and rarely corrected afterwards.
The languages / apis / best practices may have changed over time (e.g. the facebook api being a prime example), so what was documented as a good way to do something at the time might be outdated when you read it (some pages here are over 15 years old).
Just as a reminder.
These pages about different languages / apis / best practices were mostly jotted down quckily and rarely corrected afterwards.
The languages / apis / best practices may have changed over time (e.g. the facebook api being a prime example), so what was documented as a good way to do something at the time might be outdated when you read it (some pages here are over 15 years old).
Just as a reminder.
Workflow for handling a reported bug
process to keep track of a bug and have them under control
See also
Release cycle workflow
and
Release/test server setup.
The workflow processes have overlaps and are meant to be working together.
This is an example process for handling bugs in Mantis, note that it is generic though, so can be applied to any issue tracking tool. See full description below the diagram.
Bug reporter
reports bug
reports bug
Bugmaster
reviews bug
reviews bug
More info needed?
Already fixed?
Duplicate bug?
Will not fix?
Duplicate bug?
Will not fix?
Assign to "DEVELOPER"
Developer picks bug
from "DEVELOPER"
from "DEVELOPER"
More info needed?
"Resolves" bug
- enter mantis # in git comment
- paste github history url
in mantis note
- enter mantis # in git comment
- paste github history url
in mantis note
Release manager puts code on test server
For all "Resolved" bugs:
- set "Fixed in version" to tag
- assign to "TESTER"
For all "Resolved" bugs:
- set "Fixed in version" to tag
- assign to "TESTER"
A tester
tests the bug
tests the bug
Bug fixed?
Set status "Closed"
BUGMASTER
DEVELOPER
TESTER
REPORTER
Set status "Closed"
and add note (if necessary)
and add note (if necessary)
Done
Assign back to Reporter
and add note
and add note
Assign to "FAILED"
and add note
and add note
Done
Bugmaster
review "FAILED" bugs
review "FAILED" bugs
RELEASE MANAGER
Should bug be fixed
before release?
before release?
Assign to "DEVELOPER"
Done
Assign back to the developer
that handled the bug
that handled the bug
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
 |
- Reporter - the person creating the bug (can be anyone with access to mantis)
- Bugmaster - reviews the unassigned bugs and rejects or passes them on to the developers
- Release manager - (see release.txt) the person reviewing and putting the code on stage / test server
- Tester - tests the resolved bugs and closes them or rejects
Virtal users
- DEVELOPER - virtual user, where all open tasks are that the developers can take on
- TESTER - virtual user, the tasks we want the testers to test
- FAILED - virtual user, where testers assign all bugs that failed when testing
- New - new bug, needs to be reviewed
- Feedback - something needs to be clarified (missing info or other questions)
- Assigned - neutral status when assigned to a user
- Resolved - the bug has been corrected, not yet tested
- Closed - the bug has been fixed (or alternatively will not be fixed / is duplicate of other bug)
The reporter also gives the bug an initial severity / priority (how critical and how urgent is the bugfix), alternative leaves that to the default settings.
Bugmaster reviews the bug, either closes it (e.g. it is duplicate, not a problem / will not be fixed), assigns it back to the report for more information or assigns it to the virtual user DEVELOPER.
The bugmaster might also adjust severity/priority.
The developers takes the bugs themselves from DEVELOPER, they will take the bugs in the order of priority / severity (a pre-created filter that sorts the bugs in this order exist).
If it is clear that only a specific developer can handle the bug, the bugmaster or someone else, can assign the bug directly to that developer.
If the developer needs more information, e.g. cannot reproduce the bug or some clarification is needed, he will make a note regarding what he requests and assign it to the appropriate user (could be the original reporter, but could also be some other user, e.g. developer that worked on similar problem)
When the developer has completed a bug, he will set the bug status to "Resolved" and in the code commited to git he will mention the mantis number, e.g. "corrected spelling, bug #1234" and he will copy the github url to the commit in the note in mantis when changing the status to "Resolved"
This will make it easy to track why a specific code change took place, and in case the bug (or a similar bug) reappears later we can back trace what code changes had been made to fix the bug
When the release manager puts code on the test server, he takes all "Resolved" bugs and change them to Fixed in version "rel_XXX" which is the tag set for releasing the code.
That way we can keep track when we fixed which bugs. Mantis will automatically give us a change log for every version.
The release manager assigns the resolved bugs to the virtual user TESTER
The release manager informs the testers that there are bugs to be tested.
The bugs that have fixed are set to status "Closed" by the tester.
The bugs that still have not been fixed / not completely fixed / or related problem has appeared due to the code change, will assign the bugs to the virtual user FAILED.
After testing has been completed, the bugmaster will review all bugs that has been assigned to FAILED and handle them;
- assign back to "DEVELOPER" in case the bug does not need to be fixed in this release
- assign back to the developer that fixed it, so he can fix the bug straight away
Additional notes
Any person can add notes, attachments, connect a bug as related to other bugs etc, the only field that should be left alone is priority which is solely handled by the bug master (to make sure the priority of bugs are not changed randomly).