Software Testing and Quality Control

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.

Automation is primarily adopted to reduce testing time (automated tests run much faster than manual testing) and reduce cost (less manual effort required over time, especially for regression testing). Option C 'All of the above' correctly captures both these primary benefits. Option A and B individually are both valid reasons to automate. Option D is not a reason to automate - having a budget is an enabler, not a motivation. Option C is correct.

Stress testing pushes a system beyond its specified limits to find breaking points. Since the requirement states 'up to 10 MB' but we're testing with 100 MB (10x the documented limit), this is stress testing - we're intentionally exceeding normal capacity to observe failure behavior. Load testing tests expected load (within specifications). Functional testing verifies features work as specified. Regression testing checks that changes don't break existing functionality. Option B is correct.

Negative testing involves testing beyond the specified valid boundaries to verify the system properly handles invalid input. Testing with 6 characters when the requirement states maximum 5 characters is testing the failure condition - the system should reject this input. Load testing and stress testing are performance testing types, while regression testing checks for unintended changes after modifications.

The two primary methods of software testing execution are manual testing (where test cases are run manually by a human) and automation testing (where scripts and tools execute the tests). Other options list specific testing types rather than general execution methods.

One of the fundamental principles of software testing is to identify and resolve defects as early as possible in the software development life cycle (SDLC) to reduce the cost and effort of fixing them later.

Testing serves multiple purposes: it finds bugs in the software, provides confidence and information about system quality to stakeholders, and helps prevent defects by identifying issues early. 'All of the above' correctly captures that testing is not just about finding bugs but is a comprehensive quality assurance activity.