Skip to content
PWR

PWR QA

Measured coverage, tests-only changes

PWR QA plans tests, writes them, and runs Test Coverage Autopilot: analyze the repository, measure a baseline, propose a ranked plan, then add tests through reviewed pull requests. Coverage numbers come from parsed reports or they are not shown.

Request early access

QA leads, SDETs and engineering teams that want to raise test coverage without letting an agent touch production code.

How it works

PWR QA, step by step

  1. 01

    Analyze

    Autopilot reads the repository: languages, test frameworks, existing tests, CI configuration and a module map with heuristic risk signals.

  2. 02

    Measure a baseline

    A worker job runs your stack's coverage command in a sandbox and parses the report. If the runner is missing or the command fails, the baseline is reported as unavailable with the reason.

  3. 03

    Approve a plan

    You get a ranked list of test tasks, each scoped to test files only, with a credit estimate. You choose which to approve and set the budget.

  4. 04

    Review the pull requests

    Each approved task produces its own pull request through the normal workflow. Coverage is measured again on each branch and reported next to the baseline.

Available
Implemented and covered by automated tests in the current platform build.
Beta
Implemented; verification against the live external service is still pending.
Upcoming
Planned or in progress. Not usable yet.

Test planning and generation

  • QA role with a tests-first policy

    Available

    The QA role can write, edit and run tests. Modifying production code is declared as an approval gate for the role.

  • Create a Test Plan

    Beta

    A conversation that returns a risk matrix, test cases, coverage targets and quality notes for a connected repository.

    Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.

  • Generate Unit Tests

    Beta

    A task scoped to tests only. It follows the same branch, validation and pull request path as any implementation task.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Regression test first for bug fixes

    Available

    The Fix a Bug workflow adds a fixed acceptance criterion requiring a regression test before the fix.

    This is an acceptance criterion given to the agent and visible to reviewers; it is not machine-enforced.

Test Coverage Autopilot

Autopilot separates what is measured from what is estimated, and labels each.

  • Repository analysis

    Available

    Detects languages, frameworks, test frameworks, existing tests and coverage tooling. Risk ranking uses labelled heuristics such as file size, dependents and security-sensitive names.

    Analysis of a GitHub repository starts from a capped sample and is completed by the worker's full checkout.

  • Baseline measurement for Python

    Available

    Runs pytest with coverage in the sandbox and parses line and branch coverage from the report.

    Verified with a real pytest coverage run. Repository checkout has only been verified against a simulated GitHub.

  • Baseline measurement for Node and .NET

    Beta

    Coverage commands and report parsers for Jest, Vitest, Mocha with c8, and .NET test projects with Coverlet.

    Report parsers are tested on sample reports; the toolchains themselves have not been run end to end.

  • Ranked plan with approval

    Available

    A deterministic ranking by risk, missing coverage and size produces one task per under-covered file. A model can reorder or drop tasks but cannot widen a scope or add numbers.

    The optional model refinement step is tested with fabricated replies and has not been exercised against a live model.

  • Tests-only guard

    Beta

    Before any push, a guard blocks changes to production files, deleted tests, weakened assertions, added coverage-ignore markers and edits to coverage configuration.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

  • Coverage measured after the change

    Beta

    Each task branch is measured at its head and compared with the baseline. A combined figure is measured on the default branch after merges, never added up from branches.

    Verified end to end against a simulated GitHub; verification against live GitHub is pending.

QA Center and what is next

  • QA Center dashboard

    Available

    Shows the latest run, baseline, plan, per-task pull requests, credits consumed and remaining high-risk gaps. An unavailable baseline is shown as not measurable, with the reason.

  • Mutation testing for Python

    Beta

    An optional, time-capped mutation run on the Python scope. Output is recorded as the tool produced it. No score is derived.

    Off by default and runs only when the mutation tool is present in the sandbox.

  • Coverage thresholds on pull requests

    Upcoming

    A per-project policy that compares measured coverage on a pull request with a threshold, then notifies and drafts a tests-only task. It never merges, approves or blocks.

  • Go coverage measurement

    Upcoming

    Go projects are detected, but coverage profiles are not parsed yet.

  • Coverage inside Unity and Godot

    Upcoming

    Engine test frameworks are detected as a limitation. Running them needs an engine worker.

Questions

Will PWR QA ever show an estimated coverage number?

No. A percentage appears only when it was parsed from a report the coverage command wrote in that run. Otherwise the value is empty and the reason is shown.

Can Autopilot change production code to make it testable?

No. Approved tasks carry a scope that forbids production changes, and a guard checks the diff before the push. A violation stops the push and nothing leaves the worker.

Can the guard be fooled?

Partly. Assertion weakening is detected by counting assertion lines in the diff. A rewrite that keeps the count but loosens the checks passes the guard. The independent review and the human approver still see the full diff.

Which languages can it measure today?

Python with pytest is verified end to end. Node and .NET have commands and report parsers in beta. Go is detected but not yet measured. Game engine test suites are not run.

Does higher coverage mean better tests?

Not on its own. Coverage shows which lines ran, not whether the assertions are meaningful. That is why the QA deliverable keeps quality notes separate from coverage targets and why every test change is reviewed.

Read the docs

Related

Put an AI development team on your idea.

Describe what you want to build. PWR plans, builds, tests and reviews it, and you approve each step that matters.

Request early accessSee how PWR works