Software Testing Metrics and Quality Assurance

Finding and fixing faults early in the development lifecycle (such as during requirements or design) is significantly cheaper than resolving them in later test phases or post-release. Fixing bugs late requires expensive rework across multiple development phases.

Testing can show the presence of defects but cannot prove their absence or that software is entirely correct. Finding faults, assessing release readiness, and demonstrating failures are standard testing objectives, whereas proving absolute correctness is mathematically and practically impossible.

Boundary value analysis (A) is a functional testing technique - it tests at input/output boundaries. Usability testing (B) is non-functional. Performance testing (C) is non-functional. Security testing (D) is non-functional. Only boundary value analysis is functional testing among these options.

Features to be tested (A) are definitely in a test plan. Risks (B) should be in a test plan. Schedule (D mentioned as 'Schedule Reports') is in a test plan. However, incident reports (B is correct choice) are OUTPUTS of testing, not part of the plan itself - they are created during test execution, not planned beforehand.

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.

Defect Removal Efficiency (DRE) = defects before release / total defects found. Maximum value is 1 (or 100%), achieved when all defects are caught before release - no defects escape to production.

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.

Defect trend analysis reveals whether project quality is improving or degrading over time by tracking defect discovery and resolution patterns. This temporal view shows project health trajectory, unlike static metrics.

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.

Quality Control (QC) is a product-oriented process focused on identifying defects in deliverables by comparing them to set standards. Quality Assurance (QA) is process-oriented, focusing on defect prevention. Hence, comparing quality against standards to detect nonconformance is QC.

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.