Standard Bug Templates
This guideline describes the custom standard fields used in bug templates. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.
Overview
The bug template is an ABB customized template displaying the minimum requirements of fields including standard state as in the Azure DevOps Agile template plus ABB-specific fields. These specific fields are described below.
The CM process group is responsible for updating the standard bug template that is found in Opex - Repos - Configuration Management. Both templates used on-premises and in the cloud are managed by the group.
List of standard custom fields to add
- Overview
- Security fields
- Regression
- How Found
- Product Issue Number (PIN)
- External Reference
- Definition of Ready / Definition of Done
- ScopeBug
- Cloned
- Impact Analysis
- Introduced In
Security fields
To capture any potential impact on security issues, three security fields are added to be filled in case the bug is a security bug:
Effect
The Effect field states the security effect of the bug. Effect is a mandatory field. For more information, see Bug Classification
CVSS
CVSS (Common Vulnerability Scoring System) is a standard used to estimate the severity of system vulnerabilities.
Example: 8.3
CVSSCalc
CVSSCalc provides the link https://www.first.org/cvss/calculator/ to the CVSS standard web page where CVSS can be estimated to a numerical value. The calculation vector is stored in this field to show how the CVSS score was calculated.
Regression
For a definition of regression bugs, see the Regression Bugs guide.
The field named Regression is false by default and is set to True if the bug is a regression bug.
How Found
The How Found field is used to track when a bug was found. This is mandatory to fill in when registering the bug. One of the following items can be selected:
| Entry | Bug found |
|---|---|
| 01-Requirements | due to wrong/ambiguity requirement |
| 02-Design | due to wrong design |
| 03-Development | during development/unit testing |
| 04-Deployment | during deployment |
| 05-Dev Test | during manual testing |
| 06-Dev Test Automation | during automatic testing |
| 07-Documentation | during User documentation validation |
| 08-SIT | during System Integration test |
| 09-STT | during System Type test |
| 10-STT Automation | during automatic System Type test |
| 11-Media Verification | during Media verification test |
| 12-Pilot | during pilot phase by LBL/customer |
| 13-Post Release | after release, by customer |
| 14-Forward Port | fixing the bug in a newer version |
Product Issue Number (PIN)
Product Issue Number (PIN) is a unique identifier for every problem reported for the product life cycle and it is not changed once assigned.
A Product Issue Number shall be the only used identifier for an issue during communication via support cases, Field Communications, etc
For more details: Product Issue Number
External Reference
External reference is the link between the Bug raised in ADO (L4 bug) and Salesforce (customer) case.
Definition of Ready / Definition of Done
Definition of Ready and Definition of Done is implemented as a custom control using the Appgami checklist extension.
Prerequisite: The Appgami checklist extension is needed and it requires a commercial license for each organization. If the extension is not available, work item type definitions cannot be loaded correctly. If the license expires, data will still be available in work items, and queries will still work, but checklists will not be visualized by the custom control.
DoR is made of 3 fields:
- Definition of Ready
- DoR Progress
- DOR Completion
DoD is made of 3 fields:
- Definition of Done
- DoD Progress
- DOD Completion
Example:
How to find work items where the Definition of Ready is not complete?
DoR Completion <> Yes
ScopeBug
Boolean field that represents whether the bug is considered a scope bug or not. It is false for introduced bugs found during internal testing, true for deferred bugs and post release bugs.
See How-to Handle Deferred Bugs and How to Handle Bugs in Multiple Releases.
Cloned
Yes/No field that represents whether the bug is a clone of another one. (Note: It is a Yes/No text field and not boolean due to historical reasons)
Default value: No
The original bug has Cloned=No, the new bug cloned from it has Cloned=Yes.
See How-to Handle Deferred Bugs and How to Handle Bugs in Multiple Releases.
Impact Analysis
Free text field to be used to answer impact analysis questions. The questions can be customized depending on project.
Introduced In
The oldest release where the bug is known, where it was first introcuded. The allowed values are the same as area path. If multiple instances (duplicates) of this bug exist, this field is readonly in the copies and can be written only in the original bug, the one having "Cloned"=No.