Author Topic: How to write effective bug reports  (Read 8269 times)

acraig

  • Administrator
  • Veteran
  • *
  • Posts: 1562
    • View Profile
How to write effective bug reports
« on: January 05, 2007, 07:05:10 pm »
In an effort to help us narrow down bugs I will try to offer some some advice on how to improve the bug reporting on bugs.hydlaa.com.  First up is this bug:

"It seems we have the ability to repair stocks, after combining 2 of different quality and getting a difference like 235/267 for example. What is even more wierd is the fact that it doesn't eat up a repair kit when I repair it.
Also quality related issue, when combining some stocks of different quality (it depends on the order of combining), I get 265/235 quality of a stock."

Seems pretty good at the start but it's missing a couple of key pieces of information.
1) Which stocks? If I run this query
mysql> select id,name from item_stats where name like "%Stock";
I get over 22 results.  I can't check them all to see if the behaviour is the same for all of them.
2) The quality and quantity in the stacks.   Is 235/267 the before or after values?
 
3)  For the second part, again what stocks, what values, what qualities are involved?  "It depends on the order", means that order is important so that should be given as well.  The highest quality on the lowest?  The largest stack on the lowest,  the largest on the lowest quality, etc. 

With the above information I can quickly create the same condition in my test server.  Otherwise I have to make guesses which might not lead to the same bug here which will result in me closing the bug because I cannot find it.


----------
Andrew
"For all I know, she's lying, everyone's lying; welcome to the Internet"

bilbous

  • Guest
Re: How to write effective bug reports
« Reply #1 on: February 10, 2007, 05:16:50 pm »
This is good advice. Might I suggest that instead of just closing a bug that you have gone to the trouble of trying to duplicate, you post as a comment the steps you took so that the original poster could clarify or another tester might approach it from a different angle.

I know that posters do not always return to check their bugs and also that some have difficulties with the English language and that some bugs reported are due to factors outside the code.

It just seems to me that there is little harm in leaving a bug open for a little longer in the hope of fixing it.

Xillix Queen of Fools

  • Veteran
  • *
  • Posts: 1876
    • View Profile
Re: How to write effective bug reports for npcs
« Reply #2 on: February 13, 2007, 07:29:08 pm »
For bug reports of npc text

In order to make the process as easy as it can possibly be some guidelines to add consistency to the process are useful to both the settings developer and the bug reporter.
If your bug involves a quest and would be a spoiler please petition a gm instead of using bugtracker

Give us context

who are you speaking to? under which conditions? etc give us time and place please

   1. When reporting a problem with a quest give the settings member the precise name of the quest. Begin in this fashion: In the quest "Lorytia Starhammer and the clan reunion."
   2. Give exact quotation of the line in the quest script where the problem occurs, and a brief explaination of why it is wrong. Even if the npc will not give or recieve an item needed it is important to list the dialogue so that the setting member can see what exactly you are speaking of. So for example, "Lorytia does not give the clan symbol back" is no where near as useful as "after the lines, 'L: Wonderful you will find Hiacheius Dilechi near the mill he is a technician. Just tell him you need the Iron and Gold Starhammer Clan Symbol polished and a protective coating placed on it.' Lorytia does not give the Iron and Gold Starhammer Clan Symbol."
   3. When checking quests try the incorrect answers to problems and try all methods of fulfilling the quest, so that all npc dialogue is reviewed.
   4. Any items generated by quests that do not have a description should be noted.
   5. Remember, when a quest is altered everyone who is currently doing that quest will need to begin it again.
   6. You may suggest alternative answers that "should" work. Changes of this type will be a lower priority
   7. Do not add your bug to a previous bug if it is not the same one. Search first, if you cannot find the bug make a new report.

No more than one bug per report!!!
« Last Edit: February 13, 2007, 07:38:20 pm by Xillix Queen of Fools »

kicker04

  • Traveller
  • *
  • Posts: 18
    • View Profile
Re: How to write effective bug reports
« Reply #3 on: August 04, 2008, 04:25:41 pm »
Just a small question: I opened a new task about problems with mutated vowels on the bugtracker today and now it is away. I can't find it anymore. I don't know what happened to it and just a small notice about it if that bug is stupid or already noticed would have been nice.  ???

Caarrie

  • Forum Addict
  • *
  • Posts: 3369
  • We want no UNFIXED bugs!!!!!!!!!!!!!
    • View Profile
    • PlaneShift3dMods
Re: How to write effective bug reports
« Reply #4 on: August 04, 2008, 04:29:35 pm »
not that this is related to this topic but your bug got closed as a duplicate of another, if you select to be emailed about status changes on your bugs and comments, you would have gotten an email about the closure of the report. remember to search the tracker to look for duplicate reports before you make new ones.

Mythryndel

  • Testers
  • Hydlaa Notable
  • *
  • Posts: 605
    • View Profile
Re: How to write effective bug reports
« Reply #5 on: August 04, 2008, 06:48:58 pm »
Where appropriate, try to keep the following three questions in mind, and answer them with as many details as you can think of... better to have too much detail, than not enough.

1. What happens now? How does it work in the current software build?

2. What should happen? How should this work if it were fixed?

3. How do I make this condition happen? Steps to reproduce. This is the detailed steps you go through to see the error happen.
   a. If you can take the time to figure out what exact conditions cause a problem, it is HUGELY helpful.
   b. If you have random crashes that you can't figure out, provide as much detail as you can to help the testers narrow things down.