5.5 Configuration Management and Traceability
Key Takeaways
- Configuration management identifies, controls, versions, and tracks testware, test items, environments, and related work products.
- 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 still must preserve version identity and relationships.
What Configuration Management Does
Configuration management, often called 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.
Configuration Items and Baselines
A configuration item is any work product placed under configuration management. It may be simple, such as a single test case, or complex, such as a full test environment. Complex items include relationships among 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 go 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 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. It also ensures that documentation and software items are referenced unambiguously in testware. 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 test 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 that 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 to reduce 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.
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 toward CM, while coverage relationship language often points toward 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, payment product risk, executed test case, defect report, and retest result.
Together, CM and traceability make test evidence trustworthy. CM says exactly what was used. Traceability says how it relates to objectives, risks, requirements, defects, and decisions.
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?
Which relationships are examples of useful test traceability?
Select all that apply