Software Testing and Quality Control

Non-functional testing evaluates system characteristics rather than specific behaviors. Performance testing measures speed, scalability, and stability. Usability testing assesses user experience. Both are non-functional. System testing is functional (validates features work correctly).

Functional testing validates what the system does - its features, functions, and interoperability. Option B correctly describes this. Option A lists non-functional tests (performance, load, stress). Option C describes non-functional characteristics. Option D is incorrect - functional testing tests 'what' the system does, not 'how' it works internally.

Test management tools organize test cases, execution, and reporting. Quality Center (now HP ALM) is a comprehensive test management tool. Quick Test Professional is automated functional testing. Load Runner is performance testing. JMeter is load/performance testing. Only Quality Center manages the entire testing process.

Validation determines whether the software meets the user's actual needs, which is commonly summarized as building the right software. Verification, by contrast, is checking if the software was built right according to the specifications, which makes the other options incorrect.

Regression testing verifies that existing functionality still works after changes. Capture/Playback tools record test actions and replay them automatically, making them ideal for repeated regression tests. Test management tools organize tests but don't execute them. Boundary testers focus on edge cases, not regression. Data comparators validate data integrity.

White-box testing examines internal code structure. Mutation Testing alters code to verify tests catch changes. Fault Injection introduces errors to test system response. Code coverage measures how much code is executed. Specification-based testing uses requirements without code knowledge - it's black-box, not white-box.

Security testing is essential for software handling confidential data as it identifies vulnerabilities that hackers could exploit to intrude into the system. Destructive testing tests system stability under stress, usability testing evaluates user experience, and stability testing checks system reliability under load - none specifically address hacker intrusion prevention.

Smoke testing is a quick, initial suite of tests run on a new build to determine if the software is stable enough to proceed with further, more detailed testing. Distractors like end-user testing refer to acceptance testing, while the distinction between possible and reasonable is minor.

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 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.