Day 19 of Learning Testing: Configuration & Defect Management

Welcome back to Day 19 of my software testing journey! We are officially wrapping up Chapter 5 (Managing the Test Activities) today.

Over the last few articles, we learned how to plan our tests, calculate our estimates, and monitor our progress. But as testing progresses, you are going to generate a massive amount of documentation, and hopefully, you are going to find a lot of bugs!

How do we keep all our test files organized so nothing gets lost? And when we find a bug, how do we report it so the developers actually know how to fix it?

Today, we are tackling exactly that: Configuration Management and Defect Management. Let’s dive in!

1. Configuration Management

Imagine you wrote a brilliant suite of test cases for “Version 1.0” of your app. Two weeks later, the developers release “Version 2.0,” so you update all your test cases. Suddenly, the client says they want to roll back to Version 1.0. If you didn’t save your old test cases, you are in big trouble!

Configuration Management (CM) is the discipline of identifying, controlling, and tracking all of your work products.

In CM, every test plan, test strategy, test condition, test case, test script, and test report is treated as a Configuration Item. Even complex things, like your entire Test Environment, are configuration items (and the CM system records every sub-item it consists of, their relationships, and their versions).

The Baseline

When a configuration item is officially approved for testing, it becomes a Baseline. Once it is baselined, it is locked in. It can only be changed through a strict, formal change control process.

Every time a changed item is approved, CM creates a new baseline and keeps a record of the old one. This is crucial because it allows you to revert to a previous baseline to easily reproduce past test results!

Why CM is mandatory for QA:

• It ensures every test item is uniquely identified, version-controlled, and tracked for changes.
• It maintains strict traceability throughout the entire test process.
• It ensures all documents and software items are referenced unambiguously (No more guessing if you are testing “App_Final_v2” or “App_Final_Actual_V3”).

(Note: In modern Agile environments, Continuous Integration and Continuous Delivery (CI/CD) pipelines usually have automated Configuration Management baked right into the DevOps process!)

2. Defect Management (The Art of the Bug Report)

The ultimate goal of testing is to find defects. Because of this, having a rock-solid Defect Management process is essential.

First, a quick clarification: when a tester finds something weird, it is initially just called an anomaly. During the defect management process, that anomaly might be classified as a real defect, a false positive, or even just a user change request!

Whether you are doing dynamic execution or static analysis, every team needs a strict workflow for handling these anomalies from discovery to closure. A typical workflow looks like this:

1. Log the reported anomaly.
2. Analyze and classify it.
3. Decide on a suitable response (e.g., “Fix it” or “Keep it as is”).
4. Close the defect report.

(Crucial rule: This process MUST be followed by all stakeholders, no exceptions!)

Anatomy of a Great Defect Report

When you log a defect, you aren’t just complaining that the app is broken. A good defect report achieves three specific objectives:

1. It provides the developers with enough information to actually resolve the issue.
2. It provides a way for managers to track the overall quality of the product.
3. It provides ideas for improving the development and testing process in the future.

To achieve this, a dynamic testing defect report should always include the following details:

• Unique Identifier: So everyone can easily reference it.
• Title: A short, clear summary of the anomaly.
• Author Details: Date observed, issuing organization, the author, and their role.
• The “Where”: Identification of the specific test object and test environment.
• The Context: What test case was being run? What SDLC phase is this? What test data or checklist was used?
• The Description: Step-by-step instructions to enable the developer to reproduce the anomaly, along with relevant test logs, database dumps, screenshots, or screen recordings.
• Expected vs. Actual Results: What should have happened vs. what actually happened.
• Severity vs. Priority: Severity is the degree of impact the bug has on the stakeholders/requirements. Priority is how urgently it needs to be fixed.
• Status: Where is it in the workflow? (e.g., Open, Deferred, Duplicate, Waiting to be fixed, Awaiting confirmation testing, Re-opened, Closed, or Rejected).
• References: Links back to the original test case or requirement.

Fun Fact: If you use a tool like Jira or Bugzilla, fields like the Identifier, Date, Author, and Initial Status are usually generated automatically! Also, if you ever look at the official ISO/IEC/IEEE 29119–3 standard, you will notice they refer to these as “Incident Reports.”

That wraps up Day 19 and Chapter 5! We now know how to plan our tests, track our progress, organize our files, and log our bugs. In the next article, we will move into the final chapter of the ISTQB syllabus: Test Tools!

See you then!