If you do not know exactly what version of the software you are testing, your test results are meaningless
A tester runs 200 test cases and reports 15 defects. A developer fixes 10 of them and deploys a new build. The tester re-tests — but is the new build the same as the previous one except for those 10 fixes? Or did something else change? Without configuration management, nobody knows.
Configuration management (CM) provides the discipline to track exactly what was tested, what version was deployed, what test data was used, and what the environment looked like — so that test results can be trusted and reproduced.
// example: github — configuration management in practice
Configuration Management — CTFL 4.0.1
Configuration management ensures that the software and testware are identified, controlled, and tracked throughout the development and testing lifecycle.
Key CM concepts
- Configuration item (CI) — any work product placed under CM control. Examples: source code, test cases, test data, test scripts, environment configurations, documents.
- Baseline — a formally approved version of a configuration item at a specific point in time. Baselines serve as reference points for testing (e.g., "tested against baseline v2.3").
- Version control — tracking changes to configuration items over time, enabling rollback and comparison.
- Change management — the process of controlling modifications to baselined items, including impact assessment and approval.
CM and testing
For testing to be reliable, CM must cover not just source code, but all testware:
- Test plans and test cases
- Test data and test scripts
- Test environment configurations
- Defect reports and their links to the relevant software version
// tip: Exam Tip: CTFL emphasises that configuration management applies to testware as well as source code. Test cases, test data, and test environment configurations must all be version-controlled. If a test environment configuration changes between test runs, the results from the two runs cannot be reliably compared. CM ensures testware integrity alongside software integrity.
Configuration Management in a Test Context
| CM Activity | What It Covers in Testing | Why It Matters |
|---|---|---|
| Version control | Test cases, test scripts, test data files | Ensures the same test is run against each build; enables comparison across builds |
| Baseline creation | Software build + test suite + environment config at a release point | Provides a fixed reference point — "all tests passed against baseline v3.1" |
| Change management | Updates to test cases when requirements change | Ensures test cases stay aligned with current requirements |
| Traceability | Defect reports linked to specific build and test case | Enables accurate re-testing — the exact conditions of the original failure can be reproduced |
| Environment CM | OS versions, browser versions, configuration files, middleware | Ensures test environment is consistent and reproducible across test runs |
Source Code as Configuration Item
// Examples
// Version Control
Git commits with meaningful messages
// Baseline
Release tags: v2.3.0, v2.4.0-rc1
// CM Lifecycle
Step 1: Identify CI
Define what work products go under CM control
// Exam tip
CM applies to TESTWARE too — not just source code. Test cases, test data, and environment configs must be version-controlled. If environment changes between test runs, results are not comparable.
Configuration Management vs Change Management
| Aspect | Configuration Management | Change Management |
|---|---|---|
| Focus | Identifying, tracking, and controlling all work products | Controlling and approving modifications to baselined items |
| Scope | All configuration items throughout the lifecycle | Changes to baselined configuration items only |
| Activities | Versioning, baselining, auditing, status accounting | Change request, impact assessment, approval, implementation, verification |
| Tools | Git, SVN, configuration management databases | Change advisory boards, JIRA change request workflows |
| Relationship | CM provides the framework | Change management operates within that framework |
// warning: Exam Trap: "Configuration management only applies to source code." This is false. CTFL explicitly states that configuration management applies to ALL work products including testware — test plans, test cases, test data, test scripts, and environment configurations. A test suite without version control is just as much a CM gap as unversioned source code.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation