1.5 Test Process, Testware, and Traceability

The Test Activities

The CTFL v4.0 syllabus describes testing as a set of related test activities and tasks, not a rigid waterfall. There is no universal process, but a common set of activities applies in most contexts. They often overlap, occur concurrently, and repeat in iterative work.

Test planning defines objectives, scope, risks, entry and exit criteria, and deliverables, and is revised as monitoring shows the need. Test monitoring gathers information to check progress against the plan; test control takes corrective actions (such as re-prioritizing when a high-risk defect appears) to meet the objectives. The exam treats monitoring and control as a single ongoing activity that spans the others.

Analysis Versus Design Versus Implementation

These three are frequently confused, and the syllabus tests the boundaries:

• Test analysis answers what to test. The tester studies the test basis (requirements, user stories, architecture, risk analysis, regulations) and identifies test conditions — testable aspects such as a function, transaction, or quality characteristic. Analysis also evaluates the test basis for defects (ambiguity, gaps).
• Test design answers how to test. Test conditions are elaborated into test cases, sets of test cases, and coverage items, with inputs and expected results derived from test techniques.
• Test implementation answers do we have everything to run. It creates or acquires the testware: test procedures (often sequencing test cases), automated scripts, test suites, test data, and a ready test environment.

A reliable mnemonic: analysis = conditions, design = cases, implementation = procedures and data, execution = results.

Testware

Testware is the collective name for the work products produced during the test activities. It includes test plans, test schedules, risk registers, entry and exit criteria, test conditions, test cases, test procedures, test data, expected results, automated scripts, test environment descriptions, defect reports, logs, metrics, and test summary reports. Testware is itself subject to configuration management. Crucially, an undocumented opinion that was never recorded is not testware — testware must be a tangible, managed work product.

The outputs of one activity become inputs to others: design produces test cases that implementation turns into procedures, which execution runs to produce results and defect reports.

Traceability

Traceability is the ability to link related work products throughout the test process. Good traceability connects the test basis through test conditions to test cases, test results, and defects. A requirement may trace forward to test conditions, cases, results, and defects, and a defect may trace back to a user story and forward to confirmation tests.

Traceability delivers concrete benefits the exam expects you to recognize:

• Coverage assessment — which requirements or risks have or have not been tested.
• Impact analysis — when a requirement changes, which tests must be re-run.
• Auditability — evidence for regulators that required items were tested.
• Reporting — relating test results to requirements and risks for stakeholders.

Exam Tactics

CTFL questions mix process terms deliberately. If the stem says identifying what to test from a requirement, think analysis. Deriving test cases and expected outcomes is design. Organizing tests into suites or preparing data and environment is implementation. Running tests and logging outcomes is execution. Archiving testware and writing the summary report is completion. Because the activities can appear out of order in real iterative projects, match each by its purpose and output, not its position in a list.

Test Conditions, Test Cases, and Coverage Items

Three closely related outputs deserve precise definitions, because the exam tests how they nest. A test condition is a testable aspect of a component or system identified during analysis — for example, the discount calculation for premium customers. A test case is a set of preconditions, inputs, actions, expected results, and postconditions, developed during design to exercise one or more test conditions.

A coverage item is an attribute derived from one or more test conditions using a test technique — for example, a specific boundary value or a particular code branch — and coverage is measured as the proportion of coverage items exercised. So analysis yields conditions, design turns conditions into cases and identifies coverage items, and execution lets you measure achieved coverage. Keeping this chain straight prevents the common mistake of calling a high-level condition a test case, or treating coverage as something achieved during analysis.

Entry Criteria, Exit Criteria, and Iterative Reality

The test process uses entry criteria (conditions that must be met before an activity can begin, such as a stable test environment and available test data) and exit criteria (conditions that must be met before an activity is considered complete, such as planned coverage achieved and no unresolved high-priority defects). 0 these are sometimes framed as definition of ready and definition of done in agile contexts.

In iterative and agile work the activities are highly interleaved: within a single sprint a tester may analyze a story, design and implement a few tests, execute them, and feed results back the same day, while planning and monitoring run continuously across sprints. The exam expects you to recognize that the seven activities are logical groupings of tasks, not sequential phases — a question may describe two activities happening at once and still be correct.

Traceability and good testware are what make this overlapping, fast-moving process auditable: without links from basis to conditions to cases to results, no one could say what was covered or what a change affects. That is why traceability, testware, and the activities are taught together as the machinery that keeps testing organized, repeatable, and reportable even when the work is iterative.