quality-engineering-quality-assurance

name

quality-engineering-quality-assurance

description

Manual test case standards: enforce 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

• Detailed Examples

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