Testing & Support

Purpose

Testing & Support is one of the four pillars of ConfigCompare.

It focuses on understanding configuration Differences that affect testing, issue investigation, and operational support.

This chapter describes the pillar in practice, applying the concepts introduced in Chapters 03 to 10. The four pillars are introduced together in Chapter 02.

This chapter describes concepts and behaviour; step-by-step operating guidance sits outside this reference.

The investigation problem

Configuration issues are often discovered after users report unexpected behaviour.

Support teams must answer the question: “Why is the system not behaving as expected?”

The root cause may be:

Configuration changes made without documentation
Environment Differences that affect functionality
Changes made in production that have not been retroactively applied to test environments
Configuration Drift between environments
Production values remaining in a refreshed environment (an undesired Match)
Changes made during previous incident responses or troubleshooting

Manual investigation of these issues is time-consuming and unreliable. ConfigCompare provides deterministic evidence to accelerate investigation and root cause analysis.

Typical testing and support scenarios

The most common starting point is a failed or contested UAT. Users report behaviour that differs from expectations, and the investigation compares UAT against an approved baseline to establish whether configuration explains the gap. A close relative is the “it worked yesterday” report, where functionality that previously worked suddenly fails; comparing the current environment against an earlier Snapshot answers the question “what changed since it last worked?”.

Support triage benefits in the same way. Before an issue is routed to development, a Comparison establishes whether the reported behaviour is configuration-related at all, which prevents development time being spent on issues that a configuration correction would resolve.

Other recurring scenarios include:

Regression testing: comparing pre-change and post-change configuration confirms that recent changes do not affect unrelated functionality.
Environment validation: a sandbox or test environment is validated as properly configured before testing begins.
Root cause analysis: when a production incident occurs, Comparison establishes whether configuration changes explain the issue.
Sandbox validation: a sandbox copy is checked for configuration alignment with production before testing begins.

Configuration evidence for investigation

ConfigCompare provides:

Factual Difference identification: what configuration actually differs between environments.
Match identification: where configuration is identical when it should differ, such as production endpoints remaining after an environment refresh.
Historical comparison: how configuration has changed over time.

Because each finding is the output of Deterministic Comparison, the evidence needs no interpretation before it can be relied on. Root causes are documented as what changed and when, and conclusions rest on evidence rather than assumption. Replacing assumption with deterministic evidence shortens investigations that would otherwise take hours or days of manual checking.

Business outcomes

Common reasons for adopting Testing & Support governance include:

Faster issue resolution: investigation time falls when evidence replaces manual checking.
Reduced support costs: issues are resolved with fewer investigation hours.
Better first-time resolution: correct root causes are identified instead of incorrect fixes being applied.
Faster UAT completion: unexpected behaviour is resolved with configuration evidence rather than prolonged debate.
Reduced incident duration: production incidents are investigated against factual comparison results.
Testing efficiency: test environments are validated before test cycles begin.

Beyond individual investigations, shared evidence changes how teams work together: support and development teams review the same Comparison results rather than debating root causes from memory or assumption.

Support workflow

A configuration investigation with ConfigCompare typically proceeds as follows:

Triage: a timeline comparison against an earlier Snapshot answers “what changed since it last worked?”, establishing whether the issue is configuration-related before it is routed to development.
Comparison: the affected environment is compared against a baseline Snapshot or a reference environment to identify candidate Differences.
Root cause analysis: candidate Differences, and any undesired Matches, are assessed against the reported behaviour, with Rulesets and Responsibility routing findings to the owners best placed to judge them.
Resolution: configuration is corrected or reverted, or the issue is escalated to development with the Comparison result as evidence.
Validation: a follow-up Comparison confirms that the environment matches the intended baseline.

The Comparison result itself is the investigation record: it documents what differed, what was changed, and when, and supports escalation or change management without separate write-up.