AutomationSTAR

Test Automation Conference Europe

Uncategorized

A little wild, a little wonderful: your team’s Antwerp mini-guide

A railway station that looks like a cathedral, penguins next door, and an old town best explored without too much of a plan. AutomationSTAR comes to Antwerp on 4–5 November with two days of test automation and AI in testing, held a minute’s walk from the train.

Bring your team and you’ll cover more sessions, bring home more ideas, and save up to 25% on tickets. Plus, leave a little space for new experiences.

Here’s how to make the most of the city between talks.

Look up – you’ve arrived

At Antwerp Central, resist the urge to follow the crowd straight to the exit. Often called the ‘railway cathedral’, it lives up to the name. Stop under the great domed hall, take in the marble and gilt, and gather everyone for a team photo. A Room with a ZOO, our conference venue, is just a minute’s walk away. Getting the team from train to conference is the easy part. Persuading everyone to stop taking pictures might take longer.

Meet the neighbours

Not every conference has penguins next door…

Antwerp ZOO is one of the oldest in the world, and its 19th-century gardens and grand animal houses make a fine first afternoon if you arrive a day early. It’s an easy way to stretch your legs and catch up before the sessions start. It’s also a good escape between talks when your brain needs a breather. November days are short, so check closing times and go early.

Split up, swap notes

Wednesday morning is where a team really pays off. At 9am, seven hands-on tutorials start at the same time. Someone builds and breaks an AI testing agent in the AI Testing Dojo, someone else gets to grips with a scalable Playwright framework, and a third person explores agentic mobile automation. On your own you get to choose one. With a team, you can cover them all.

The keynotes give everyone something to discuss over lunch, and deep dives are already starting to book out – so the sooner your team is registered, the more choice you’ll have.

book tickets

Let the old town lead

Make for Grote Markt, where ornate guild houses that lean over the square reward a slow look upwards. The Brabo fountain tells the city’s founding legend: a giant, a severed hand and a hero with a good throwing arm. Then follow the cobbled streets, take a turn that looks interesting and see where you end up.

Let a different colleague choose each stop: a coffee here, a warm waffle there, a table somewhere inviting. Leave enough room for the conversation to wander too.

Raise a bolleke

If your team enjoys a Belgian beer, book the De Koninck brewery experience to learn how Antwerp’s favourite beer is made. Then order a bolleke, as the locals call it after its round glass. The site has food shops and places to eat, so you can easily stay for dinner. Book ahead for groups.

Or keep it simple: after Wednesday’s EXPO party, reserve a long table in the old town and let the day’s talks carry on over dinner. Expect at least one heated debate about flaky tests.

Follow the river to a fortress

A medieval fortress on your evening wander? Antwerp has that covered. Head towards the Scheldt and you’ll find Het Steen, the city’s oldest surviving building. Stop for a photo, take in the river views and give yourselves a little time before dinner. A few centuries of history makes a good change from talking about your next sprint.

Make room for chocolate

For a team outing with broad appeal, put Chocolate Nation on the list. Its interactive museum explores the world of Belgian chocolate, making it a tempting stop for a spare afternoon — especially if November sends you indoors.

Afterwards, seek out a chocolate shop together and compare your choices. Anything that makes it back to the office is a bonus.

Bring something back together

Attending AutomationSTAR as a team means you’ll come home with more sessions covered, more practical takeaways and a shared plan to act on them. Antwerp adds the long dinners, the detours and the conversations you rarely find time for during a normal working week. And it costs less:

  • Team of 3–4: 15% off
  • Team of 5–9: 20% off
  • Team of 10: 25% off, just €1,050 per person

Bring your colleagues, comfortable shoes, and a little curiosity. Antwerp will take care of the detours! You can find out more about hotels and getting here on our Location page.

Your next team trip is less than a month away! Book your tickets now.

book tickets

The Skills I Learned and the Ones That Got Away

