0% found this document useful (0 votes)
16 views2 pages

SoP - Bug Tracking Tool

This document outlines the standard operating procedure for using Bugzilla as a defect lodging and management tool during the execution phase. It details the necessary information to be filled out when raising a new bug, including product, version, severity, and description, as well as the process for reporting blocker issues and generating reports. Additionally, it provides guidance on how to customize reports for better tracking and analysis of defects.

Uploaded by

Tom Jerry
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
0% found this document useful (0 votes)
16 views2 pages

SoP - Bug Tracking Tool

This document outlines the standard operating procedure for using Bugzilla as a defect lodging and management tool during the execution phase. It details the necessary information to be filled out when raising a new bug, including product, version, severity, and description, as well as the process for reporting blocker issues and generating reports. Additionally, it provides guidance on how to customize reports for better tracking and analysis of defects.

Uploaded by

Tom Jerry
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
You are on page 1/ 2

Execution Standard Operating Procedure (SOP)

Bugzilla

As agreed between Client, Testing team & Dev teams we are using ‘Bugzilla’ as Defect Lodging &
Management Tool; Below mentioned points needs to be considered throughout the execution phase &
details in the tool to be inserted in the mentioned way while raising a New Bug.

However, Post Logging into your individual account, below are the information we need to fill while lodging
a new Bug.

– Product – Default selected as Phase I


 Version – Default selected as unspecified
 Component – User Selection ---Business UAT (For CLIENT TEAM Users), Sample Defects for Walk-
through (For KT session & tool demo purposes) & TestComponent (For TESTING TEAM Users)
 Hardware – Default selected as PC Windows
 Summary – User Selection, Bug Summary must be thorough. It should be Crisp and clear in nature
 Status – User Selection, Separate sheet is attached to understand how the status details needs to be
opted . Status has to be ‘New Call’ while raising any New Bug.
 Reported – Default selected based on Login UserID; When the Bug was raised including Date, Time
& Reporter information
 Modified – Last Date & Time on which any action was made against the Bug
 Deadline Date & Time – User Selection; Date on which reporter of the Bug expects resolution of the
Bug based on the agreed TAT
 Expected Release Date – User Selection; Date on which DEV TEAM agrees to provide resolution of
the Bug based on the agreed TAT
 Assignee – User enter-able; User against which Bug need to be assigned; Separate sheet is attached
to understand how the Assignee details needs to be opted
 Team – User enter-able; Team against which Bug need to be assigned; Separate sheet is attached to
understand how the Team details needs to be opted
 Severity – User selection; has to be selected as Enhancement for a CR point; For any Bug it has to be
selected as Blocker / Critical / Major / Minor. Default option will be Major
 Priority – User Selection - Marking of this should be logical & has to be selected as High / Medium /
Low
 Description – User enter-able; Our defect description should give crystal clear understanding of
what issue we are facing at our end during execution & we shall try to provide details in a way that
No one from the Developing team contact you to understand the issue mentioned in the Bug. This
will be including the reference numbers for e.g, policy number, Endorsement number, Claim number
 Steps to Reproduce – User enter-able; Again, very important & this should be descriptive as well.
Whoever is seeing a bug should be able to navigate through the bug mentioned from the initial to
the screen on which the bug is found.
 Attachment (Snapshots / Evidences) – User Selection - Needless to say, we shall attach system
snapshots according to the bug description in a sequential manner.
 cf_Defect Date: User Selection; Date on which defect was raised
 cf_Product: User Selection; Product of the Bug raised (Private Car / 2W / etc..)
 cf_Module: User Selection; Module of the Bug raised (New Business / Endorsements / Business
Partner/ etc ..
 cf_Department: User Selection; Department of the Bug raised (UWR / OPS / IT / Finance / etc ..)
 Drop Detail: Based on the Scope & Deliverable; to be selected from Drop I to Drop V

Whenever a blocker issue is found, we highlight immediately to DEV TEAM & raise it on Bugzilla. We won't
wait for Defect Triage to discuss this sort of issues. Defect Triage is getting conducted in a daily basis
@11:30A & we need to make sure we discuss the blockers and critical ones in that Meet.

For extracting the report, we should select:


Reports → Tabular Reports → Horizontal & Vertical Axis Selection (This will be user selection for e.g, Status
in Horizontal Axis & Product in Vertical Axis) → Phase Selection → Component Selection → Defect Status
Selection → Resolution Selection → Generate Report → Click on CSV → Check the excel sheet downloaded

By following the above mentioned steps, default report will be downloaded in .csv format from the Bugzilla.

For any changes in the report, we need to click on ‘Change Columns’ button. After clicking this we need to
select the contents we want in the report from the available list of options. After selecting the content, click
on Right arrow & click on Save Changes. Again, click on CSV, By following the above mentioned steps,
manually altered report will be downloaded in .csv format from the Bugzilla.

You might also like