Every company will be slightly different on what they expect, but as a Tester there is a certain standard you should hold yourself to regardless of where you work. This can cut down on turn over time by giving developers/support teams the information they need to fix issues quicker as well as giving stakeholders the right information to decide if they ‘care’.
Different defect systems have different fields, and every implementation may have custom fields as well. I will attempt to go over the ‘standard’ fields you are likely to find with any system.
This field seems to be the most straight forward. This will either look like a one sentence summary of what is wrong (eg: The about button should not be green) or a one sentence summary of what the result should be (eg: The about button should be orange). Either is fine, it just depends on how your organization wants defects to be titled.
This one varies probably more than any, from the amount of levels of priority to the meaning of said levels. The most common that I have seen looks as such (remember this is an example only, and your organization may look different):
P1 – Showstopper/Blocker: This defect will stop us from going live with out a doubt. It blocks a large amount of other tests or ‘breaks’ a core piece of functionality.
P2 – Required: This defect will probably stop us from going live, but it is not stopping us from performing our tests (blocking a lot of other test cases).
P3 – Desirable: This defect is not critical for the release, but may hinder user experience. Something that can usually wait till the next release or for a patch.
P4 – Nice To Have: So low of a priority you would not expect people to spend any time looking at this while any other defects are open.
Note: Remember that as Testers we are not the deciders of priority. We should be actively communicating with our stakeholders as they are the ones who decide. The better you know these people, the better you’ll be able to discern potential priority. For example, some stakeholders may not care about a typo on a settings page, as the application is being used by internal users only. Some may care more about a typo than they care about a missed feature!
This is probably the most important field when it comes down to understanding and fixing the defect. The more detail, the quicker and more accurate the resolution. Here are things I like to include in a description:
- A high level summary of the defect and impact, sometimes called an executive summary, for those that need a 2-3 sentence run-down.
- A description of the defect, including any and all details (eg: user account used, OS, customer account number, function being tested, environment, SKUs). This should include as much detail as available. If your organization has no impact or workaround fields, include that information here as well.
- EXACT reproduction steps. Give the old 1, 2, 3 assuming that the reader has no prior context. The reader should be able to follow your steps if they are a BA, Dev, Triage, PM, or any other role.
- Expected results. It helps if you can include a link to a requirement and maybe an excerpt of it as well.
- Actual results, and if it is not obvious, a comparison of the two.
- Any additional test data (eg: names used for customer, time of day, etc.) that may be relevant to the defect. This really varies based on what you are testing and the defect found.
This field is a lot less common, but a good one to have. If your organization does not provide this field, it can be helpful to include a workaround for this defect (if there is one) at the end of your description. Just like in the description, good practice would be to include actual steps and data to illustrate the workaround to someone who has not performed the workaround before.
There are many other fields that your organization may include in it’s defect tracking system. The best advice I can give is always err on the side of caution and include as much detail as you can. The more detailed the defect, the better job the triage and development teams can do, and the faster the defect can be resolved.
Feel free to comment below how things are done at your organization, thoughts on the post, and anything you think I may have missed!