Ahead of her AutomationSTAR Deep Dive, Close Encounters with Systems, Rachel Kibler reflects on the skills that shaped her testing career—and how systems thinking gave her a name for what she was already doing.

I started my career by diving headfirst into the context-driven testing community, forming some very strong opinions along the way. I look back at my dogmatism and wonder why I was so convinced that I, a baby tester, was right just because I was parroting something persuasive that resonated with me.

I found my way to conferences, which broadened my horizons and showed me that yes, everyone thinks in terms of context, and the arguments that we have within our testing community can be tiresome, worn-out, and ultimately unhelpful, even harmful when they gatekeep and manufacture heightened emotions around who’s doing testing “the right way”.

Ten years in, I hold a lot of my strong beliefs still, but considerably more loosely, and I’ve become much more understanding of everyone’s journey. Turns out, not everyone needs to do things the way I do them!

In addition to my attitude shift, I found that the skills I learned early on formed a lot of what I care about and still think about. And that these skills that I value turned out to be systems thinking before I had the words for it. Elisabeth Hendrickson’s book, Explore It!, was massively influential in learning how to create test charters and organize my mental models, as was Janet Gregory and Lisa Crispin’s Agile Testing in thinking strategically about how to deliver quickly and not be a bottleneck.

James Whittaker’s How to Break Software was one of the earliest I read, and though he does spend a lot of time on printer testing, the idea of creativity in your testing by shaking up the machine (sometimes literally) was helpful. And doing the Black Box Software Testing foundations course by Cem Kaner and Rebecca Fiedler through the Association for Software Testing played a huge role in shaping my skills too.

Because of those influences, I learned to think about software in creative ways, to not trust what someone says the software does and does not do, and to spend time following my gut instincts about where things could be broken, largely at the boundaries of the software and the boundaries of our understanding of the software.

I learned how to communicate well with my developers and at the right time. I learned how to advocate for my bugs, and hopefully for the user. I learned how to identify risk and to bring people together for conversations about what matters and what quality is for our products, creating feedback loops and shared mental models. These skills felt good to me, they felt right, and they enabled a solid career with good delivery of software.

Some testing skills eluded me though. Writing extensive documentation has never been my strong suit, and though I do strongly believe that test management systems are a kindness and should be a system of record for our software, writing steps down in depth has always felt daunting and overwhelming to start with. But documentation does make our system legible to others, modeling what we understand to be true. I also never really got a handle on what my automation should look like when it’s at its best, when it’s giving the feedback on the system in the right place.

AI changed the game for me, enabling me to pay more attention to the “what” and the “why” of automation rather than the “how” that had been so much of the concern of past me. However, thinking about documentation and automation in terms of systems may be the thing that drives both of these forward for me.

For AutomationSTAR in Antwerp this November, I get to do a deep dive into systems thinking itself. I’ll give a brief overview of the concepts in systems thinking before we dive deeper into time delays and other less intuitive things, pulling heavily from the new work of Elisabeth Hendrickson and Joel Tosi (their book, Signals & Levers, releases on September 22nd, 2026) as well as the work of Donella Meadows (Thinking in Systems: A Primer) and many others. Learning from Elisabeth Hendrickson’s book at the beginning of my testing career and now from her new book with Joel Tosi seems fitting.

I didn’t invent any of this, it’s been around for a long time, but it’s more relevant than ever right now. Systems are becoming more and more complicated as we throw AI into the mix for both the software itself and the processes around it. Feedback loops are getting longer and stranger, and the levers to pull are moving. Testers talk about systems in daily work, but perhaps without the structured framework to make the conversation’s importance clear. Systems thinking gave me language for the things I learned to do by instinct or by mimicry, and I’m excited to pass that on so you can talk about the things you already do and care about in terms of systems.

Rachel Kibler is speaking at AutomationSTAR – check out her Deep Dive and book your tickets.

Six Test Automation Trends That Will Actually Change Your Week in 2026

What do this year’s conference submissions reveal about where test automation is heading? As a member of the AutomationSTAR 2026 Programme Committee, Gomathi Ramalingam has been reviewing the ideas and experiences practitioners want to share. Here, she picks out six trends that stood out—and offers a practical starting point for each.

You can join her tutorial, AI Testing Dojo: Build, Break & Master Agents, at AutomationSTAR 2026.

Every year someone publishes a list of testing trends, and every year most of it is weather. It rolls over the industry, makes a lot of noise, and leaves your Tuesday unchanged. So when we read through the AutomationSTAR 2026 submissions on the programme committee, I was looking for something different: not what people are excited about, but what is already altering the day-to-day work of the teams behind the submissions.

Two numbers stuck with me. Around two-thirds of this year’s abstracts mention AI, LLMs or agents in some form. And ‘trust’ turned up in roughly one in five, which is a vocabulary shift I have never seen at this scale before.

Put those together and you have the story of 2026: the industry has stopped asking whether AI will write our tests and started asking how on earth we know when it has done it well.

Here are the six trends I think deserve your attention, each with one thing you can start this week.

1. Agentic testing is moving from demo to duty

For the last two years, ‘AI in testing’ mostly meant a chat window that produced plausible-looking test cases. That picture is changing. The pattern now showing up in real pipelines is a set of specialised agents with narrow jobs: a planner that explores the application and drafts a plan, a generator that turns the plan into executable code, and a healer that re-runs failures and repairs broken locators.

Playwright has formalised exactly this planner–generator–healer split and the Model Context Protocol (MCP) has become the standard plumbing that lets an agent see an accessibility tree rather than a wall of raw HTML.

The reason this matters is that decomposition is a hallucination-control strategy. An agent with one small, checkable job is far easier to audit than a monolith that “does testing”.

Do this: Pick one narrow, boring job in your pipeline, such as triaging failed runs or proposing locator fixes and give it to an agent with a human approval step. Do not start with “generate our regression suite”.

2. Trust has replaced coverage as the metric that matters

The World Quality Report 2025–26 found that 89% of organisations are piloting or deploying GenAI in quality engineering, yet only 15% have managed enterprise-wide adoption. The most telling figure is the barrier list: 60% cite hallucination and reliability as a blocker. Teams are not short of AI-generated tests. They are short of a reason to believe them.

A green tick from a test the model wrote, asserting a value the model also invented, is not evidence of anything. I have watched a beautifully formatted suite pass at 100% because every assertion was tautological. The work of a tester in 2026 is increasingly to be the accountability layer for output that was produced faster than any human could read it.

Do this: Add a quality gate before AI-generated tests are merged. Mine has six checks, but even three will change your outcomes: does each test assert something the code could plausibly get wrong, does it reference a real endpoint or element, and would it fail if the feature were deleted?

3. AI-generated code needs AI-aware testing

It is not only tests being generated. A large and growing share of production code now starts life in a model, and the trust gap is widening: in Stack Overflow’s 2025 developer survey, 84% of developers use or plan to use AI tools, yet 46% say they do not trust the accuracy of the output, up from 31% the year before. That code has characteristic failure modes. It handles the happy path elegantly, invents APIs that do not exist, and quietly drops edge cases that were never in the prompt.
This is good news for testers. Classic technique is back in fashion. Boundary values, negative paths, state transitions and idempotency checks are precisely the things a model skips when it is optimising for “looks correct”.

Do this: When a change is flagged as AI-assisted, run a short, explicit review checklist against it rather than the same one you use for human code. The checklist should include “which inputs did the prompt not mention?”

Be in the room for all the important conversations at AutomationSTAR 2026 – book your tickets now.

4. Flaky tests are finally being priced

For years flaky tests were tolerated as a tax. This year’s submissions and blog posts treat them as a cost line, and that reframing is overdue. Every retry, every “re-run and it passed”, every engineer who has learned to ignore red builds is a measurable drain on delivery. And in an agentic world it is worse: an agent that learns your suite is noisy will learn to retry, heal and paper over, which is exactly the behaviour you do not want automated.

