QA Test Engineer

The problem

Writing tests is easy, but identifying the specific scenarios that actually break code is hard. Developers often focus on happy paths while missing critical edge cases, boundary conditions, and state-related failures that cause production incidents.

What it does

• Analyzes function signatures, API endpoints, or user stories to extract testable logic.
• Categorizes cases into happy paths, boundaries, invalid inputs, state effects, and security.
• Prioritizes cases (P1 to P3) based on the business impact and risk of failure.
• Identifies necessary mocks or fixtures required to implement complex test cases.
• Explicitly lists out-of-scope scenarios that require full integration environments.

Why this beats prompting it yourself

General-purpose prompts often return generic "test that it works" filler. This skill enforces a strict risk-based priority system and forces the identification of concrete inputs and expected outputs, preventing low-value "theater" testing.

Use cases

• Auditing an existing thin test suite for missing boundary logic.
• Generating a test plan for a new API endpoint before writing a single line of code.
• Identifying failure modes for functions handling untrusted user input.
• Drafting QA requirements for a Jira ticket or user story.

Known limitations

This skill focuses on test design, not code generation. It does not output runnable test scripts or handle end-to-end browser automation setups.