Software Testing and Quality Control

Stress testing explicitly evaluates how a system behaves when load conditions near, meet, and exceed maximum capacity. In contrast, load testing typically validates performance under expected normal or peak load profiles without deliberately forcing failure.

Smoke testing is also known as sanity testing. It's a preliminary testing phase that verifies the most critical functions of an application work before proceeding to more comprehensive testing. The term comes from hardware testing where you plug in a device and check if it smokes. Adhoc testing (A) is informal but not specifically sanity-focused, Compatibility testing (B) checks cross-platform behavior, and Mutation testing (D) involves modifying code to test test suites.

Good testing practices include early test analysis and design (A) and defining different test levels with specific objectives (B). These principles ensure thorough coverage throughout the development lifecycle. Option C is incorrect because testers should get involved BEFORE coding starts, not after - they should be involved during requirements and design phases to enable testability and early defect detection.

Adhoc testing is performed without formal test plans or test case documentation. Testers rely on their intuition, experience, and understanding of the system to find defects on an ad-hoc basis. This contrasts with Alpha testing (A) which is formal testing by developers, Beta testing (B) which is formal user testing, and Unit testing (C) which follows structured test cases for individual components.

Alpha testing is a form of internal validation testing performed by potential users, customers, or internal test teams at the developer's site. Because the target testers are external-like users rather than the core developers themselves, 'users/customers' is correct.

Independent testing encourages objectivity because testers are separate from the development team and have no stake in proving their code works. This independence reduces bias that developers might have when testing their own code. Unit Testing (A) and System Testing (B) are test levels, not approaches to ensuring objectivity. Destructive Testing (D) is a testing technique, not an organizational approach.

An Acceptance Test Plan describes testing where the primary goal is establishing confidence that the system meets requirements and is ready for deployment. Acceptance testing focuses on validating that the system satisfies user needs and business requirements. A Master Test Plan (A) covers all testing, a System Test Plan (B) focuses on integrated system functionality, and a Project Plan (D) covers overall project management, not just testing.

Test harness and unit test framework tools primarily support test execution and logging. These tools automate running test cases, capture results, log execution details, and report pass/fail status. While some frameworks may have features for management (A), specification (B), or performance monitoring (C), their core function is executing tests and recording outcomes.

Usability testing evaluates how user-friendly an application's interface is. It focuses on the user experience, ease of navigation, intuitiveness of design, and overall satisfaction when interacting with the system. This is distinct from Regression testing (A) which checks for unintended changes, Performance testing (C) which measures speed and scalability, and Functional testing (D) which verifies specified behaviors.

Use Case testing identifies test cases that exercise the entire system from start to finish on a transaction-by-transaction basis. Use cases represent real-world user scenarios and workflows, making them ideal for validating end-to-end system functionality. Unit testing (B) focuses on individual components, State transition testing (C) examines system state changes, and Decision table testing (D) maps complex business rules.

Review techniques like walkthroughs and inspections can be applied to any documented work product in software development. This includes software code, Requirement Specification documents, Test Design specifications, and other artifacts. Reviews are a static testing method that examines documents without executing the code.

Functional testing is classified as a test type (testing what the system does) rather than a test level. Component testing, System testing, and Acceptance testing are test levels (organizational levels of testing). The ISTQB classification of test types includes functional testing, non-functional testing (performance, usability, etc.), and white-box/structural testing as the main categories.

Structure-based testing techniques (also called white-box testing) analyze the internal structure of the code. Their key characteristic is that they are used both to measure coverage (like statement coverage, branch coverage) and to design additional tests specifically to increase that coverage. This distinguishes them from experience-based techniques and specification-based techniques.