Software Testing Techniques and Methodologies

When using reliability metrics to determine testing completion, you want test cases that reflect real-world usage patterns. Option A represents operational profiling, testing system functions proportional to their actual usage frequency. Options B, C, and D describe stress testing, edge-case testing, and complexity-focused testing, which are valuable but not the best fit for reliability-based stopping criteria.

Project risks relate to the management and delivery capability of the project (such as staffing, budget, or suppliers). Product risks focus on potential failures, defects, or quality issues within the software or system being built.

Statement coverage doesn't guarantee branch coverage because a single if-else statement can be fully covered by one branch. Branch coverage guarantees statement coverage because every executed branch implies its statements were executed. Decision coverage is essentially the same as branch coverage for single conditions, so they guarantee each other.

Recorded test scripts are brittle when the UI changes unexpectedly (i), and debugging failed playback is necessary when scripts don't replay correctly (v). Data is not automatically stored separately from scripts (ii); that's an advantage of data-driven testing you'd add manually. Expected results must be added (iii) but that's not a disadvantage of recording itself, and documenting exact inputs (iv) is actually a benefit.

Testing can only prove the presence of defects, not their absence. Due to the infinite path combinations and complexity of software, it is impossible to guarantee that all defects have been removed from a program, making the statement false.

Testable software exhibits observability (you can see its internal state), simplicity (easier to understand and test), and stability (consistent behavior). All three are recognized characteristics of software that is easy to test effectively.

Black-box testing focuses on validating functional requirements, ensuring that each program function is fully operational and produces the expected outputs for given inputs. Glass-box and white-box testing focus on internal program logic and code paths rather than verifying operational requirements from a functional perspective.

White-box testing (also called glass-box or structural testing) examines the internal structure and implementation details of software. It requires knowledge of the code to design test cases that cover internal paths and logic. This contrasts with black-box testing which only considers inputs and outputs.

Black-box testing validates software functionality by examining inputs and outputs without accessing internal code. It checks for incorrect or missing functions, interface errors, and performance issues by testing against specifications. This approach evaluates the system from an external user perspective, simulating real-world usage scenarios.

White-box testing examines internal program structures. Logic errors (like incorrect paths) and typographical errors (like variable misspellings that still compile but cause wrong execution flows) can be missed by black-box testing, which only verifies external inputs/outputs. Both behavioral and performance errors are typically checked in black-box testing.

Cyclomatic complexity measures the number of linearly independent paths through a program's source code. It provides a quantitative metric of code complexity based on control flow analysis. Higher complexity indicates more decision points and potential execution paths, which impacts testing requirements. It does not directly measure cycles, errors, or statements.

Condition testing is a white-box technique that focuses on exercising logical conditions within program modules. It tests various combinations of condition outcomes to ensure all logical paths are validated. The approach specifically targets decision points and boolean expressions, distinguishing it from other control structure testing techniques.

Data flow testing selects test paths based on how variables are defined (assigned) and used (referenced) throughout the program. It tracks the flow of data between variable definitions and their uses to ensure coverage of data relationships. Option A describes basis path testing, option B describes condition testing, and option D describes loop testing, which are different white-box testing techniques.