eduramos21

audit

Audit an automated test suite and score it against a rubric. Finds sleeps, duplication, missing assertions, tests at the wrong layer, coverage gaps against requirements, and what is slow. Use when asked to audit, review or assess a suite, when inheriting one, or when a suite is slow or flaky and nobody knows why.

Data & Documents Listed

bug-report

Write a bug report someone can act on, and file it to whatever tracker the project uses. Use when a test fails for a real reason, when exploring turns something up, or when the user says file a bug, raise a ticket, or report this.

design

Turn a refined requirement into a test design. Produces a risk scored coverage matrix saying what to check, at which layer, and what to automate, plus what is deliberately not covered and which charters to explore by hand. Use after refining a requirement, when planning test coverage, or when the user says test design, test plan, what should we test, or coverage.

explore

Run a session based exploratory test against a running app, in a real browser or on a device, and keep the session sheet. Produces findings, questions and bug drafts. Use when asked to explore, poke at, or manually test something, when a design says a condition needs a human rather than a script, or when there is no requirement to test against yet.

fix

Fix failing or flaky tests, and refactor a suite that has grown duplication. Finds the root cause rather than making the test green. Use when a test fails, when a suite has gone flaky, after a UI change broke locators, or when asked to clean up tests.

flake-triage

Work out why a test is failing or flaky before changing anything. A decision tree over the five real causes, and the rerun protocol that tells a flake from a real defect. Use when a test fails, when a test passes locally and fails in CI, when a build is red intermittently, or when someone suggests adding a retry.

generate

Write automated tests from a test design or a described behaviour, in whatever stack the project uses. Use when asked to generate, write or add tests, to automate a design, or to cover a new feature with tests.

init

Set up the QA framework in a project. Works out the stack, writes qa.config.yml, and drops in a CI file. Use when starting on a repo that has no qa.config.yml, when qa-context says no config was found, or when the user says set this up, init, or wire this in.

Data & Documents Listed

profile

Build a profile from a test suite that already exists, by reading it. Drafts profile.yaml and CONVENTIONS.md describing what the repo actually does, so generated tests match the repo instead of a generic example. Use when a project has tests but no profile fits, when generated code does not match the house style, or when the user says my repo already has tests.

qa-config

Resolve the project's QA setup, which profile is active, how to run tests, and what the code conventions are. Use at the start of any QA task, before writing a test, reading a suite, refining a requirement, or auditing anything. Also use when a QA task fails because the profile or config could not be found.

refine

Turn a requirement, user story or ticket into something testable. Produces acceptance criteria, an ambiguity list, and a risk table, and asks the questions that need a human. Use when given a ticket to test, when a story is vague, before writing any test for new work, or when the user says refine, groom, or what should this do.

test-design-techniques

Pick and apply test design techniques. Equivalence partitioning, boundary values, decision tables, state transitions, pairwise, risk scoring, and choosing which layer a check belongs in. Use when turning a requirement into test cases, deciding what to cover, judging whether a suite covers enough, or when someone asks what to test.