This is a situation a lot of enterprise IT teams have to face more than they would like to admit. A change request is received. It’s a routine project, it’s a small scope, it falls into the low-risk category, and nothing’s really peculiar on paper. It gets approved. Three days later, there’s an incident. A post mortem is then pulled up, revealing that the release in the back of this “routine” change actually went with a significant increase in regression test failures that no one outside of the QA team was aware of.
Not a single thing was done wrong, per se. The data for the tests was available. It simply operated in a different system from the approving system.
This is the gap that many businesses are attempting to bridge: What the QE teams know about a release and what ServiceNow – or whatever system is managing change and incident workflows – sees. These have long been treated as distinct concerns, managed by distinct teams and teams’ tools. That is changing, but it’s about time.
There are two systems that should be communicating and don’t. There are two systems that need to be in communication but aren’t.
ServiceNow has become the backbone of change management and incident response for a huge number of enterprises. It’s the place of approvals, the place of categorizing risk, the place of monitoring what changed, when something went wrong. Meanwhile, Quality Engineering resides in a different place altogether – the test passes, defects, regression history, flaky test patterns, all in engineering dashboards that operations teams never access, if they ever do.
It’s not anyone’s fault that the disconnect exists. These are tools created for different users and different uses. The people approving a change, however, have no idea about the health of the underlying code, and the people who do have an idea are 3 systems removed from the approval process.
So changes are scored on something like “how big is this” or “which team owns it” instead of “what does the actual quality data say about this release. The start of an investigation is typically a “clean” slate; when something fails, the investigation begins with a clean slate.
What is happening when you hook up the two?
The organizations that are further down this aren’t taking apart all of their tools and beginning from scratch, they’re just wiring everything together. Teams begin to repeat a few patterns once they start doing it seriously.
The most popular starting point is to change risk scoring that is truly based on something real. The risk score uses real-time QE information associated with that particular release: test coverage, number of open defects, performance of regression suite. It’s no longer a standard release when it has thin test coverage; it is flagged up before anyone would sign it off.
Then there’s incident correlation, which is just might be the more useful little long-term. If an issue does arise, teams can follow it back to the release and review the quality signals at the time of the release. Did it use to drop before this shipped? Did there ever have to be tests that are flaky, and waved off as “probably nothing”? This makes post mortem more of a pattern matching exercise than a guessing game, since it is already available.
Some teams are working harder and implementing automated escalation, if a service begins to exhibit a downward trend in quality metrics for a couple of sprints, then the system notifies them or automatically prevents the next change from being added to that service, instead of waiting for someone to raise their hand during a standup.
This is all very common. It is a connective tissue, it is not a new invention. However, this connective tissue is missing for quite some time.
In what ways is this picking up steam right now?
This is being driven by a couple of factors to an even greater degree than two or three years ago.
The first one is obvious—the release velocity. Teams that are shipping a few times per week just don’t have the budget for a human to sit down and assess risk on every single change. If it’s done at this rate, automated, data-driven scoring becomes the only practical choice.
Downtime is even less tolerable than ever before. “we didn’t catch it in QA” is no longer as effective when more of the business is running on always on systems. Now, after outages, leadership asks more difficult questions and the answer “the data existed, it just wasn’t connected to the decision” isn’t something that anyone wants to hear twice.
Then the amount of change due to AI-fueled development. As more and more code is written and shipped, more and more changes have to be assessed for risks, and that was a problem before it picked up speed. There’s got to be something to take that volume and tying quality data to operational processes is one of the more practical solutions available today, not the hottest, but it works with what teams already do.
What This Tends to Look Like in Practice
Nobody sensible tries to roll this out across the entire organization on day one. The teams that get it right usually start with one critical application, connect its test coverage and defect data into the change risk model, see what breaks, fix it, and only then expand to incident correlation and, eventually, automated escalation.
It also tends to go smoother when quality processes were built with this kind of visibility in mind from the start, rather than trying to retrofit two systems that were never designed to talk to each other. Enterprises working with established quality engineering services often have an easier time here, simply because the groundwork, structured test data, consistent metrics, clean integration points, already exists instead of needing to be built from scratch mid-project.
The teams that get the most value out of this shift tend to stop treating QE as a checkpoint you pass through before a release goes out, and start treating it as something closer to a live operational signal, the same category of thing as latency or uptime, not a report that gets filed and forgotten.
The Real Shift Here
What’s actually happening underneath all of this is a change in what “quality” even means inside a large organization. It used to be a gate, something a release had to clear before it shipped, checked off and moved past. Increasingly, it’s becoming something operations teams watch continuously, the same way they’d watch any other health metric for a system that matters.
The enterprises leaning into this aren’t just cutting down on outages, though that’s the easy metric to point to. They’re closing a gap that’s existed for a long time between the people who could see a release was risky and the people who had to deal with it once it broke, usually the exact same information, just stuck in two systems that never had a reason to talk to each other before now.
That’s a fixable problem. It just took a while for anyone to bother fixing it.
About the Author: Aniket writes about enterprise technology trends and works closely with delivery teams at Kellton.
