mcpField
Q
qa-split-testing-levels-pyramid

qa-split-testing-levels-pyramid

github.com/testomatioTesting & quality1678 installsUpdated 6d ago
Repository

About qa-split-testing-levels-pyramid

QA Split Testing Levels — Test Pyramid is a testing skill that assigns feature scenarios to the cheapest testing level capable of catching each failure. It inventories a project's existing tests and recommends coverage by layer and test kind.

Key features

  1. 01Inventory existing tests and testing layers
  2. 02Assign scenarios to the lowest suitable layer
  3. 03Recommend coverage by layer and test kind
  4. 04Explain why scenarios require higher-level tests
  5. 05Provide manual verification steps when needed

Use cases

  1. 01Plan tests for a feature from risk scenarios
  2. 02Avoid manual checks for cases covered by automation
  3. 03Decide whether a scenario belongs in API, web, or mobile e2e tests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/testomatio/skills --skill qa-split-testing-levels-pyramid

After installing, type/qa-split-testing-levels-pyramidin Claude Code to confirm it loaded.

Details

From the project README

QA Split Testing Levels — Test Pyramid

Applies the testing pyramid to a feature: each scenario goes to the cheapest level that can still catch its failure. Input: a feature description, or risk scenarios from a prior QA analysis.

Testing levels

Default layers, bottom to top:

  • unit + integration
  • e2e
  • manual

A layer can hold several kinds of tests with separate runners: e2e api / e2e web / e2e mobile. Other testing layers a project may have instead: component, functional, contract, visual. Take the testing layers and kinds from the project; use the default only when the scan finds nothing.

Workflow

  1. Inventory existing tests with the scan-automation-project skill.
  2. Detect the project's testing layers and the kinds of tests inside them.
  3. Assign each scenario to the lowest layer that catches its failure, and to a kind within it.
  4. Recommend a coverage split per layer and kind.

Rules

  • Do not recommend manual verification for scenarios already covered by automated tests.
  • Explain why a scenario cannot sit at a lower layer when assigning it upward.
  • A kind never covers another kind of the same layer: e2e web does not cover e2e api.
  • Generalize existing automated scenarios; expand only when the user asks.

Output

  • Section 📐 Testing levels: the layers and kinds used, when they differ from the default.
  • Section ☑️ What is already tested: number and scope of existing tests per layer and kind.
  • Section 🧪 Testing plan: scenario → layer and kind (e2e / api), with reasoning.
  • When the environment can render charts, add a pie chart or test pyramid: test count and share per layer and kind. Skip the diagram in plain terminal output.
  • For manual items: how to verify (action → expected result).

Next actions

Offer after the plan:

  • Write manual test cases or a checklist → qa-write-test-cases skill.
  • Automate manual cases into autotests → automate-manual-test-cases skill.
  • Map tests to source files for change-aware runs → qa-test-code-coverage skill.

Comments

Markdown supported