1. Introduction (Traceability Value Explained)
Traceability is a key concept in software testing, especially in ISTQB Foundation Level. It connects different work products such as business requirements, user requirements, risk items, test conditions, test cases, and test results.
With good traceability, you can answer questions like:
- “Which tests cover this requirement?”
- “Which requirements are affected by this failed test?”
- “How much of the business scope has been tested so far?”
This question checks whether you understand what correct and meaningful traceability looks like in real projects.
이 문제는 “트레이서빌리티가 실제로 어떤 가치를 제공하는가?”를 묻습니다. 트레이서빌리티가 좋으면, 어떤 요구사항이 어느 테스트에 연결되는지, 그리고 어떤 테스트 결과가 비즈니스 목표에 어떤 영향을 주는지 한눈에 볼 수 있습니다. 즉, 요구사항 ↔ 테스트 케이스 ↔ 테스트 결과 ↔ 리스크를 연결해 주는 개념입니다.
2. Question & Options
Question: Which of the following statements is a CORRECT example of the value of traceability?
- a) Traceability between the mitigated risks and test cases that passed provides a means of determining the level of residual risk
- b) Traceability between user requirements and test results provides a means of measuring project progress against business goals
- c) Traceability between testers and test cases that failed provides a means of determining the skill level of the testers
- d) Traceability between the identified risks and written test conditions provides a means of determining which risks are worth testing
보기들은 모두 “A와 B를 연결하면 무엇을 알 수 있는가?”라는 구조로 되어 있습니다. 정답을 찾으려면, “트레이서빌리티가 실제로 하는 일인가?” 그리고 “프로젝트에 도움이 되는 정보인가?”를 기준으로 생각하면 됩니다.
3. Correct Answer
✔ Correct Answer: b)
Why option (b) is correct?
Option (b) talks about traceability between user requirements and test results. This is one of the most classic and useful forms of traceability in testing.
If each user requirement is linked to one or more test cases, and each test case has a result (e.g., Passed, Failed, Not Run), then the team can easily see:
- Which requirements have been tested
- Which requirements have passed all tests
- Which requirements still have failing or missing tests
This gives a clear view of project status in terms of business goals, because user requirements usually represent what the user and business want to achieve.
Example: Imagine you have 10 user requirements for a new online payment feature. Each requirement is linked to test cases, and you can see that:
- 7 requirements have all related tests “Passed”
- 2 requirements have some “Failed” tests
- 1 requirement has “Not Run” tests
From this traceability, you can say something like: “About 70% of the user requirements are fully tested and passed. The rest still need work.” This is a direct measurement of project progress against business goals.
요구사항과 테스트 결과를 연결하면, “어떤 요구사항이 테스트되었는지, 통과했는지, 아직 실패 또는 미실행 상태인지”를 바로 확인할 수 있습니다. 이 정보는 곧 비즈니스 목표(요구사항) 기준에서 프로젝트가 얼마나 완료되었는지를 보여줍니다. 그래서 b) 선택지는 트레이서빌리티의 실제 가치를 잘 설명하고 있으며, 정답입니다.
4. Why the Other Options Are Incorrect
a) Mitigated risks ↔ passed test cases
Option (a) talks about traceability between mitigated risks and test cases that passed. At first glance, this may sound useful, but there is an important problem.
To understand residual risk (what risk is still remaining), you need to know:
- All identified risks
- Which risks have tests linked to them
- Which of those tests passed or failed
- Which risks have no tests at all
If you only look at “mitigated risks” and “passed tests”, you are already ignoring: risks with failed tests, and risks with no tests. These are exactly the risks that contribute to residual risk.
Therefore, this form of traceability is incomplete for determining the level of residual risk, and the statement is not correct.
a) 보기에서 말하는 것처럼, “완화된 리스크(이미 처리된 리스크)”와 “통과한 테스트 케이스”만 연결하면, 아직 남아 있는 리스크(잔여 리스크)는 보이지 않습니다. 실제로 잔여 리스크를 보려면 모든 리스크 ↔ 모든 테스트 결과를 연결해서, 테스트가 없거나 실패한 부분을 찾아야 합니다. 그래서 a)는 틀린 설명입니다.
c) Testers ↔ failed test cases
Option (c) uses traceability between testers and failed test cases to determine tester skill. This is not a good or meaningful use of traceability.
First, the purpose of testing is often to find defects. If a tester is very skilled, they may actually cause more failures because they design better tests that reveal more problems. So, “more failed tests” might mean the tester is good, not bad.
Second, sometimes the test objective is to build confidence that the system works, not to find defects. In that case, many passed tests may be a goal. So simply counting failed tests per tester does not reliably show skill level.
Also, using this type of metric can create bad behavior. Testers might focus on making tests pass (to look “better” in metrics) instead of designing strong tests that actually reveal issues.
c) 보기처럼 “테스터와 실패한 테스트 케이스”를 연결해서 실력을 평가하는 것은 위험합니다. 테스트의 목적이 결함을 찾는 것이라면, 실패한 테스트가 많다는 것은 오히려 좋은 테스트를 설계했다는 의미가 될 수도 있습니다. 또한 이런 지표를 성과 평가에 쓰면, 테스터들이 “실패를 피하는 테스트”만 만들려고 할 수 있어, 품질 향상보다는 숫자 맞추기에 집중하는 부작용이 생깁니다. 그래서 c)는 올바른 가치 설명이 아닙니다.
d) Risks ↔ written test conditions
Option (d) describes traceability between identified risks and written test conditions. This can be useful for checking whether all important risks have at least some test conditions linked to them. It helps identify where more test conditions may be needed.
However, the option claims that this traceability “provides a means of determining which risks are worth testing”. That is not correct.
The decision of which risks are worth testing is part of risk management, especially risk analysis and risk mitigation. It is usually based on factors such as:
- Impact (how bad it is if the risk happens)
- Likelihood (how likely it is to happen)
- Cost and time of testing
Traceability itself does not make that decision. It only shows which risks are already linked to test conditions and which are not.
d) 보기에서 말하는 트레이서빌리티는 “어떤 리스크에 대해 테스트 조건이 작성되었는지”를 확인하는 데는 도움이 됩니다. 즉, 아직 테스트 조건이 없는 리스크를 찾아낼 수는 있습니다. 하지만 “어떤 리스크를 테스트할 가치가 있는지 결정하는 것”은 리스크 관리(리스크 분석·완화)의 역할이지, 트레이서빌리티 자체가 하는 일이 아닙니다. 그래서 d)도 오해를 낳는 표현입니다.
5. Summary & Study Tip
Traceability is powerful when it connects test work to business value and risks. The most meaningful links are usually:
- Requirements ↔ Test Cases ↔ Test Results
- Risks ↔ Test Conditions / Test Cases ↔ Test Results
Option (b) is correct because it shows how traceability between user requirements and test results can be used to measure project progress against business goals.
When solving ISTQB questions, ask yourself:
- “Does this traceability help me see coverage, risk, or progress?”
- “Is this something we would really use in a real project?”
트레이서빌리티는 테스트 활동을 비즈니스 목표와 연결해 주는 강력한 도구입니다. 특히 요구사항과 테스트 결과를 연결하면, “우리가 해야 할 일 중 얼마나 검증되었는지”를 명확히 볼 수 있습니다. 시험에서 비슷한 문제가 나오면, “이 연결 관계가 실제 프로젝트에서 쓸모 있는 정보인가?”를 기준으로 정답을 고르면 훨씬 쉬워집니다. refer to FL-1.4.4
Related: More ISTQB posts / 다음 문제