Configuration Management
"It works perfectly on my machine - you must be testing the wrong version." Configuration Management is the discipline that prevents exactly this chaos, keeping every piece of software, document, and test script uniquely identified and tracked.
~11 min read
The core ideas, explained
The Purpose of Configuration Management
The primary goal of Configuration Management is to establish and maintain the integrity of a project's work products - software, documents, data - throughout the entire lifecycle. Every item gets a unique name and version number, and changes cannot be made randomly: they must be tracked, with previous versions saved so the team can roll back if something breaks.
A developer updates the tax calculation logic for 2026. Instead of just saving over the old file, CM tools like Git save it as `TaxCalc_v2.0`, preserving `TaxCalc_v1.0` in case the new code causes a massive system failure and needs to be reverted immediately.
Configuration Management for Testware
Testware - test plans, test cases, automated scripts, and test data - is just as important as the application code, so it must also be placed under Configuration Management. If the software requirements change, the test cases must change too, and version control manages that evolution. CM ensures you're always running the correct version of a test case against the correct version of the software.
The login screen is updated to require a fingerprint (Software v2.0). If the QA team runs the old automated test script that only inputs a password (Test Script v1.0) against Software v2.0, the test will fail. CM ensures Test Script v2.0 is permanently linked to Software v2.0.
Configuration Management in Test Reporting
Configuration Management provides the crucial context for defect reports and test execution summaries - a bug report is useless if it doesn't specify the exact environment and code version where the bug occurred. When testers log a defect, they must reference the exact CM version of the software, the operating system, and the test environment.
A tester writes: "The app crashes on the checkout screen." The developer can't reproduce it. The CM fix: "The app crashes on the checkout screen. Software version: `App_v3.4.1`. Environment: `Staging_Server_B`. OS: `iOS 17.1`." Now the developer can pull that exact configuration to reproduce and fix the bug.
Baselines
A Baseline is a snapshot of the software and its documentation at a specific point in time that has been formally reviewed and agreed upon. It serves as a stable foundation for future work - a locked reference point the team can always revert to if development goes off track.
Before a major holiday freeze, the team declares `Release_Candidate_4` as the baseline. If developers write new, unstable code during the holidays, the QA team continues to test against the stable `RC_4` baseline to ensure it's ready for launch, ignoring the new, un-baselined code.
Key points to remember
- Integrity is the goal - CM ensures you never lose a file, overwrite a good test case, or test the wrong version of the code.
- Testware is software - test cases, scripts, and data must be version-controlled exactly like developer code.
- Traceability between versions - you must know which version of a test applies to which version of a requirement.
- Defect reports require CM data - always include exact version numbers of the software and environment to enable debugging.
- Tools: Git, Subversion (SVN), Bitbucket, and Jira are common tools that support Configuration Management processes.
Terminology
A few terms from this topic worth knowing precisely.
The discipline that maintains the integrity of a project's artifacts - software, documents, and testware - by uniquely identifying, version-controlling, and tracking every item throughout the lifecycle.
Every artifact produced or used during testing - test plans, test cases, scripts, test data, environments, logs, and reports.
A snapshot of the software and its documentation at a specific point in time that has been formally reviewed and agreed upon, serving as a stable foundation or rollback point.
Summary
Configuration Management is the organizational backbone of a software project. It provides unique identification and version control for all project artifacts, including both the application code and the testware. By enforcing strict versioning and creating stable baselines, CM ensures testers are always testing the right code with the right tests, and that developers have the exact version numbers they need to reproduce and fix reported defects.
| Concept | One-line memory hook |
|---|---|
| Configuration Management (CM) | The "librarian" that versions and tracks every file |
| Integrity | Ensuring artifacts are not lost, corrupted, or secretly changed |
| Testware CM | Treating test scripts and test data with the same respect as source code |
| Unambiguous Referencing | Stating the exact version number in every defect report |
| Baseline | A locked, stable snapshot of the project at a specific point in time |
Check your understanding
20 questions, easy to hard - click an option to see if you got it right.