Upload a document about writing defect. Hope it is useful for you！o(∩_∩)o...
This document gives a guideline for writing defect.
|
All Defects Should Contain the Following: |
|
Defect ID |
Created by UrTracker system. |
|
Brief Descrīption |
Very short descrīption to identify the defect. |
|
Severity |
Based on customers’ experience. |
|
How Found |
Ad-hoc |
|
scrīpt |
|
Status |
Generated manually in UrTracker. |
|
Date Submitted |
The time when defect is created. |
|
Closed Date |
Updated by system after defect closed |
|
Priority |
Based on Severity, Difficult to fix and so on. |
|
Build Version |
The build version when defect reported |
|
Detailed Descrīption |
ACTUAL RESULT: |
|
Describes the incorrect behavīor. |
|
|
|
EXPECTED RESULT: |
|
Describes the correct behavīor. |
|
|
|
STEPS: |
|
Describes how to reproduce the defect |
|
|
|
RECOVERY: |
|
Describes how to recover from error, etc. |
|
|
|
ADDITIONAL CHARACTERIZATION NOTES: |
|
Include whether defect is reproducible. |
|
The related info of the defect. |
|
|
|
ERROR INFORMATION: |
|
*Only include if applicable |
|
|
|
Test File/Test Case No. |
If defect found during scrīpted testing, type the scrīpt name here. |
|
Workaround |
Describes how to avoid defect |
|
Configuration |
The environment in which the defect occurs. |
This section is for AEM Planet project. It lists general guideline for writing a good defect.
1. An effective defect report usually has the following qualities:
Consistency-----Write to a standard format (or template).
Readable---------Easy to read and understand.
Repeatable------Contains information needed to reproduce the problem.
Clear---------------Do not include ambiguous or confusing information.
Concise-----------Content is brief but comprehensive.
Correct------------Do not include inaccurate information.
Complete---------Do not miss critical information.
Relevant----------Report contains relevant information needed to understand the problem.
Focused----------Describes one specific problem.
2. Useful tips for writing effective defect reports with the qualities listed above include:
----------Make wise decision on your own to collect required defect information in an efficient method.
----------Analyze the defect and just do necessary test verification that can provide valuable information.
----------In order to get more information related in a defect, you have to doing more verification. That means more test time and much more money. Remember doing effective testing to save money.
----------Keep your target audience in mind when writing your defect report. For example, though the assigned engineer may be your primary target, someone else may be reassigned to resolve the problem and there may be a variety of other readers for this report.
----------Spend a few extra minutes writing your defect reports. You already spend a lot of valuable time finding defects. Make your time worthwhile so you can improve your chances of getting your defect fixed.
----------Reread the final report to make sure it makes sense and that you have captured all relevant information.
----------Have someone else review and provide feedback on your defect report.
----------Do not be judgmental about someone’s work or design in your defect report. Avoid words such as “why did you” or “this is a poor design”. This will not help the defect resolution process.
3. Don’t use ambiguous words and sentence in the defect, for example:
----------Doesn’t work.
----------Can’t be installed.
----------An error/unexpected box pops up.
----------The roll bar cannot be moved.
4. Brief Descrīption--------is the most important part in the defect. A good one-line summary will help everyone quickly understand a problem while at the same time will uniquely identify a problem. A one-line summary is similar to a newspaper headline.
----------It should be concise. It is not the step list.
----------Don’t begin with the Verb, or the Adverbial Modifier.
----------Don’t contain the unnecessary information. For example, if you found a defect on OS 9x. But in fact, this defect also occurs on other OS, such as OS 2K, XP, please don’t contain OS 9x in the Brief Descrīption.
Examples:
----------Language in the first row has a strange format in the supported language list. (What does the word “Strange” mean? What kind of symptom is strange?)
----------The Minimal Install does not include any section of Build. (“any section” here doesn’t make any sense.)
5. Steps:
----------Use action words to start describing a step.
----------Don’t list too many steps. It is better if the steps are less than 8 steps.
----------Don’t confuse the steps and the actual result.
----------Use short sentence to instead of long sentence.
6. Actual Result:
----------If the defect contains different symptom with the same defects, we prefer to submit separate defects with different symptom.
----------Don’t confuse the actual result and expected result.
----------Do not be judgmental about someone’s work or design. Don’t use the subjective word.
----------Actual Result should also be concise.
7. Expected Result:
----------Make the expected result that defined in spec and the expected result that you think that should be as different.
----------Do not be judgmental about someone’s work or design. Don’t use the subjective word.
8. Additional Information------Additional Information maybe different with different kind of defects. The basic rule for providing the additional information is trying our best to help the developer to get the root cause of the defect. Any information may help the developer get the root cause of the defect should be listed here.
----------Does the defect also occur on other OS?
----------Is the defect related to the different Browser configuration?
----------Is there any workaround?
----------What’s the reproduce rate?
9. Attachment------Screenshot is helpful for developer to identify the defect, especially the complex defect.
----------Don’t include unnecessary margin with the screenshot.
----------The screenshot should be clear enough.
----------It’s better to use the Red color to point out the error area, with clear comment. The comment should also use highlight color, such as red color, 12 size font.
----------The screenshot should be saved as .JPG format instead of .BMP format.
10. Configuration-----We should provide the special configuration information based on special defects. Configuration information includes but is not limited to: Browser, Application, PC H/W, Build, and OS version.
