BugTracker Guide
The Bugtracker is intended for 5 main user groups.
The Reporters are the players who found a bug in game (or in the CVS version) and would like to report it in order to get it fixed. After they report the bug or the feature request, they should remain available for retesting, providing additional information (comments, files, screenshots, etc.) if needed.
The Testers are the members of the so called “bug group” and their main role is to verify every single bug reported by the reporters and confirm it or not. The task should not be marked as new if:
There is already a similar bug report, therefore the new bug report should be marked as a duplicate and the master bug should be specified in the duplicate bug report.
The bug is not really a bug. It can’t be reproduced or it is a feature. In this case the bug should be closed and marked with “Not a bug” resolution. A comment stating why this is not a bug should be written as well.
In certain cases, a bug can’t be verified by a member of the bug group, therefore it should be marked as “could not verify”. This happens if certain circumstances, or certain hardware, for example, are necessary for performing the test.
A bug (or a feature request) when they are marked as new should have a proper report. The testers are responsible to verify the information in the proper report, asking the reporters for more information if needed, and correcting the fields that haven’t been fixed properly by the reporter.
When a bug is set to the status “Ready to test” the testers need to verify the fix. If the fix is not working they should change the status of the task to “In progress” again, assigning it back to the proper assignee. Otherwise, the task status can finally be set to “Closed”, with resolution “Fixed”.
A bug that is an exploit or can make the server crash should not be visible to everybody and can therefore be marked by the testers as “Private”. Right now, Flyspray allows just the admins to view such bugs, but in future versions of the software it will be possible to make this visible to specific user groups (e.g. the testers and the developers).
The Prospects are those people that are trying to enter the PS team. They might get a bug report assigned to fix and since their fixes need to be verified by a department leader or by an admin they will just get assigned to a bug report, but they can’t even close it. When a prospect completes the work on a task, they should set the status to “Ready to review”.
The Developers are the ones to whom a bug report should be assigned (by the admins). If a developer can fix the bug assigned, he should set the status to “In Progress” and once the fix is completed he should set the status to “Ready to test” and assign it to a tester member. Of course, if necessary, a task can be reassigned to another developer.
The Admin’s role is mainly to “moderate” the bugtracker and verify that no problems occur. They have also the role to assign the tasks to the relevant developer or prospect and they can evaluate the feature requests. If the feature request won’t be implemented, the task status should be changed to “Closed” with resolution “Won’t fix”.
There are two types of task available.
Bug Report. To be used when a feature is not working as it should
Feature Request. To be used when a new additional feature or improvement is desired
Unconfirmed. Every new task (bug report or feature request) will be opened in this status. This indicates that the task hasn’t yet been verified by some tester and therefore, it could be not valid.
New. In general, a feature request (except if too absurd or if it is already known that won’t be implemented) should be always marked as New by the testers. A bug report is marked as new when it can be reproduced or it is a valid claim. If a developer can’t fix the bug he got assigned, he should mark it back as new, so that an admin can re assign it.
Assigned. Except rare occasions (e.g. all the admins are on holiday!), it is just the admin that can assign a task to a developer. This might occur both in the case that the case is a bug report or a feature request. For convenience, the task might be assigned to a tester in order to get it verified. NOTE: it is possible to have more than one assignee per task.
In progress. When a developer starts to work on a task that he got assigned, he should mark the status as in progress in order to make everybody understanding that something is happening. In such way, it is also possible for the admins to re-assign to other people the bugs if necessary (no work will be duplicated). It is also really recommended that the developers show the progresses of their task using the “Percent Complete” field. In this way, people are aware that something is happening and will also know when approximately the conclusion of the task will be (if not specifically indicated by the “Due to Date” field).
Ready to test. When a task is completed by a developer (not a prospect) it should be marked as ready to test, so that the members of the testers user group can investigate if the implementation was proper. The main responsible for the verification of the fix is the test team, however, some developer (not the task assignee) may attempt to verify a task as well.
Closed. There are several ways to mark a task closed. This can be done mainly by the bug group as well as by the admins. If an implementation is performed, it is up to the testers to verify the validity of it and decided if the task is completed. When a task is marked as closed, different resolutions can be chosen.
Ready to review. A prospect that has completed its task on the bugtracker should mark the status of it as ready to review. In this case, the admins of the bugtracker, or whoever is following the prospect will evaluate his task completion.
Postponed. This is used by the admins to indicate a feature request which sounds interesting enough to be implemented, but that is not possible to do now – for a lack of resources or because a release is pending. It should be assigned to somebody when the moment is proper.
Could not verify. Sometimes, due to the lack of proper data, the testers can’t verify the new tasks that are filed in the bug tracker. In this case, they mark the report as not possible to be verified and the admins will take care of it.
None. The majority of the tasks should have this resolution. All the tasks that are still opened (including features request), with the exception of the ones that could not be verified by the testers.
Not a bug. If a bug report is written about something that is not a bug (it is supposed to be like that or it can’t be reproduced), the bug report must be closed with this resolution.
Won’t fix. If a feature request is completely out of PS vision or roadmap (also for future releases) an admin should close the task marking it with such resolution.
Duplicate. Sometimes, a reporter files a new task which has been already inserted and considered previously. Often, this happens because they do not search if a similar request/problem has already been written or because they do not know how to search. Sometimes, it also happens because the titles of the reports are not clear. In any case, the testers have the task to verify that the new tasks haven’t already been filed and if they are already in the bugtracker, the task should be marked as duplicate of the first one (which will be the “master” report).
Fixed. When a task has been implemented and the tester has verified that it works correctly, it can be closed as fixed.
This part is rather intuitive and it is usually applicable just for bug reports (and not features requests). In any case, if a bug report is applicable to all operating systems, then this field should be marked with All, otherwise, the most proper operating system should be chosen.
The list of available version will vary every time a release is performed.
There are usually two versions that are related to the “present”, which should be the ones for which a bug report is filed. One is cvs, the other one is the current version that is released.
A task can be inserted in the roadmap of a specific new version release marking it as “to be closed” in a future version.
The past versions, in general, should not be used.
Going through all the available categories seems a bit overdue, since they should be rather intuitive. In the case, for the future versions, the ambiguous categories will be presented in this document.
Here there are listed at least the macro-categories that are available:
Engine. Everything that is related to the client, the server and their interaction should end up here.
Setting. This should be used when the task concerns elements of the setting, like quests typos, NPC dialogs that should be improved and request more concerning the setting itself.
Rules. Sometimes behind part of the game there are formulas that could be improved or dynamics of how the game should work out (for example, concerning PvP areas or spells damage). In this case (and also when it is about the player guide) it is proper to use this category
3D art. Everything related to the 3D world of which Planeshift world is made of should be placed here. Also characters animations.
2D art. When it is about textures or backgrounds and every other piece of art that is “flat”, this is the right category.
Bugtracker. If there is a problem within the bugtracker it is good to write it here. The PS team is not responsible of the development of the bugtracker, but can collect requests and bug reports in order to send them to the Flyspray team, instead.
It is important to point out that it is part of the tasks of the test team to verify that the task has been assigned to the right category. Sometimes, it is not easy to find the proper category and that is why the test team should be a reference for understanding how to do this, thanks to their better knowledge of the development process.
This value indicates how heavy is the impact of the task (if bug or if feature request) on the game.
Used in combination with the priority can be helpful for sorting out the tasks according to how important and how fast they need to be solved.
Critical. When a task is marked as critical it is a matter of extreme importance. The playability is compromised and, if a release is pending, the critical tasks are the show stoppers. To be used usually, in combination with priority flash and immediate.
High. The importance of the task is high, but the task is not blocking a release or destroying totally the playability or the game balance.
Medium. A medium severe task has some importance to improve the game playability, but it is nothing that will need to get a really high priority in a crowded to-do list.
Low. This should be the default value for any task that doesn’t have a specific relevance.
Very Low. Really small, not relevant issues should get this severity. A detail on a map, or a typo in a system message, annoyances to the game.
This value should indicate how fast the task should be fixed. This can vary during the life cycle of the task, depending from a pending release, from the fact that the reported bug is an exploit, etc.
Flash. This must be fixed as soon as the bug/feature report has been written! To be used for exploits and server crashes.
Immediate. This should be fixed within a week from when the task has been assigned. To be used for those bugs which make it impossible to play the game.
Urgent. This needs to be fixed within three weeks from the date of assignment. It should be used with disturbing bugs that requires attention from the developers, but won’t create any serious problem to the game playability (e.g. client crashes).
High. A task that has high priority should be solved within a month. Important issues which don’t prevent to play the game, but however, constitutes an important feature should be considered high priority.
Normal. No specific deadline is set to such a task, but the task should have some relevance and therefore, it should be fixed when all the prioritized issues are solved.
Low. This should be used for those tasks that are describing small details to be fixed or problems that are not affecting at all the playability of the game. There is no specific deadline set for such tasks.