CTFL-v4 Static Testing Practice Question
During a review process, a tester notices that the requirement document is ambiguous regarding how a specific error message should be displayed. What is the best course of action for the tester?
⚠ Common exam trap
Candidates often assume testers should guess the developer's intent or wait until dynamic testing to uncover requirement ambiguities, missing the opportunity provided by static review.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Report it as a defect in the requirement document during the review.
Clear communication is essential in static testing. Reporting the ambiguity as a defect is critical because ambiguous requirements lead to incorrect implementation. By documenting this as a defect, the tester ensures that the author must clarify the requirement before development begins. This proactive approach prevents the developer from making incorrect assumptions, thereby saving time that would otherwise be spent on rework after the feature is implemented.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Assume the most logical implementation and document that in the test plan.
Why it's wrong here
Assuming an implementation path creates a risk of mismatch between the developer's logic and the user's requirements. Testers should never assume behavior; instead, they must ensure requirements are clarified. If the requirement is ambiguous, the correct action is to flag it for the author to resolve immediately.
- ✓
Report it as a defect in the requirement document during the review.
Why this is correct
Documenting ambiguity as a defect is the correct procedure. Static testing aims to improve document quality; therefore, identifying gaps or vague language is a successful outcome. This forces the stakeholder or author to clarify the requirement, ensuring that development is based on accurate, unambiguous information from the start.
- ✗
Ignore the ambiguity until the dynamic testing phase identifies it.
Why it's wrong here
Postponing the identification of an ambiguity until dynamic testing is inefficient. By that point, code has already been written and potentially integrated. If the requirement was wrong, the cost to change it is significantly higher than simply clarifying the document during the review phase of development.
- ✗
Ask the developer to decide how the error message should behave.
Why it's wrong here
Developers are not the primary authority on requirement intent. While they may have technical input, the product owner or business analyst should clarify requirements. Leaving this decision to the developer ignores the business perspective and risks building functionality that does not align with user needs or stakeholder expectations.
About these practice questions
One of 144 original CTFL-v4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISTQB exam blueprint
This CTFL-v4 practice question is part of Courseiva's free ISTQB certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CTFL-v4 exam.