TestCrunch 2026: Testers Aren't Obsolete. But Buckle Up.

Golden Age for Testers — or the Last Conference with Humans in the Room?

Florian Fieber, President of the German Testing Board and someone who's been knee-deep in AI and testing for nearly two decades, opened his talk with a quick audience poll. Hands up if you use ChatGPT or similar tools regularly at work. Almost every hand in the room. Now — keep your hand up if you feel your job is becoming obsolete.

Silence.

"That was actually my last slide," he said with a grin. Then he proceeded to spend the next hour making sure no one fell asleep after the opening coffee break.

Three Pillars of AI in Testing

Florian structured the conversation around three distinct angles — because confusing them is how you end up solving the wrong problem:

AI as a test object. Non-deterministic, probabilistic systems like LLMs don't behave like traditional software. Same input, different output. That breaks the classic true/false testing model and demands new quality criteria: fairness, explainability, transparency, model drift.

AI as a testing tool. Test case generation, test data, self-healing automation scripts — real productivity gains, real value. But also a new source of non-determinism inside the testing process itself. AI outputs vary. Hallucinations happen. Validating the validator becomes part of the job.

AI-generated code as the new normal. The vibe coding era means a flood of AI-generated code heading straight for QA. And research shows this code has more defects, not fewer — fewer syntax errors, but significantly more logical, conceptual, and architectural issues. The kind that are harder to spot and more expensive to fix.

"Someone has to clean up this mess. Some people call them testers."

95% of Companies Aren't Seeing Positive ROI from GenAI

An MIT study cited in the talk found that the vast majority of companies adopting GenAI are not achieving a positive return on investment. Florian called it the "buy now, pay later" problem — what you save in coding time, you spend in debugging, validation, and fixing the issues AI introduced.

This isn't an argument against AI. It's an argument for having someone in the room who understands the risks. Enter: the tester.

The Bottleneck Is a Feature, Not a Bug

One of the more provocative moments: Florian argued that the deliberate, human pace of QA is a strategic advantage, not a weakness. If testing is a bottleneck, the problem isn't the
testers — it's overproduction upstream.

"Maybe it's good that there's some time in between that helps us think about what we're actually doing. Otherwise we'll push a button, get a new SAP system in five minutes, and nobody understands why."

A Fool with a Tool Is Still a Fool

Florian mentioned he recently switched from ChatGPT to Claude — with good results. But he was equally quick to name the trap many fall into: one-sentence prompt, generated output, copy-paste, sent to manager as a finished test plan.

"A tool with a fool is still a fool."

His conclusion was clear: AI is not replacing testers. It's raising the bar for what a tester needs to be — a critical thinker, a quality gatekeeper, someone who understands risk and can communicate it to everyone else in the room.

If Florian Fieber's talk answered WHY testers won't disappear in the age of AI, Petr Škoda's answered WHAT that actually looks like on the ground — straight from the trenches of automotive software development at Green:Code, formerly DigiLab, a subsidiary of Škoda Auto. 

No grand theory. Just a team that was drowning, decided to do something about it, and built their way out.

From Seven Months to Three Days. That's Not Magic — That's a Custom AI Assistant in Jira.

The Before: QA as a Firefighter at the End of the Line

The starting point will sound familiar to anyone who's spent time in QA. Testers permanently behind schedule, reactive by design, spending up to 70% of their time on manual test execution. No capacity for shift-left. No visibility for management. And the inevitable consequence: QA as the bottleneck everyone blames for delays.

"We wanted out of that loop." So they started experimenting.

The Journey to a Custom Solution

It started modestly — a team member, Mára, earned a GCP certificate, began prompting, and the team suddenly had a working prototype of their first AI assistant. But the automotive industry is heavily regulated, with strict rules around data handling. Off-the-shelf AI tools simply didn't fit.

So instead of giving up, they pivoted: they built their own application. Custom Jira extensions, custom plugins, their own context and secrets management. And one of their testers — Kuba — transformed into the full-stack developer of their internal tool, bringing to it exactly what a developer without QA experience never could: a deep understanding of what a tester actually needs.

The New Workflow: AI as Co-Pilot, Not Autopilot

The resulting system covers the full testing lifecycle as an assistant, not a replacement. Requirements review before development begins catches ambiguities and spec errors before a single line of code is written. Automatic generation of test scenarios from user stories. Automated test execution with the ability to select the right AI model and knowledge base for each project's specific context. Standardized bug reporting that finally looks consistent regardless of who writes it.

The key emphasis: AI receives rich context — project-specific, domain-specific, regulatory — before it generates anything. Without context, the output is mediocre. With context, it's actionable. Human validation remains at every step.

The Numbers That Are Hard to Ignore

