Software Testing and Quality Control

Test plans are created and accessed through the 'Planning' section of testing tools like RQM. This section provides dedicated features for designing, organizing, and managing test plans. Construction and Requirements are different sections, and Builds refers to compiled code versions.

Test plans progress through a lifecycle with multiple states. 'Draft' is the initial state during creation, 'Ready for review' indicates completion pending approval, 'Approved' means authorized for execution, and 'Retired' indicates the plan is archived. All are valid states.

The Keyword view in test scripts is designed to organize commonly-used test steps into reusable components. This promotes modularity, reduces duplication, and allows teams to create libraries of standardized test actions that can be shared across multiple test scripts.

The test schedule section specifically details timelines, planned start and end dates, and testing milestones. The test plan section covers scope and strategy, requirements covers what to test, and summary provides a high-level overview.

Work items (for defect tracking, task management, or follow-ups) can be created at any level of the testing hierarchy. This provides flexibility - you can track issues at the test case level, test suite level (affects multiple tests), or individual test script level.

The Precondition section specifies the required state, setup, or conditions that must exist BEFORE a test case can be executed. This ensures the test starts from a valid, known state. Postconditions describe the state after execution, while Test case design covers the test logic itself.

When a PEST (defect/enhancement) is retested and passes verification, it moves to Completed status indicating the issue is resolved and verified closed. Activated would mean it's open/in progress, Opened is the initial state, and Accepted is an intermediate approval state but not the final closed state after successful retest.

The Related records tab in an ALM task allows linking related PEST (likely Problem/Enhancement/Software Task) items with a retest task. This maintains traceability between the original issue and its verification task. Options A, C, and D are incorrect - the tab is for linking PEST items, not test cases or projects, and 'None' is false since B is correct.

ClearQuest (CQ) can be launched through multiple methods: directly via standalone URL, from RQM's Defects icon, and from the test execution screen's 'Add new Defect' option. Therefore 'All of the above' is correct.

Use case diagrams are most directly useful to testers as they define test scenarios and user flows. Activity diagrams help with test flow but are less directly used. Deployment and class diagrams are less relevant for functional testing.

Test design coverage and test execution coverage evaluate the completeness of test activities against planned targets. They require complete datasets of all planned test cases and executions, which only stabilize at the end of their respective phases, making them phase-end metrics rather than continuous in-progress metrics like invalid defects.

Option 2 states that test cases are normalized when different complexities exist to arrive at a common figure, which is correct. Option 1 about industry standards is also stated as true in this context. Since both options are presented as true, option C (both) is correct. Normalization converts different complexity levels to equivalent simple test case counts.

Test design coverage measures how many testable requirements are covered by the test cases created. The correct formula is (requirements covered by test cases) / (total testable requirements). Option D captures this precisely. Option A incorrectly uses test cases in the numerator, while options B and C have incorrect formulas.

Defect removal efficiency (or TCS test effectiveness) is calculated as the ratio of defects found during internal phases (Component, Integration, and System testing) to the total defects found (including Acceptance testing and Customer-reported bugs). Here, TCS found 165 defects out of a total of 200 (165 + 5 + 30), yielding 82.50%.

Test failures are typically qualified by error thresholds and resource utilization metrics. Option A (>40% errors) indicates a high error rate that would fail a test. Option B (CPU >90%) represents excessive resource consumption that could indicate performance issues. Therefore, Option D, which combines both conditions, correctly identifies valid test failure criteria. Option C (CPU<90%) would not qualify as a failure.