Skip to main content

Testing Process

This document outlines the Top Gun team's approach to feature testing using peer review.

The Process​

1. Contract Features Tracker​

When a new contract begins, create a Contract Features Tracker ticket that:

  • Lists all major features in the contract
  • Links to individual testing tickets as they're created
  • Tracks overall testing status

2. Feature Testing Tickets​

As a developer completes a feature, they create a Feature Testing Ticket that documents:

SectionPurpose
Feature OverviewWhat the feature does and why
User FlowStep-by-step intended journey
Navigation (App)How to reach the feature as a user
Navigation (Code)Key files and components
Happy PathExpected successful flow
Edge CasesUnusual but valid scenarios
Unhappy CasesDeliberate error handling
Testing ChecklistVerification checklist

3. Assignment & Review​

  1. Developer creates the testing ticket after completing the feature
  2. Team lead assigns the ticket to a developer who didn't build the feature
  3. Tester follows the documentation to test the feature
  4. Tester leaves feedback as comments on the GitHub issue
  5. Developer addresses any issues found

4. Scope Changes​

If a feature's scope changes after the testing ticket is created:

  • The original developer must update the testing ticket
  • Notify the assigned tester if testing is in progress

Roles & Responsibilities​

Feature Developer​

  • Create comprehensive testing ticket before marking feature complete
  • Document all test cases (happy path, edge cases, error states)
  • Include clear navigation instructions (both app and code)
  • Update documentation if scope changes
  • Address issues found during testing

Tester (Assigned Developer)​

  • Do an initial blind test
  • Follow the documented test cases
  • Leave detailed feedback as GitHub comments
  • Note any undocumented behaviors discovered
  • Verify fixes for issues found
  • Update the contract tracker status

Team Lead​

  • Create contract tracker tickets when starting work on a new contract
  • Assign testing tickets to appropriate developers
  • Monitor testing progress across contracts
  • Ensure testing is completed before release

Best Practices​

Writing Good Testing Tickets​

Do:

  • Be specific with steps ("Click the blue 'Submit' button" not "Submit the form")
  • Include expected results for each step
  • Document prerequisites (logged in as admin, has existing data, etc.)
  • Link to specific files in the codebase
  • List edge cases you considered during development

Don't:

  • Assume the tester knows the feature context
  • Skip documenting "obvious" behaviors
  • Forget to update when scope changes
  • Leave sections empty - mark N/A if not applicable

Providing Feedback​

When testing, leave comments that are:

  • Specific: Include steps to reproduce any issues
  • Objective: Focus on behavior, not opinions
  • Actionable: Suggest fixes if you have ideas
  • Documented: Include screenshots or recordings when helpful

Example Feedback Comment​

## Issue: Form doesn't validate email format

**Steps to reproduce:**
1. Navigate to /settings/profile
2. Enter "notanemail" in the email field
3. Click Save

**Expected:** Validation error before submission
**Actual:** Form submits, API returns 400 error

**Suggestion:** Add client-side email regex validation

**Screenshot:** [attached]

FAQ​

Q: Who creates the testing ticket? A: The developer who built the feature.

Q: When should the testing ticket be created? A: After the feature is complete but before the PR is merged, or immediately after merge.

Q: What if I find something not covered in the test cases? A: Document it in your feedback! This helps improve future testing tickets.

Q: Can the feature developer also be the tester? A: Ideally No. The point is fresh eyes catching blind spots.

Q: What if the feature is too small for a full testing ticket? A: Use your judgment. Quick bug fixes may not need one, but any major user-facing feature should be documented.

Last updated on by Zach Sedlack