Manual QA testers often start with no-code tools because coding takes time to learn. But these tools usually lock you in with no clean way to export tests or scale as projects grow.
I’m early in exploring a hybrid tool that lets you
create, edit, and run test suites in no-code or code,
and generate an exportable Playwright project that’s easy to understand and extend with code when needed.
Just curious if this sounds like a common headache or if it’s just mine.
Would love to hear what others think.
I am curious, is there something specific you’re looking for since doesn’t Playwright itself allow for this? Granted it’s not edit/update but create and export. But if you’re looking for updates as well, I haven’t come across anything like that.
No-code tools are generally great for the quick creation of tests, but as your project gets bigger, those tools tend to feel restricting, especially when one cannot export or extend the tests easily.
Hybrid tool idea that can switch between no-code and code environments and maybe even export to Playwright sounds extremely handy. So, you are not the only one. I, for my part, have struggled with having that flexibility.
Would love to hear if others have found tools that do this well.
From what I’ve gathered talking to manual QAs, Playwright’s test generator only solves part of the no-code problem.
Here’s what keeps coming up:
After recording, you’re left with a full Playwright codebase
Editing those tests means jumping into code, which many manual testers aren’t comfortable with
Even getting set up requires coding: repo setup, dependencies, CI/CD, scheduling runs, etc.
So the options usually are:
Learn coding (time-consuming)
Ask devs to write tests (not ideal)
Hire a test automation engineer (costly)
And because test automation is often rushed and last-minute, many teams turn to tools like TestRigor, Katalon, etc., since they let you click your way to a working test suite fast that you can run and schedule.
BUT After spending hundreds of hours building your test suites, you can’t export your selectors, test cases, or test logic. So switching to Playwright (or anything else) means starting over from scratch.
That makes a lot of sense. I do agree with most of what you’re saying. The one point I’d push back on, and I totally understand that there is nuance and depending on the company you may not have a choice in this, is that Devs writing tests are not ideal.
My devs write all the tests. Our QAs tell them and validate what tests needs to be written. So we try not to make ‘tester’ a role but focus on the Analyst part of the QA workflow. Part of our feature work is making updates to the regression script if needed that devs now handle. So, we did have QAs and Engineers originally create the E2E script (we used selenium), but now dev teams are responsible for updating and maintaining it. This can be echoed by the Dora research group - DORA | Capabilities: Test automation
This totally slipped my mind, but something you could look into and I usually don’t recommend it for this particular use case, but have you looked into UIPath? It’s a low/no code solution generally used for doing business automation but you could utilize it for what you’re wanting to do. It as far as I know, doesn’t export to playwright or any code, it is its own ecosystem.
Thanks again Sean, ( just realized your username is Sharmon but your name’s Sean — my bad!)
and yeah that all makes sense.
One thing I always wonder though: writing and maintaining E2E tests is practically a whole job on its own. On top of system design, building features, documenting APIs, testing locally, debugging, solving defects, etc… that’s a lot to expect from devs.
Do you ever get pushback from Devs, PMs or leadership about the time it takes? Or is the project in more of a maintenance mode without a constant stream of new features?
It can be a lot and depending on the company and culture there’s a lot of nuances to your particular situation. But we’ve put in a lot of work and processes to really help change mindsets and culture within the product we oversee.
I can’t get into too much detail but my product is not in maintenance mode. It’s one of our flagship products at the company. We generally release a new feature or enhancement every month.
We did/do get some push back from devs. Some devs are really good about it and some need a little more encouragement to jump in. What makes it easier is iterative deployments. So many small changes. Those small changes are easier to maintain over time compared a massive release (although we do have some of those as well). So, it can be a lot. We try to let teams self organize and figure out their work. The nice part is having many backend services to 1 front-end. Not much changes on the front-end too much. So the fixes are small and pretty easy for developers to make.
We had a string of bad deployments and the business pushed on us to fix it and fix it ‘now’ so we took all that data and showed them the cost of rushing. From there we worked with our Product Owners to help slowly build that trust and now our stake holders and PMs, they are now saying and telling us that if we need extra days to ensure we’re thorough and doing it the right way, they’d rather us do that … just give them more than a weeks notice if we’re able… But it’s a delicate trust we built and we need to make sure we now do our part.
How we break it up, we have architects who do designing and some development(my role but my domain is quality while we have specific App Archs for feature work). We want to get our QAs to do more exploratory and set up tests ahead of time so Devs know what they should check for. Our documentation practices could be better, but we are more leaning into the code and tests are the documentation, instead of explicitly created docs.
Testing Locally - this is something we do very rarely. To get where we want to get too, we need to trust that we tested it correctly via the code. Small changes make for small problems and easy fixes when we do find something wrong.