Scribd
Upload
26 views3 pages

Major Defect Management Guidelines

This document provides guidelines for SoftPro QA team members on defect logging and monitoring. It defines defect severity levels according to ISTQB as critical, major, minor, and cosmetic. Critical defects completely block testing or cause data loss/corruption. Major defects impact major functionality or data but have a workaround. Minor defects affect minor functionality and have an easy workaround. Cosmetic defects do not affect functionality or data. The document also lists best practices for logging defects in the tracking system, including providing a clear title, reproduction steps, attachments, and associating it to the correct story or task.

Uploaded by

Divya Muthanna
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
26 views3 pages

Major Defect Management Guidelines

This document provides guidelines for SoftPro QA team members on defect logging and monitoring. It defines defect severity levels according to ISTQB as critical, major, minor, and cosmetic. Critical defects completely block testing or cause data loss/corruption. Major defects impact major functionality or data but have a workaround. Minor defects affect minor functionality and have an easy workaround. Cosmetic defects do not affect functionality or data. The document also lists best practices for logging defects in the tracking system, including providing a clear title, reproduction steps, attachments, and associating it to the correct story or task.

Uploaded by

Divya Muthanna
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

SOFTPRO: QA DEFECT CHARTER

Document Objective:
The purpose of this article is to ensure and validate all SoftPro QA members have common
understanding of the procedures involved in defect logging & monitoring primarily on

 Defect Severity
 Defect Severity Categorization
 Defect logging best practices
DEFECT SEVERITY DEFNITION (ISTQB)
Severity is defined as the degree of impact a Defect has on the development or operation of a
component application being tested.
DEFECT SEVERITY CATEGORIZATION
Critical:

 The defect affects critical functionality or critical data.


 QA is completely blocked to perform any testing on product
 It does not have a workaround.
 The TFS has 2 options for the same
o 1 – Data Loss/ Corruption/ Security
 Defects related to installation of the product or transactions going to
processing resulting in data loss
o 2 – Functionality loss without workaround
 Defects affecting major functionality or major data of the system being
untestable without any workaround
 E.g. Unable to submit CPL but Jacket submission is successful
Major:

 The defect affects major functionality or major data.


 It has a workaround but is not obvious or simple.
 In TFS the option for the same is
o 3 – Data/ Functionality loss with workaround
 E.g. The expected property details is not mapped from Proform to 360 and
user has to explicitly submit entire property details once again in product
form
Minor:

 The defect affects minor functionality or non-critical data.


 It has an easy workaround.
 In TFS the option for the same is
SOFTPRO: QA DEFECT CHARTER

o 4 – Partial loss of function or feature set


 E.g. An expected value is not checked by default and user has to explicitly
check it in product form
Cosmetic:

 The defect does not affect functionality or data.


 It does not even need a workaround.
 It does not impact productivity or efficiency.
 It is merely an inconvenience.
 In TFS the option for the same is
o 5 – Cosmetic Error
 E.g. Petty layout discrepancies, spelling/grammatical errors.

DEFECT LOGGING BEST PRACTISES

 Ensure below details for the defect is listed in TFS


o Title: Should be concise and clear to all. Adhere to team specific prefix
“Performance: Issue”, “CSI: Issue” etc...
o Iteration Path
o Area Path
o Assigned To:
 All clarification related defects prefixed with ‘Clarification’ to be assigned
to BA
 All vendor related defects to be assigned to BA
 Defects related to user story implementation to be assigned to relevant
developer.
o Severity
o Steps to Reproduce:
 Simple, clear steps to reproduce the defect including any pre-
requisites/conditions/setups/configurations.
 Include Actual vs. Expected result
o Version Found
o Attachments:
 Include all supportive documents (screenshots, video file, log file, binaries
etc.)
o Links: any defect raised has to be associated to respective QA Task/ User Story
 All UI related inconsistencies observed for a single page should be logged under one
defect.
 Attach email chains for defects which has involved back to back discussions with the
project stakeholders to ensure the context is maintained for future references.
SOFTPRO: QA DEFECT CHARTER

 Ensure defect is consistently reproducible, if not mention the same in the defect
description.
 In Multi-QA projects, ensure defects are discussed before logging to avoid duplicate
defects
 For defects which would not be addressed in the current release, mark them active and
assign it to respective BA with appropriate comments.
 In case of any conflict with the Dev., discuss the defect with BA. BA will always have the
last word on it.
 Mark the reopened defects as Active before assigning it to relevant developer. In case of
multiple occurrences of defects being reopened, highlight it to the offshore QA manager/
QA Lead.

You might also like