Testing Summary

Overview

Generate structured testing documentation by analyzing Linear issues and git commits. Produces markdown files with test scenarios, steps, and expected results formatted for QA handover.

IMPORTANT: Focus exclusively on QA/blackbox testing. Only include user-facing functionality, UI behavior, and observable outcomes. Exclude implementation details, code verification, component names, or technical internals.

When to Use

Trigger this skill when users request:

• "Create test instructions for [Linear issue]"
• "Generate testing summary for the last commit"
• "Create QA handover documentation"
• "Write test scenarios for [feature/bug fix]"

Workflow

1. Gather Context

Collect information from multiple sources:

Linear Issue:

Use: mcp__linear-server__get_issue
Extract: title, description, implementation steps, acceptance criteria

Git Commit:

git log -1 --stat          # Get commit summary
git show HEAD              # Get full diff

Code Changes: Analyze the diff to understand:

• Which components were modified
• What functionality changed
• What edge cases might exist

2. Analyze Implementation

Map code changes to QA test scenarios (user-facing only):

• New features → Feature verification from user perspective
• Bug fixes → Regression tests for user workflows
• UI changes → Visual/interaction tests
• Form changes → Input validation and submission flows
• Data changes → Verify correct data displays to user

Exclude:

• Component names, file names, technical implementation
• Code structure verification
• Internal state management details
• API endpoints or backend logic

3. Generate Test Document

Use the template from assets/test-template.md:

Structure:

1. Summary section (issue link, commit hash, changes overview)
2. Test instructions header with:
   • Developer verification checklist
   • Environment details
   • Preconditions (data, feature flags, mock data)
3. Numbered test scenarios with:
   • Descriptive scenario title
   • Test steps (numbered list)
   • Expected results

Scenario Guidelines:

• Start with happy path scenarios
• Add edge cases based on user workflows
• Include negative test cases (error handling from user perspective)
• Cover all user-facing changes only
• Reference specific mock data when applicable
• Write from user perspective (no component/code references)
• Focus on "what user sees/does" not "how code works"

4. Fill Template Sections

Environment:

• Local dev, staging, or production
• Mock server if applicable

Preconditions:

• Required data setup
• Feature flags to enable
• Mock data created (list specific mock entities)
• User permissions needed

Test Scenarios: Minimum 3-6 scenarios covering:

1. Primary functionality (happy path)
2. Alternative flows
3. Edge cases
4. Error handling
5. Integration points
6. Regression checks

Resources

assets/test-template.md

Standard template for test documentation. Contains the exact structure expected by QA:

# {ISSUE-ID} - Testing Instructions

**Commit:** `{hash}` - {message}
**Issue:** {linear-url}

## Summary

{1-2 sentence overview of changes}

## Changes

- {bullet point list of modifications}

## Test Instructions

### Developer Verification before handover to QA:

- [ ] All scenarios tested & passed

**Environment:** {environment}

**Preconditions, data, feature flags:**

{list preconditions, mock data, feature flags}

---

### 1: {Scenario Title}

**Test steps:**

1. {step}
2. {step}

**Expected results:**

- {expected behavior}

---

### 2: {Scenario Title}

**Test steps:**

1. {step}

**Expected results:**

- {expected behavior}

Example Usage

User request:

"Create test instructions for LSTOCK-469"

Skill execution:

1. Fetch Linear issue LSTOCK-469
2. Get last commit: git log -1 --stat and git show HEAD
3. Analyze changes (renamed component, added department-specific logic)
4. Generate 6 test scenarios:
   • Email wholesaler fields visibility
   • ORDER_GW department toggle behavior
   • Mock data verification
5. Fill template with specific test steps
6. Save as LSTOCK-469-testing.md

Best Practices

• Be specific: Reference exact component names, field names, mock data entities
• Cover flows: Happy path + edge cases + error states
• Use preconditions: List all mock data, feature flags, setup steps
• Number everything: Scenarios and test steps for easy reference
• Expected results: Be explicit about what QA should see/verify