Test automation for a mid-sized project that previously took 7 months now takes 2–3 days. Overall capacity savings for the project team: up to 13%. And perhaps more importantly — testers finally have time to do what they never had time for before: get involved early, challenge requirements, and prevent defects instead of just discovering them.

An audience member raised the question that was on everyone's mind: What happens to tester seniority when AI takes over the routine work? Petr Škoda acknowledged it as a real and ongoing concern. The key, he argued, is keeping humans in the validation seat — AI generates, humans judge, verify, and empathize with the end user.

Sometimes the best way to explain something complex is to tell a story. Petr Fifka clearly knows this — instead of slides full of diagrams and arrows, he brought Lucy and her AI agent, the Bot.

The audience gave him the highest score of the entire conference.

Lucy is an experienced tester getting into test automation. The Bot is her new AI co-pilot. Her partner. Her saviour. At least at first.

Phase One: Euphoria

Lucy gives the Bot a manual test scenario. She uses Claude Opus — the most powerful model available. The Bot thinks for a moment, then produces a complete Playwright test. It looks good. It might even work.

Lucy is thrilled. "I just paste in the manual scenario and it gives me finished code? This is amazing!"

So she starts trusting the Bot more and more. Stops reviewing the outputs. Stops checking the details. It's working, right?

Phase Two: The Crash

A few weeks — or months, depending on the team — later, the inevitable happens. Production is down. Tests are broken. Lucy spends hours trying to fix code she doesn't understand, because the Bot wrote it and she never really read it.

Petr paused on the specific example from that first generated test. Sensitive credentials hardcoded directly in the test file. Unstable selectors. Pointless comments. No component reuse. No Page Object Model.

"This isn't the Bot's fault. It's Lucy's."

Strong words — but said with empathy, not judgment. And then he explained why.

"The model is like a hyperactive junior on three Red Bulls. It's trying to deliver fast and correctly — but nobody told it what 'correct' means on this project."

AI learns from public repositories. And what dominates those? Code that works — not code that's maintainable. Without context, rules, and examples, the model has no idea what your team considers quality.

Phase Three: Onboarding the Bot

Lucy didn't give up. She went back to the start and asked a different question: what if the
problem isn't the Bot, but how I brought it onto the project?

And so she onboarded the Bot like a new team member. She wrote an instruction file — a structured document (~300 lines; the recommended maximum is 1,000) covering who the Bot is and what its role is, the basic architecture of the application, quality rules (Page Object Model mandatory, maximum function length, locator strategies, how to handle test data and sensitive credentials), and concrete code examples — not general advice, but actual demonstrations of what good looks like.

"Show, don't tell" — Petr's central principle for the entire talk. A generic instruction like "write clean code" is useless. A concrete example of clean code changes everything.

Multi-Agent Orchestration: One Bot Isn't Enough

But even perfect instructions don't solve everything. Petr demonstrated what happens when a single agent has too many rules and too many tasks: the context overloads, and the agent starts ignoring rules or inventing new ones.

The solution? Split the work across specialised agents with clear, non-overlapping responsibilities: an E2E orchestrator that manages the full test flow, an exploratory agent that navigates the application looking for unexpected behaviour, a locator reviewer that checks selector stability, and a security agent that ensures sensitive data stays where it >belongs.

Playwright MCP: An AI That Actually Sees the Browser

The highlight of the talk was a live demonstration of Playwright MCP — a tool that gives the AI agent direct control of a browser. In real time, the Bot opened a test application, navigated the login flow, took screenshots, generated a report — and caught a bug: the system was accepting invalid login credentials.

The entire E2E scenario took five minutes and twenty seconds.

From the audience: "What about security when an agent is browsing the web? Prompt injection?" Petr's response was disarmingly honest: "I'm not a security expert. I go talk to a security engineer and let the right person handle it."

The Punchline: The Tester Becomes an Architect

Petr's story of Lucy and the Bot is really a story about maturity. About the fact that AI euphoria is a natural phase — but one you have to grow out of. The tester's role isn't disappearing. It's moving — from executor to agent architect.

"Before you get into a flying car, learn how to drive."

Host Jiří Charvát set up the fourth talk in his signature style. He asked the room who has a messy sock drawer — because you spend four times longer finding what you need there.

Exactly like navigating unstructured test code, code you wrote six months ago that now looks "like it was written by a stranger, in the dark, drunk, during an economic crisis."

Then came the punchline: "AI, great stuff, hype, fantastic — but before you get into a flying car, learn how to drive first."

With that, Konstiantyn Teltov took the stage — QA lead, QA architect, founder of a QA Guild, and author of over fifty articles on Medium. He came with a topic that would have headlined any conference three years ago, but today risks being overshadowed by the AI spotlight. Design patterns. Classic. Foundational.

Gang of Four in the Testing World: A Practical Tour

Konstiantyn walked through the classic 23 GoF patterns and picked the ones that actually matter in test automation — always anchored to a concrete problem and its solution:

