5.5 Configuration Management and Traceability
Key Takeaways
- Configuration management identifies, controls, versions, and tracks testware, test items, environments, and related work products as configuration items.
- A baseline is an approved version of one or more configuration items that can be changed only through controlled change management.
- Configuration management supports reproducibility because previous baselines can be restored or inspected.
- Traceability connects test basis, test conditions, test cases, test results, defects, risks, and requirements.
- In CI/CD pipelines, configuration management is often automated but must still preserve version identity and relationships.
What Configuration Management Does
Configuration management (CM) is the discipline of identifying, controlling, and tracking work products as configuration items. In testing these items may include test plans, test strategies, test conditions, test cases, test scripts, test data, test environments, test logs, test results, defect reports, and the test object itself.
CM matters because test results only mean something when the tested version is known. "Login failed in system testing" is weak evidence if no one knows the build, browser, database version, feature-flag state, environment, test data, or test-case version. CM turns an anecdote into reproducible evidence.
The v4.0 syllabus states that CM ensures test items and testware are uniquely identified, version controlled, tracked for changes, related to each other, and referenced unambiguously throughout the test process.
Configuration Items and Baselines
A configuration item is any work product placed under CM. It may be simple, such as a single test case, or complex, such as a full test environment that bundles components, versions, data sets, services, infrastructure, and tools.
A baseline is an approved configuration used as a reference point. After a baseline is approved for testing, changes should pass through a formal or agreed change-control process. This prevents uncontrolled changes from invalidating results, hiding defects, or making failures impossible to reproduce.
| CM concept | Testing example |
|---|---|
| Unique identification | Test case TC-LOGIN-007 version 3 |
| Version control | Build 2.4.1 tested with API contract version 12 |
| Change tracking | Requirement update linked to modified tests |
| Baseline | Approved release candidate plus environment and data set |
| Reversion | Restore a previous baseline to reproduce a failure |
How CM Supports Testing
CM ensures that test items and testware are uniquely identified, version controlled, tracked for changes, and related to other configuration items, and that documentation and software items are referenced unambiguously. This supports repeatability, auditability, and confidence in test evidence.
Consider a regression failure found after a database migration. Without CM, the team may not know whether the failure came from code, schema, test data, environment configuration, or an outdated script. With CM, the result is tied to exact versions, making investigation faster and more reliable.
CM also helps when testing is interrupted or repeated. If a previous release baseline can be restored, testers can reproduce an old defect, compare behavior across versions, verify a fix, or prove a change introduced a regression. This is especially important for maintenance releases and regulated systems.
Traceability
Traceability is the ability to connect related work products. A requirement may trace to acceptance criteria, product risks, test conditions, test cases, test scripts, executed results, defects, and completion evidence. Traceability supports coverage analysis, impact analysis, reporting, and change control.
Traceability answers practical questions:
- Which requirements have no tests?
- Which high product risks are still uncovered?
- Which test cases must change if this user story changes?
- Which defects were found by tests covering a specific requirement?
- Which tests prove that a release criterion was satisfied?
The exam trap is reducing traceability to a spreadsheet of requirements and tests. A trace link is useful only if it helps decisions. If a high-risk requirement changes, traceability should reveal affected tests, data, automation, defects, and reports. If a defect is severe, traceability should reveal the test basis, test-object version, and coverage area. Distinguish CM (about versions and identity) from traceability (about relationships and coverage).
CI/CD and Automated CM
In continuous integration, continuous delivery, and continuous deployment, CM is often automated by repositories, build systems, artifact stores, environment definitions, container registries, feature-flag systems, and test-management tools. Automation improves speed, but the principle is unchanged: identify versions and relationships clearly.
A strong pipeline records the source revision, build artifact, dependency versions, environment configuration, deployed services, test-suite version, test data, and test results. A weak pipeline says "main failed last night" without enough evidence to recreate the event. For CTFL, remember that version-number language usually points to CM, while coverage-relationship language usually points to traceability.
Practical Example
A test case fails on mobile checkout. Good CM records the app build, operating system, device model, browser or native-app version, payment-service stub version, feature flags, test account, test data, and script version. Good traceability connects the failure to the checkout requirement, the payment product risk, the executed test case, the defect report, and the retest result.
Together, CM and traceability make test evidence trustworthy: CM says exactly what was used, and traceability says how it relates to objectives, risks, requirements, defects, and decisions.
CM and Traceability Across the Test Process
0 test process. During test planning, the test basis and test object are identified as configuration items so the plan references stable versions. During test analysis and design, test conditions and test cases are linked back to the requirements, risks, and acceptance criteria that justify them. During test implementation, scripts, data, and environments are version controlled and bundled into a baseline. During test execution, results are recorded against the exact tested build, and any defect is tied to that build and to the originating test case.
During test completion, the consolidated testware and traceability records are archived so a future maintenance or audit activity can reconstruct what was tested and why.
This end-to-end view explains why the syllabus treats CM and traceability as supporting disciplines rather than one-off documents. A change-impact analysis, for example, depends on both: traceability identifies which tests relate to a changed requirement, while CM identifies which versions of those tests, data sets, and environments must be updated and re-baselined. Neither discipline alone answers the question "what must we re-test, against which version, to safely ship this change?" Strong teams therefore keep both current as the product evolves.
Exam Traps
- CM is about identifying and versioning configuration items; traceability is about linking related work products. Match the language in the stem.
- A baseline is approved and changes only via change control; ad-hoc edits break reproducibility.
- Automation in CI/CD does not replace CM principles; version identity and relationships still must be preserved.
A team can reproduce an old failure because it knows the exact tested build, environment, data set, and test-script versions. Which practice most directly enabled this?
An auditor asks which requirements currently have no test cases and which product risks remain uncovered. Which practice answers these questions?
Which relationships are examples of useful test traceability?
Select all that apply