Koel QA
Now looking for early access customers

Ship knowing what works.

Koel tests your application against what your business asked for, and tells you plainly what works, what doesn't, and what your customers would notice. Your team stays in charge of every decision.

Apply for early access See how it works
A release in Koel QA: its stages and the decision waiting on you
Product screen, shown with demo data.
What Koel does

From your requirements to tested releases

Koel reads your requirements and each release's tickets, plans the testing, writes test cases traced to every requirement, and turns every test case that can be automated into an automated test in Playwright, a widely used testing tool. No automated tests today? Koel sets them up. Already in Playwright? Koel works inside your project.

Testing teams

A full test inventory from day one, automated tests that stay current as releases change, and failures already sorted so the same problem isn't investigated twice.

Product and business owners

Release by release: which requirements are working, which defects are open, and what customers would experience, so the decision to ship is made knowingly.

Developers

An outside-in check of their changes: tests written from the requirements, not from the code, that run with every build in your pipeline once configured.

How a release goes through Koel

The same six steps, every release

So you always know where things stand, and where a person decides.

Understand

Koel reads your requirements and lists what it understood, what's unclear, and the questions for your team.

You review it.

Plan

A test plan and test cases, each traced to the requirement it checks.

You approve before anything is built on them.

Automate

Automated tests, each tied to a test case, and so to its requirement.

You approve before they judge a release.

Run

Downloadable results, with step-by-step screenshots for every test.

Sort

Every failure is sorted. The ones that look like real defects come to you.

You confirm.

Release

What changed is tested, and the release ends with a report: what passed, what's open, and what's still untested.

Setting up an application in Koel QA: four stages, the step waiting on you, and the sign-off record
Setting up a new application: where it stands, what's waiting on you, and who signed off each part. Demo data.

Testing where features connect

Many of the hardest defects live in the handoffs: a screen and the service behind it, one step of a process and the next, what one user enters and another sees.

When a release changes one feature, Koel works out which others depend on it and tests the whole journey through them, the way a customer would. Any connection not yet tested is listed in the release report, so a gap is always visible.

Why you can trust the results

Results you can check, not just a green run

Tests come from your requirements, not your code.

A test that only repeats what the code does passes on the code's own mistakes. A test written from the requirement fails when the application doesn't do what was asked.

Every test traces to a requirement.

Each result rolls up to its requirement. Requirements with no test are counted and shown, not hidden.

Coverage means depth, not a tick.

For each requirement Koel asks where it could fail: wrong or missing input, limits, each kind of user, the order things happen. Each gets a test case.

A test can't be quietly weakened.

If a change would make a test easier to pass, such as a check removed or a test skipped, the work stops and a person sees it.

A failing test is a finding.

Our goal isn't a green run. It's to find your product's defects and show them honestly.

What can't be confirmed goes to a person.

Anything the checks can't trace back to your requirements or results is shown to your team, not passed along.

A team of agents, and the checks behind them

Planning agentReads your requirements and tickets; writes the plan, the test cases and the questions for your team.
Automation agentWrites the automated tests.
Review agentReads the tests the way a senior tester would, and sends back the ones that don't really check what they claim.
Triage agentLooks at every failed test and suggests why it failed.
Koel's built-in checks aren't agents, and they don't guess. After each agent's work they confirm it matches your requirements and the actual results, and stop the work for a person if a test was made easier to pass. No agent can change your application, approve anything, or mark a defect as known.

Traceability and coverage

For every requirement you can see its test cases, its automated tests and their latest results, in one place.

Coverage is counted against your requirements, not lines of code: how many have tests, how many of those pass, and which aren't tested yet and why: waiting on an answer from your team, waiting on test data, or not yet automated.

Koel's traceability page: coverage counts and the requirements traceability matrix
Traceability: every requirement with its test cases, automated tests, latest result and defects. Demo data.
When a test fails

Every failure, sorted

So your team knows what to do with it. The triage agent suggests the kind; a person can always choose differently, and Koel follows the person's call.

Product defect. The application doesn't do what the requirement says. Your QA lead confirms it, and it's reported on every run until it's fixed, without being investigated again.
Test needs updating. The application changed as intended, and the test still expects the old behaviour.
Test needs maintenance. Something in the test itself needs fixing, such as a button it can no longer find.
Environment issue. The test environment, access or test data got in the way. Once fixed, those tests run again.
Awaiting clarification. The requirement doesn't say clearly what should happen. The question goes to its owner, and the test waits.
Failures in Koel QA, biggest first, each with the requirement beside what happened and Koel's suggestion
Failures, biggest first: the requirement beside what happened, and Koel's suggestion for each. Demo data.
The release decision

Whether to ship is yours to decide

Koel's job, and your testing team's, is to find defects and present them clearly: what each one breaks and what your customers would experience.

Whether to release with open defects is a business decision. Your organization chooses who makes it: a business owner, a program lead, a product manager. That person sees each open defect and decides: ship with it, or fix it first. Koel records the decision and the reason, and the release report shows what was tested, what passed, which defects are open and what was decided about each.

DECIDED BY A PERSON
with a name and a reason

What we need from your team

  • Your requirements: documents, user stories or tickets, however your team keeps them.
  • Your existing test cases and automated tests, if you have them. Koel reviews them first and shows where they leave gaps.
  • A test environment Koel can use, with test accounts for each kind of user.
  • Someone who can answer questions about the requirements when they're unclear.
  • The people who approve the plan and the tests, and the person who makes the release decision.
Early access

We're looking for early access customers.

Try Koel on your own requirements, with hands-on help from our team.

Email info@koelqa.com