AI makes claims.I test them.

For engineering leaders who need release decisions backed by evidence, not by what the agent said. Playwright and AI agent testing, with the code and the traces published.

Book a 30-minute discovery call See the evidence Fixed quotes once scope is agreed. Remote, or on site in the UK and Europe.
EVIDENCE LAB 01, 17 OCT 2026
suite A, from the spec15/15 caught
suite B, from the code7/15 caught
expect(agent).toHaveActuallyDone(it) ✓
  • Stanford Code in Place section leader, taught CS106A Python
  • Microsoft MVP, 2025 and 2026
  • LinkedIn Learning instructor, 90,000+ learners across multiple courses
  • Former BBC Principal Test Engineer
  • 20+ years in software engineering
The problem

A green tick is not evidence.

An AI agent says it did the job. The suite passes. The release board asks one question: how do we know? If the answer is "the agent said so", you do not have a test. You have a claim.

  • What a pass hidesIn Investigation 01 both suites passed on the working app. One of them then let eight of fifteen real bugs through.
  • What it costsIncidents after release, a board that stops trusting the suite, and engineers rebuilding tests they were told were finished.
  • What changes itIndependent checks, each tied to a retained trace, and a verdict written so the people who sign the release can read it.
Evidence Lab

One claim, actually tested.

Each investigation takes a claim people make about AI in testing, runs a reproducible experiment, and publishes the code, the logs and the verdict. Nothing appears before it has been run.

  • The claim"AI can write your Playwright tests for you."
  • The testTwo suites generated by the same AI for the same small app: one from the specification alone, one with the implementation in view. Fifteen bugs injected one at a time. Which suite notices?
  • The evidencePrompts, both suites, the app, the mutants, the runner and the full results, all downloadable and rerunnable.

What this means for your team: ask what the AI was given before you trust what it wrote. Tests generated from the code are snapshots of the code. Tests generated from the specification can tell you the code is wrong.

All investigations
INVESTIGATION 01, 17 OCTOBER 2026

AI-written tests catch bugs. The ones written from the code mostly do not.

Suite A: written from the specification15 of 15 bugs caught
Suite B: written with the code in view7 of 15 bugs caught

Both suites passed on the working app. Same model, same app, same afternoon. The suite that had seen the code let eight real bugs through, including a counter that counted the wrong thing and a delete button that deleted the wrong task.

Read the investigation
Consulting

Three ways to get evidence before you ship.

  1. 1. A 30-minute callYou describe the system and the decision in front of you. I say whether I can help and what it would take.
  2. 2. Fixed scope, fixed quoteAgreed in writing before any work starts. No day rate that drifts.
  3. 3. A verdict you can act onFindings tied to retained traces, written for the people who sign the release, not only the people who wrote the tests.
Two weeks, fixed price Start here

AI Agent Sign-off Assessment

Twelve checks, every finding tied to a retained trace, a verdict your release board can read without me in the room. See a sample report.

Best for: a team about to put an AI agent in front of users, and a release board that wants an independent yes or no.
Ask about an assessment
Two weeks, part-time

AI Quality & Engineering Productivity Diagnostic

Where is delivery friction coming from, and is your AI adoption helping or hiding it? Up to eight interviews, a scored maturity view and a prioritised 90-day plan.

Best for: engineering leaders who suspect AI adoption is hiding delivery friction rather than removing it.
Enquire about the Diagnostic
Pilot sprint, five working days

Playwright Modernisation Sprint

Migration strategy, reference implementation in your repository, CI configured for parallel runs, and a measured before-and-after on a slice of your suite.

Best for: teams on an older framework, or a slow and flaky Playwright suite, who want measured proof before committing to a migration.
Enquire about the Sprint

Client work is confidential. The method is not. No logos, no anonymised stories. Every claim on this site is backed by a published experiment you can rerun, or a fact you can check on the press page.

Full details and FAQs: Playwright and AI quality consulting and training, including the one-day AI Agent Testing Workshop. Fixed quotes once scope is agreed on a 30-minute call. Remote, or on site in the UK and Europe. Quotes exclude VAT.

A good fit

Teams shipping AI agents or Playwright suites who want an independent read, a published method, and are ready to show the code and the traces.

Not a fit

Anyone who needs the answer to be yes. The verdict is the verdict. Sponsored content is labelled and never touches a finding.

Qambar Raza on stage at SEETEST 2026, arms wide, in front of a slide about inspecting a website with Playwright
Speaking

Talks that show the test, not the slide.

  • Testing AI Agents with Playwright and MCP: A Practitioner's GuideSEETEST 2026, Ljubljana, 6 to 7 October 2026
  • The Human Side of AI TestingBCS SIGiST, London, 7 July 2026
  • Playwright At ScaleHow To Test This podcast, episode 40, 56 minutes with host Mamadou N'diaye, September 2026. Watch

SEETEST 2026, Ljubljana. Photo: Marko Risovic.

Listed and mentioned by

  • University of MiamiToppel Career Center course listing
  • Playwright SolutionsRecommended course, December 2024
  • LinkedIn LearningPublished course repositories
  • MicrosoftMVP, Developer Technologies, 2025 and 2026

Every fact, with where to check it: press and mentions.

Free download

The AI Agent Testing Checklist

27 checks before you trust an agent in production: boundaries, tool-use verification, the check step, failure modes, evaluation, and the Playwright evidence to keep for each. Three pages. The same checklist used in the workshop.

Not sure where you stand? Take the 2-minute scorecard first.

Qambar Raza, wearing blue glasses and a blue checked shirt
Qambar Raza, Manchester
About

The engineer behind the channel.

Engineering Productivity & AI Quality Leader at CGI, Microsoft MVP and LinkedIn Learning instructor. Formerly Principal Test Engineer at the BBC, with 20+ years in software engineering spanning development, test automation, quality engineering and engineering leadership. Section leader on Stanford's Code in Place Python programme.

Why publish the method, the code and the traces? Because the only way to tell a tested claim from a confident one is to look at the evidence. If my own work cannot stand that test, it should not be trusted either.

Based in Manchester, UK. Views are my own. Not affiliated with Microsoft's Playwright team. Facts, mentions and appearances, with where to check each: press and mentions.

My work sits where software engineering, quality and AI meet. I focus on a simple question: what evidence do we have that the system behaves as expected, especially when automation or AI gives us a confident answer?