Every release tested by AI before it ships. Agents verify each Azure DevOps bug fix in the running system, test the user interface after every release and show which user stories each change touches.
AI coding tools made typing faster, but typing was never the slow part of delivery. The queue forms where work is specified and checked, and release testing is usually the longest part of that queue.
We put agents into the delivery lifecycle where the queue is. Before each release, agents work out what changed between versions, which user stories those changes affect, and which tests need to run. Then they run them. Your team reviews the results and decides.
Release testing · Business with in-house applications
The client is anonymised at their request, and we discuss the detail under NDA.
15+
Testing FTE released
Every
Release AI-tested before go-live
Per story
Version changes mapped to user stories
The client runs its own line-of-business applications with heavy integration. Every release needed a large manual testing effort to work out what had changed and what might break.
Agents now test every release before it goes live. They produce the version differences, show which user stories each change might affect, run the regression tests and test the affected journeys through the user interface. Every bug raised in Azure DevOps is reproduced and its fix verified in the running system. Release testing is automated, and 15+ testing roles are no longer needed.
Agents work out what changed between the current and the next release, across code and configuration.
Each change is mapped to the user stories it might affect, so nobody has to guess what to retest.
Agents create or update the tests those stories need, including regression tests across integrations.
The regression suite runs before every release, and failures come back with the likely cause.
Your team reviews the results and the story impact report, and decides whether the release goes.
Our clients run their own line-of-business applications with heavy integration, not a clean demo tenant. We use Microsoft's agents where they fit, and build our own where the process crosses systems.
Unit and API tests show that the code runs. They don't show that a user can still raise an order or post an invoice. Our AI testing works the way your testers do: from the ticket, and through the screens people actually use. It runs at two points, on every bug and after every release.
A bug marked resolved in Azure DevOps is not always fixed in the system. Agents check.
Agents read the bug in Azure DevOps: the steps to reproduce, the expected behaviour, attachments and linked user stories.
Agents follow those steps in the system to confirm the bug exists, and record what they see.
Agents link the failure to the change, configuration or data behind it, and add their findings to the ticket.
Once a fix is deployed, agents repeat the original steps in the system to check the bug is really resolved.
The work item gets the steps, screenshots and result. Your team closes it, or reopens it with the evidence attached.
After each release, agents open the application and work through the affected user journeys as a person would, so a broken screen or a failed integration shows up before your users find it.
The version comparison and story impact map show which user journeys the release could affect.
Agents open the application and work through each journey as a user would: clicking, entering data and moving between screens.
What appears on screen is checked against the expected result, including data that arrives through integrations.
Every journey, passed or failed, is recorded with screenshots and a step log.
Failures are raised in Azure DevOps against the release and the user story. Your team decides whether the release goes.
F&O has its own slow parts: specs and fit-gap work, long builds, regression testing after every Microsoft service update, and impact analysis before upgrades. General AI coding tools struggle with X++ because they cannot see the AOT.
Our own FinOps Workbench reads around 180,000 AOT objects and cross-references straight from an environment's metadata. That gives agents the context they need to draft specs, write extensions against real metadata, review code continuously and run regression suites after each service update.
It replaces the repetitive part of release testing. In our client result, release testing is automated and 15+ testing roles are no longer needed. The people who remain review results and decide on releases.
Yes. Agents read the bug in Azure DevOps, reproduce it in the system, and check it again once a fix is deployed. They post the steps, screenshots and result to the work item, and your team decides whether to close it.
Real UI testing. After every release, agents open the application and work through the affected user journeys as a person would, checking what appears on screen at each step and recording screenshots as evidence.
Before each release, agents compare versions and list which user stories each change might affect. It tells your team what was tested and why, instead of relying on memory or a full manual retest.
Yes. Our client result came from a business running its own line-of-business applications with heavy integration, not a packaged product.
Yes. We use our FinOps Workbench tooling to give agents the AOT context they need, including regression testing after Microsoft service updates.
With a fixed-price look at your release process and test effort, then a pilot on one application or release train, measured against a metric we agree upfront.
Book a call and we will talk through your release process, test effort and applications.
Or call us directly: 01625 569 777