Singleton — one instance of a config file or database connection. Note: some engineers call it an anti-pattern; use deliberately.

Factory Method — abstracting WebDriver selection. Chrome hardcoded directly in the test? Classic trap. "It's like a coffee machine — the interface is 'make coffee.' Whether it's a latte or espresso is decided by the subclass."

Abstract Factory — for multiple database providers. The test works only with the contract, never the concrete implementation. One of Konstiantyn's personal favourites.

Builder — for complex data models with many fields. A constructor with six parameters is an anti-pattern. Builder enables Lego-style object assembly. "Your code becomes readable."

Prototype — cloning similar objects without repeating initialization.

Facade — a single entry point into a complex subsystem. "Show your card, get access to whatever you need."

Plus the test-specific classics: Page Object Model, Component Object Model, Lazy Initialization, Dependency Injection (never hardcode the driver inside a page object), and Object Pool for recycling WebDriver instances.

Overengineering: A Trap Everyone Has Fallen Into

An audience member asked the sharp question: how do you balance robust architecture with a framework that junior testers can actually contribute to?

Konstiantyn answered with disarming honesty: "When I was a mid-level engineer, I overengineered everything. Every time I learned something new, I tried to apply it everywhere. We all do it — including now with AI."

The prescription: start simple. Ask whether the problem you're solving actually recurs. A pattern is a tool, not a dogma.

Design Patterns as Rails for AI

The talk's strongest idea came at the end. An audience member asked: Will our reliance on classic design patterns increase to structure AI-generated boilerplate? Or will AI eventually create its own ways to organize test logic?

Konstiantyn was unambiguous: "I hope AI won't create anything on its own. Because AI is not intelligence in the human sense — it's a probabilistic system."

And then, with a delivery that earned the biggest laugh of his talk: "If AI starts thinking for us — I believe that will be the end of our civilization. Sorry, I grew up on Terminator."

Design patterns don't become obsolete in the AI era — they become more important. A clear project structure, explicit contracts, and well-defined interfaces are precisely what AI needs as "rails" to generate code that stays maintainable and understandable.

"Remember: you are engineers and architects of tests. Not just automation engineers."

An insider view — from the other side of the table.

Three years ago, Robin Weiss stood on this same TestCrunch stage as a QA Manager. This year he returned — in a different role. As a Product Manager at Vendavo. As someone for whom QA isn't a colleague but a partner. And as someone who noticed something unsettling.

"The testers stopped calling," said host Jiří Charvát in his introduction. "As every parent knows — you raise them, and then they stop picking up the phone."

Before diving in, Robin proposed a brief ritual. Five seconds of silence — for the QA professional who first convinced a developer that a defect is a defect, not an intende feature. "This person recently left this world. Chuck Norris."

Laughter in the room. Then four problems that slowly quieted it.

Problem #1: Loss of Context — How We Lost Klára

Robin described a world the room knew well: on one side, manual QA — analysts, contextual knowledge, the product manager's sparring partner. On the other, automation QA — efficiency, frameworks, speed.

"The world was roughly in balance. Then AI arrived."

The conversation about what to test and why quietly disappeared. In its place: discussions about frameworks, agents, implementations. Automation QA has a natural affinity for AI — and gets the opportunities, the attention, the budget. The contextual, business-oriented side of QA fades away.

Robin illustrated this with a concrete story. Klára — one of the best QA professionals he's ever worked with. Someone who came to every refinement session with a prepared list of questions, analysed the impact on the entire system, and regularly sent the product manager back to the customer with the message that the brief simply didn't make sense.

"She made me happy. I always thought I came prepared. Often I wasn't."

And today? The team went from nine QAs to four. Klára can't keep up. She arrives at refinement sessions unprepared, with no time to review the brief, no time to push back. And Robin? "I feel great. Nobody has any questions. It seems like AI has made the whole process smoother."

Except it hasn't. There's just nobody left to tell him otherwise.

Problem #2: The Junior Crisis — A Broken Chain

Few in the room admitted their company had hired a junior in the past six months. Weiss wasn't surprised.

Why would companies hire juniors? The reason used to be clear: regression testing, backlog triage, bug verification. Today a senior with AI tools does it in a fraction of the time. The junior-level work has vanished — and with it, the reason to hire juniors.

But this breaks the natural chain: junior → mid → senior → mentor. "The half-life of any engineer is somewhere between two and five years. People leave — you can't stop that. And when they go, they take their knowledge with them. Who replaces them?"

Companies saving money on juniors today will be asking where all the seniors went in a few
years.

Problem #3: Shift-Right — Back to Where We Started

Klára has no time. There are no juniors. So who tests on the left? Who stops and tells the product manager that the brief doesn't make sense?

