Skip to content

QA Flows Overview

QA Flows let you generate automated test cases from natural-language requirements and run them against your application in real browsers. Instead of writing tests by hand, describe what you want to test and let Marketrix build executable test flows for you.

  1. Create a QA Flow — Provide a description or upload a PRD. Marketrix turns it into structured test cases. Each test flow is called a QA Flow and contains a set of test cases.
  2. Review the test cases — Inspect the generated cases, refine them with a follow-up instruction, or edit them directly before running.
  3. Run the tests — Execute the test cases against your application in a real browser. Each execution is called a QA Run.
  4. Review results — See which tests passed, which need attention, and why. Every test is evaluated automatically and given a verdict.
  • AI-powered generation — Describe what to test in plain language, or upload a PRD; Marketrix writes the test cases.
  • Real-browser execution — Tests run in Chromium, Firefox, or WebKit — no scripting required.
  • Automatic evaluation — Every test run is judged against its expected outcome and given a pass / needs-healing / fail verdict.
  • Self-Healing — When a test drifts (it still reaches the expected outcome, but via a different path), Marketrix can repair the steps so the test keeps passing. See Self-Healing.
  • Run history & reports — Track every QA Run with pass/fail counts and a per-test report that includes screenshots and the steps Marketrix actually followed.
  • Cross-browser runs — Run the same flow across multiple browsers and compare results side by side.
  • Versioning — Test cases keep a version history, so you can review, roll back, or accept changes over time.

Each test in a QA Run receives one of these outcomes:

| Verdict | Meaning | |---------|---------| | Passed | The application reached the expected outcome and the followed steps aligned with the planned steps. | | Needs Healing | The expected outcome was reached, but Marketrix took a different path than the planned steps — a candidate for Self-Healing. | | Failed | The expected outcome was not reached. This usually points to an actual bug in the application. |

When a test needs healing or fails, Marketrix classifies the underlying cause to make triage faster:

| Category | Meaning | |----------|---------| | Locator | A UI element could not be found — often caused by selector changes after a deploy. | | Assertion | The expected result did not match the actual result. | | Timeout | The application was too slow or unresponsive during the test. | | Flow change | The application workflow changed since the test was generated. | | Environment | An infrastructure or connectivity issue prevented the test from running. |