Software Test Process: Six Activities and Deliverables

What the process is and where it comes from

The fundamental test process is the activity model described in the ISTQB syllabus and, in a closely related form, in ISO/IEC/IEEE 29119-2. It names the things that have to happen for testing to be complete and what each one produces, so that a test lead can see progress in deliverables rather than in hours spent. The URL this page recovers was, as far as the archive shows, a PDF associated with Rex Black's Managing the Testing Process; this page is an independent explanation of the process, not that book, though the book remains one of the best treatments of it.

The activities are logical, not chronological. Analysis for one feature can run while execution for another is under way; completion for a sprint overlaps with planning for the next. What does not change is that each activity has inputs it cannot start without and deliverables that show it is done.

The six activities

Inputs, activities, deliverables and exit criteria per activity. If you cannot name the deliverable that shows an activity is done, that activity is not being managed.
Activity	Inputs	Main activities	Deliverables	Exit criteria
Planning	Test strategy, requirements baseline, release plan, risk register	Define scope and objectives, score product risks, choose levels and techniques, estimate, schedule, define entry and exit criteria	Test plan, estimate, schedule	Plan reviewed and baselined; criteria measurable
Analysis	Test basis: requirements, user stories, designs, risk scores	Review the test basis, identify test conditions per feature, prioritize by risk, raise defects against the basis	Test conditions with traceability to the basis, basis defect reports	Every in-scope requirement has at least one condition; basis defects logged
Design	Test conditions, risk classes, technique rules from the strategy	Apply techniques (partitioning, boundaries, state models, decision tables) to derive test cases, define test data requirements, identify environment needs	Test cases (high level then detailed), test data specification, environment requirements	Cases cover all conditions; coverage per risk class meets the plan
Implementation	Test cases, data specification, environment requirements, automation stance	Write procedures and scripts, create or mask test data, build and verify the environment, order cases into suites and schedules	Test procedures, automated scripts, test data, verified environment, execution schedule	Smoke test passes in the environment; suites ready and prioritized
Execution	Test procedures and suites, the build under test, the execution schedule	Run tests, log results, compare actual to expected, report and triage defects, retest fixes, run regression	Test log, defect reports, updated test status	Exit criteria from the plan met or an exception approved
Completion	Test log, defect status, plan criteria, team experience	Check exit criteria, hand over testware, archive environments and data, write the summary report, hold a lessons-learned session	Test summary report, archived testware, lessons learned, updated strategy or process	Report accepted by stakeholders; testware and lessons recorded

Monitoring and control

Monitoring collects data on progress: conditions identified against planned, cases designed and executed against planned, pass rate, defects open by severity, coverage per risk class. Control is what you do about the gap: re-prioritize, add effort, change scope, or re-plan. Monitoring and control is not a seventh activity in sequence; it runs across all six from the day the plan is baselined until the summary report is signed. The metrics that feed it should be the same numbers used in the exit criteria of the plan, so that progress and completion are measured in one currency.

The most common control decision is scope reduction under schedule pressure. The risk classes decided in planning are what make that decision safe: drop low-risk cases first, and record what was dropped in the summary report.

In a two-week sprint

The whole process runs in every sprint, mostly without documents. Planning happens in sprint planning: the stories in scope, their risk scores from refinement, and the definition of done as the exit criteria. Analysis and design happen as stories are refined: acceptance criteria become test conditions and examples become test cases, often written with the developer before coding. Implementation is the automation of those examples and the preparation of any data the story needs. Execution is continuous as stories complete, with exploratory sessions on the high-risk ones. Completion is the sprint review and retrospective, with the regression suite as the archived testware. The deliverables exist; they live in the backlog tool and the repository rather than in documents. What sprints often lose is the completion step: if the retrospective never discusses escaped defects and test debt, the process has five activities, not six.

In a regulated project

In a medical device, automotive, aerospace or financial project the same six activities run with formal gates. Planning produces a signed test plan that references the applicable standard. Analysis produces a traceability matrix from requirements to conditions that an auditor can follow. Design produces reviewed test cases with a recorded technique per case. Implementation produces qualified environments and, where scripts are used, evidence that the scripts themselves were verified. Execution produces logs with tester identity, build identifier and timestamp for every result, and defect reports with impact analysis. Completion produces a summary report that states, requirement by requirement, what was tested and with what result, plus a signed statement of residual risk. The activities are identical; the difference is that every deliverable is a controlled document and every exit criterion is a gate with a signature.

The one question per activity

Planning: do we know what done means? Analysis: do we know what to test? Design: do we know how? Implementation: can we run it? Execution: what did we find? Completion: what did we learn? A test lead who can answer all six for every feature is in control.

Where the process breaks

Planning without measurable exit criteria, so execution ends when time runs out rather than when the plan is met.
Analysis skipped, so test cases are written from the user interface instead of from the requirements and missing behavior is never tested.
Implementation started before the environment is verified, so the first week of execution is spent debugging the environment.
Execution without a triage rhythm, so the defect backlog grows and retests pile up at the end.
Completion skipped, so testware is lost, lessons are not recorded, and the next release starts from the same guesses. The estimate in particular never improves without the actuals that completion records.

Common questions

What are the stages of the software test process?

Planning, analysis, design, implementation, execution and completion, with monitoring and control running across all of them. Older syllabi grouped analysis and design together and named five stages; the content is the same.

What is the difference between test analysis and test design?

Analysis decides what to test: it reads the test basis and identifies test conditions. Design decides how: it applies techniques to the conditions to derive test cases and data. Analysis finds gaps in requirements; design finds the inputs that will expose defects.

What deliverables does the test process produce?

A test plan, test conditions with traceability, test cases, test data and procedures, automated scripts, a verified environment, a test log, defect reports, a test summary report and a lessons-learned record.

Does the test process apply to agile teams?

Yes. Every activity happens in a sprint, mostly in the backlog tool and repository rather than in documents. The definition of done is the exit criteria; refinement is analysis and design; the retrospective is completion.

What is monitoring and control in testing?

Monitoring is collecting progress data against the plan; control is the corrective action when the data shows a gap: re-prioritizing, adding effort, changing scope or re-planning. It runs across the whole process.

Who owns the test process?

The test lead or test manager owns the process for a project; the head of testing owns the standard process for the organization. In agile teams the whole team owns it, with a tester usually accountable for the deliverables.

Software test process: six activities, inputs and deliverables