Software Testing and Quality Control

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.

This question asks which is NOT an objective of testing. All the listed options (A: determining if system meets specifications, B: determining if system meets needs, C: providing insight into SDP) are actually valid objectives of testing. Therefore, D (None of the above) is correct because all A, B, and C ARE testing objectives, so none of them is 'not an objective'.

A test case is the documented step-by-step procedure for executing a test, including the actions to perform and the expected results for verification. A test script is the automation code. A test condition is what needs to be tested. A testing tool is software used to execute tests. Therefore, 'Test case' is the correct answer for a step-by-step procedure.

The statement 'Testing will exercise 90% of the code' is neither a vision, a standard, nor a policy. It's a specific quantitative target or goal for a particular project. A vision is a broad aspirational statement. A standard is an established norm or requirement. A policy is a governing rule. This statement is a specific measurable target, so 'None of the above' (D) is correct.

The correct answer is C. Review.

A review is an activity that includes confirming understanding, brainstorming, and testing ideas. It is a formal process of evaluating a product, service, or process to ensure that it meets the requirements of the stakeholders. Reviews can be conducted at any stage of the development process, from the initial concept to the final product.

Brainstorming is a technique used to generate creative ideas. It involves bringing together a group of people to share their ideas in a free and open environment. Brainstorming is often used in reviews to generate new ideas for improving a product or service.

Testing is the process of evaluating a product or service to ensure that it meets the requirements of the users. Testing can be conducted manually or automatically. In reviews, testing is often used to verify that the product or service meets the requirements of the stakeholders.

Code walkthrough is a technique used to review code. It involves walking through the code line by line with a group of people to ensure that the code is clear, concise, and easy to understand. Code walkthroughs are often used in reviews to ensure that the code is of high quality.

Inspection is a technique used to review documents. It involves reviewing the documents line by line with a group of people to ensure that the documents are accurate, complete, and up-to-date. Inspections are often used in reviews to ensure that the documents are of high quality.

Therefore, the only option that includes confirming understanding, brainstorming, and testing ideas is C. Review.

The Expected Result section defines what the test should produce when it executes correctly, which serves as the acceptance criterion for determining if the test case passes or fails. Post-conditions define system state after execution, Actual Result is what occurs during execution, and Result is just a general term.

Test cases and test plans typically start in the Draft state when first created. Other statuses like Under Review, Ready for review, or Approved represent subsequent stages in the lifecycle.

CQ (ClearQuest for defect tracking) integrates with RQM (Rational Quality Manager) allowing bidirectional launching. Users can initiate CQ directly from the Defects section, or from the test execution screen when adding a new defect triggered by test failure. This integration streamlines the defect lifecycle from test execution to defect creation.

A work item tracking system allows team members to assign, monitor, and update tasks, requirements, bugs, and other activities, facilitating status tracking. Assigning a test case or defect alone is too narrow to describe a work item's general purpose.

Test cases are not required to be linked to test plans. While linking provides traceability and organization, test cases can exist independently in repositories, be reused across multiple test plans, or be created ad-hoc for exploratory testing. The linkage is a best practice for structured testing, not a mandatory requirement.

Test management tools provide multiple access paths to test cases for flexibility and traceability. From Test Plans (organized by scope), Requirements (for requirement-test coverage), and Construction (test development/build phase). This multidimensional access supports different workflows: planning, verification, and execution.

Test cases can have multiple valid statuses throughout the testing lifecycle. 'Passed' indicates successful execution, 'Failed' indicates defect discovery, 'Blocked' means execution cannot proceed due to dependencies, and 'Deferred' means postponement to a future iteration. All are legitimate states.