Quality assurance

From plan to evidence, in one run.

Create test plans and cases from requirements and collected screens, then execute across Chromium, Firefox, WebKit, and API contracts. Every failure includes screenshots, replay videos, and logs.

Request a demoTalk about managed QA

Automate on pushes and PRs, with approval flows included.

Four capabilities

How requirements become execution.

Plans select cases. Cases run. Runs leave evidence.

01 Plan

Test planning

A plan explains what to test and why, and selects cases for the run. Plans move from draft to active, then to archived after release.

Learn more

02 Cases

Test case generation

Refine drafts from screens, documents, and code into verifiable cases, with priorities and automation levels. PR changes generate additions, updates, and removals awaiting approval.

Learn more

03 API

API testing

Validate requests and responses against API contracts. Server/API projects without screens begin here immediately after setup.

Learn more

04 UI · UX

UI testing · Expert UX review

The same cases run in Chromium, Firefox, and WebKit, with separate results and evidence for each engine. Experts document screen flows and usability concerns that automation cannot judge in UX review notes.

Learn more

Automation rules

Smoke tests on every push. Regression before release.

Set run conditions by repository, branch, and changed-path patterns. Tests run on pushes and PRs. Runs requiring approval wait until the QA lead approves them.

  • Define conditions by repository, branch, and changed-path pattern
  • Run types: smoke, regression, new feature, pre-release, API contract, permissions, unit checks
  • Browser notifications for approval requests, completion, and FAIL decisions
  • Retain run history and display recent runs on the dashboard

Evidence

Failures come with replay videos and logs.

Every failure automatically captures the screen at that moment, a replay of the steps, and an execution log. Developers can start fixing without asking how to reproduce it.

  • Every run: HTML report, replay videos, execution logs, evidence files
  • Result statuses: passed, failed, inconclusive, skipped
  • Separate evidence for each browser engine
  • Automatically create Jira issues from failures, with direct links to results
More about test reports & evidence

Severity and decisions

A minor failure does not mean FAIL.

Failures have four severity levels: critical, major, minor, and trivial. Only critical or major failures cause FAIL. Minor or trivial failures and inconclusive tests result in CONDITIONAL for human review.

  • Critical or major failures in stable tests → FAIL
  • Only minor/trivial failures, or deferred/quarantined tests → CONDITIONAL
  • All executed tests pass on the first attempt → PASS
  • Coverage below 80% means CONDITIONAL, even if all tests pass

Coverage · Reliability · Trends

Keep a record of what was not checked.

A case that exists but has not run is not verified. Count only the scope actually supported by execution.

Coverage

Requirements coverage is the proportion of testable statements extracted from documents that runs support, with an 80% target. Also track execution across 17 checklist categories and collected screens never opened by tests. This is not code coverage.

View coverage

Test reliability

Track tests whose results flip on the same commit over the last 20 runs. A flip rate of 20% or more triggers automatic quarantine. Tests continue to run and report, but cannot cause FAIL. Measurement is per browser engine.

View test reliability

Quality trends

Track weekly pass rates, approval times (p50/p95), PR suggestion acceptance, and automation ratios by project. See where quality improves across releases, beyond a single decision.

View quality trends

Frequently asked questions

Before you start quality assurance.

Can we start without organized requirements documents?
Yes. Screen collection and code-based case generation can take you to the first run. Attach whatever documents you have: feature lists, wireframes, WBS documents, or permission matrices. Coverage becomes more precise as documentation grows.
Do generated cases run immediately?
No. Unverifiable drafts are discarded and replaced, duplicates are removed, and priorities and automation levels (manual, candidate, automated) are assigned. PR suggestions become cases only after human approval.
How do you handle flaky tests with changing results?
Quarantine rules handle them. Tests that flip on the same commit are automatically quarantined and cannot cause FAIL. The decision remains CONDITIONAL for human review. Quarantined tests continue to run and report, so they never silently disappear.
Does it support mobile apps or API-only services?
Three-browser UI testing runs on web projects. API-only services begin with API contract testing as server/API projects, without screen collection. Mobile and desktop app support can be reviewed for your project in a demo.
Do we need to discard our existing CI and tests?
No. Qoretix runs on GitHub Actions push and PR events alongside your existing pipeline. Code-based case generation reads the repository, so existing tests can also inform drafts.
Where do people take part in this workflow?
In three places: approval of case suggestions and runs; judgment on failure severity and UX; and release sign-off by the QA lead. With managed QA, IXC experts carry out these tasks in the same interface.

Start with one case across three engines.

See how planning, cases, execution, and evidence connect in a demo using a real staging environment.

Request a demoTalk about managed QA

sales@qoretix.com+82-33-242-0210Weekdays, 10:00–18:00 KST