ISTQB_Managing the Product_2.3 Defect Management_TM-2.3.1 (K3) Implement a defect management process, including the defect workflow, that can be used to monitor and control defects

 

Element Description
Defect Management Process of recording, managing, and tracking anomalies/defects throughout SDLC.
Other Names Incident Management (ISO/IEC/IEEE 29119-3), Anomaly Management (TMAP).
Purpose Control quality, identify trends, improve test/dev processes, optimize cost of quality.
Defect Lifecycle Phases Detect → Report → Analyze → Fix → Retest → Close (or Reject).
Detection Methods Static testing (reviews, walkthroughs) & dynamic testing (actual vs. expected results).
Defect Workflow States OPEN → IN PROGRESS → RESOLVED → CLOSED / REJECTED (can include RE-OPENED, DEFERRED etc.)
Best Practices Unified workflow across org, 1 terminal state (CLOSED), role-specific states, meaningful transitions.

Workflow State
Description Example (Web App Defect)
OPEN Defect logged by tester Tester finds login page crashes on invalid email input.
IN PROGRESS Developer starts analyzing Dev reviews logs, identifies validation bug in JS.
REJECTED Defect not valid/duplicate Dev rejects: working as intended per new spec.
RESOLVED Fix applied, ready for retest Dev updates input validation logic and marks resolved.
CLOSED Tester confirms fix & closes Tester retests: no crash, closes defect.
RE-OPENED Reoccurs or fix not valid Same crash still happens in Firefox. Tester reopens.
DEFERRED Fix postponed Minor bug in tooltip text deferred to next release.

   

                    [Defect Management]
                                 |
        ------------------------------------------------------
        |                         |                          |
   [Defect Lifecycle]       [Workflow States]         [Best Practices]
        |                         |                          |
  Detect → Report        OPEN → IN PROGRESS →        - Unified Workflow
  → Analyze → Fix        RESOLVED → CLOSED           - 1 Terminal State
  → Retest → Close       |→ REJECTED / RE-OPENED     - Role-specific States


🔹 Short Scenario MCQ 1

Scenario: A tester finds a discrepancy in the test result but realizes later the test script had a bug.
Q: What should the defect status be?
A. OPEN
B. RESOLVED
C. REJECTED
D. CLOSED
✅ Answer: C. REJECTED


🔹 Short Scenario MCQ 2

Scenario: In an Agile team, a developer fixes a bug and notifies the tester.
Q: What should be the new defect state?
A. RE-OPENED
B. RESOLVED
C. CLOSED
D. IN PROGRESS
✅ Answer: B. RESOLVED


🔹 Long Scenario MCQ 3

Scenario: A defect was found during testing and logged. The developer rejected it, saying it's a duplicate. Later, it was found that both defects had different root causes.
Q: What would be the best practice here?
A. Keep it rejected
B. Mark it as OPEN and assign again
C. Delete the defect
D. Ignore and wait for UAT
✅ Answer: B. Mark it as OPEN and assign again

Q1:

You find that clicking the “Submit” button on a form results in a blank screen. You raise a defect. The dev checks and says it’s not reproducible.
A. RESOLVED
B. REJECTED
C. CLOSED
D. OPEN
✅ Answer: B. REJECTED


Q2:

You retest a defect fixed by the developer, and the issue is resolved. What should be the next state?
A. RE-OPENED
B. IN PROGRESS
C. CLOSED
D. NEW
✅ Answer: C. CLOSED


Q3:

In TDD, several automated tests fail. What is the correct action?
A. Log defects for each failure
B. Reject all failures
C. Do not log them as defects
D. Close them immediately
✅ Answer: C. Do not log them as defects


Q4:

An Agile team uses a simplified defect workflow. Which one is typical?
A. 10-step workflow with assigned QA sign-offs
B. OPEN → IN PROGRESS → RESOLVED → CLOSED
C. IN REVIEW → ESCALATED → READY → DELIVERED
D. PROPOSED → UNDER QA → DEFERRED → OBSOLETE
✅ Answer: B. OPEN → IN PROGRESS → RESOLVED → CLOSED


Q5:

Why should there be only one terminal state (e.g., CLOSED)?
A. Reduces developer workload
B. Simplifies workflow training
C. Ensures consistent defect closure data for analysis
D. Prevents reopening defects
✅ Answer: C. Ensures consistent defect closure data for analysis


Q6:

Who typically owns a defect when it's in “IN PROGRESS” state?
A. Test Manager
B. Developer
C. Product Owner
D. Automation Engineer
✅ Answer: B. Developer


Q7:

Which best describes “cost of quality” in defect management?
A. Money spent fixing UI bugs
B. Total cost of test tools
C. Effort and cost related to preventing, finding, and fixing defects
D. Cost of hardware testing setup
✅ Answer: C. Effort and cost related to preventing, finding, and fixing defects


Q8:

Which of the following is NOT a valid reason to reject a defect?
A. Duplicate
B. Incorrect test case
C. Requirement misunderstanding
D. Developer is busy
✅ Answer: D. Developer is busy


Q9:

A tester logs a defect, but the Product Owner says it's out of scope for this release. What state fits best?
A. REJECTED
B. DEFERRED
C. CLOSED
D. RESOLVED
✅ Answer: B. DEFERRED


Q10:

Defect is fixed but during confirmation testing, issue still exists. Tester should:
A. Close the defect
B. Reopen the defect
C. Escalate to Test Manager
D. Reject the defect
✅ Answer: B. Reopen the defect

                                                  

No comments:

Post a Comment

Lets Start...............

Cypress

Syllabus Q & A Set -1 Q & A Set -2