Test Activities, Testware and Test Roles
Testing isn't one activity - it's a process with distinct stages, each producing its own artifacts (testware), carried out by people in different but often overlapping roles. This topic walks through the fundamental test process end to end.
~9 min read
The fundamental test process
Test Planning
Defines the test objectives and the approach to reach them within the constraints of the project: scope, risks, resources, schedule, and entry/exit criteria. Test planning happens continuously throughout the project, not just once at the start.
A test manager decides that, given a tight two-week timeline, exploratory testing will cover the new checkout flow while automated regression covers everything already shipped.
Test Monitoring and Control
Test monitoring continuously compares actual progress against the test plan, using metrics such as defects found, tests executed, and coverage achieved. Test control uses that information to take corrective action - adjusting the schedule, reprioritizing tests, or changing exit criteria.
Halfway through the sprint, the test lead sees defect discovery is far higher than expected and reprioritizes the remaining test charters toward the riskiest, most defect-prone module.
Test Analysis
Analyzes the test basis (requirements, user stories, risk analyses) to identify testable conditions - "what" to test. This is where test techniques first come into play, and where ambiguities or gaps in the test basis are often discovered and raised as defects against the requirements themselves.
While analyzing a user story for a discount feature, a tester notices it never states what happens with a negative discount code, and raises it as a requirements defect before any test case is written.
Test Design
Turns the testable conditions identified during analysis into concrete test cases and test procedures - "how" to test each condition, including specific inputs, preconditions, and expected results.
The "negative discount code" condition becomes an explicit test case: input a discount of -10%, expect the system to reject it with a validation error.
Test Implementation
Organizes the designed test cases into test procedures or scripts, arranges them into a logical execution order (a test suite), and prepares everything needed to run them - test data, test environments, and any required tools.
A tester bundles the checkout test cases into a single automated suite, seeds the test database with sample discount codes, and confirms the staging environment is ready.
Test Execution
Runs the test suite - manually or via automation - and compares actual results against expected results. Any mismatch is logged as an incident (an anomaly that may or may not turn out to be a genuine defect).
Running the checkout suite reveals that a valid 10% discount code is being rejected; the tester logs an incident with the exact steps, expected result, and actual result.
Test Completion
Occurs at project milestones - a release, a sprint end, or even a cancelled project. Activities include finalizing test summary reports, checking all incidents are appropriately closed or deferred, archiving testware for future reuse, and capturing lessons learned to improve the next test cycle.
At the end of the release, the team archives the automated test suite for reuse next sprint and documents that the discount-code edge case should be added to the standard regression pack going forward.
Testware: what testing produces and uses
Every activity in the test process produces or consumes artifacts collectively known as testware: test plans, test cases, test procedures/scripts, test data, test environment configuration, test logs, incident reports, and test summary reports. Good testware doesn't just support the current cycle - well-organized test cases and data can be reused across sprints and releases.
Just as important is traceability: linking testware back to the test basis (the requirements or user stories it was derived from). Strong traceability makes it possible to answer questions like "which requirements have no test coverage yet?" or "which test cases become obsolete if this requirement changes?"
Test roles: tester vs. test manager
Reviews and contributes to the test basis, identifies and analyzes testable conditions, designs and implements test cases, executes tests, logs incidents, and uses test tools and automation.
Owns the overall test strategy and plan, coordinates monitoring and control, manages resourcing and schedule, and reports test status and risk to stakeholders.
These are conceptual roles, not always separate job titles - on small teams or in agile environments, one person may cover both, and the whole team often shares responsibility for quality.
Key points to remember
- The fundamental test process has seven activities: planning, monitoring & control, analysis, design, implementation, execution, and completion.
- Test analysis identifies WHAT to test from the test basis; test design decides HOW to test it as concrete test cases.
- Test monitoring measures progress against the plan; test control acts on that information to adjust course.
- Testware includes every artifact the test process produces or consumes - plans, cases, scripts, data, environments, logs, and reports.
- Traceability links testware back to the test basis (requirements/stories), making it possible to see which requirements are - and aren't - covered.
- A tester designs, implements, and executes tests and reports defects; a test manager owns the overall strategy, planning, and stakeholder reporting - though on small or agile teams these responsibilities often overlap.
Terminology
A few terms from this topic worth knowing precisely.
Defining test objectives and the approach to reach them within a project's constraints - scope, risks, resources, schedule, and entry/exit criteria.
Continuously comparing actual test progress against the plan (monitoring), and taking corrective action based on that information (control).
Examining the test basis to identify testable conditions - "what" needs to be tested - before test design decides "how."
Converting testable conditions identified during analysis into concrete test cases - specific inputs, preconditions, and expected results.
Arranging test cases into test procedures/suites and preparing the data, environment, and tools needed to run them.
Running a test suite and comparing actual results against expected results, logging any mismatch as an incident.
The activity, at project milestones, of finalizing test summary reports, archiving testware, and capturing lessons learned for future cycles.
The body of knowledge used as the source for designing tests - typically requirements, user stories, or risk analyses.
A mismatch between expected and actual results logged during test execution - it may or may not turn out to be a genuine, confirmed defect once investigated.
Every artifact produced or used during testing - test plans, test cases, scripts, test data, environments, logs, and reports.
Linking testware back to the test basis it came from, so gaps in test coverage against requirements can be identified.
The role that reviews the test basis, designs and executes tests, and logs incidents - distinct from, but often overlapping with, a test manager.
The role that owns the overall test strategy and plan, coordinates monitoring and control, and reports test status and risk to stakeholders.
Summary
The fundamental test process - planning, monitoring & control, analysis, design, implementation, execution, and completion - turns a test basis into evidence about quality. Along the way it produces traceable testware, and relies on both testers and test managers, whose responsibilities often blend on real-world teams.
| Activity / concept | One-line memory hook |
|---|---|
| Test planning | Decide the approach before you start |
| Monitoring & control | Measure progress, then course-correct |
| Test analysis | Figure out WHAT to test |
| Test design | Figure out HOW to test it |
| Test implementation | Get suites, data, and environments ready |
| Test execution | Run it, compare, log incidents |
| Test completion | Wrap up, archive, learn for next time |
| Testware & traceability | Every artifact links back to a requirement |
| Tester vs. test manager | Hands-on execution vs. strategy & reporting |
Check your understanding
10 quick questions - click an option to see if you got it right.