ISTQB AI Testing certification, with Chapter 9 mapped to a runner you can open and read

ISTQB CT-AI, short for Certified Tester AI Testing, is an advanced specialist certification from the International Software Testing Qualifications Board. It sits on top of the Foundation Level certification and covers two things most other testing certifications do not combine in one syllabus: quality characteristics of AI-based systems, and how AI can be applied to the testing work itself. The exam is a forty-question multiple-choice paper and the syllabus is public. Where it differs from CTFL and CTAL is scope: CTFL is about testing in general and CTAL drills into test management or technical testing, while CT-AI is the only core ISTQB credential that squarely addresses machine-learning systems and AI-assisted tooling as test subjects and test tools.

The syllabus splits along a clean line. The first half is Testing AI-Based Systems: quality characteristics like flexibility, autonomy, adaptability, evolution, bias, ethics; the ML workflow; training and test data; ML performance metrics; ML-specific test techniques like pairwise, metamorphic testing, and back-to-back. That is seven or eight chapters of the nine. The second half is Using AI for Testing. It describes AI-based test case generation, AI-driven element identification, self-healing tests, defect analysis, UI regression visual comparison, and natural-language test specifications. The first half is almost always what accredited courses focus on because it is the harder exam content. The second half is shorter, more practical, and is the part that maps one-for-one onto what an open-source runner like Assrt already does today.

Eighteen tools. They are declared as a single TOOLS array in assrt-mcp/src/core/agent.ts, starting at line 16 and ending at line 196. The list: navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, wait_for_stable. Each is a JSON schema the Claude model sees, plus a thin adapter in src/core/browser.ts that forwards it to a Playwright MCP call. The whole surface area a learner has to read to understand an AI testing agent is about 180 lines of TypeScript in one file. That is the implementation artefact the CT-AI syllabus describes at the conceptual level in its Using AI for Testing chapter.

Not by CSS selectors. When the model wants to click a button, it first calls the snapshot tool. That returns an accessibility tree from Playwright MCP, with each interactive element tagged with a stable ref id (e.g. ref=e12). The model then calls click({ element: "Sign in button", ref: "e12" }). The browser.ts adapter resolves e12 to the underlying Playwright locator and issues the real click. There is no reliance on #login-button, .btn-primary, or any other DOM selector that breaks when a designer changes a class. The element identification is semantic, which is exactly what the Using AI for Testing section of the CT-AI syllabus calls out as the difference between AI-driven and traditional automation.

A file called scenario.md that reads like a QA engineer wrote notes to another human. Example: "#Case 1: Signup happy path. Go to /signup, use a disposable email, enter password Secret123!, click Sign up, wait for the inbox, paste the OTP, verify dashboard loads with the user's email in the top right." That is the whole specification. The agent decides which tools to call in what order. The #Case delimiter lets you stack scenarios in one file; each case runs in sequence in the same browser session. You are not writing code, you are writing intent. The runner's job is to translate intent into the eighteen tool calls.

It emerges from the design rather than being a named feature. Traditional automation breaks when a locator changes because the locator is a literal string in your test code. Here the locator is produced fresh by snapshot every time the agent needs to act. If a developer renames a button, the accessibility tree still surfaces a button with the same role and accessible name; the new ref id flows through and the click lands. No locator to update, no selector to fix. The thing that self-heals is the gap between intent and element, and it heals on every tool turn rather than at some scheduled maintenance window. That is closer to what the syllabus means by self-healing than a proprietary rewrite engine bolted onto brittle CSS selectors.

A supplement, and a specific one. You still need to study the first half of the syllabus to pass the exam: ML quality characteristics, data partitioning, pairwise testing, back-to-back testing, confusion matrix, F1 score. None of that lives in a browser automation runner. But when you reach Using AI for Testing, instead of reading the chapter once and hoping it sticks, open /Users/matthewdi/assrt-mcp/src/core/agent.ts alongside it. The abstract bullet points map to concrete functions. The chapter goes from something to memorise to something you can point at. Candidates who have worked with a real runner retain the material better than candidates who only read slides.

Zero dollars on top of whatever Claude credentials you already have. The runner is MIT licensed in the assrt-mcp repo. Model calls bill against your Claude Code subscription or your regular Anthropic API key, whichever is set. That is usually a few cents per full end-to-end scenario. Commercial AI-testing platforms that the accredited courses often demo sit in a different price bracket entirely; the top-tier enterprise plans land in the $7.5K/month range with annual commits. Both exist for real reasons. For a candidate studying CT-AI who wants to run the syllabus concepts on their own laptop tonight, the open-source path is dramatically cheaper and materially easier to audit.

Because you can read it. An accredited course often demos a commercial platform where the reader clicks through a dashboard, watches a test generated, and gets told the AI does the hard part. What the AI actually did, which tools it called, how it resolved elements, how many characters of page context it passed to which model, all of that is behind a service boundary you cannot cross. In Assrt, the TOOLS array is 180 lines. The agent loop is another 200. The Playwright adapter is one more file. There is no black box; the Using AI for Testing concepts are visible as function calls with schemas and return values. That level of transparency is rare in the commercial AI QA space and it happens to line up with what the syllabus wants learners to understand.

Four files, about an hour of reading. First, /Users/matthewdi/assrt-mcp/src/core/agent.ts lines 16 to 196 — the TOOLS array, the ground truth for what an AI testing agent can do. Second, the SYSTEM_PROMPT string in the same file at line 198 — the shape of instructions the model actually sees, including the snapshot-first selector strategy and the OTP paste workaround. Third, /Users/matthewdi/assrt-mcp/src/core/browser.ts — how each agent tool becomes a Playwright MCP call; this is where element identification becomes concrete. Fourth, /Users/matthewdi/assrt-mcp/src/core/keychain.ts, all 66 lines — the auth model that makes the whole thing zero-setup on a Mac where Claude Code is signed in. Read those four and the Using AI for Testing chapter will feel like the reference manual for the code you just read.