Testing Metrics and Project Management

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.

ALM request types include Defect, Environment, Issue, and Deployment - all are valid request categories. Therefore 'All of the above' is the correct answer.

Phase found In and Iteration found In are project metadata fields located in the Project tab. This tab contains project assignment and lifecycle information. Related records, Attachments, and RCI workflow tabs serve different purposes.

Requirement traceability matrix (RTM) is a document that links requirements to test cases and is typically created during requirements management or verification phase, not during the core requirement analysis activity. Issuing documents, doubt clarification, and scope clarification are all integral parts of the requirement analysis process where requirements are gathered, analyzed, and defined.

Test effort is measured in person-months, which represents the work done by testers in a month. With 5 testers working for 1 month, the test effort for the first month is 5 person-months. This is simply the number of testers allocated since effort is calculated per month of work.

Test design completion percentage is calculated as (actual test cases created / estimated test cases) × 100. Here, 490 test cases were created out of 500 estimated, giving (490/500) × 100 = 98%. Option B (102%) would imply exceeding the estimate, while option A (100%) would mean exactly meeting the estimate.

Test design completion percentage is calculated as (actual test cases created / estimated test cases) × 100. Here, 490 test cases were created out of 500 estimated, giving (490/500) × 100 = 98%. Option B (102%) would imply exceeding the estimate, while option A (100%) would mean exactly meeting the estimate.

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%.

Requirement test coverage is calculated based on the proportion of requirements tested out of the total estimated requirements. Here, 39 tested out of 46 total gives 39 / 46, which is approximately 84.78 percent, rounding to 85 percent.

ROI can be collected when benefits equal or exceed costs. Option 1 (Cost ≤ Benefit) includes both equality and benefit exceeding cost. Option 2 (Cost = Benefit) is the break-even point. Since Option 1 already includes the break-even condition, the question frames this as both conditions being relevant for ROI collection.

Invalid defects are those that should not count against quality metrics. Duplicate defects, environment defects (not product defects), and defects arising from requirement changes all fall outside valid product defects. Since all three categories (A, B, C) represent invalid defects, option D is correct.

TPS = total transactions / total seconds. 1 hour 30 minutes = 90 minutes = 5,400 seconds. TPS = 15,000 / 5,400 = 2.777... ≈ 2.78. Option C (2.77) is the closest match. Option A is too low, B is slightly off, and D is too high.

Target: 60,000 transactions in 30 minutes. One user completes 70 transactions/hour = 35 transactions/30 minutes. Users needed = 60,000 / 35 = 1,714.285... ≈ 1,714 users. Option A matches this calculation. Options B, C, D are either too low or too high.

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.

A metric is a quantitative measure used to assess performance. The most comprehensive answer includes all three temporal aspects: past performance (historical analysis), present performance (current monitoring), and future performance (predictive analytics). Option A captures this complete scope, making it the correct choice. Options B and C are incomplete as they omit one of the temporal dimensions.