Testing Summary

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