qa-testing-feature

QA Testing Feature

Performs end-to-end QA testing of the feature in the current branch by reading all related documentation, creating a comprehensive test plan, and executing automated tests to find issues.

Be fully autonomous — Do NOT stop or pause to ask for confirmation. Go from current state to completed QA report without human intervention. Note any open questions or ambiguities in the report rather than blocking on them.

Context

• Repository: streamlit/streamlit
• Main branch: develop
• Head branch: !git branch --show-current

Workflow

First, determine the QA output directory based on the branch name:

# Derive feature name from branch (strip prefix before "/" if present)
# Falls back to short commit hash in detached-HEAD environments (e.g., CI)
FEATURE_NAME=$(git branch --show-current | sed 's|.*/||')
FEATURE_NAME=${FEATURE_NAME:-$(git rev-parse --short HEAD)}
QA_DIR="work-tmp/qa-${FEATURE_NAME}"
mkdir -p "$QA_DIR"

Use $QA_DIR for all output files throughout this workflow. This allows multiple QA runs for different features to coexist.

- [ ] Phase 1: Gather feature context
- [ ] Phase 2: Create QA test plan
- [ ] Phase 3: Set up debug environment
- [ ] Phase 4: Execute test plan
- [ ] Phase 5: Generate QA report

Phase 1: Gather feature context

Collect all documentation related to the feature being tested:

1. Identify the feature from branch changes:

   # Determine the base branch (from PR if exists, otherwise develop)
   BASE_BRANCH=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || echo "develop")
   git fetch origin "$BASE_BRANCH" 2>/dev/null || true
   git diff "origin/${BASE_BRANCH}" --stat
   git log "origin/${BASE_BRANCH}..HEAD" --oneline
   

2. Read spec documents (if available):

   • Check specs/ directory for related specs
   • Check work-tmp/ for implementation notes
   • Read any linked GitHub issues from commit messages

3. Check the agent-wiki for related documents:

   • If a PR exists for this branch, look in agent-wiki/pull-requests/<pr-number>/ for implementation plans, exploration notes, or design decisions
   • Use gh pr view --json number -q .number 2>/dev/null to get the PR number (may not exist yet if running before PR creation)
   • Look in agent-wiki/references/ for relevant reference documents
   • If no PR exists, skip PR-specific lookups and note this in the test plan
   • These documents may contain context, design rationale, and edge cases discovered during implementation