Software Testing Fundamentals

All listed items are valid reasons for test/system failure: testing fault (test procedure wrong), software fault (code bug), design fault (logic/design error), documentation fault (incorrect specs/docs), and environment fault (external factors).

A driver is a test component that calls the function being tested with test data and verifies results. Stubs simulate called components (not the one under test). Drivers are used for unit testing of functions/methods.

Test prioritization focuses on scheduling and ordering test cases so that the highest-risk or highest-priority items are executed first, ensuring that resources deliver the best possible quality assurance within the limited timeline available.

A new testing tool should first be used by a small pilot team to establish best practices, evaluate its effectiveness, and develop usage guidelines before broader rollout. This prevents ineffective adoption across the organization.

Test data collection should comprehensively cover test factors (what was tested), functions/subroutines (which code units), and environmental/execution details. The option All (C) implies comprehensive data collection including these categories.

File integrity verification uses control totals to detect data corruption or unauthorized changes. Control totals (sums, counts, hashes) provide a mathematical check that file contents remain intact. The other pairs are mismatched.

In software engineering, reliability measures the probability that a system will operate without failure. Option A correctly captures this by focusing on failure likelihood rather than fault presence or other quality attributes like usability or schedule adherence.

Regression testing specifically targets unchanged software components to verify recent changes haven't introduced unintended side effects. It's not limited to UAT phase and can be manual, though automation is common practice.

Equivalence partitioning is a standard black-box testing technique that divides input data into partitions of equivalent behaviors. It is highly versatile and applicable across all testing levels, including unit, integration, system, and acceptance testing.

The actual complexity metric (cyclomatic complexity) quantifies the number of linearly independent paths through source code. Testing coverage aims to traverse these paths, making this metric essential for determining test completeness.