QA work after support with an AI agentInvestigation, description and documentation via MCP and skills
We optimise one step of the chain: QA after support. An agent reproduces a Jira bug on a test stand via MCP, narrows the path, describes and documents it, a skill makes the steps a repeatable process, QA checks by hand. Support and development do not change.
A customer bug passes support and reaches QA. This is where investigation, description and documentation are done by hand, so this is the step we optimise. An agent connected to Jira and a test stand via MCP, plus a skill with the steps written down, take the routine over. QA checks the result by hand. Support and development work as before.
In this exampleOnly the QA step changes: all QA time used to go into doing the tasks; now agents do them, and QA accepts the results and manages the agents.
In generalMany agents can run at once, and QA time per task drops.
agent · PAY-142agent · PAY-143agent · PAY-144QA time shifts to managing and accepting
Each of the three parts runs per bug in its own agent, and QA launches several at once.
Takeaway
In this exampleInvestigation, description and documentation go one after another and pass through the agent. QA keeps the final check and the contested parts.
In generalAll three parts are repeatable actions with a clear result, so they can be written down and handed over. The decision “is this a bug and how important” stays with a human.
What to doSplit your work on a bug into these three parts and mark which one takes the most time.
MCP: the agent works where QA works
MCP (Model Context Protocol) is a way to connect an agent to work systems so it reads and writes in them itself instead of getting a retelling.
In this exampleVia MCP the agent reads PAY-142 in Jira, goes to the test stand and writes the result back. QA copies nothing between windows.
In generalWithout connections to the systems the agent has to be given a retelling, and a retelling loses details. The test stand is the place where the agent can try and break things without touching production.
What to doStart with two connections: Jira and the test stand. Add the rest as needed.
A skill: a written process instead of repeating by hand
A skill is a way of working written down for the agent: steps, a report template, rules. Another person and another agent can repeat it.
agent · PAY-142agent · PAY-143agent · PAY-144QA time shifts to managing and accepting
One skill, many runs: an agent per bug. The written process does not require QA to repeat it personally.
same steps every timeone report templatepassed to colleaguesimproved from mistakes
Takeaway
In this exampleThe six steps are written down once. Any QA runs the skill on a new ticket and gets a report in the same format.
In generalA skill turns “how I usually do it” into a process that does not depend on who is on shift today. An agent mistake goes into the skill as a new rule, and next time it is gone.
What to doWrite your steps for one type of bug as a skill and run it on three closed tickets.
One QA — several agents: time shifts to managing and accepting
Bugs can be reproduced through different channels, and each agent takes its own.
A sketch of the principle; the scale is arbitrary, not a measurement.
Takeaway
In this exampleQA launches agents on PAY-142, PAY-143 and PAY-144 at once. While they work, QA does not sit over one bug but checks the finished results one by one.
In generalBefore, QA’s time added up across all bugs in a row. Now each bug has its own agent: browser-based, code-based or via API, and QA keeps only a short check. The more agents are running, the more QA time goes into managing them and reviewing, not routine.
What to doGrow the number of agents gradually: it is bounded by the number of stands, test data sets and limits. Put the time QA no longer spends on routine into managing agents, checking and improving the skill.
Example: PAY-142 from ticket to report
Jira ticket · a customer request passed from support to QA
PAY-142 · Card payment fails when a promo code is entered
from customerpassed by supportno stepserror screenshot
Investigation: 6 actions → 3 left
logincatalogaddresscartpromo codecard payment
Narrowing down: the agent removes actions one by one and after each checks whether the bug still reproduces. Whatever the bug survives without is crossed out.
On request · sequence diagram
Description and Jira record · comment on PAY-142
Stepscart → promo code → card payment
Expectedthe payment goes through with the discount
Actual“payment failed”, the promo service returns error 500
Where to lookthe call to the promo service from payments (see the diagram)
One QA — several agents at once
agent · PAY-142agent · PAY-143agent · PAY-144QA time shifts to managing and accepting
While the agent handles PAY-142, other agents take PAY-143 and PAY-144, and QA checks what is already done.
The ticket and all names are invented for the example.
Takeaway
In this exampleFrom one line from the customer came a short path of three actions, a diagram and a ready report in Jira. QA did not do this; QA reviews the result.
In generalEach of the three parts of QA work left a visible trace: a narrowed path, a diagram, a record. This way the result can be checked in minutes instead of reconstructed from memory.
What to doAsk the agent to show the narrowed path and the record: they show right away whether it went the wrong way.
What stays with QA
Right pathwalks the steps by hand on the stand
Right errormatches the customer screenshot
Right narrowingthe crossed-out steps really are extra
How importanta human decides severity and priority
agent · PAY-142agent · PAY-143agent · PAY-144QA time shifts to managing and accepting
The time QA no longer spends on routine for every bug goes to managing agents, checking, priorities and improving the skill.
Takeaway
In this exampleQA opens the stand, repeats the steps from the report by hand and confirms it is the bug the customer described. Then the ticket goes to the developer as before; if it fails, the report goes back to the agent.
In generalA model readily confirms itself, and invented details look like findings. So the last word stays with a human who looks with their own eyes. QA work shifts from performing the routine to checking and improving the process.
What to doAgree that a report QA could not repeat by hand does not go to the developer.