Launched this week
Releasing fast shouldn’t mean breaking things. As your product grows, Ogoron takes over your QA process end‑to‑end. It understands your product, generates and maintains tests, and continuously validates every change - replacing a systems analyst, test analyst, and QA engineer. Get predictable releases, fewer bugs in production, and full coverage without manual effort. Ship faster. Stay in control. Break nothing
Free Options
Launch Team / Built With
Ogoron
@elena_nimchenko Kudos on the launch. How does Ogoron handle flaky tests or UI changes that break coverage over time?
Ogoron
@swati_paliwal Thanks for the great question! Flaky tests and UI changes that slowly break coverage are very real problems in long-lived QA systems, so this is something we think about a lot.
Ogoron addresses this in a few ways. We support test healing when product changes invalidate existing coverage, and we also have quarantine-style policies for unstable tests so that flakiness does not automatically pollute the whole signal.
More broadly, we try to reduce the impact of flakiness by structuring test coverage intelligently rather than treating every test as equal. In practice, that means differentiating tests by significance, cost, and role in the pipeline, so teams can manage reliability and signal quality much more deliberately over time
Cool! the bit that caught my attention is the test maintenance claim. most AI testing tools i've tried are decent at generating tests, but they go stale fast. and then you're spending more time fixing the tests than fixing the product. curious how Ogoron handles it when the UI changes significantly, like a nav restructure or a renamed flow? does it detect drift automatically, or does someone still need to nudge it? that's genuinely the hardest part of QA automation in my experience, so would love to know how you've tackled it.
@fraser_svg Thank you for the great question!
When some tests fail you run
It puts every failed test into one of three classes:
code bug
test bug
unsure
Test bugs are then fixed by Ogoron
The bugs in "unsure" state need human review. Our experience with pilot customers show 10% to 50% tests fall into this category, depending on a project. Our experience also show that about 15% of the failures are incorrectly classified.
Once a human have put the failed tests into test bug category, they can be fixed by Ogoron.
@nick_mikhailovsky1 that 10-50% "unsure" range is really interesting. so the human review step is basically the quality gate for the tricky cases. 15% misclassification rate is honest too, most tools wouldn't publish that number. does the "unsure" percentage tend to shrink over time as ogoron sees more of a project's patterns? or is it pretty stable regardless of how long it's been running on a codebase?
@fraser_svg We have not analyzed the dynamics of "unsure" percentage yet - thank you for the idea!
"9x faster, 20x cheaper" is doing a lot of heavy lifting in that tagline, and I'm curious where those numbers come from and what the baseline looks like.
A team of three humans running manual regression cycles, or a mix of Cypress and a part-time QA contractor? The claim lands very differently depending on what you're replacing.
The angle I am finding genuinely interesting is test maintenance. That's where automated QA silently falls apart. Tools generate tests fine, but when the product changes, someone still has to fix everything that broke. If Ogoron is actually handling that loop autonomously, that's the real differentiator, not the generation part.
Lastly, I'm also wondering how it handles logic that lives outside the UI, i.e., complex business rules, edge cases that aren't obvious from the interface or the codebase alone. That's usually where a human QA engineer earns their salary, and it'd be good to know where the ceiling is.
Congrats on the launch, Elena and team.
@ryanwmcc1 Ryan,
I agree the question of baselines is important . We have this clear on Ogoron website, but probably not as clear here on Product Hunt. Let me explain this.
9x faster test creation vs Automated test engineers is a figure we got with our pilot customers. Test engineer created some 60 UI autotests per month manually. Ogoron allowed creating some 30 UI autotests per day. Some 85% of the tests worked out of the box, and the day was mostly spent fixing the broken 3-6 tests.
20x cost reduction is versus manual regression testing.
Ogoron handles the test maintenance loop semi-autonomously. If the test fails,
can put it into one of three states:
test bug
product bug
unsure
A human have to review unsure tests and put into one of the buckets. Test bugs are then fixed by Ogoron.
bold claim. curious where this breaks - QA automation typically hits hard exceptions fast when scope expands. what's the failure recovery model?
Ogoron
@mykola_kondratiuk That is a very fair question. Hard exceptions are a real limit for QA automation, especially as scope expands.
Our view is fairly pragmatic: the boundary is reached when the correct behavior cannot be reliably reconstructed from the available artifacts – code, tests, specs, documentation, and the behavior of the product itself.
So our recovery model is to recover automatically where the system can establish a high-confidence truth, and surface ambiguity when it cannot. In practice, that means Ogoron can adapt a lot of standard cases on its own, but in genuinely disputed or under-specified situations it asks the user to resolve them explicitly rather than pretending certainty.
A big part of the product is expanding that high-confidence zone over time – from general web patterns to increasingly domain-specific behaviors
Pragmatic is the right call. Hard exceptions that block releases are worse than automation gaps - especially when you are scaling coverage fast. The key is knowing which ones actually matter.
Can Ogoron be used in a hybrid cloud setup where some services are on‑prem and others in the cloud? We have sensitive data that can’t leave our servers
@alexey_kochetkov Both the hybrid and pure on-prem are in our backlog
Can it handle repos with a history of 10 000+ commits? We’ve been building our app for 5 years.
Ogoron
@alibekovand Good question. A long commit history by itself is usually not a serious issue.
Most codebases can be read progressively, layer by layer, so what matters more than the raw number of commits is the current architecture of the project and how much useful signal exists in the code, tests, and docs.
We have already tested Ogoron on many large repositories, including products that have been developed for more than 10 years. So a repo with 10,000+ commits is well within the kind of scale we expect to handle.
Hi! How does it integrate with version control systems like Git? Can it create pull requests with suggested fixes?
Ogoron
Hi Karina! Yes – for GitHub, we already support this via a GitHub Action, including workflows that can open pull requests with generated changes.
For other Git-based systems, the integration is not yet fully packaged, but we do provide a CLI, so setting up an automated PR flow is usually quite simple – basically a couple of extra shell steps beyond calling Ogoron itself.
The main thing that is still GitHub-first for now is self-serve billing. For other systems, we can support early access directly – feel free to email me at vmynka@ogoron.com