홀웨이 테스트
홀웨이 테스트란 복도에서 사람을 붙잡아 제품을 사용하는 모습을 지켜보는 데서 이름을 따왔습니다. 여기서 그 사람은 구현, 스펙, 또는 코드를 생성한 대화를 보지 못한 하위 에이전트이므로 작성자가 아는 내용을 알 수 없습니다. 이 에이전트는 요구사항과 사용자 대상 문서를 읽고, 어떤 일이 일어나야 하는지 결정한 후, 실제로 시도해보고 현실이 다른 부분을 보고합니다. modama 크롤러에서는 이것만으로 오후에 실험 20개 분량의 동작을 발견했으며, 테스트 스위트가 고정해버린 결함도 포함되었습니다.
두 가지 모드가 있으며, 종종 결합하여 사용합니다:
- 행동: 테스터가 테스트 입력을 만들고, 각각에 대한 기대치를 실행 전에 작성한 후, 도구를 실행하고, 비교하고, 분류합니다.
- 육안 평가: 사람을 위한 출력의 경우, 테스터가 실제 터미널에서 도구를 구동하고 스크린샷을 평가합니다. 이렇게 하면 텍스트 파싱이 절대 발견하지 못하는 문제(출력이 스크롤되어 보이지 않음, 잡음이 신호를 압도함, 줄바꿈, 페이지가 진단 정보를 숨김)를 잡을 수 있습니다. 번들 드라이버
${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py는 가상 X 서버 아래에서 xterm을 시작하고, 키를 보내고 스크린샷을 찍습니다. 이를 위해xvfb,xterm,xdotool,imagemagick(ImageMagick의import)이 설치되어 있어야 하며, devcontainer가 이를 제공할 수 있습니다.
감사를 표하며 차용한 체크리스트: ali5ter의 MIT 라이선스 cli-ux-tester 스킬의 11가지 CLI 사용성 기준이 ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md에 있으며, 명령줄 도구에 대한 추가 패스로 사용됩니다.
시작하기 전에
사용자와 다음 사항을 확정합니다. 이것이 테스터의 브리핑이 됩니다:
- 테스터가 읽을 수 있는 것. 처음 사용자가 가질 수 있는 것만: 요구사항, 사용자 문서, 명령어 도움말. 파일이나 디렉토리 이름을 지정하고, 나머지(소스, 테스트, 스펙, 설계 노트, git 히스토리)는 명시적으로 금지합니다. 테스트의 요점은 새로운 시각입니다. 모든 추가 문서는 그 효과를 약화시킵니다.
- 도구와 실행 방법. 명령줄 또는 진입점, 테스트 입력을 생성할 위치(scratch 디렉토리, 절대 저장소가 아님), 설치 가능한 것, 건드리면 안 되는 것(읽기 전용 데이터 마운트는 읽기 전용).
- 반드시 다루어야 할 커버리지. 요구사항과 마지막 플레이 테스트의 차이점에서 도출된 테스터가 반드시 다루어야 할 케이스 목록, 그리고 '자체 실험 추가'도 포함됩니다. 육안 평가 테스트의 경우: 시나리오, 터미널 크기, 누를 키.
- 질문에 답할 사람. 테스터는 요구사항에 어떤 일이 일어나야 하는지 명시되지 않은 경우 메인 세션에 질문합니다. 메인 세션은 설계에 따라 답변하고, 자신 있게 답할 수 없었던 내용은 소유자를 위한 TODO 항목으로 기록합니다.
- 보고서 위치와 요약 길이.
브리핑
범용 하위 에이전트를 백그라운드에서 생성하고 ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md의 템플릿으로 구성된 브리핑을 제공합니다: 페르소나("처음 사용해보는 중요한 초기 사용자로서의 연구 소프트웨어 엔지니어"), 엄격한 읽기 규칙, 사용자가 받는 것과 동일한 명령 참조, 방법(생성, 실행 전 기대치 작성, 실행, 비교, 일치/버그/놀랍지만 방어 가능/차이/질문으로 분류), 필수 커버리지, 질문 지시, 보고서 구조. 육안 평가 테스트의 경우 ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md의 브리핑을 사용합니다. 이 브리핑은 드라이버를 설명하고 테스터가 스크린샷만 평가하도록 합니다.
모델: 육안 평가 테스터에게는 더 저렴한 모델로 충분합니다. 보고만 하면 되기 때문입니다. 행동 테스터는 세션의 모델을 사용하는 것이 좋습니다. 어떤 일이 일어나야 하는지 추론해야 하기 때문입니다.
실행 중
테스터의 질문에 설계 근거와 함께 답변하고, 질문이 버그를 드러냈을 때는 알려줍니다(그런 다음 정상적인 방식으로 버그를 수정하고, 테스트를 추가하고, 테스터에게 도구가 변경되었음을 알립니다). 자신 있게 답할 수 없었던 내용의 실행 목록을 유지합니다. 이 목록은 추측이 아닌 결정 사항으로 소유자에게 전달됩니다.
완료 후
- 보고서를 읽습니다. 코드에서 각 버그 주장을 확인한 후에만 수용합니다. 소스 코드에 접근할 수 없는 테스터는 증상만 설명하며, 원인은 다를 수 있습니다.
- 프로젝트가 설계 노트를 보관하는 곳(예:
design/playtest.md)에 지속적인 기록을 작성합니다: 무엇이 막혔는지, 무엇이 테스트 및 스펙 시나리오와 함께 수정되었는지, 제공된 답변, 그리고 항목별로 본인의 의견이 포함된 소유자를 위한 TODO 목록. - 각 결함에 대해 "이것을 잡을 수 있었던 것은 무엇인가"에 답하고 이를 추가합니다: 테스트, 규칙, 검사. 이 답변이 없는 결함은 반만 수정된 것입니다.
- 테스터의 트리와 스크린샷을 재현 가능하게 유지합니다: 보고서 옆이나 scratch 디렉토리에 실험을 재실행하는 작은 스크립트를 저장하고, 기록에 경로를 명시합니다.
규칙
- 테스터는 저장소를 절대 수정하지 않으며, 금지된 내용을 읽지 않으며, 보고서에 자신이 받은 내용(하네스가 요청하지 않고 첨부한 내용 포함)을 명시합니다.
- 기대치는 실행 전에 작성되어야 합니다. 그렇지 않으면 비교가 무의미합니다.
- 발견 사항은 순간입니다: 정확한 명령어, 기대한 것, 관찰된 것, 관련 stderr 줄 또는 스크린샷 파일 이름.
- 테스터가 질문으로 보고한 내용을 테스트 중에 수정하지 마십시오. 먼저 버그인지 설계 선택인지 결정한 후, 테스트와 함께 수정하십시오.