Lets start with a bit of back story.
I am a full stack developer. Developer being the keyword here, not a QA developer.
But in my current role, I was recently asked to come up with a testing suite for the web application and the Flutter app I was managing and maintaining.
At that time, I didn’t have anything better to do and thought this would be a fun little project to work on for a couple of weeks.
Boy o boy, I was wrong.
People in QA are so opinionated.
Everyone has their preferred framework, structure, naming convention, abstraction, folder structure and a very strong opinion about why your approach is wrong.
Starting with the industry best practices
I started by trying to follow the trends and best practices used in the industry.
Page Object Models, reusable helpers, proper assertions and all the usual bits and bobs.
For the web application, which was built with React, I chose Playwright.
For the Flutter app, I went with integration_test.
Sounded simple enough.
The login test that took three hours
The first test I tried to write was a simple login flow.
Open the application
Enter the username and password
Press the login button
Wait for the dashboard
Easy, right?
It took me ages.
And by ages, I mean roughly three hours just to get the web test to pass reliably.
The actual Playwright test ended up being around 300 lines once I included the boilerplate, setup, selectors, assertions, waits, Page Object Model structure and everything else needed around the actual journey.
Then came the Flutter app.
That one was worse.
The app has its own custom way of starting different flavors, and both the web application and Flutter app are white-labelled products.
That means there are a lot of variations to cover.
Different branding, configurations, screens and sometimes slightly different user journeys.
Before I could even test the login flow, I needed a pile of setup code just to launch the correct version of the app.
The Flutter test eventually went beyond 500 lines, including the boilerplate.
I couldn’t even get it to run on the first day.
On the next day, with a fresh cup of coffee and Claude sitting beside me like an unpaid junior developer, I finally managed to get somewhere.
It ran.
But it was still flaky.
Fixed waits are a trap
The APIs did not always respond at the same speed.
Sometimes the dashboard loaded quickly.
Sometimes it took a few extra seconds.
Sometimes a loading indicator appeared.
Sometimes it disappeared almost instantly.
So fixed waits were unreliable.
Wait too little and the test fails.
Wait too long and the whole suite becomes painfully slow.
Then you add more conditions, more retries, more pumpAndSettle, more element checks and more code around what should be an extremely simple user journey.
At one point I stopped and thought:
Why am I explaining every single technical action when the actual requirement is obvious?
The requirement was simply:
The user should be able to launch the app, log in and reach the dashboard.
So I decided to break down the same journey as a prompt and let Claude try to execute it.
The prompt was something like this:
Launch the app and wait for loading to finish. Tap login, fill in the username and password, submit the form and verify the dashboard appears.
That was basically it.
Less than 120 characters of actual testing intent, depending on how you phrase it.
And on the first try, it got it right.
I was starstruck.
What actually changed
Obviously the prompt does not magically remove all the complexity.
Something still needs to:
Launch the app
Inspect the interface
Find the relevant elements
Interact with them
Wait for the correct states
Decide whether the journey passed or failed
But that responsibility no longer had to sit inside hundreds of lines of test code written and maintained by me.
With Playwright or Flutter integration tests, I had to explain how every action should happen.
With the prompt, I only had to explain what the user was trying to achieve.
That was the aha moment.
From one prompt to full user journeys
From there, I kept adding more prompts for different user journeys.
Login.
Create a beneficiary.
Start a transaction.
Complete multi-step forms.
Check that records appeared in the correct list.
The only scripts I wanted to maintain were the ones needed to launch the Flutter app or open the web application.
The rest of the journey could be described in natural language.
The next journey was much easier to add.
Then the next one.
And the next one after that.
It was not perfect
I don’t want to make this sound like one prompt suddenly solved every testing problem.
It didn’t.
Sometimes the instructions were too vague.
Sometimes the application entered a state the agent could not recover from.
Sometimes a site blocked automation completely.
And traditional coded tests are still better when you need complete determinism and precise control over every interaction.
Playwright is also faster and more predictable for stable flows where you already know exactly what should happen.
But for business-level user journeys, this felt completely different.
I was no longer spending most of my time writing selectors, waits and boilerplate.
I was describing what the user should be able to do.
That small moment became CueTest
That small aha moment eventually gave birth to CueTest.
CueTest lets you describe end-to-end tests in natural language and watch the browser execute them.
The Android testing side is not live yet, but the web testing platform is available now.
I am still figuring out how far this approach can go, where it breaks and where traditional frameworks still make more sense.
So please don’t expect a polished marketing answer from me.
Try it.
Break it.
Give it a weird user journey.
And leave me your honest feedback.
I would especially love to hear from people maintaining Playwright, Selenium, Cypress or Flutter integration test suites.
Do you think agentic testing will eventually replace most traditional end-to-end scripts, or will it mainly sit beside them?
Top comments (1)
A bit of extra context: I am not claiming prompts are already better for every kind of test.
Playwright and Flutter integration tests still win when you need speed, determinism and precise control.
The interesting part for me was how much easier it became to author and maintain business-level user journeys once I only had to describe the intended outcome.
Would love to hear where people think this approach breaks down.