Do this: Spend an hour producing a flaky test audit. List the tests that failed and then passed on retry in the last thirty days, with the minutes of pipeline time they consumed. Take the number to whoever owns the roadmap. It is a far more persuasive argument than “we need to fix tech debt”.

5. API-first testing is the natural habitat for AI

There is a reason so much of the serious agentic work is happening at the API layer rather than the UI. APIs are text. Specifications are text. Requests and responses are structured, deterministic and cheap to run thousands of times. A model reasoning over an OpenAPI document is operating in its comfort zone; a model reasoning over a rendered DOM is guessing at pixels.
Contract testing fits this beautifully. A contract is a machine-readable statement of intent, which means it can serve as both the prompt and the guardrail for generated tests.

Do this: If you are going to let a model generate tests anywhere, start with your APIs, feed it the spec rather than a description and measure hallucination rate per prompt. You will quickly discover that some ways of asking produce reliable tests and others produce fiction. Keep a scored library of the ones that work.

6. The tester’s skill stack is shifting, and it is not towards prompting

The tempting conclusion from all of the above is that testers need to become prompt engineers. I do not think that is quite right. The skills the 2026 submissions actually reward are older and harder: writing precise context, designing an experiment that can distinguish a good output from a convincing one, and thinking adversarially about a system that will confidently tell you it is fine.
That is testing. It always was. The difference is that the system under test now includes the tool doing the testing.

Do this: Give your team a low-stakes sandbox and a challenge: build a small testing agent, then break it. Nothing calibrates judgement about where AI helps and where it is dangerously wrong faster than watching your own agent fail. It is the format I am using for a hands-on tutorial at AutomationSTAR this November, and it is the approach I would recommend whether or not you attend.

The thread running through all six

Automation has always been about removing humans from the parts of the work that do not need them. What 2026 is clarifying is which parts those are. Generation is being automated. Judgement is not. The teams that will do well are the ones that treat every green tick from an AI as a claim to be verified, not a result to be celebrated.

Want to take these ideas further? Join us at AutomationSTAR in Antwerp on 4–5 November for practical talks, hands-on tutorials and conversations with the people putting them to work. Explore the programme, and find the sessions that tackle your team’s next challenge. Check out and book your AutomationSTAR tickets.

Book tickets

We analysed every AutomationSTAR 2026 submission. Here’s what test automation will look like in 3 years

This year’s Conference theme of “Future Skills” is not just a theme – it is being echoed by the data we are receiving for the Call for Speakers on the roles of the future and the skills that will define them.

Curious about how your job will look like in 3 years?

Instead of reading job advertisements from the past – our speakers are tackling the problems they face today with the tools they use and are frantically searching for the necessary skills to keep their job.

The AutomationSTAR Call for Speakers this year is even more valuable for those who work in test automation and quality in general. This year’s Programme Committee analysed all the submissions for the opportunity to speak at this event, and the result of such analysis paints a picture of what working in test automation will look like in 3 years from now.

If you work in quality this is THE event you MUST attend in 2026. Here is why.

book tickets

The topic map has been redrawn

Three years ago, our topic categories were organised around technologies: web, API, mobile, performance. Look at where submissions landed this year.

Of the submissions we received 35% fell into what we’re calling ‘AI-native’ categories of work such as ‘vibe testing’, ‘agentic AI’ and Gen AI-augmented automation. These categories have naturally evolved in the community and were not created by us for marketing purposes and have since taken off.

Meanwhile the category of Automation Strategy & Architecture retained its position as one of the most popular at 20%. Given the rapid evolution of the tools available for automation this category will continue to be relevant as someone needs to ensure that the automation is working effectively.

Code Craft & Maintainability scored the lowest with 2% of all submitted topics. As we were really excited to start to dive into the many questions and topics how to build something new in the first place, the community is clearly more interested in just building something new instead of taking care of something that has already been built. This is a gap one should be aware of.

