testing-qa

Interactive browser-based AppSec training game where players identify vulnerabilities in code and learn secure coding practices
Category: discovered
Tags: github, community
Version: 1.0.0
Author: walid
Downloads: 0
GitHub stars: 2
Updated: 2025-11-21
Source: G-Hensley/bug-hunt-vuln-detection
Download the latest version (v1.0.0) from this page.
SKILL.md

# Testing & QA Skill

## Activation Context
Activates when writing tests, discussing test strategies, or ensuring quality standards.

## When to Invoke qa-engineer Agent
- Creating test plans
- Writing test cases
- Executing QA testing
- Automated test development
- Performance testing
- Regression testing
- Test coverage analysis

## Testing Strategy

### Test Pyramid
```
        /\
       /E2E\      <- Few, expensive, slow
      /------\
     /Integr.\   <- Some, moderate cost/speed
    /----------\
   /   Unit     \ <- Many, cheap, fast
  /--------------\
```

### Test Coverage Requirements
- **Unit Tests**: 80% minimum coverage
- **Integration Tests**: All API endpoints
- **E2E Tests**: All critical user flows
- **Performance Tests**: Key operations under load

## Test Types

### Unit Tests
**Purpose**: Test individual functions/methods in isolation

**Characteristics**:
- Fast execution (< 5 minutes for full suite)
- No external dependencies (use mocks/stubs)
- Test one thing per test
- High volume (majority of tests)

**What to Test**:
- Business logic
- Utility functions
- Data transformations
- Edge cases and error conditions
- Input validation

### Integration Tests
**Purpose**: Test component interactions

**Characteristics**:
- Moderate execution time
- May use real database/services (or close replicas)
- Test multiple components together
- Moderate volume

**What to Test**:
- API endpoint responses
- Database operations
- External service integrations
- Authentication/authorization flows
- Data persistence

### E2E Tests
**Purpose**: Test complete user workflows

**Characteristics**:
- Slow execution
- Use production-like environment
- Test from user perspective
- Low volume (focus on critical paths)

**What to Test**:
- User registration/login
- Critical business workflows
- Payment flows
- Data CRUD operations
- Multi-step processes

### Performance Tests
**Purpose**: Ensure performance under load

**What to Test**:
- API response times (< 200ms target)
- Database query performance
- Page load times (< 3s)
- Concurrent user handling
- Memory usage and leaks

## Testing Patterns

### Arrange-Act-Assert (AAA)
```javascript
test('should calculate total price with tax', () => {
  // Arrange
  const items = [{ price: 10 }, { price: 20 }]
  const taxRate = 0.1

  // Act
  const total = calculateTotal(items, taxRate)

  // Assert
  expect(total).toBe(33) // 30 + 10% tax
})
```

### Test Naming Convention
```
describe('UserService', () => {
  describe('createUser', () => {
    it('should create user with valid data', () => {})
    it('should throw error when email is invalid', () => {})
    it('should hash password before saving', () => {})
  })
})
```

## Coordination Protocol

### Feature Testing Workflow
1. **Planning**: Review feature spec from product-manager
2. **Test Design**: Create test plan before implementation
3. **Development**: Work with engineer to ensure testability
4. **Execution**: Write automated tests
5. **Manual Testing**: Perform exploratory testing
6. **Reporting**: Document findings and create issues

### Handoff Points
- **From product-manager**: Feature requirements and acceptance criteria
- **From architect**: System design and integration points
- **From backend-engineer**: API contracts and endpoints
- **From frontend-engineer**: UI components and user flows
- **To code-reviewer**: Test coverage reports
- **To security-engineer**: Security test scenarios
- **To devsecopsengineer**: Test automation in CI/CD

## QA Checklist for New Features

### Functional Testing
- [ ] All acceptance criteria met
- [ ] Happy path works as expected
- [ ] Edge cases handled
- [ ] Error cases handled gracefully
- [ ] Form validation works
- [ ] Data persists correctly

### Cross-Browser/Device Testing (Frontend)
- [ ] Chrome
- [ ] Firefox
- [ ] Safari
- [ ] Edge
- [ ] Mobile browsers (iOS Safari, Chrome Android)
- [ ] Responsive design at different breakpoints

### Accessibility Testing
- [ ] Keyboard navigation works
- [ ] Screen reader compatible
- [ ] Color contrast sufficient
- [ ] ARIA labels present
- [ ] Focus indicators visible

### Performance Testing
- [ ] Page load < 3 seconds
- [ ] API response < 200ms
- [ ] No memory leaks
- [ ] Handles concurrent users

### Security Testing (with security-engineer)
- [ ] Input validation working
- [ ] XSS prevention
- [ ] CSRF protection
- [ ] Authentication required
- [ ] Authorization enforced

## Test Documentation

### Test Plan Template
```markdown
# Test Plan: [Feature Name]

## Scope
What will be tested and what won't be

## Test Strategy
- Unit tests: [areas to cover]
- Integration tests: [endpoints to test]
- E2E tests: [user flows to test]

## Test Cases
1. **TC-001**: User can login with valid credentials
   - Pre-condition: User exists in database
   - Steps: Navigate to login, enter credentials, submit
   - Expected: Redirected to dashboard

2. **TC-002**: Error shown for invalid credentials
   - Pre-condition: None
   - Steps: Navigate to login, enter invalid credentials, submit
   - Expected: Error message displayed

## Test Data
Required test data and how to set it up

## Dependencies
External services, test environments needed

## Schedule
Timeline for test execution
```

## Defect Reporting

### Bug Report Template
```markdown
**Environment**: [Dev/Staging/Production]
**Severity**: [Critical/High/Medium/Low]

**Description**:
Clear description of the issue

**Steps to Reproduce**:
1. Step 1
2. Step 2
3. Step 3

**Expected Result**:
What should happen

**Actual Result**:
What actually happens

**Screenshots/Videos**:
[Attach if applicable]

**Additional Info**:
Browser, OS, user role, etc.
```

## Best Practices
- Write tests before code (TDD when possible)
- Keep tests independent and isolated
- Use meaningful test data (not just "test123")
- Don't test implementation details
- Maintain tests like production code
- Run tests locally before pushing
- Fix broken tests immediately
- Review test coverage in PRs