Testovex - No-code, AI test automation for enterprise QA
by•
Testovex is an Automation Center of Excellence (ACOE) platform that lets enterprise QA teams build, manage, and run end-to-end tests — without writing code.
Replies
Best
Maker
📌
Hey Product Hunt 👋
I'm Puneet, founder of Testovex.
I built this to fix a problem that's quietly eaten years of QA teams' time: flaky, high-maintenance test automation. Every UI change breaks scripts, Selenium suites rot, and teams spend more time fixing tests than writing them. The "no-code" alternatives that solve this (Tosca, Katalon, etc.) are priced per-seat and per-node, so the cost explodes the moment your team grows.
So I spent the last several months building Testovex solo — a no-code test automation platform running on a Playwright engine. You get Playwright's speed and reliability, but a manual QA can build tests by recording a flow in Chrome — no code, no engineers required.
What's live in beta today:
✅ No-code builder + Chrome recorder
✅ Playwright execution — cross-browser, parallel
✅ Smart locators (9 strategies) so tests survive UI changes
✅ Reusable components, RBAC, version history
✅ Run recording — video, screenshots, traces
✅ CLI + CI/CD
It's free during beta, and I'm doing hands-on onboarding personally.
I'd genuinely love your feedback — especially from anyone in QA or test automation. What's the most painful part of keeping your test suites alive? And what would make you trust a no-code tool with your test coverage?
Happy to answer anything 🙏
Report
A native integration with Jira or Linear would save us a ton of time, since right now we manually link test runs back to tickets and it gets messy fast. If a failing test could auto-create or comment on the linked issue with logs and screenshots attached, that would close the loop between QA and dev without any extra glue work. Would love to see something like that on the roadmap.
Report
Maker
@foodpro This is exactly the kind of feedback we love — thank you for the detail.
You're right that the manual linking is where the "logical last mile" of automation usually breaks down.
Every run already carries the video, step-by-step screenshots, and full Playwright trace on failure — so the raw material for an auto-comment-with-evidence flow is there. Native Jira/Linear integration (auto-create or comment on the linked issue when a test fails, logs + screenshots attached) is genuinely on our roadmap — you've basically described the exact shape we've sketched internally. I'll make sure it moves up the list based on this.
While that's in the works — we've also been pushing hard on cutting down manual effort earlier in the pipeline. We just shipped AI-powered test generation straight from a URL: point it at a page, and it drafts a full set of runnable test cases (happy path, negative, validation, UX) in under a minute, no code, ready for QA to review and approve. Same philosophy as what you're describing — remove the glue work between QA and everything around it, not just at the reporting end.
Would love to keep you posted when Jira/Linear lands — happy to loop you in as an early tester if that's useful. What's your current stack, Jira or Linear (or both)?
Report
Maker
👋 Quick update for anyone checking out Testovex today —
One feature I want to make sure people don't miss: AI-powered test generation from a URL.
Paste any page URL — no code, no setup — and Testovex reads the page and generates a full set of executable test cases in under a minute. Not a checklist, not pseudocode — real Playwright tests with steps, locators, and assertions, ready to run.
It covers happy path, negative cases, UX checks, and validation — the same scenarios a sharp QA engineer would think to test manually. Every test lands as a Draft first, so your team reviews and approves before anything runs — AI drafts, humans decide.
If you're evaluating test automation tools, this is the part I'd try first. Happy to answer any questions below 👇
Report
Maker
Another one worth flagging — this one's newer and I think it solves a problem most test automation tools don't even try to touch: testing from the requirement, before the app is even built.
Most tools generate tests by scanning an existing, built app — which means the tests just validate "does this match itself," not "does this match what was actually supposed to be built." Testovex's Blueprint feature flips that: give it a user story or requirement, and it generates test cases straight from the spec — referencing elements semantically (by role/label/name), since the UI doesn't exist yet.
Once the app is built, one click binds those tests to the real UI — matching each semantic reference to actual elements. Then Testovex generates a Conformance Report: a traceability matrix showing exactly where the build matches the spec, and flags anything the requirement expected that never got implemented (or behaves differently than specified).
Basically: instead of "here are some tests for what we built," it's "here's proof of whether we built what we said we would." That gap — between what was specced and what shipped — is usually invisible until a customer finds it. This surfaces it automatically.
Would love thoughts from anyone who's dealt with that spec-vs-built drift on their own teams 👇
Replies
A native integration with Jira or Linear would save us a ton of time, since right now we manually link test runs back to tickets and it gets messy fast. If a failing test could auto-create or comment on the linked issue with logs and screenshots attached, that would close the loop between QA and dev without any extra glue work. Would love to see something like that on the roadmap.
@foodpro This is exactly the kind of feedback we love — thank you for the detail.
You're right that the manual linking is where the "logical last mile" of automation usually breaks down.
Every run already carries the video, step-by-step screenshots, and full Playwright trace on failure — so the raw material for an auto-comment-with-evidence flow is there. Native Jira/Linear integration (auto-create or comment on the linked issue when a test fails, logs + screenshots attached) is genuinely on our roadmap — you've basically described the exact shape we've sketched internally. I'll make sure it moves up the list based on this.
While that's in the works — we've also been pushing hard on cutting down manual effort earlier in the pipeline. We just shipped AI-powered test generation straight from a URL: point it at a page, and it drafts a full set of runnable test cases (happy path, negative, validation, UX) in under a minute, no code, ready for QA to review and approve. Same philosophy as what you're describing — remove the glue work between QA and everything around it, not just at the reporting end.
Would love to keep you posted when Jira/Linear lands — happy to loop you in as an early tester if that's useful. What's your current stack, Jira or Linear (or both)?
👋 Quick update for anyone checking out Testovex today —
One feature I want to make sure people don't miss: AI-powered test generation from a URL.
Paste any page URL — no code, no setup — and Testovex reads the page and generates a full set of executable test cases in under a minute. Not a checklist, not pseudocode — real Playwright tests with steps, locators, and assertions, ready to run.
It covers happy path, negative cases, UX checks, and validation — the same scenarios a sharp QA engineer would think to test manually. Every test lands as a Draft first, so your team reviews and approves before anything runs — AI drafts, humans decide.
If you're evaluating test automation tools, this is the part I'd try first. Happy to answer any questions below 👇
Another one worth flagging — this one's newer and I think it solves a problem most test automation tools don't even try to touch: testing from the requirement, before the app is even built.
Most tools generate tests by scanning an existing, built app — which means the tests just validate "does this match itself," not "does this match what was actually supposed to be built." Testovex's Blueprint feature flips that: give it a user story or requirement, and it generates test cases straight from the spec — referencing elements semantically (by role/label/name), since the UI doesn't exist yet.
Once the app is built, one click binds those tests to the real UI — matching each semantic reference to actual elements. Then Testovex generates a Conformance Report: a traceability matrix showing exactly where the build matches the spec, and flags anything the requirement expected that never got implemented (or behaves differently than specified).
Basically: instead of "here are some tests for what we built," it's "here's proof of whether we built what we said we would." That gap — between what was specced and what shipped — is usually invisible until a customer finds it. This surfaces it automatically.
Would love thoughts from anyone who's dealt with that spec-vs-built drift on their own teams 👇