The AI wave, measured

“AI is everywhere” is easy to say. Here’s what it looks like in numbers.

About two-thirds of the abstracts in all areas (design of tests, leadership, etc.) referred to AI, LLMs or agents. Autonomous and agentic AI was mentioned in 22% of the abstracts. On average, the abstracts focusing on AI, LLMs or agents received higher ratings from the committees than the abstracts that did not focus on these topics.

Additional to the former findings, the analysis furthermore detected a meta-trend within the abstracts under review: roughly 70–80% of the abstracts were written with the support of an LLM.

As before, however, when every single abstract was written to perfection using an LLM, the only remaining difference would be the authors’ experience. And this is exactly what the reviewers are trying to find – in line with this year’s review theme.

The vocabulary shift

Perhaps the clearest signal of all: count which words the community reaches for.

“Agents” and “agentic” were mentioned 40 times. The Model Context Protocol (MCP), for model deployment that was not yet established two years ago, was even mentioned more often than Selenium, Cypress and Appium together. Playwright, the heavyweight automation tool, was even mentioned as often as MCP.

The graph does not mean to suggest that all people have stopped using Selenium and Cypress for running their thousands of test pipelines. Rather, the focus of the test automation discussion has shifted from which test automation framework to use (Selenium, Cypress, Appium, etc.) to how to control, direct, put bounds to, and trust an autonomous test system.

Be in the room for all the important conversations at AutomationSTAR 2026 – book your tickets now.

Future Skills: the theme that chose itself

When we set “Future Skills” as this year’s theme, we wondered if the community would engage with it. They did — but not in the way a skills-matrix would predict.

The word that humans keep using in this year’s abstracts is: trust. It appears in 21% of the abstracts. This word is used to discuss the trustworthiness of AI, of different types of of fully autonomous agents, of teams of agents, and of the systems under test by the authors. Also discussed are collaboration, communication, leadership, and judging.

Interesting the term “test management” didn’t make the cut as a keyword in any of the abstracts. What was once a foundational term for a whole conference track a decade ago is now gone from practitioners’ vocabulary and has been replaced with terms that speak to trust, human judgment, and human / AI collaboration.

So here’s the nutshell summary of Future Skills: The mechanical parts of our work are getting covered by automated tools and thus will cease to be our area of work in the future.

What will remain with us, is what makes us human. That is: knowing when the green of your dashboard is only painting it green and thus might be lying to you.

Deciding how much autonomy to give to which kind of autonomous agent. Explaining risks to people who have to make decisions on the basis of that risk.

Fresh stories, seasoned voices

One more finding we loved.

72% of proposed talks will be new to AutomationSTAR 2026. 58% of submitters are experienced conference speakers, yet they are rewriting their stories as the automation field is changing very quickly.

The audience-level mix for the proposed talks is 58% intermediate, 33% introductory, 9% advanced. The field of automation is being reinvented fast, and so there is a point at which everyone is a beginner for that section of the discipline. Hence the community will be presenting talks for this audience.

From everywhere, to Antwerp

We received submissions from 35 countries around the world with 2/3 of the submissions coming from all over Europe. The country with the most submissions was India followed by submissions from the Americas, the Middle East and Asia-Pacific. The community is asking the same questions in Bangalore, Berlin and Brussels.

What this means for your career

The 2026 program is essentially a translation of everything we have stated: the agentic frontier, the strategy and architecture backbone of the program, actual use cases as opposed to vendor pitches, and a thread of human skills of judgment, trust and communication that no model can ever automate.

Data confirms that our profession will not be replaced by machines. Instead, we will be redefining the work of the next generation of information workers, directing autonomous systems, architecting quality strategy that leverages off these systems, and bringing trust, judgment to the work that machines cannot.

We can get a grip on this work quickly by understanding the work of our peers around the submissions for the 2026 program have been written by the very people redefining our work, our students work, and the work of our clients – two fast-paced days in a room with them is likely to get you and your work ahead quickly – join us in Antwerp in November.

