Rethinking Testing Leadership in the Age of AI [Testμ 2026]

Embrace AI, Keep The Suitcase

She names the audience split directly. Some testers are against AI, some are for it, and many at every seniority level are still unsure how to lead with it.

Her own position is stated without hedging. She talks about embracing AI rather than leaving it out, drawing a parallel to the arrival of automation, when everyone was learning to build the right skill set.

She is candid that she is not a coder and does not enjoy coding, which is why plain-English test authoring interests her.

The counterweight she returns to throughout is to not forget your testing suitcase, meaning keep the original skill set alongside the new one rather than trading one for the other.

Her stated agenda runs through the acceleration, the hidden risks, what should stay human, rebuilding ownership, and a leadership playbook, framed as material to take back to a team.

The Acceleration Slide

She reads three figures off a slide: three times faster test creation with AI assistants, 70% less manual scripting effort, and minutes rather than days from idea to executable test.

None of them is attributed, on screen or in speech. Given the publisher of this recap is also the vendor whose product appears two slides later, they are reported here as slide claims rather than findings.

Her claim around them is that teams on AI-native platforms can turn plain-English intent into running automation in minutes with no framework required.

She qualifies the enthusiasm immediately. Testers who were never comfortable with automation are now automating through AI, which she calls excellent to watch, as long as they are also learning and can stand by what they are doing.

The leadership turn she draws is that the harder question is not how fast you can generate tests but which tests actually matter for a given release. Her instruction on risk assessment carries a hedge worth keeping: teams should do it as humans, and not just fully let AI do it.

The Vendor Slide

Her before-and-after slide covers AI-native test creation using the publisher’s own product, which is named on the slide and never run.

The before column is every test step scripted by hand, hours per test case, deep framework knowledge required, and locators that break so suites go red overnight and the spikes appear in the morning.

The after column is describing intent in plain English, agents generating the steps, self-healing when the interface shifts, and minutes per test case.

She adds an unprompted caveat that cuts against the marketing framing. The tool still has to understand the system being built, which puts the burden back on prompt quality, so teams need to be good at prompt engineering too.

She references the publisher twice more. Once fairly, noting the hand-scripting problem is not specific to that vendor. And once as a purchasing suggestion, telling leaders they could speak to the vendor about providing training. Both are reported here with the publisher relationship stated.

The Copilot Study

She introduces this as a story backed up by references, then never names, cites or displays one.

The claim is that GitHub, which she notes is owned by Microsoft, ran a controlled study finding developers using its coding assistant completed a coding task about 55% faster than developers without it.

What is missing is the study name, year, sample size, venue and any description of the single task involved. It is recorded here as her characterisation of a study rather than as a finding. The published chapter list calls it a Microsoft study, which is a shorthand she did not use.

She then extends it beyond what she described, saying engineering teams report similar gains and that AI assists with writing and updating tests. That generalisation from a coding-task study to testing work is unattributed.

Her stated lesson is that the acceleration is real and worth embracing, and that speed like this changes what a leader needs to watch for.

Visibility Drops

Her core mechanism is that as AI takes on more decisions, visibility drops, because so much happens in the background and so fast.

The personal test she applies is whether she could stand by an answer if something went wrong, and whether she can explain why a particular test ran at all.

The two audit questions she tells leaders to ask out loud are who chose this test, and why was this result marked as pass when it actually failed.

Her diagnosis is that ownership blurs exactly when risk should be easiest to see, which she says is a normal situation at many companies, without evidence for the generalisation.

Her remedy is deliberately low-tech, running risk assessments with developers, business analysts and product people rather than delegating them. She extends it to migration: before moving a legacy system into a new AI-driven one, confirm the old system is stable, because instability means the code already smells.

Knight Capital, 2012

Her cautionary tale is a public incident recounted from a slide rather than first-hand experience. New trading software was deployed containing a bug tied to old, unused code that had never been fixed, and an automated system began executing erroneous trades at speed.

The figures she gives are roughly 440 million dollars lost in 45 minutes before anyone stepped in. She cites no source for either number.

Her stated lesson is that automated systems can fail fast and without noise, so somebody must own watching what automation does in production rather than trusting that it is running.

Her practical translation is to put the right alerts around anything automated you have just migrated.

Her bridge out of the section is that AI speeds up testing and also scales risk silently, unless somebody is watching for it.

The Human-Only List

Her framing challenge is direct: not everything should be automated, and if you are automating everything, she would like to understand why.

Risk-based prioritisation stays human, and she ties it explicitly to conversation, noting that the presence of AI does not mean people stop talking to each other.

Exploratory testing stays human as curiosity- and intuition-driven bug hunting, whether solo, assisted or paired.

Accessibility and ethical judgment stay human, and she describes bringing in accessibility champions and ethics-facing colleagues to give a green tick where a model cannot make the call. The exact phrasing on that slide is garbled in the captions and is paraphrased here.

Final release sign-off is her hardest line, and she stumbles into it before correcting herself: you should not let AI sign off your release, and you should not let it do this ever. She is agnostic about the mechanism, saying old-school sign-off is fine as long as a human does it.

The Green Check Mark

She describes auto-healing agents on a slide, detecting a broken locator after an interface change, updating the test automatically, and keeping the suite green without manual fixes. No agent was run on screen.

The leadership question she puts to the audience is whether the interface changed on purpose, or whether the healing hid a real regression. That middle clause is garbled in the captions and is paraphrased.

