CTFL 4.3.3: Explain the value of white-box testing
K2Syllabus section 4.3.3
3 original PrepBench practice questions for learning objective 4.3.3 of the CTFL 4.0 syllabus. Try the examples below and check each answer against its syllabus reference.
Practice questions
Question 1
A module's specification is outdated and in places ambiguous, but the team must still find defects in the module. Which strength of the white-box test techniques applies to exactly this situation?
- They reliably reveal requirements that were never implemented in the software at all
- The entire software implementation is taken into account, even when the specification is vague or outdated
- They can be applied before the test object has been designed or implemented
- They remove the need to derive any test cases from a specification
Show answer
- They reliably reveal requirements that were never implemented in the software at allDefects of omission are the corresponding weakness of white-box testing, not a strength.
- Correct answer: The entire software implementation is taken into account, even when the specification is vague or outdatedThe whole implementation is considered even with a vague or outdated specification.
- They can be applied before the test object has been designed or implementedWhite-box test cases can only be created after the design or implementation exists.
- They remove the need to derive any test cases from a specificationWhite-box techniques complement specification-based testing rather than replacing it.
A fundamental strength that all white-box test techniques share is that the entire software implementation is taken into account during testing, which facilitates defect detection even when the software specification is vague, outdated or incomplete. The corresponding weakness is that if the software does not implement one or more requirements, white-box testing may not detect the resulting defects of omission.
Syllabus section 4.3.3
Question 2
Which statement accurately describes a limitation of white-box testing?
- Considering the complete implementation becomes a weakness when the specification is incomplete
- Its coverage measures provide little basis for generating additional tests
- It may not detect resulting defects when the software omits one or more requirements
- Its usefulness is largely limited to executing implemented software dynamically
Show answer
- Considering the complete implementation becomes a weakness when the specification is incompleteConsidering the complete implementation is a strength when the specification is vague, outdated, or incomplete.
- Its coverage measures provide little basis for generating additional testsWhite-box testing provides an objective coverage measure and information for additional tests.
- Correct answer: It may not detect resulting defects when the software omits one or more requirementsRequirement omissions may leave resulting defects undetected by white-box testing.
- Its usefulness is largely limited to executing implemented software dynamicallyWhite-box techniques can also be used during static testing, including dry runs of code or pseudocode.
Although white-box testing considers the full implementation, it may not detect the resulting defects when software does not implement one or more requirements. This is a qualified limitation, not a claim that omissions can never be detected by testing.
Syllabus section 4.3.3
Question 3
A team has run only black-box tests. It now wants to know which parts of the code its tests have never touched, so that it can write further tests for them. What does the team need?
- White-box coverage measures, which give an objective measurement and the information needed to generate additional tests
- A larger set of black-box tests derived from the same specification as before
- A checklist-based test session aimed at the areas the team believes are untested
- An independent test team to repeat the black-box testing from a fresh perspective
Show answer
- Correct answer: White-box coverage measures, which give an objective measurement and the information needed to generate additional testsThey give both the objective measurement and the basis for further tests.
- A larger set of black-box tests derived from the same specification as beforeMore black-box tests still provide no measure of actual code coverage.
- A checklist-based test session aimed at the areas the team believes are untestedA checklist rests on belief about what is untested rather than on measurement.
- An independent test team to repeat the black-box testing from a fresh perspectiveRepeating black-box testing, however independently, still measures no code coverage.
Performing only black-box testing does not provide a measure of actual code coverage. White-box coverage measures provide an objective measurement of coverage and the necessary information to allow additional tests to be generated to increase that coverage, and subsequently to increase confidence in the code.
Syllabus section 4.3.3
Original PrepBench practice material, not official exam questions or exam dumps. PrepBench is independent and is not affiliated with or endorsed by ISTQB®.