Join us at AutomationSTAR 2026, Antwerp, 4–5 November.

Book tickets

Why the Future of Test Automation is Code AND No-Code

As AutomationSTAR brings together leaders and practitioners in testing, one ongoing debate always comes up: should test automation be code-driven or no-code?

The truth is, the strongest strategies use both. By letting each approach play to its strengths, teams cut bottlenecks, empower more contributors, and deliver quality software faster.

The Pitfalls of Choosing One Approach

When organizations lean too heavily on one side—whether code or no-code—the same challenges show up again and again:

  • Skill gaps: Different levels of coding expertise create dependencies and slow progress.
  • Silos: Developers, QA, and manual testers often work separately, with little shared visibility.
  • Maintenance overhead: Coded frameworks can be fragile and time-consuming to update, while a no-code-only strategy can limit flexibility for advanced scenarios.

Instead of streamlining releases, testing becomes another obstacle—especially when framed as code versus no-code instead of embracing both.

The Strengths of Code-Based Automation

Code-based frameworks like Selenium, Cypress, and Playwright remain essential for complex cases. They provide:

  • Flexibility and customization to test virtually any scenario
  • Fine-grained control over selectors, browser behavior, and environments
  • Precision for complex workflows and edge cases

For engineering teams, code is still the best tool when precision and customization are required.

The Strengths of No-Code Automation

No-code testing platforms thrive on speed and accessibility. With plain-language authoring and visual interfaces, they allow non-technical testers to contribute directly. They excel at:

  • Regression and smoke tests that repeat across releases
  • Routine workflows that don’t require custom code
  • Broad participation across QA and business testers

The benefit: engineers aren’t pulled into repetitive work, freeing them to focus on higher-value challenges.

Code + No-Code in Action

The difference becomes clear when comparing the two side by side. In one demo, a Selenium test for a simple e-commerce checkout flow took nearly an hour to script. Using a no-code approach, the same flow—with assertions—was built in just two minutes.

Real-World Proof: EVERSANA

EVERSANA INTOUCH, a global life sciences agency, needed to unify testing across distributed teams while meeting strict compliance requirements. Their approach:

  • Adopted code-based visual testing for precision.
  • Expanded to no-code test automation, enabling global manual testers to build end-to-end tests directly in the browser.
  • Result: A 65%+ reduction in regression testing time, faster validation across browsers and environments, and improved collaboration across roles.

The biggest change wasn’t only speed—it was trust. Developers, testers, and compliance began working from shared results, cutting duplicate effort and improving confidence across the organization.

Takeaway for QA and Engineering Leaders

The question isn’t “code or no-code?” It’s how best to integrate both. By using no-code for regression and repeatable flows, and code for complex scenarios, teams reduce bottlenecks, shorten feedback cycles, and scale their testing with confidence.

For mid-size to enterprise teams, this balanced approach delivers:

  • Faster test creation and execution
  • Greater collaboration across roles and skill levels
  • A strategy that keeps pace with modern release cycles

Closing Thought

The future of testing isn’t about choosing sides—it’s about working smarter with both. At AutomationSTAR, we look forward to exploring how code and no-code together are shaping the next generation of test automation.

Stop by the Applitools booth at AutomationSTAR to continue the conversation.

Author

Liran Barokas

Liran Barokas is Director of Solutions Architecture at Applitools, where he helps teams across EMEA scale their test automation strategies with AI and visual validation. With a background spanning engineering, customer success, and quality leadership, Liran works closely with QA and development leaders to accelerate release cycles, reduce maintenance burdens, and deliver measurable testing outcomes.

You can meet Liran—together with Lior Levi, VP and EMEA Leader at Applitools—during AutomationSTAR 2025 to continue the conversation on code and no-code test automation.

Applitools were exhibitors in AutomationSTAR Conference EXPO 2025. Join us in Antwerp 4-5th November 2026.

part of the