Skip to main content

​
What you do

Install the CLI and the noqa-testing skill, then ask. The skill carries the whole workflow, so there is nothing else to set up and nothing to explain to your agent:
Both work — the first leaves the scope to the agent, the second pins it down. From there you only answer when it asks.

​
What the agent does

  • Learns your app from three sources:
    • your code — the screens, navigation and business rules behind the feature;
    • your tests in noqa — the app context, the cases you already have, and their earlier runs, which show the screens and the paths between them as your app was really used;
    • the app itself — where the first two leave gaps, it builds the app, installs it and walks through it on a device.
  • Writes the test cases — in plain English, from a cold launch on a clean install, with shared steps like login and onboarding pulled into reusable flows.
  • Proves each case before saving it — it performs the scenario on the device first, so the steps match what the app really does, not what the code suggested.
  • Runs the suite and fixes what it wrote — the noqa agent executes the cases; a case that fails on its own wording comes back for a fix and another run.
  • Reports real defects — a failure in the app itself is handed to you with the failing step and its screenshot, and the case is left as written.
What you get back is a suite where every case has been walked once and verified once — reliable from the first release, not the second.

​
Regression before release

Once the cases exist, running them is one command. The noqa agent runs one case or the whole suite against a fresh build — on your local devices, on cloud devices, or in CI, so every release passes the same checks.

Device CLI

How the agent drives a device

Writing test cases

What a good case looks like