What a QE Org Will Look Like in 2027 [Testμ 2026]

The January Hockey Stick

Todd Lemmonds dated the real effect of AI to the beginning of this year, when agentic engineering became genuinely available. Before that some teams had Copilot and some used a model to check things, and the mode was closer to seeing what it would produce.

What followed hit development and testing at once, and quality was the side that got caught out.

His description of the position is unflattering and accurate: QA went onto its back foot because nobody knew how to handle the volume of code arriving at them. Shift left had been discussed for years without solving the underlying problem, which was building and maintaining test cases as fast as development could write code.

Five months into working with TestMu AI customers, his summary of the field is that everyone is implementing AI in some form, and everyone is stuck on the same two things. Orchestrating it all together, and then trusting the output of that orchestration.

Senthil Kannan placed his own organisation earlier on the curve, in an exploration phase, watching the industry impact while adopting. His framing of the upside is that AI accelerates the automation work, which gives engineers time to think, so human critical thinking becomes the valuable part again.

Pooled and Floating Teams

Impu Chunchegowda gave the most concrete structural answer, and dated her shift to January as well. Two years ago the tooling was mainly Copilot helping with code; the real change came when the organisation was told to work out how to use agents.

The structure went from one QA per product team to a pooled and floating model, with people flexed across teams based on release risk and how loaded each team is.

Her team also built its own agents rather than waiting for tooling. One generates test cases and has been trained on the cross-functional dependencies; another handles code review.

The result she describes is a division of labour rather than a headcount cut. The tactical work is taken by AI, and the team works on the strategic and risk-based side.

The Assumptions That Broke

Asked which assumption stopped holding, Impu Chunchegowda named writing test scenarios and cases end to end. That work is close to eliminated, with the initial planning stage handled by the agent, including identifying dependencies, and bug triage in the pipeline routing automatically to the right team.

She was direct about the consequence for people. The manual and exploratory tester role is fading in her organisation, drastically reduced rather than gone, and using an agent has become effectively mandatory across the team.

Senthil Kannan named a different broken assumption, which is how quality is positioned. Ask any technology organisation and quality has been seen as a bottleneck, an overhead, a cost centre, and therefore something not to invest in.

His work with leadership is to make it value-driven instead, supporting engineering to release with confidence. Developer velocity is now fast enough that automation alone cannot keep pace, and the ground QE can hold is experience: system-level knowledge, product understanding and the nuances that come with both.

The Exploratory Tester

Todd Lemmonds took the opposite side of Impu Chunchegowda’s prediction, which is the most useful disagreement in the panel.

His case is that the best exploratory testers are subject matter experts out in the field, doing unreasonable things with the product all day and finding what nobody else does. What they lack is the underlying system knowledge to isolate what actually broke.

That isolation step is why he thinks the role survives. If you are not part of the architecture assembling and validating agents, you will be exploratory testing, because someone has to debug the failure and feed it back to the development agent.

His larger claim goes further than testing. The roles most affected are developers and DevOps, and he sees a near future of one developer and one tester producing stories together, handling pipelines and database work themselves because the agents know how.

Who Takes the Go or No-Go?

With decisions moving toward developers and agents, the moderator asked who actually makes the release call. Todd Lemmonds answered with a system he helped build earlier in his career at a meteorology company.

It was a launch commit dashboard for SpaceX. Every weather condition had a rule, breaking a rule lit a red light, and a red light meant no launch, with the delay running to a day, a week or a month depending on the rule.

Ported to software, that means a launch dashboard where broken quality gates show as red, and the only way to launch on red is for someone accountable for the business to choose to.

Impu Chunchegowda described a stricter arrangement in practice. They use a dashboard, and QA remains the final checker: QA approves, it goes to the business, and the business decides to deploy.

Underneath that they built integration tests on the same framework developers already use for unit tests, so both run inside the pipeline and return pass or fail in the development environment rather than at pre-production. From pre-production into production, QA is still the gate.

QE as a Governance Layer

Senthil Kannan answered the same question by changing the subject to culture, which he treats as the real variable.

Historically the quality team owned quality and was accountable for it, which produced exactly the behaviour you would predict: everyone else passes the ball and lets QA decide.

What they are building instead is combined responsibility, where the wider organisation is responsible for quality while the expertise stays in the quality engineering team, and that team becomes a governance layer across the existing gates.

His reason for the governance framing is specific to agents. Because nobody knows when an agent will make a mistake, they operate with a lens of cautiousness and use QE to supply it, whether the signal is an agentic notification or a failure in an automation run.

The New Metrics

Impu Chunchegowda gave the sharpest numbers of the session, and the shift is away from counting activity.

