Instruction for bugs triage

Triage instruction
Triage's kanban

Instruction

In triage, must be defined:

the environment of the defect adding one of the bellow labels
- env:production issues detected in master branch
- env:development issues detected in dev branch
- env:next release issues detected in next branch
The Severity
- S0 - Critical defects.
- S1 - Major Defects
- S2 - Minor Defects
- S3 - Trivial Defects
- Examples
- Some tips on finding the severity
  - Decide the impact
  - Isolate the defect
The Priority
- P0 - Immediate
- P1 - Urgent
- P2 - High
- P3 - Normal
- P4 - Low
The type of error
[optionally] The module where it occur (select the label "modeule:")
[optionally] The user role (select the label "role:")
[optionally] Discard**:
- if the behavior reported in the issue is actually correct.
  - Labelled as resolution:by design
- if Triage feels that the issue is not impactful enough to spend time on.
  - Labelled as resolution:WontFix
  - leave a comment explaining why
- If an earlier issue is already tracking this behavior.
  - Labelled as resolution:Duplicated
  - Link to the other issue
- If it's a feature request or a question
  - Labelled as Feature request or question
  - Remove label bug
  - Remove from project board.

Severity

The classification of defect based on its impact on operation of product is called Severity.

#ff5c00 S0 - Critical defects.

Are those which results in the failure of the complete software system, of a critical subsystem so that no work or testing can be carried out after the occurrence of the defect. It also applies to data loss failures and with processes that leave inconsistent data stored on the database.

#ff8106 S1 - Major Defects

Are those which also causes failure of entire or part of system, but there are some processing alternatives which allows further operation of the system. It also applies to the system crashing, or aborting, during normal operation of a non-critical flow.

#fec34d S2 - Minor Defects

Do not result in failure but causes the system to show incorrect, incomplete, or inconsistent results (note that show inconsistent results is way different of generating inconsistent results at database level as explained above). A critical usability issue fits also in this category, as well as if there is a simple workaround.

#87f776 S3 - Trivial Defects

Are small errors that do not prevent or hinder functionality, typos, grammar mistakes, wrong terminology, general usability issues and styling.

Examples

Following are examples of type of Defects, which falls under each category.

Critical defects

It is not possible to use the system on some of the most common flows.
Login does not work
Main page does not load
A null pointer exception on a critical subsystem
Functionality missed out / Incorrect implementation (major deviation from Requirements).
Performance Issues (If specified by a Customer).
Browser incompatibility and Operating systems incompatibility issues (depending on the impact of the error and the statistical usage data).

Major Defects

Accessibility faults
Cursor Set Focus and Tab flow on the Page.
Functionality incorrectly implemented (minor deviation from Requirements).
Performance Issues (if not specified by a Customer).
Mandatory validations for mandatory fields.
Images, graphics, text missing/overlapping which hinders functionality.
Front End / Main Page alignment issues.

Minor Defects

Screen layout issues
Keyboard shortcuts not working
Documentation errors
Page titles missing.
Pages style different than Front End / Main Page style.
Default Value missing for the fields required.
Missing images or text which does not hinders functionality.

Trivial Defects

Spelling Mistakes / Grammatical Mistakes.
GUI image colours etc.

The classification of impact of a defect is important for following reasons:

It helps to determine the efficiency of Test Process.
It helps to decide the priority of the defect, hence improves overall development process by fixing higher priority defects first.
The bug tracking process can be made more effective if the severity of the defect is clearly defined.

Some tips on finding the severity

Following list consist of some questions that may allow you to decide yourself the measure of severity.

Does the system stop working after defect occurs?
Does the system recover from the defect by any means?
If the defect is recoverable, does the system require external effort to recover from the defect? (i.e. it will not recover on its own)
Did I check whether the same defect is reflected in all other related sections (or entire system)?
Can I be able to repeat the defect in some other system having same configuration (O/S, Browsers) as that of the system where I found the defect?
Can I be able to repeat the defect in other configurations also?
Does the defect affect all users? (i.e. Only a particular category of users will face the defect)
Does the defect occurs frequently?
Are the inputs to make the defect easy to get? (i.e. not special data has to be created)

The number of Yes on the previous questions should give you a good idea about the severity.

For example, if the system stops working, then further testing of the system is not possible and hence severity is high. Also the defect should be generalized as far as possible. I.e. after you find the defect, try to find out that the defect is repeated in all cross-browsers, cross-O/S etc.

Decide the impact

Some defects are obvious to decide its severity. For example, "404 HTTP error occurs when navigating to particular screen". Sometimes, a minor defect repeats in all sections or such defect is much more frequent. In those cases, the impact of the defect is higher from the point of view of an user even though it is minor defect. Hence, such defects get higher severity.

Isolate the defect

Isolating the defect helps to find out its depth of impact.

Analyse the defect with what class of inputs does the defect supports.
Make sure that the defect occurs only with particular sequence of operation or list out other sequences, which cause the defect.

Priority

The level of business importance assigned to an item

It is important to note that Priority may change over the time. Triage, on top of setting the priority when receiving a new issue, will periodically review the backlog of open issues to ensure the order of fixing matches current Product Roadmap.

#700e01 P0 - Immediate. Bugs that are mission critical to the core functionality of the application and for which there are no workarounds. These bugs absolutely must be fixed before the customer can release the app to the public.

#d53600 P1 - Urgent. Bugs that are related to the core functionality of the application, but don’t have to be fixed before product launch. However, these bugs should be fixed in the first available patch or release after launch.

#fec34d P2 - High. Should be fixed as early as possible

#feb204 P3 - Normal. May be fixed after the release / in the next release. This is the priority set as default.

#ffd22b P4 - Low. Fixing can be deferred until all other priority defects are fixed

Type of error

a11y Accessibility related functionality is broken
API API is broken or invalid response is coming.
App Crash Some of the functions that can lead to crash of the application. These needs to be identified as early as possible and needs to be rectified.
Browser Compatibility Sometimes latest updates are available and the program may not be compatible with the same.
CALC Improper logic for calculation. The bright example of such an error is the lost Mars Climate Orbiter. Such situation happened because there were used English units in the metric system.
CMD Some expected commands are omitted in the system.
COMM The process of user’s communication with the product may be impossible because of this type of errors, for example, the guide is unavailable or the notifications are not shown.
Compatibility Violation of forwards/backwards compatibility in a design-time piece.
DB If Data in the data base is not getting refreshed \ updated \ deleted or edited
ERRORS Improper handling of the errors. If something goes wrong, the user should get the proper and clear notification. Its text should be short and contain all necessary information about the nature of the error and the ways of its possible removal.
FLOW Control flow bugs. The violation of the sequence of actions.
FUNCTIONAL The improper system behavior or enabled product features.
GUI Relates to design of the Interface. It is either related to the Application Form \ Reports of the application. Also Page Layout issue on Various Screen Sizes can be come under this definition.
l10n Localization related problems
Parse Code syntax error that prevents the code to compile
SSP Software Service Pack. In case new updates are available in the system and application is not compatible with the new updates can lead to these bugs
Syntactic The grammar mistakes or misspelled words and sentences used in product GUI.
SYS Any program which is not compatible with the Operating system, Hardware or the environment can lead to system related bugs