Automation Tester — QA Toolkit role playbook

Once per project

Stand up the architecture.

Define the gTAA before you write a test — the architecture decides your level split, tooling, and maintainability targets. Everything below is generated from qa.config.yml.

automation tester — setup

> /qa:automation-strategy          # 1 · gTAA architecture: level split, tooling, CI, maintainability targets
> /qa:scaffold                     # 2 · build it: Playwright+TS · K6 · Pact · axe · CI pipeline
> /qa:test-env staging             # 3 · document / provision the environment the suite runs against

The core loop

One feature, at the right level.

Let automate decide what is worth automating by ROI; build it at the lowest level that proves the behavior (API > component > E2E).

automation tester — per feature

> /qa:automate "guest checkout"        # 1 · WHAT to automate: score priority × complexity, pick by ROI
> /qa:implement "guest checkout"       # 2 · build at the right level and run
> /qa:test-data order                  # 3 · factories & fixtures so every test owns its data
> /qa:api-automate /orders             # 4 · surface deep-dives where needed:
> /qa:scan-ui https://app/checkout     #     UI → page objects → covering cases
> /qa:web-automate "checkout journey"   #     full E2E for the critical journey

Keep CI honest

The maintenance loop.

A red build is a signal, not a chore. Start build-wide with /qa:ci; drop to the targeted commands when you already know the cause.

automation tester — maintenance

> /qa:ci                          # whole red build: bucket every failure, fix + confirm, harden to green ×3
> /qa:ci x                        # …then verify the full suite locally (extended gate)
> /qa:fix-jenkins                 # Jenkins-only: pull failed cases, fix by root cause, re-run locally
> /qa:fix-ci ci.log                # a single pasted log / any other CI
> /qa:flaky-hunt                  # intermittent → deterministic fixes, not retries
> /qa:self-heal                   # UI changed → repair locators (heals HOW we locate, never WHAT we verify)
> /qa:triage "<failure>"           # the failure is a REAL product defect → escalate, leave the test red

fix-*, self-heal, and flaky-hunt fix test/env/flakiness causes only. A genuine product defect goes to triage and the test keeps asserting correct behavior. A green build you can't trust is worse than a red one.The honesty rule

Quarterly

Health-check the suite itself.

Architecture & anti-patterns

automation-audit — gTAA / SOLID / pyramid shape, scored

Coverage

coverage-measure — structural + requirements + risk

Testware quality

static-analysis — complexity & maintainability of the tests

Highest-value gaps

review-coverage — the missing tests that matter most

Where your work goes

Hand-offs.

Receives ←

Manual Tester — runs /qa:automate on their stable case CSVs.
Test Leader — priorities from the risk register.

Hands off →

Everyone — your suite is the safety net that /qa:regression, /qa:status-report, and /qa:go-no-go read from.

Cheat sheet

One line per situation.

You need to…	Run
Decide what's worth automating	`/qa:automate <cases\|feature>`
Build + run tests for a feature	`/qa:implement <feature>`
Triage a whole red build (any CI)	`/qa:ci` (`/qa:ci x` = full-suite gate)
Fix a red Jenkins build	`/qa:fix-jenkins`
Kill flaky tests	`/qa:flaky-hunt`
Repair tests after a UI change	`/qa:self-heal`
Health-check the whole suite	`/qa:automation-audit`