3. Bug Lifecycle Management

QA Process

Bug lifecycle management ensures that defects are identified, documented, validated, tracked, prioritised, and resolved efficiently throughout the QA cycle.

A properly managed bug process improves communication between QA, developers, product managers, and stakeholders while ensuring product stability.

A. Reporting Bugs

1. Write a Clear Bug Title

The bug title should clearly describe the actual issue observed in the system.

A good bug title:

Explains what is broken
Mentions the affected component or behaviour
Is concise but descriptive
Helps developers quickly understand the issue without opening the ticket

For example:

Good: “Ticket count badge shows 0 after applying Open filter”
Bad: “Filter issue”

The goal is to make the issue searchable and understandable immediately.

2. Steps to Reproduce

Every bug must include precise reproduction steps.

The steps should:

Start from a clean state
Be written in sequence
Avoid unnecessary information
Be reproducible by another person without explanation

A proper reproduction flow helps developers:

Recreate the issue consistently
Debug faster
Avoid misunderstandings

If the bug requires specific conditions such as user roles, test data, or browser settings, those details are documented clearly.

3. Expected vs Actual Result

Each bug report should clearly differentiate:

What should happen
What actually happened

The expected result is usually based on:

PRD
Acceptance criteria
Figma design
Existing system behaviour

The actual result should describe the observed behaviour factually without assumptions.

Avoid vague statements like:

“It is broken”
“Does not work properly”

Instead, describe the exact failure condition.

4. Attach Screenshots & Recordings

Visual evidence is mandatory during bug reporting.

Depending on the issue type:

Screenshots are attached for UI or visual issues
Screen recordings are attached for workflow or interaction-related issues
API logs are attached for backend issues

Attachments help developers:

Understand the context faster
Observe timing or animation-related issues
Verify environment conditions
Reduce back-and-forth communication

Each file is labelled clearly to avoid confusion.

5. Include Console & Network Logs

For frontend or API-related issues, browser DevTools are inspected.

This includes:

Console errors
Warnings
Failed network requests
Request payloads
Response payloads
Status codes

Relevant logs are added to the ticket so developers can identify:

JavaScript failures
API mismatches
Backend errors
Failed resources
CORS issues
Authentication failures

For complex API issues, HAR files or request-response screenshots may also be attached.

6. Assign Severity & Priority

Every bug is classified using severity and priority.

Severity defines the technical impact of the issue:

Critical
High
Medium
Low

Priority defines how urgently the issue should be fixed:

Severity and priority are not always the same.

For example:

A cosmetic issue on a homepage banner may have low severity but high priority because users see it immediately.
A backend issue affecting a rare edge case may have high severity but lower priority.

Correct classification helps teams plan fixes effectively.

7. Include Environment Details

Every bug report includes testing environment information such as:

Browser and version
Operating system
Device type
Screen resolution
App version/build number
Environment name (Dev, Staging, UAT, Production)

This helps developers reproduce the issue under the correct conditions.

Many bugs are environment-specific, so missing environment details can delay debugging.

8. Link to Test Case

Whenever possible, the bug is linked to the related test case.

This helps maintain:

Requirement traceability
Test coverage visibility
Release tracking
Regression planning

It also allows teams to identify which scenarios are producing the most defects.

B. Validating & Retesting

1. Reproduce on Clean Session

Before reporting any issue, the bug is reproduced on a clean session.

This usually includes:

Using incognito mode
Clearing cache and cookies
Resetting local storage/session storage
Using fresh test data

This step helps eliminate false positives caused by:

Cached data
Old sessions
Stale API responses
Corrupted browser state

Only reproducible issues should be logged as defects.

2. Cross-Browser Verification

The issue is tested across multiple browsers and devices to identify whether the defect is:

Browser-specific
Device-specific
Responsive-specific
Universal across all platforms

Typical browsers tested include:

Chrome
Firefox
Safari
Edge

Cross-browser verification helps developers narrow down the root cause faster.

3. Duplicate Check

Before raising a new bug, existing tickets are searched.

The goal is to avoid:

Duplicate tickets
Confusion in prioritisation
Repeated debugging effort
Incorrect defect metrics

If the issue already exists:

A comment is added
Additional evidence is attached
Related scenarios are linked

Proper duplicate management keeps the bug tracking system clean.

4. Design vs Bug Check

Before reporting UI-related issues, the implementation is compared carefully against Figma.

Sometimes behaviour that appears incorrect may actually:

Match the approved design
Be intentional
Be part of a design update

This validation prevents unnecessary bug reports.

5. Retest on Correct Build

Before retesting a fix, the deployed build version is confirmed with the developer or release team.

This ensures:

The latest code is deployed
The correct environment is being tested
The fix being validated actually exists in the build

Testing the wrong build wastes time and creates confusion.

6. Regression Test After Fix

After validating a fix, nearby or dependent functionality is also tested.

This regression validation ensures:

The fix did not break related features
Shared components still work correctly
Existing workflows remain stable

Regression testing after fixes is critical for maintaining release stability.

7. Reopen vs New Bug

If a previously fixed issue still exists:

The original bug is reopened
New screenshots/videos are attached
Additional findings are documented

A new ticket is created only if:

The issue is unrelated
The root cause differs completely
The behaviour changed significantly

This helps maintain accurate defect history.

8. Track Fix & Deploy Status

Bug tracking includes monitoring:

Fix status
Deployment status
Environment availability
Retest readiness

QA retesting begins only after:

The fix is confirmed complete
Deployment is confirmed successful
Correct environment availability is verified

This prevents premature retesting.

C. Bug Triage

1. Participate in Bug Triage Meetings

Bug triage meetings are conducted regularly with:

Developers
Product Managers
QA engineers
Stakeholders

During triage:

Open bugs are reviewed
Severity and priority are discussed
Release impact is analysed
Deferred items are identified
Ownership is clarified

The objective is to ensure that critical defects are resolved before release.

2. Clarify Reproduction Steps for Developers

Sometimes developers may not be able to reproduce reported issues.

In such situations:

QA pairs with the developer
The issue is demonstrated live
Additional logs are captured
Environment conditions are verified

This collaboration reduces debugging delays.

3. Identify Root Cause Patterns

Recurring defects in the same module or workflow are monitored closely.

If patterns emerge, QA may identify:

Weak architectural areas
Missing validations
Poor error handling
Incomplete requirement definitions
Unstable integrations

Identifying recurring patterns helps teams improve long-term product stability.

4. Negotiate Deferrals

Not all defects are fixed immediately.

Some bugs may be deferred based on:

Release timelines
Risk level
Business priority
Technical complexity

When deferrals happen:

The decision is documented
Stakeholders are informed
Known issues are tracked clearly
Risk acceptance is confirmed

This ensures transparency during release planning.