Basic bug attributes

<As this article is based on Microsoft's product summary and is only for learning and communication, any commercial use is prohibited and the consequences are at your own risk!>

During the test, if we find the defect of the product, we will report a bug. What are the basic attributes of the bug? This is the definition at Microsoft.

 

The following attributes are required for a bug:

• General
  1. ID-each bug is unique. Once a new bug is successfully written, the system automatically generates a unique ID.
  2. Title-is a simple description of a bug. If the developer can understand the meaning of a bug through the title, the title is a good title.
  3. Area path-where to find the bug, or which component, XML, qP, QE, am, ts, and so on the bug.
  4. Iteration path-when the bug was found, such as ctp1, ctp2, RC, and RTM.
  5. History-all changes to the bug are reflected in history, including when and who did what.
  6. Description-a detailed description of the bug. It is also a supplement to the Title Description.
  7. Repro-since a bug is reported, you must provide the reproduction steps to Dev so that they can reproduce the bug according to the repro step you provided.
  8. Attachments-log is available in many tests. You can attach the log information in case of errors so that Dev can study the problem more conveniently and in depth.
• Status
  1. Assigned to-who is the bug, or which Dev should be used to fix the bug.
  2. State-Current Status of the Bug, including active and resolved.
  3. Issue type-mainly includes code and test, and other types, such as design, specification, and DCR.
  4. Impact-which aspects are affected by the bug, including functionality, test, localizaion, logo, and UI.
  5. Severity (the smaller the number, the greater the severity)
     • (1)-system crash, data loss, incorrect results
     • (2)-Major functionality or other severe problems; product crashes in obscure Cases
     • (3)-fit and finish issues
     • (4)-Typos, incorrect wording in obscure areas of the Product
  6. Priority (the smaller the number, the higher the priority)
     • (0)-blocking: BVT, autobuilder, build break, unusable
     • (1)-key scenario: embarrassing, PSS involved
     • (2)-important scenario: before any release
     • (3)-some MERs: No PSS or newsgroups; before RTM
     • (4)-may fix if not destabilizing
• Created
  1. Created date-the time when the file bug is provided by the system automatically.
  2. Created by-the name of the person whose file bug is automatically provided by the system.
  3. Source-who discovered it? Test team, dev team, or location team.
  4. How found-how the problem was discovered? Automation testing, ad hoc testing, or bug bash.
• Resolved
  1. Resolved date-the time when the system automatically provides a resolve bug.
  2. Resolved by-automatically provided by the system, the person who resolve the bug.
  3. Resolution-what is the solution? By design, duplicate, external, fixed, not repro or won't fix.
  4. Test ID-which test case found the bug.
• Misc
  1. Branch-branch the problem was discovered in
  2. Build-build the problem was discovered in
  3. Test custom-freeform tagging field for testing