Scribd Logo
Upload

Welcome to Scribd!

  • 61 views

    Defect Charter

    Uploaded by

    Divya Muthanna
    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.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Defect Charter

    Uploaded by

    Divya Muthanna
    61 views3 pages
    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.

    Original Description:

    defect charter

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    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.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    61 views3 pages

    Defect Charter

    Uploaded by

    Divya Muthanna
    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.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 3

    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