Agent-Skills.md

Agent Skills: Quality Assurance Standards

Write manual test cases with 1-condition-per-TC granularity, Module_Action on Screen when Condition naming, platform prefix rules, and High/Normal/Low priority classification. Use when writing or reviewing manual test cases for Zephyr — to split compound TCs, fix naming violations, assign correct platform tags, or determine bug priority. (triggers: test case, manual test, zephyr, test scenario, naming convention, acceptance criteria)

UncategorizedID: hoangnguyen0403/agent-skills-standard/quality-engineering-quality-assurance

Repository

hoangnguyen0403/agent-skills-standard
HoangNguyen0403License: Apache-2.0
362103

Install this agent skill to your local

pnpm dlx add-skill https://github.com/HoangNguyen0403/agent-skills-standard/tree/HEAD/skills/quality-engineering/quality-engineering-quality-assurance

Skill Files

Browse the full folder contents for quality-engineering-quality-assurance.

Download Skill

Loading file tree…

skills/quality-engineering/quality-engineering-quality-assurance/SKILL.md

Skill Metadata

Name
quality-engineering-quality-assurance
Description
"Write manual test cases with 1-condition-per-TC granularity, Module_Action on Screen when Condition naming, platform prefix rules, and High/Normal/Low priority classification. Use when writing or reviewing manual test cases for Zephyr — to split compound TCs, fix naming violations, assign correct platform tags, or determine bug priority. (triggers: test case, manual test, zephyr, test scenario, naming convention, acceptance criteria)"

Quality Assurance Standards

Priority: P1 (HIGH)

1. Test Case Granularity

  • 1 Test Case = 1 Condition on 1 Screen.
    • Split Screens: "Order Details" & "Item Details" are separate.
    • Split Conditions: "Config A" & "Config B" are separate.
  • No "OR" Logic: Each TC must test a single, distinct path.

2. Naming Convention

  • Pattern: ([Platform]) [Module]_[Action] on [Screen] when [Condition]
  • Rule: Only include [Platform] if requirement is exclusive to one platform (e.g., [Mobile]). Omit if it supports Both.
  • Example: Order_Verify payment term on Item Details when Toggle is OFF (Supports Both)

3. Priority Levels

Use priority rationale to justify each classification:

  • High: Critical path, blocker bug.
  • Normal: Standard validation, edge case.
  • Low: Cosmetic, minor improvement.

4. References

Anti-Patterns

  • ❌ "Verify order flow works" — too broad; every TC must cover exactly 1 condition on 1 screen
  • ❌ Testing Web and Mobile behavior in a single TC when behavior diverges — split into separate TCs per platform
  • ❌ Order_Verify page — name must follow the full pattern: Module_Action on Screen when Condition
  • ❌ Marking a cosmetic spacing bug as High priority — reserve High for critical path blockers only