QA Tester

개요

QA Tester는 tmux 세션에서 애플리케이션의 실제 동작을 대화형으로 검증하는 에이전트입니다. 서비스 시작, 명령 전송, 출력 캡처, 기대값 대비 검증, 정리(teardown)까지 합니다.

유닛 테스트는 코드 로직을 검증하지만, QA 테스팅은 실제 동작을 검증합니다. 애플리케이션이 모든 유닛 테스트를 통과하면서도 실제 실행 시 실패할 수 있습니다. tmux를 통한 대화형 테스팅은 시작 실패, 통합 이슈, 사용자 대면 버그를 잡아냅니다.

언제 쓰는가

• 자동화된 테스트 스위트가 해당 동작을 커버하지 않을 때
• 대화형 CLI 입출력 시뮬레이션이 필요할 때
• 서비스 시작/종료 테스팅이 필요할 때
• 스트리밍/실시간 동작 검증이 필요할 때

쓰지 않을 때

• 프로젝트에 해당 기능을 커버하는 테스트가 있을 때 (테스트 실행이 더 효율적)
• 단순 명령 검증 (직접 실행이 더 효율적)
• 정적 코드 분석 (architect가 더 적합)

사용 예시

"API 서버가 정상 응답하는지 실제로 테스트해줘"
"이 CLI 도구의 대화형 기능을 검증해줘"
"서비스 시작 후 /health 엔드포인트를 확인해줘"

테스트 프로세스

1. 전제 조건 확인: tmux 설치, 포트 가용, 디렉토리 존재를 확인합니다. 미충족 시 즉시 실패합니다
2. 설정: 고유 이름(qa-{서비스}-{테스트}-{타임스탬프})으로 tmux 세션을 생성하고, 서비스를 시작하고, 준비 신호를 대기합니다
3. 실행: 테스트 명령을 전송하고, 출력을 대기하고, tmux capture-pane으로 캡처합니다
4. 검증: 캡처된 출력을 예상 패턴과 대조합니다. PASS/FAIL을 보고합니다
5. 정리: tmux 세션을 종료하고, 아티팩트를 제거합니다. 실패 시에도 반드시 정리합니다

주요 규칙

• 고유 세션 이름: qa-{서비스}-{테스트}-{타임스탬프} 형식. "test" 같은 일반 이름 금지
• 준비 상태 대기: 서비스 시작 후 바로 명령 전송 금지. 출력 패턴이나 포트 가용성 폴링
• 출력 먼저 캡처: 어서션 전에 반드시 tmux capture-pane 실행
• 항상 정리: 테스트 실패 시에도 반드시 세션 종료. 고아 프로세스 방지
• 적절한 딜레이: send-keys와 capture-pane 사이에 짧은 딜레이 필요

다른 에이전트와의 조합

• architect: Architect가 진단하고 테스트 계획을 출력하면 QA Tester가 실행합니다 (진단-검증 루프)
• debugger: 테스트 실패의 원인 분석은 debugger 몫입니다
• verifier: 자동화된 테스트 검증은 verifier에 맡깁니다

레퍼런스