Software Testing and Quality Control

Statement testing (A) examines code execution - white box. Path testing (B) analyzes code paths - white box. Data flow testing (C) tracks variable use - white box. State transition testing (D) focuses on system states and transitions - this is black-box testing, not white-box, as it tests behavior without examining internal code.

Software testing metrics typically fall into categories like coverage (test coverage metrics), progress (defect counts, test completion rates), and quality (defect density, reliability measures). 'Summary' is not a standard metric category but rather a type of report.

When introducing automation, demonstrating its value (such as ROI and time saved) is critical to justify the initial high investment. While cost, quality, and performance are important metrics, proving value is the primary driver for adoption.

Automation Index measures what portion of your test suite can be automated. Option C correctly identifies it as a percentage of automatable test cases. The other options focus on cost, effort, or investment rather than the core metric of automatability.

Test execution completion is calculated at phase-end to show what percentage of planned scripts actually ran. This timing makes sense as it summarizes the phase's execution performance.

Defect Density quantifies bug concentration by dividing total defects by software size. This metric helps assess quality across different modules or projects with varying code sizes.

Quality of fixes measures the percentage of fixed defects that had to be reopened. Lower values indicate better initial fixes. A reopened defect suggests the original fix was incomplete.

Automation Progress tracks completion of your automation effort by comparing automated cases against automatable ones. Unlike Automation Index (which measures potential), this measures actual progress toward that potential.

This report identifies defects that block the execution of the largest number of test cases, keeping them in a waiting state. High severity or priority bugs do not necessarily block tests, and requirement linking does not measure blocking status.

Problem reports by priority directly reflects quality by showing the distribution of defects by severity. This quality-focused metric differs from process metrics like ageing or retest, which measure timing and workflow efficiency.

A Major defect is one with significant impact that still allows testing to continue, especially when a workaround exists. Critical defects block testing entirely, while Minor defects have negligible impact. The presence of an interim solution confirms this is Major rather than Critical.

Performance testing focuses on system responsiveness, throughput, scalability, and resource utilization (infrastructure). Invalid data entries are functional defects that would be caught during functional testing, not performance testing. Performance testing assumes valid inputs and tests how the system performs under load.

Compatibility testing validates actual software interactions with databases, backward compatibility with older versions, and peripheral compatibility. Forward compatibility (future unknown versions) cannot be tested - it's a design consideration, not a validation element. We can test backward compatibility but cannot predict future system requirements.

Functional testing validates what the system does (features and behavior), not how it performs. Response time, reliability, and memory leaks are non-functional quality attributes that require specialized performance, stress, and longevity testing respectively. Functional testing assumes the system works and checks if features meet requirements.