• Change failure rate - how many bugs are introduced into production after each deployment. Across roughly six months they had only one or two.
• Defect removal efficiency - bugs found in UAT against those found in production, which moved from around 30 percent to between 75 and 80 percent.
• Severity-one issues - tracked alongside the other two as the set reported to executives.

Her point about why these matter is political rather than technical. Change failure rate gave visibility into why QA exists and how it contributes, in a way that test execution counts never did.

Senthil Kannan tracks a different pair. The first is false positives in their indicators, because pipelines, agentic responses, automation engineers and manual testers currently overlap into redundancy, and exploratory testing is being used to revalidate results as an evaluation layer over both the agentic and automated output.

The second is predictable turnaround time. Developer velocity fluctuates sharply between sprints, and being predictable about how long QE takes on a story is what stops quality being seen as the bottleneck.

Metrics for the Agents

Measuring the agents is a separate problem from measuring the team, and both panellists with agents in production had answers.

Impu Chunchegowda’s approach is comparative. When an agent finds something it opens a ticket, so the organisation can separate what the agent found from what manual testing found and show the business the difference.

Her reason for insisting on that split is the prevailing mood. Every company she encounters currently believes the model can do everything, and only the comparison makes the real contribution legible to an executive team.

Todd Lemmonds, who works on testing non-deterministic systems, said the metrics change completely because the thing under test does.

• Consistency - a deterministic test expects 100 percent consistency across runs, and an agent does not give you that.
• Hallucination - his line being that you sometimes wonder whether testers are working, and you never have to wonder whether they are hallucinating.
• Accuracy - measured against what a human does on the same work.
• Speed - how fast the agent gets there.

He characterised the current moment as an adversarial phase, a contest over who does the job better, with symbiosis as the eventual goal. The destination metrics stay traditional, meaning mean time to recovery and defect slippage, arrived at by running one project with agents and another with humans and comparing what reaches production.

The 2027 Org Chart

Asked directly whether teams are expanding, contracting or holding, the two operators gave different answers, which is the honest result.

Senthil Kannan expects to expand, with the caveat that the only real question is whether the right people are in the right seats for that journey. His upskilling list is system design, DevOps and the release process end to end.

His reasoning is that engineering will always depend on people for how quality and value reach the customer, and that is not a decision a machine takes. It requires understanding trade-offs, because quality is subjective and planting your foot on a gate is not partnership.

Impu Chunchegowda is holding her team the same size and upskilling instead. Everyone has been through agent training, and the company allocates four to five weeks a year to cross-training, with two test leads building skills and teaching the rest.

Her observation about who learns fastest is worth noting for anyone hiring. People straight out of university pick up the agent tooling with almost no training, so the cross-training effort goes into the business instead.

Skills That Last

Impu Chunchegowda’s advice to the junior engineers on her team separates the two things people conflate. They may be the best in the room at using AI, and that is not the same as being valuable.

Todd Lemmonds gave the most quotable test for career durability, and it is a practical one rather than a list of technologies.

Take a task you have been given at work. Do it, then immediately train an agent to do that same task. If you can do both, he argues you have the skills for the next five years.

Pair that with learning the business better than the people around you, which he called the first thing to do rather than the last, and his estimate stretches to ten.

Q & A Session

The moderator pulled two audience questions from the Q&A box mid-panel, and closed apologising for the ones there was no time to reach.

• If an AI is right 95 percent of the time, is that good enough, given you then have to check the evidence for the other 5 percent?

  Senthil Kannan: Trust is the cornerstone, so the number matters less than what the deviation does. Between 90 and 95 percent accuracy the difference may not be large; the question worth asking is whether the deviation breaks your test, and any deviation should be compared against the trust model you have chosen to work to. His preference is unambiguous: an agent that says it is not skilled enough to answer, or cannot execute the request, and hands back to a human, beats one that is confidently wrong. Development can take chances in a way quality engineering cannot. The moderator framed the underlying problem the same way, noting agents rarely say they think or assume something, they simply state an answer and leave you to work out whether it is right.

• How much evidence is enough, and where is it not needed?

  Impu Chunchegowda: Evidence is required for everything you test, and she traced the habit to starting her career taking screenshots so that a developer claiming QA had not tested something could be answered. With agents the need is greater than ever, because you start a run, sleep, and come back in the morning: without a record of what happened there is nothing to diagnose. That matters most for sporadic, non-reproducible failures, where a human tester could simply explain what they saw. Her minimum is what was tested, at what time, and a capture taken at the moment of failure attached to the ticket.

  Todd Lemmonds: He agreed and added the part teams skip. Nobody expects an agent to be right every time, so the real question is what your process is for improving it. There has to be a recursive element in these pipelines, tracking where agents go wrong so they get better, and in the architectures he builds a summary of what happened is always written somewhere a future agent can read it and understand the last failure. Without that, the agents never improve.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.