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