Software Testing Fundamentals

Structure-based testing (also called white-box testing) derives test cases from the internal structure of software - such as code, design, and architecture. It requires access to and understanding of how the software is built internally. Option A describes specification-based testing, B and D refer to experience-based testing techniques.

Testing exit criteria are based on measurable completion indicators like code coverage thresholds, defect density trends, and cost-benefit analysis. Resource availability is a constraint that affects HOW testing is performed, not a decision criterion for WHEN to stop. The stop decision depends on whether test objectives have been met, not on whether resources remain available.

In quality management, quality is most standardly defined as conformance to requirements, ensuring the product meets specified user needs. While zero defects is an ideal goal, it is not the definition itself, and testing metrics do not define overall quality.

Risk-based testing is fundamentally an analytical approach because it involves systematic identification, assessment, and prioritization of risks using analytical techniques. It uses risk assessment matrices, impact analysis, and probability calculations to determine testing priority - making it analytical rather than model-based (which uses formal models), methodical (which follows predefined procedures), or consultative (which relies on expert judgment).

Test control (part of test management) involves taking corrective or guiding actions based on test metrics and reports. Test monitoring is gathering data, test reporting is presenting information, and test planning is upfront preparation. Control is the active response to reported information - taking action to realign testing with objectives when metrics show deviations.

Test process activities (planning, monitoring, control) can begin once requirements have been approved because these activities depend on having defined test basis. Testing doesn't require code completion or delivery - test planning and design happen during earlier phases. Design completeness alone is insufficient; requirements approval provides the necessary foundation.

Configuration Management is responsible for uniquely identifying and controlling versions of test items, documents, tests, and test harness. It provides version control, traceability, and reproducibility. Risk Management deals with risks, Defect Management tracks bugs, and Incident Management handles test incidents - none of these provide the unique identification function described.

Cyclomatic complexity was developed by Thomas McCabe and is commonly called McCabe's number or McCabe's complexity metric. It's a measure of code complexity based on control flow. McAffee is unrelated, 'Test complexity value' is not a standard term, and 'Defect density' measures bugs per unit size, not structural complexity.

Defect detection and correction is Quality Control - it involves inspecting the product to find and fix defects. Quality Assurance focuses on preventing defects through process improvement. Defect management is the tracking system, and Software testing is the broader activity. The detection-correction cycle is reactive QC, not preventive QA.

V model, Agile model, and Waterfall model are well-known software development/testing models. The 'X model' is not a recognized testing or development model in standard software engineering literature. This appears to be a fabricated option to test fundamental knowledge of testing models.

Severity 1 indicates the most critical defects (system crash, data loss, complete feature failure). Such high-severity defects must receive high or urgent priority for resolution. Assigning 'Low' priority to a Severity 1 defect would be inappropriate because the impact is critical, even if frequency is low. Priority must align with severity for critical issues.

Bugzilla is a widely-used web-based bug tracking and defect management system developed by Mozilla. It's used for reporting, tracking, and managing defects/issues. It's not for scenario generation, regression testing automation, or test data generation - its primary and well-known purpose is defect/issue management.