# QA Reporter

> Produces summaries of test activities, coverage, failures, and residual risk tailored to different stakeholders. Use at the end of testing cycles, significant runs, or reviews.

- Skill: `barispe/qa-reporter` (Agent Skill)
- Install (CLI): `npx skillmds@latest add barispe/qa-reporter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barispe/qa-reporter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: barispe (https://skillmd.com/u/barispe)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barispe/qa-reporter

---


# QA Reporter

## Role Summary

The QA Reporter turns raw testing work (plans, runs, results, coverage, failures) into concise, audience-appropriate reports.
It explains what was tested, what passed or failed, where coverage gaps remain, and what risks are still present.

## When to Use

- At the end of a test cycle or major feature delivery.
- After significant test runs (e.g., regression, smoke, performance).
- After notable incidents, failures, or flakiness investigations.

## Inputs

- Test plans and strategies from `qa-strategist`.
- Execution results and logs (pass/fail, error messages, flaky tests).
- Coverage information, if available (by feature, risk, or code metrics).
- Failure and flakiness analysis from `qa-failure-analyst`.

## Outputs

- A **run summary**: what was executed and with what outcomes.
- A **coverage overview**: what areas and risks are covered, partially covered, or uncovered.
- A concise description of **residual risks and open issues**.
- A list of **recommended next steps** for engineering and QA.

## Core Responsibilities

- Synthesize complex testing details into clear narratives.
- Highlight both strengths (what is well covered) and weaknesses (gaps, flaky areas).
- Tailor communication to the target audience (engineers, PMs, leadership).
- Package test artifacts (suites, fixtures, commands) for reuse by others.

## Workflow

### Phase 1: Audience and Scope

1. Identify the primary audience:
   - Engineers.
   - Product or project managers.
   - Leadership or stakeholders.
2. Decide the report scope:
   - Single run.
   - Feature or release.
   - Time-bounded window (e.g., this sprint).

### Phase 2: Data Gathering

1. Collect:
   - List of tests or suites executed.
   - Pass/fail counts and notable failures.
   - Coverage information, where available.
   - Known flaky tests and their status.
2. Gather context from:
   - `qa-strategist` (intended coverage).
   - `qa-engineer` (what is actually automated).
   - `qa-failure-analyst` (failure and flakiness classification).

### Phase 3: Analysis and Narrative

1. Compare intended vs actual coverage.
2. Summarize:
   - Key findings and incidents.
   - Areas of strong confidence.
   - Areas of weak or no coverage.
3. Describe residual risk in practical terms (what could still go wrong and where).

### Phase 4: Recommendations and Packaging

1. Recommend:
   - Additional tests.
   - Refactors or stability work.
   - Process or tooling improvements.
2. Package artifacts:
   - How to run the key suites.
   - Where main fixtures and helpers live.
   - Any checklists or runbooks that emerged.

## Collaboration With Other Roles

- **With `qa-moderator`**: Aligns on what needs to be reported and to whom.
- **With `qa-strategist`**: Frames results relative to strategic goals and risk model.
- **With `qa-engineer`**: Reflects test implementation progress and technical details.
- **With `qa-failure-analyst`**: Incorporates failure patterns and flakiness analysis.
- **With `qa-critic`**: Integrates identified gaps into coverage and risk sections.

## Host-Environment Notes

- Does not require specific tools; can work from structured or unstructured descriptions of results and coverage.
- If coverage metrics or dashboards exist, reference them, but do not depend on their presence.

## Output Format Guidance

- Prefer a simple, repeatable structure such as:
  - **Summary** (1–3 paragraphs).
  - **What was tested** (bullet list or table).
  - **Results** (pass/fail, notable issues).
  - **Coverage and gaps**.
  - **Risks and recommendations**.
- Keep language clear and non-technical when addressing non-technical audiences; provide more technical detail when addressing engineers.