Ticket In. Trusted Tests Out.

How a team of AI agents turned a Jira ticket into tested code and a pull request in under five minutes with a quality gate at every handoff.

By Mohanram - Senior Artificial Intelligence Engineer | Agentic AI Testing Marketplace | A SWARM #2 Show & Tell

‍

Every testing team has skilled people. So why does a single ticket still take days to move through testing?

This is because the functional tester waits for the ticket. The automation engineer waits for the test cases. The performance engineer waits for a stable build. The security engineer waits for the code. And the test lead waits for everyone, chasing results across Jira, repositories, CI pipelines, scanners and chat.

AI assistants have made individual tasks faster. But making each person faster doesn't necessarily make the entire team faster.

At SWARM 2: Show and Tell, Galent's AI community gathering in Chennai, Mohanram, Senior Artificial Intelligence Engineer at Galent, shared his approach to tackling these challenges with the Agentic AI Testing Marketplace.

The idea? Instead of giving every tester another AI assistant, bring together a team of specialist AI agents, coordinate their work, and put a quality gate between every handoff.

Here's how it works - and what real runs reveal.

The problem isn't the work. It's the waiting.

Imagine a testing team operating like a relay race. Each person does their part, but the next person can't start until the baton arrives.

Now imagine a requirement changes halfway through. The sequence starts again.

AI can help each person write test cases or scripts faster, but it doesn't automatically fix this dependency chain. Worse, if nobody checks the AI-generated output against the original requirement, a test can turn green without validating what it was supposed to.

A broken test is visible. A false pass can be dangerously convincing.

That's the distinction the Agentic AI Testing Marketplace is designed to address: not just generating tests faster, but checking whether those tests actually prove the requirements.

So, what makes an AI agent different from a chatbot?

Think of it as three stages of evolution:

1. The chatbot: You ask it to write a test. It gives you an answer. You take it from there.

2. The individual agent: You give it a goal, such as testing a Jira ticket. It can plan steps, use tools and work towards completing the task.

3. The coordinated team: Specialist agents take responsibility for different testing activities. An orchestrator coordinates them, quality gates validate their outputs, and people retain control over the final decisions.

What happens when you press Run?

The workflow starts with a Jira ticket number. From there, the platform coordinates the testing process.

• Prescreen: Reads the ticket and determines which testing activities are needed. A copy change, for example, doesn't automatically need a load test.

• Specialist agents: Generate functional test cases, create Playwright browser automation, run k6 performance tests and conduct security checks.

• Quality gates: Validate outputs against the ticket's requirements. The Oracle Check is designed to reject tests that pass without proving their acceptance criteria.

• Self-healing: When a gate identifies a problem with the test itself, an agent can attempt a repair and rerun it. If the product is at fault, the run stops and flags the issue for human attention.

• Delivery: Results flow back to Jira, alongside the associated code changes, GitHub pull request and Jenkins CI results.

The proof is in the runs

Here are some examples from the platform's reported runs - not mock demonstrations. Each illustrates a different part of the workflow.

One ticket. A pull request. Under five minutes.

In one reported run, the platform took Jira ticket SCRUM-5 through its testing workflow in 283.8 seconds - under five minutes.

The run included:

• Seven acceptance criteria read from Jira.

• Fourteen test cases written and saved back to Jira.

• Browser automation against the application.

• A self-correction after a quality gate failed.

• A Jenkins result of 12 passed, 0 failed.

There was an important detail in the evidence, too: four of the 14 test cases were marked as not executed. The platform surfaced that gap rather than quietly presenting the run as a complete success.

That's the kind of transparency that matters in quality engineering. A trustworthy report should show what passed, what failed and what wasn't tested.

From 28.6% to 96.4% code coverage

In another run on a Go service, the Go Coverage agent measured coverage at 28.6% and identified four functions without tests.

The Go Test Generation agent then created two test files, ran the tests and verified the results. Reported coverage rose to 96.4% - an increase of 67.8 percentage points.

The lesson isn't simply that AI can write tests. It's that test generation becomes more useful when it is followed by execution and measurable verification.

Performance and security are part of the picture, too

The platform also demonstrates how testing can extend beyond the user interface.

• Performance: A reported load-test run recorded 4,273 checks passed with a 0% error rate.

• Security: The workflow brings together six scanning methods covering static analysis, dependency vulnerabilities, exposed secrets, configuration, container images and a software bill of materials.

• Deployment: A deployment agent can build and start an application from its repository so that tests target the intended build, rather than an outdated shared environment.

The security reporting follows a particularly important principle: if a check couldn't run, it is marked NOT RUN. Unknown is not the same as zero.

The most important rule: people stay in control

Automation doesn't remove the need for engineering judgement.

In this model, people still review generated test cases, approve pull requests, define performance targets, decide which security findings block a release and make the final call.

Nothing merges until a person approves it.

The objective isn't to remove testers from the process. It's to reduce the time spent coordinating repetitive work, while giving engineers better evidence to make decisions.

That's also why the quality gates matter. Each agent's output must be checked before it becomes the next agent's input. When something doesn't add up, the workflow should expose the problem not hide it behind a green status.

Building AI that earns our trust

The Agentic AI Testing Marketplace explores a bigger question facing engineering teams today: what happens when AI moves beyond helping with individual tasks and begins coordinating entire workflows?

The answer can't be speed alone. It has to include traceability, verification, honest reporting and human accountability.

That was the spirit of the demonstration at SWARM 2: Show and Tell sharing not just an idea about what AI might do, but a working approach, real execution evidence and the engineering decisions behind it.

And that's what SWARM, Powered by Galent, is all about: bringing builders together to share experiments, challenge assumptions and learn from what others are creating.

Building something interesting with AI? Bring it to SWARM.

Join the community, meet fellow builders, and put your name forward to demo at the next edition.

JOIN THE SWARM COMMUNITY →

‍