sumo-qa-finding-test-data

Retrieve and validate known-good test data from a shared catalogue.

5|1|Updated May 12, 2026
One-click install
npx skills add https://github.com/sumithr/sumo-qa --skill sumo-qa-finding-test-data
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sumo-qa-finding-test-data
Source: https://github.com/sumithr/sumo-qa/tree/main/skills/sumo-qa-finding-test-data
Command: npx skills add https://github.com/sumithr/sumo-qa --skill sumo-qa-finding-test-data

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you locate the exact test data you need while ensuring every record is validated fresh against the source system, preventing stale or invented fixtures.

Core Features & Use Cases

  • Explain data requirements: Determine what specific test data must exist for a scenario (e.g., which account state or boundary value).
  • Find known-good records: Retrieve candidate entries from the shared catalogue for a requested need.
  • Validate before using: Re-validate the returned record against the source in the same turn and surface timestamped freshness evidence; for registration, confirm with the user before writing side effects.
  • Register new known-good data: Save a newly verified entry as known-good only after user confirmation, including validation evidence and structured entry fields.

Quick Start

Tell your agent: "Find a known-good pending invoice for the due-date boundary test and validate it against staging right now."

Frequently Asked Questions about sumo-qa-finding-test-data

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find validated test data for boundary-value testing in staging?

To find validated test data, you can retrieve candidate entries from a shared catalogue and re-validate them against the staging source system in the same turn. This provides timestamped freshness evidence to ensure records are reliable for boundary-value tests.

What is the best way to prevent stale fixtures from breaking automated QA workflows?

Preventing stale fixtures requires strict freshness validation against the source system before using the data. Re-validating known-good records in the same turn ensures your fixtures have not degraded and prevents invented entries from corrupting QA workflows.

How do I register new fixture management entries without causing unintended side effects?

To register new fixture management entries safely, you must confirm with the user before writing any side effects. The system enforces registration confirmation, saving structured entry fields and validation evidence only after explicit approval.

Can I retrieve test data for specific account states if the record is not in the catalogue?

No, you cannot retrieve test data if the record is not in the catalogue. The system strictly forbids inventing entries that do not exist, ensuring all returned account states or boundary-value data are known-good and verified.

Does TDD validation require source-system freshness evidence for every test data lookup?

Yes, TDD validation requires source-system freshness evidence for every lookup. The system mandates strict freshness validation in the same turn, surfacing timestamped evidence so you know the test data is currently valid.