Software Testing Fundamentals

Internal failure in testing context refers to addressing defects at their origin within the development process itself. Training programmers to write better code and introduce fewer bugs represents a preventive approach that targets the root cause of defects - the human element and development practices. This is fundamentally different from external failures that manifest during testing or in production, as it focuses on prevention at the source rather than detection downstream.

Structural testing examines the internal implementation details of software, including code structure, logic flow, algorithms, and data handling. It requires knowledge of and access to the internal code architecture, making it synonymous with white box testing. This contrasts with black box testing (also called functional testing) which only considers inputs and outputs without knowledge of internal workings.

A test driver is a control program that invokes and coordinates the execution of the software component being tested with various test data sets. It serves as the test harness that drives the testing process, captures output from each test case, and organizes results for evaluation. Test drivers are essential for automated testing and enable systematic execution of multiple test scenarios without manual intervention.

Desk checking is an informal software quality technique where the developer manually reviews, traces, or checks their own code logic before formal testing begins.

The compound condition condition1 && (condition2 || function1()) contains multiple atomic conditions that can be independently true or false. Condition coverage requires testing each atomic condition for both true and false values, which is necessary here since we have condition1, condition2, and the return value of function1(). Decision coverage would only test the overall if/else decision (true/false), statement coverage would only ensure each statement is reached, and path coverage would test all possible paths through the code which is more comprehensive than needed.

Equivalence partitioning divides input or output data into ranges where the system handles all members similarly. Therefore, testing just one representative value (597078) suffices to cover the partition. Testing every value (597080) is redundant and defeats the purpose of the technique, while options 597078 and 597081 do not define equivalence classes.

Exhaustive testing means testing all possible combinations of inputs and preconditions. While theoretically possible, it becomes impractical for real-world systems due to the combinatorial explosion of test cases. The answer correctly identifies this dichotomy - it's possible in principle but not feasible in practice.

White-box testing techniques require knowledge of internal code structure. Statement testing, decision testing, and condition coverage all examine internal code paths. Boundary value analysis is a black-box technique that only considers input/output boundaries without internal code knowledge.

Test closure activities occur after testing is complete and include handing over testware, archiving testware, and evaluating the process. The hand-over of test-ware (test scripts, data, logs) to maintenance or other teams is explicitly part of test closure.

Smoke testing (also called confidence testing) is the initial testing done to verify that the most crucial functions work. If the smoke test passes, you have confidence the build is stable enough for further testing. Sanity testing focuses on specific defect fixes, not initial confidence.

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.

Maintenance is a non-functional quality characteristic because it describes HOW the system performs (ease of modification, updating, or repairing) rather than WHAT it does functionally. Non-functional characteristics include attributes like usability, reliability, performance, and maintainability. Feasibility (A) is a project consideration, Usability (B) is also non-functional, and Regression (D) refers to a type of functional testing.

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.

COTS is a standard industry acronym that stands for Commercial Off-The-Shelf, which refers to software or hardware products that are ready-made and available for purchase in the commercial market.

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.