Nobody. And so — paradoxically — in the era of the greatest test automation in history, we're drifting back to reactive testing at the end of the cycle.

"Shift-right. I think that's where we're slowly heading."

Problem #4: Loss of Control — Who's Reading the Fifteen-Page Document?

AI generates enormous volumes of content. Tests, scenarios, architectural documents, specifications. And nobody reads them.

Robin described a situation from his own practice: an architect takes his epic, runs it through AI, and produces a fifteen-page architectural proposal. "I don't read it. I can't. The headings look fine, it roughly makes sense — I approve it."

Based on that approval, it gets implemented. Based on the implementation, tests are generated. And the mistake that originated in the poorly thought-through brief propagates through the entire process — all the way to production.

"And then the whole thing gets documented using AI as well. That's your recipe for a proper disaster."

The Closing Argument: Convince the Decision-Makers

"The biggest threat isn't that AI will replace us. It's that we'll rest on our laurels assuming it can't."

The happy manager who reduced five QAs to two and got a bonus for the savings isn't looking beyond the next fiscal quarter. QA professionals need to speak that language — and make their case before it's too late.

The highlight of the day wasn't lunch. It was the man who tests the Earth.

Host Jiří Charvát admitted he didn't want to believe the abstract. He read it three times. He went to check the website to make sure it was real. Then he introduced the talk with a reference to Alex Garland's TV series Devs — about a machine capable of simulating the entire universe, past and future.

"This is the same thing. Just in its early stages."

Kristián Kottfer, QA engineer at BAE Systems OneArc — a company born from Bohemia Interactive Simulations — took the stage. His team builds a real-time graphical simulation of the entire planet Earth at 1:1 scale, used for military, police, and emergency services training in around sixty countries worldwide.

Why simulate the planet instead of just going outside? "Because we need to get better at warfare. Or at defending ourselves." Instead of burning real ammunition or deploying to live exercises, soldiers step into a simulator — on screen, in a headset, or inside a motion-based vehicle simulator — and train safely. Anywhere on Earth. Repeatedly. With a complete recording of every second.

What Are You Actually Testing When You Test a Planet?

VBS4 with the VBS Blue engine is not a game. The goal is not entertainment but training
effectiveness and compliance with military doctrine.

Real-time rendering targeting 60 frames per second — each frame must complete in 16
milliseconds. The engine calculates lighting at the triangle level, sun position, atmospheric scattering, weather, particle effects. Since rendering everything is impossible, the system dynamically decides — what's far away gets simplified, what the user can't see doesn't get drawn.

The data pipeline is a modular network of interconnected plugins — a DAG structure — that generates and modifies world content. Over sixty biomes, each with multiple seasonal layers. And then — what Kristián described as the most fascinating challenge — multimodal sensors. VBS Blue doesn't just simulate what the human eye sees. It simulates night vision and thermal imaging, each with entirely different physical models. Wet asphalt behaves differently in thermal view. Air humidity affects heat dispersion differently depending on conditions. And all three display modes must be physically consistent — with each other and with reality.

"Now you know how our QA feels. When you want to test a system like this, it can sometimes feel like an impossible task."

Seven QA Engineers for 21 Developers — and a System Where Lives Depend on the Output 

The Blue Team has 21 engine developers and 7 QA engineers. Seniority is extreme: some team members have been with the company for ten to twenty years. The testing environment uses no commercial tools — it's a suite of internal applications. BlueView is the production view. DiagManager is a deep control console. Dev script provides deterministic test automation.

The CI/CD pipeline produces daily and nightly builds with visual regression tests — pixel-by-pixel image comparisons, GIF diffs, reports via Hub, Sheets, and Slack. And here appears one of the talk's most interesting problems: non-determinism from the graphics engine itself. Upscaling algorithms produce variable results. Micro-stutters — tiny rendering hiccups invisible to the human eye — cause a visual test to fail because a single pixel changed for a fraction of a second. And every PC renders slightly differently.

Finding the right tolerance threshold that catches real regressions without flooding the team with false alarms is itself a technical challenge.

AI in a System Where the Output Affects Real Lives

Kristián was direct and measured on the topic of AI — and all the more valuable for it at the end of a day full of AI discussions. In a company working for the defence sectors of sixty countries, security and compliance requirements are extreme. A random AI system with access to internal infrastructure is simply not an option.

The realistic plan: AI as an assistant for summarising visual test results, log analysis, generating reports, and communicating changes across teams. Not as a replacement for expert judgment in safety-critical parts of the system.

"Most teams that start with AI fail because their eyes are too big. We start small and measure the benefit."

The Day's Final Word

Kristián Kottfer closed with a thought that perfectly bookended the entire TestCrunch 2026 day: "We in QA always work with chaos. And the only way to manage it is slow, steady, iterative progress — solving one problem at a time, not looking for a solution that solves everything at once."