Software Testing and Quality Control

Cyclomatic Complexity is a structural metric calculated from the control flow graph of code (based on nodes, edges, and connected components). Since it requires knowledge of code structure and control flow, it's fundamentally a white box testing technique used for code coverage analysis and complexity measurement.

Option B states 'Testing can prove that there are no defects' which is INCORRECT. This is a fundamental principle in software testing: testing can never prove the complete absence of defects. Testing can only show the presence of defects (option A), reduce probability of undiscovered errors (option C), but cannot guarantee zero defects (option D). The question asks for the incorrect statement, so B is the correct choice.

Statement Coverage is a white-box testing technique that requires examining the internal code structure to ensure each statement is executed. Black-box testing techniques (equivalence partitioning, boundary value analysis, decision tables) focus on inputs and outputs without seeing the code. Therefore, Statement Coverage does not come under black-box testing.

The Pesticide Paradox in software testing states that if the same tests are repeated repeatedly, eventually they will no longer find new defects because the software becomes 'immune' to those specific tests. To combat this, test cases must be regularly revised and reviewed to discover new defects. Options A and B describe other testing activities, while D is too vague.

Test Control activities involve making decisions during test execution based on monitoring information. This includes setting entry criteria like requiring retest of fixes before proceeding. Test preparation completion percentage and analysis for future recommendations are test management or evaluation activities, not direct test control.

White box testing is a structural technique that examines internal code structure, logic, and implementation. It requires knowledge of the system's internal workings. Specification-based testing is black box testing, which relies on external requirements without accessing internal code. The statement incorrectly categorizes white box as specification-based.

State transition testing is extensively used in embedded software because embedded systems typically have well-defined states and state-dependent behavior. Techniques like use case testing, boundary value analysis, and decision table testing are useful but state transition is particularly well-suited for systems with state machines.

Poor software characteristics are product risks as they affect the final software quality. Problems defining requirements are project risks affecting development process. Design and code quality are project risks. However, failure to follow up on testing findings is a project risk (process issue), not product risk. Option B incorrectly categorizes it as product risk.

Testing is highly context-dependent. The testing approach varies based on domain (safety-critical vs e-commerce), system type (embedded vs web), regulatory requirements, organizational culture, and available resources. A one-size-fits-all approach doesn't work across different contexts.

Test closure activities include finalizing and archiving testware for future reuse. This ensures test artifacts are properly documented, stored, and retrievable for regression testing, audits, or future project reference. Archiving test environment and infrastructure details is part of these closure activities.

Testing objectives include finding defects, gaining confidence about quality, and preventing defects. Fixing defects is a development activity, not a testing objective - testers identify issues but developers fix them.

Acceptance Testing is the testing phase that demonstrates system compliance with user requirements. It is the final testing stage where the system is validated against the agreed-upon requirements before it goes into production. This differs from black box, system, or independent testing which focus on different aspects of quality.

The statement is True in a theoretical sense - complete validation would require testing every possible input in the domain. However, this is practically impossible for most programs due to the infinite or extremely large number of possible inputs. This represents an ideal theoretical goal rather than an achievable testing practice.

Testing is more effective than reviews for locating errors that span modules because reviews typically examine individual modules or components in isolation. Testing can actually execute the interactions between modules, making it better at discovering integration and interface problems that occur when different parts of the system work together.