Software Testing and Quality Control

The absence-of-errors fallacy is a fundamental testing principle stating that finding and fixing defects does not guarantee a usable system. A system can be defect-free but still fail to meet user needs or business objectives. Testing is context-dependent, exhaustive testing is impossible, and early testing is actually recommended.

Test analysis and design is the phase where testability is evaluated. During this phase, testers examine the test basis (requirements, specifications) and test objects to determine if they can be effectively tested. This includes checking if the requirements are clear, measurable, and testable.

Test closure activities include checking planned deliverables, archiving testware, and handing over to maintenance. Writing a test summary report is actually part of evaluating exit criteria and reporting, not a test closure activity. The test summary report is created earlier when deciding if testing is complete.

Good relationships between testers and developers depend on professional, objective communication. Writing factual incident reports helps developers understand and fix issues without feeling personally attacked. Understanding managers, identifying workarounds, and promoting quality are all valuable but secondary to clear, objective reporting.

Testing is split into distinct stages primarily because each stage serves a different purpose - unit testing checks individual components, integration testing checks interfaces, system testing checks the whole system, etc. This separation ensures comprehensive coverage.

Regression testing involves re-running many existing tests repeatedly after each code change. Test tools automate this efficiently, saving significant time and effort compared to manual execution. Other testing types like UAT, system testing, and integration testing often require more human judgment and exploratory approaches that benefit less from pure automation.

A requirement is testable if it can be verified through a concrete, measurable test. Specifying that response time must be 'less than one second' under a specific load provides a quantifiable metric, unlike subjective or impossible criteria like 'user friendly' or '0 faults'.

System testing is typically performed by independent test teams (option A is true). Faults found during system testing are indeed expensive to fix because they're caught late in development (option B is true). Functional testing, which tests against requirements, is more commonly used than structural testing in system testing (option D is true). End-users are primarily involved in user acceptance testing, not system testing, making option C the false statement.

Testing is complete when the required level of confidence has been achieved, not when arbitrary conditions are met. Time running out (option A) is a constraint, not a completion criterion. Finding no more faults (option C) is unrealistic and doesn't prove sufficient coverage. Option D is subjective and unmeasurable. Option B is the only criterion based on measurable confidence levels and risk assessment.

The V-model is a systems development lifecycle model that maps testing phases directly to corresponding development phases. It verifies designs early through static techniques and aligns verification (like design reviews) with validation (testing code against specifications).

A test plan includes features to be tested (option A), risks (option C), and schedule (option D) - these are all planning elements. Incident reports (option B) are documents created during test execution when defects are found. They are outputs of the testing process, not inputs to the planning phase.

A failure is a departure from specified behavior - the system doesn't work as expected. Option A describes a defect or bug in the software. Option C describes an error in the code. Option D describes a mistake made by a person. The standard sequence is: mistake (human) → error (code defect) → failure (observable incorrect behavior).

Verification asks 'Are we building the product right?' - it checks that the software correctly implements the documented requirements and specifications. Option A 'Is the task done correctly' captures this - it's about process correctness. Validation asks 'Are we building the right product?' which is about whether requirements themselves match user needs. Option A correctly identifies verification as process correctness.

Validation asks 'Are we building the right product?' - it verifies that the software being built actually addresses the real user needs and intended purpose. Option B 'Is the correct task done' captures this - it's about requirements validity, not implementation correctness. Verification (Option A) is about building correctly according to specs. Option B correctly identifies validation as checking whether the right product is being built.

The defining characteristic of automated testing is that tests execute without human intervention during the run - you write the test once, and it runs repeatedly unattended. Option A correctly states this key feature. Option B is wrong because manual intervention contradicts automation. Option C is too broad - not all testing is automated. Option D is incorrect because automation's purpose is to eliminate the need for testers to manually run each test. Option A is correct.