Managing the Test Activities

Purpose and Content of a Test Plan

A test plan documents the approach, resources, schedule and risks for a test effort. Typical contents: context, stakeholders, communication, risk register, test approach, budget, schedule, entry/exit criteria, deliverables.

Tester's Contribution to Iteration / Release Planning

• Identifying and prioritizing risks
• Clarifying user stories and acceptance criteria (Three Amigos)
• Estimating testing effort
• Identifying needed test environments and data

Entry and Exit Criteria

Entry criteria define the preconditions for starting a test activity (e.g. testware ready, environment available). Exit criteria define when a test activity can be considered complete (e.g. coverage achieved, risks mitigated, no high-severity defects open).

Test Estimation Techniques

• Ratio / metrics-based — using past project data.
• Extrapolation — basing estimates on similar past activities.
• Wideband Delphi / Planning Poker — expert estimation by consensus.
• Three-point estimation — optimistic, most likely, pessimistic.

Test Case Prioritization

• Risk-based — priority by risk level.
• Coverage-based — by maximizing coverage.
• Requirements-based — by importance of requirements.

Test Pyramid & Testing Quadrants

Test pyramid (Mike Cohn): many fast unit tests at the base, fewer integration tests, very few slow UI/E2E tests at the top. Testing quadrants (Brian Marick / Lisa Crispin) classify tests by business-vs-technology facing and supporting-team-vs-critiquing-product.

Risk = combination of likelihood × impact. Product risks relate to the test object (failures, missing features, poor quality). Project risks relate to the project's management and control (delays, supplier issues, staff turnover).

Risk-Based Testing

Uses risk analysis to focus testing on the most important areas — affects test selection, prioritization, depth and timing.

Risk Activities

• Risk identification
• Risk assessment / analysis (likelihood × impact)
• Risk mitigation (response: mitigate, contingency, accept, transfer)
• Risk monitoring

Test monitoring gathers information to compare actual progress against the plan. Test control takes corrective action. Common metrics: test case status, defect metrics, coverage, schedule, cost.

Test Reports

• Test progress reports — periodic, status of the test effort.
• Test summary reports — issued at end of a test phase / project.

Configuration management establishes and maintains integrity of work products. For testing it ensures:

• All test items are uniquely identified and version controlled.
• Testware references the correct version of the test object.
• Changes are traceable.

Defects found during testing should be investigated, classified and reported. Typical defect report contents:

• Unique identifier, title, status, severity, priority
• Date, author, version of test object
• Description, steps to reproduce, expected vs actual results
• Logs, screenshots, environment details
• References to test case / requirement
• Recommendations and conclusions