# Quality Engineering Quality Assurance

> Write or review manual Zephyr 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 for test-case authoring and review; defer Jira traceability, linking, and pushing cases to Zephyr.

- Skill: `hoangnguyen0403/quality-engineering-quality-assurance` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add hoangnguyen0403/quality-engineering-quality-assurance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hoangnguyen0403/quality-engineering-quality-assurance/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: HoangNguyen0403 (https://skillmd.com/u/hoangnguyen0403)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/hoangnguyen0403/quality-engineering-quality-assurance

---

# Quality Assurance Standards

## **Priority: P1 (HIGH)**

## 1. Test Case Granularity

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

## 2. Naming Convention

- **Pattern**: `Platform_Module_Action on Screen when Condition` (e.g., `Web_Order_Verify...` or `Mobile_Order_Verify...`)
- **Rule**: Only include `Web_` or `Mobile_` prefix if requirement exclusive to one platform. Omit prefix 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

- [Detailed Examples](references/test_case_standards.md)

## Anti-Patterns

- **No Broad TCs**: `"Verify order flow works"` — too broad; every TC must cover exactly 1 condition on 1 screen
- **No Shared TCs (Divergent)**: Testing Web and Mobile behavior in single TC when behavior diverges — split into separate TCs per platform
- **No Incomplete Naming**: `Order_Verify page` — name must follow full pattern: `Module_Action on Screen when Condition`
- **No Priority Inflation**: Marking cosmetic spacing bug as High priority — reserve High for critical path blockers only

## Review wording

- Call out naming violations explicitly when a test case breaks the naming convention, then split it into separate TCs with one condition on one screen.

## Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
-  naming violations
- 1 Test Case = 1 Condition
- High: Critical path
- Low: Cosmetic
- Module_Action on Screen when Condition
- No "OR" Logic
- Split into separate TCs
- priority rationale