home / skills / vadimcomanescu / codex-skills / senior-qa

This skill helps you design risk-based QA plans, optimize test layer choices, and triage flaky tests to ensure reliable releases.

npx playbooks add skill vadimcomanescu/codex-skills --skill senior-qa

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
950 B
---
name: senior-qa
description: "QA workflow for building test strategies and validating releases: risk-based testing, test pyramid decisions, E2E/integration/unit coverage, exploratory testing, and regression planning. Use when creating test plans, reviewing test coverage, triaging flaky tests, or preparing release sign-off criteria."
---

# Senior QA

Optimize for confidence per unit effort.

## Quick Start
1) Identify the risky user journeys (money, auth, data loss, critical flows).
2) Choose the right test layer:
   - unit for logic, integration for boundaries, E2E for key paths
3) Define a release test plan:
   - must-pass automated tests + focused manual checklist
4) Treat flakiness as a product bug: root-cause it and fix it.

## Optional tool: scaffold a test plan doc
```bash
python ~/.codex/skills/senior-qa/scripts/scaffold_test_plan.py . --out docs/qa --force
```

## References
- Test plan template: `references/test-plan.md`

Overview

This skill codifies a senior QA workflow to maximize confidence per unit effort when planning and validating releases. It guides risk-based testing, layer selection (unit/integration/E2E), exploratory testing, and regression planning. Use it to create focused test plans, reduce flakiness, and define clear release sign-off criteria.

How this skill works

The skill inspects product risk areas and recommends test layer decisions: unit tests for logic, integration tests for boundaries, and E2E for critical user journeys. It helps produce a release test plan that separates must-pass automated checks from targeted manual checks and includes strategies for exploratory testing and regression scope. It also surfaces flaky-test triage steps, treating recurrent flakiness as actionable product debt.

When to use it

  • Creating a release test plan for feature launches or patches
  • Reviewing test coverage to balance unit, integration, and E2E effort
  • Triaging flaky or intermittent tests before a release
  • Defining minimal must-pass criteria for release sign-off
  • Prioritizing tests based on user-impact and business risk

Best practices

  • Focus automated coverage on fast, deterministic tests and reserve E2E for critical paths
  • Identify and document the riskiest user journeys early (payments, auth, data loss)
  • Pair a small must-pass automated suite with a concise exploratory/manual checklist
  • Treat flakiness as a product issue: trace root cause, fix or quarantine, and add prevention
  • Use risk and effort trade-offs to decide what to automate vs. test manually

Example use cases

  • Scaffold a release test plan that lists must-pass automated tests and a manual testing checklist
  • Evaluate current test pyramid and recommend shifting tests to more appropriate layers
  • Triage recurring flakiness by classifying root causes and proposing remediations
  • Plan regression scope for a patch: decide which E2E paths must run and which can be sampled
  • Define sign-off criteria that map business risk to test requirements

FAQ

How do I pick which journeys are 'risky'?

Prioritize flows that impact revenue, account access, data integrity, or core user retention. Use usage metrics and business impact to rank them.

When should I add a new E2E test?

Add an E2E when a journey cannot be reliably validated by unit or integration tests and its failure has high user or business impact.

What if tests keep flaking after fixes?

Quarantine the test to avoid noise, add instrumentation to capture failure context, and track flakiness as technical debt until root cause is eliminated.