Effective Defect Reports and Failure Reproduction
1. Introduction
A key goal of a defect report is to help developers reproduce the reported failure as quickly and accurately as possible.
The faster a failure can be reproduced, the sooner the underlying defect can be analyzed and fixed.
결함 리포트(Defect report)의 가장 중요한 목적 중 하나는 개발자가 결함을 빠르게 재현할 수 있도록 돕는 것입니다.
재현이 쉬울수록 결함 분석과 수정도 빨라집니다.
2. Practice Question
❓ Question
Consider the following defect report for a Book Lending System.
- Defect ID: 001
- Title: Unable to Return a Book
- Severity: High
- Priority: (missing)
- Environment: Windows 10, Google Chrome
Description:
When attempting to return a book using the Book Return feature, the system does not register the return and the book remains checked out to the user.
Steps to Reproduce:
- Login to the Book Lending System as a user who has checked out a book.
- Click on the “Book Return” button for the book that has been checked out.
Expected Result:
The book should be returned and no longer appear as checked out to the user.
Actual Result:
The book remains checked out to the user and is not registered as returned in the system.
Attachments: (empty list)
Which of the following is MOST likely to help the developer reproduce the failure quickly?
- a) Adding information about which users and which books the failure affects to the “Description” section
- b) Filling in the missing value for the “Priority” field
- c) Adding memory dumps and database snapshots after each reproduction step
- d) Repeating the same test case for different environments and writing separate defect reports
✅ Correct Answer: a)
3. Explanation
✔ a) Adding affected users and books — Correct
Providing information about:
- Which users are affected
- Which books are affected
gives the developer concrete input data that can be reused immediately.
This significantly increases the chance that the developer can reproduce the failure quickly and reliably.
영향을 받는 사용자와 도서 정보를 제공하면, 개발자는 동일한 입력 데이터를 사용하여 결함을 빠르게 재현할 수 있습니다.
Why the other options are incorrect
❌ b) Filling in the “Priority” field — Incorrect
Priority indicates how urgently a defect should be fixed.
While important for planning, it does not help reproduce the failure.
우선순위는 결함 수정 순서를 정하는 데 필요하지만, 재현에는 도움이 되지 않습니다.
❌ c) Adding memory dumps and database snapshots — Incorrect
Although such technical data can sometimes be useful, adding them:
- Makes the defect report harder to read
- Introduces large amounts of irrelevant data
- Slows down analysis
Especially when added after every step, this approach reduces efficiency.
모든 단계마다 메모리 덤프나 DB 스냅샷을 추가하면 정보 과다로 인해 오히려 분석이 느려집니다.
❌ d) Writing defect reports for different environments — Incorrect
The question focuses on reproducing the failure in a specific environment.
Creating multiple defect reports for other environments does not help reproduce this particular failure faster.
이 문제는 특정 환경에서의 재현을 묻고 있으므로, 환경별 중복 리포트 작성은 적절하지 않습니다.
4. Summary Table
| Option | Helps Reproduction? | Reason | 요약 |
|---|---|---|---|
| a | ✔ Yes | Provides concrete input data | 입력 정보 제공 |
| b | ✖ No | Only affects planning | 계획용 |
| c | ✖ No | Too much irrelevant data | 정보 과다 |
| d | ✖ No | Unrelated to fast reproduction | 초점 벗어남 |
5. Final Takeaway
For the ISTQB exam, remember:
A good defect report helps developers reproduce failures quickly by providing clear steps and concrete, relevant input data.
시험 대비 핵심 문장입니다.
좋은 결함 리포트는 재현에 필요한 명확한 절차와 구체적인 입력 정보를 제공한다.
Related: More ISTQB Posts | Next Question