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