»
News RSS
We'd like to officially welcome you all to the now operational SWG:ANH - Bug Tracker.
As we're nearing our official date for Open Source, the necessary services that will ensure the project runs smoothly are being brought up. So in the coming days you'll be seeing a number of posts like this as things are being prepared.
Anyways, onto the bugtracker details and workflows, as well as some bug submission tips.
Please bear in mind that these workflows are / will be subject to some changes as we proceed. Any changes that do happen will be outlined on the official forums as well as the website FAQ pages.
Last, but definitely not least, thank you everyone for your hard work and effort in submitting the bugs to the temporary location on the forums, it is most appreciated!
Please read the notes below, and take a moment to register on the new site, linked below:
Bug Tracker - Workflows, Roles & Responsibilities
Bug flow:
new --> confirmed --> assigned --> acknowledged --> resolved --> closed
1.) Bug Created (Status set to NEW)
2.) QA verifies bug (Status changes to CONFIRMED)
3.) QA Leads assign bug to developer (Status changes to ASSIGNED)
4.) Developer acks the bug assignment (Status changes to ACKNOWLEDGED)
5.) Developer fixes bug, bug goes back to QA for testing (Status changes to RESOLVED)
6.) Bug fixed (Status changes to CLOSED)
(if the bug has not been fixed it will be flipped back to ASSIGNED)
Commenting on Bugs:
Anyone can comment on bugs with status set to NEW
QA Team can comment on on bugs with status set to NEW, CONFIRMED, RESOLVED
Developer(s) can comment on on bugs with status set to ANY
Manager can comment on on bugs with status set to ANY
Version(s), Roadmap(s) and Feature Releases:
Version 0.1.0 - Now
Version 0.2.0 - Open source (26th June, 2010)
Version 0.3.0 - Basic professions
Version 0.4.0 - (undecided)
Version 0.5.0 - (undecided)
...
Version 1.0.0 - All done!
Bug(s) Tips 'n Tricks
The following, adapted from How to Write a Bug Report: A Dozen Helpful Tips, by Bernie Berger, (Copyright © 1997, All rights reserved) may be helpful to QA testers as they begin writing bug reports.
1. Be very specific when describing the bug. Don't allow room for interpretation.
2. Calling things by their correct names will eliminate ambiguity. ‘Crafting kit vs. Generic Crafting Tool’
3. Don't be repetitive. Don't repeat yourself. Also, don't say things twice or three times.
4. Try to limit the number of steps needed to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.
5. Start describing where the bug begins, not before. For example, you don't have to describe how to load and launch the game if the problem is that it crashes on exit.
6. Proofreading the bug report is very important. Punctuation is your friend.
7. Make sure that all step numbers are in sequence. (No missing numbers and no duplicates.)
8. Please make sure that you use sentences. This is a sentence. This not sentence. Avoid using texting 'shorthand' words and phrases such as 'u need 2' or 'becuz' in bug reports.
9. Don't use a condescending or negative tone in your bug reports. Don't say things like "It's still broken", or "It is completely wrong".
10. Don't use vague terms like "It doesn't work" or "not working as intended". This does not give any information that might be useful in fixing the problem.
11. If there is an error or system message involved, be sure to include the exact wording of the text in the bug report. If there is a crash please include a crash log. A screenshot is worth a thousand words.
12. Once the text of the report is entered, you don't know whose eyes will see it. You might think that it will go to the developers and that's it, but it could show up in other documents that you are not aware of, such as reports or newsletters or future test plans. The point is that the bug report is your work, and you should take pride in your work.