Her process fix borrows from engineering practice. Just as developers do code reviews, she likes a quality engineer to sit in on those reviews, and then to go and check what was actually healed and why.

Her follow-through is to make everything auditable, so a leader can produce proof for what shipped.

Skills Atrophy

Her opening claim is that skills atrophy without anyone noticing, because when AI always has the answer, teams stop asking the question.

Her supporting evidence is a personal, unsourced observation over roughly six months that the general nature of people talking to each other has dropped off sharply. No cohort, team or measurement accompanies it.

The three losses she names are fading debugging instincts, dropping framework fluency, and new engineers never learning the why.

Her counter-practice is to make prompting a shared spoken artifact. Talk about the interesting prompts, and talk about the ones that failed when you expected them to pass, because someone else may need that prompt. Her phrase for it is building a wiki of your prompts.

Her two-tester example is presented as a case study but is a hypothetical with no company, timeframe or data. Two testers get the same suggested fix from the same agent. One ships it as-is, never understands the root cause and cannot answer the team’s questions. The other treats it as a starting point, applies repeated why questions, and catches an underlying data issue the agent missed.

Her conclusion is that the difference between them is not the tool but critical thinking, which she calls a skill leaders have to protect on purpose. The captions lose the negation in that sentence and reverse its meaning, so it is paraphrased here rather than quoted.

Rebuilding Ownership

Her ownership slide poses four questions: who writes the test intent, who approves AI-generated tests before merge, who owns a test the agent auto-healed, and who signs off on release risk.

Her answers are offered as options rather than a mandate. An engineer or quality engineer writes intent. A tech lead, quality engineering manager or lead developer approves before merge. The original test owner keeps a healed test. A quality engineering manager or product manager signs off release risk.

Her reciprocity argument for healed tests is neat: add a developer as reviewer, because just as you value their code and review it, they can come and check your auto-healed solution.

The rule she states as absolute is that if AI can act, a named human must be accountable for the outcome, always. The point is that a person’s name is attached, not that a responsibility matrix exists somewhere.

She then describes a root cause analysis agent that classifies a failure as flaky, a real bug or an environmental issue, flags its confidence so low-confidence or customer-facing cases are marked, and routes to human review where a lead signs off before it shapes a release decision.

There is a real tension here worth surfacing rather than smoothing. The slide she has just described shows an agent classifying failures, and the next line says AI does not triage. This is a claim about what should happen rather than a description of the slide, and her reconciliation is the confidence threshold plus the lead’s sign-off. She narrows it herself immediately: AI can offer potential solutions and guide, and should not be the thing that triages.

The Leadership Playbook

Her frame has four parts. Judgment means deciding what AI should never own alone and writing it into the definition of done. Ownership means naming a human for every automated decision. Trust means building earned trust rather than blind faith, though the slide’s exact wording is garbled and is paraphrased. Resilience means designing teams and systems that fail safely.

Her argument for treating resilience as a staffing question is that a team only stays sustainable if it is not mostly composed of people new to AI or using AI for everything.

The playbook starts with mapping decisions: which tests are safe to automate and which must stay human. Her example of what stays human is unusually concrete, covering the look, the feel, and how it feels to actually run the product.

Then instrument for visibility, logging what the AI decided and why, because it may prove useful later.

Then rotate skills deliberately to protect debugging and critical-thinking practice, and set confidence thresholds that trigger human review, checked periodically.

The last item is a quarterly review of the AI tooling, rechecking thresholds, coverage and blind spots, on the reasoning that something happening silently and unreviewed can cost a lot of money. She closes on strong leadership mattering more than ever, and on treating AI as a two-way relationship rather than a friend that does everything for you.

Q & A Session

Roughly eight minutes, about a quarter of the runtime, went to questions relayed by the host from the Q&A box. Two of the four answers are declines.

• What is the biggest leadership mistake organisations make adopting AI?

  Laveena Ramchandani: Not knowing what they are doing, driven by the fear that other teams already have AI and yours is behind, so people rush in. A tool helping another area may not be what your area needs right now, so understand it properly, build a business case, and talk to your own team about how it would actually help. She checks twice whether the answer landed.

• Which pre-AI leadership habit should people drop?

  Laveena Ramchandani: I personally have not dropped anything and would not drop anything. Keep the skill set built over years and learn prompt engineering and agents on top. Certification-style training could be parked for now in favour of making the team AI-savvy. She declines to name a habit, first mis-hearing the question and asking for it to be repeated, and the answer reframes the question as addition rather than subtraction, that training point being her only concession. The published chapter title presents this as though she named a habit to drop.

• Where is the biggest AI opportunity: customer experience, productivity, operations or decision-making?

  Laveena Ramchandani: All of them. On customer experience, AI could surface incoming problems and feedback faster than manual sifting. On productivity, I use AI assistants daily myself, but rising productivity must not cost communication, so share the prompts that work. On operations, monitoring tools are already embedding AI. On decision-making, an agent can tell you whether to proceed with a release but may not be completely right, so never fully trust AI. She declines to choose.

• How do you stop QA becoming the bottleneck when verification has not sped up as much as development?

  Laveena Ramchandani: Verification takes time precisely because teams are not blindly trusting AI output. Tell the teams pressuring you that you still need time to validate, because a fault reaching production will cost more, and be transparent that you are not blocking the release but making it a quality one. If leadership asks what percentage out of a hundred you would trust without verification, give them the real figure, and if they accept that risk the decision has moved up to them. She agrees with the premise, and her approach is honesty rather than speed.

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.