Software Defect Prevention

Defect prevention practices, finding defects in a specification with models and review techniques, analyzing test results to improve defect detection, and defect classification for root cause analysis.

5 minutes 5 Questions

In the ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA) syllabus, Software Defect Prevention covers activities that stop defects from being introduced, or find them as early as possible, instead of only detecting failures during dynamic testing. Preventing or containing defects early lo…

Concepts covered
Structural Coverage Analysis and Test Gap AnalysisAd Hoc ReviewingRelating Test Results to Defect Counts and SeverityPredicted Versus Actual Defect Cluster AnalysisPerspective-Based ReadingScenario-Based ReviewingDefects Revealed by Data-Based, Behavior-Based and Rule-Based ModelsDefect Detection Percentage AnalysisRoot Cause Analysis Supported by Defect ClassificationChecklist-Based ReviewingDefect Arrival Pattern AnalysisRole-Based ReviewingDetecting Defects in Activity DiagramsTest Analyst Contributions to Defect PreventionDetecting Defects in Decision Tables and with Model-Based TestingModeling a Specification to Reveal Its DefectsDetecting Defects in State Transition DiagramsMeasuring Defect Prevention: Defect Removal Efficiency and Phase Containment EffectivenessDefect Classification Methods: Orthogonal Defect Classification, IEEE 1044 and Defect Taxonomies
Test mode:
Start practice test

CTAL-TA - Software Defect Prevention Example Questions

Test your knowledge of Software Defect Prevention

Question 1

A test analyst reviews defect arrival data for an order management system that exchanges data with a warehouse system. System integration testing ran four iterations and found 5, 6, 5 and 6 defects. Every planned test was executed, with a 96% pass rate. The team had expected arrivals to rise to a single peak and then fall slowly. Acceptance testing then ran three iterations and found 4, 19 and 11 defects. Of these 34 acceptance defects, 22 are wrong field mappings between the two systems, and these are covered by test conditions at system integration level. Another 9 are workflow appropriateness issues that emerged only when end users performed real tasks. The remaining 3 are cosmetic. Which improvement to defect detection do these results point to most strongly?

Correct Answer: Redesign the system integration tests for order-to-warehouse data mapping, since that level stayed flat while missing defects it could catch

The flat integration arrival curve, instead of the expected peak, combined with 22 field-mapping defects later found in acceptance, shows that the integration tests were ineffective at detecting defects their own test conditions covered. Those tests should be redesigned.
Keeping the tests unchanged mistakes a high pass rate for quality when the tests were simply weak. Adding scenario-based integration tests targets the 9 appropriateness defects, which only emerged when real users performed real tasks and so are rightly found in acceptance testing. Extending acceptance testing treats the symptom and does not fix the leakage from the earlier level.
Key concept: using defect arrival patterns and defect leakage to judge test effectiveness.

Question 2

A test analyst analyzes system testing of a parking permit portal 90 days after release and splits the defect data by user role. Resident role: system testing found 40 defects and 18 escaped to production, all of them cosmetic. Business account role: system testing found 12 defects and 8 escaped. Three of the 8 came from timeouts in the live payment gateway, which the test environment did not include and which was out of system testing scope. The other 5 escapes are high severity, and all occur when renewing fleet permits for exactly 10 or 11 vehicles, where the rules change from a standard fee to a fleet fee. Administrator role: system testing found 18 defects and 2 medium-severity report layout defects escaped. Which improvement to defect detection do these results point to most strongly?

Correct Answer: Design boundary value tests for business-account fleet renewals around the ten-vehicle fee change, where that role's high-severity escapes cluster

The five in-scope high-severity business escapes all occur at 10 or 11 vehicles, where the fee rule changes, so focused boundary value tests there would catch the most important missed defects.
The resident role has the most escapes and the lowest in-scope detection percentage (40 of 58, about 69%), but every escape is cosmetic. The business role's raw 60% includes three gateway timeouts that were outside system testing scope; excluding them gives about 71%, and the low raw figure does not justify a gateway fix. Exploratory charters for every business screen are unfocused, because the escapes cluster at one specific boundary.
Key concept: interpreting defect detection percentage by excluding out-of-scope escapes, weighting by severity and targeting the technique to where escapes cluster.

Question 3

After system testing of a new release of a utility meter reading service, a test analyst investigates why three high-severity failures reached production. The technical test analyst's test gap report compared the release build with build 17, the first build delivered to system testing. It listed 4 of 140 changed methods as unexercised, and all 4 received new system tests before release. Since the previous production release, 390 methods had changed in total, and 250 of them were changed in builds 9 to 16, which went only to component testing. Coverage was recorded for every system test run on builds 17 to 23. All three production failures were in methods changed in build 12 that no system test had executed. Which improvement to defect detection do these results point to most strongly?

Correct Answer: Set the gap comparison baseline to the previous production release so every change since then is checked against system test coverage

The failures came from methods changed in build 12, which predates the build 17 baseline. Those changes never appeared in the gap report, so moving the baseline to the previous production release would have exposed all 390 changes, including the 250 that only went through component testing.
Running the analysis after every build still uses the wrong baseline, so the build 12 changes would stay invisible. Risk-weighting older low-coverage methods targets unchanged code rather than the untested recent changes. Merging component coverage would mark the failing methods as exercised and hide the very gap that let the failures escape.
Key concept: test gap analysis depends on choosing the correct comparison baseline for changed code.

More Software Defect Prevention questions
510 questions (total)
Practice 100 questions
One session at a time, always new questions