ホールウェイテスト は何をしますか？
名前の由来は、廊下で人を捕まえて製品を使っている様子を見ることから来ています。ここでの「人」は、実装や仕様、コードを生成した会話を見ていないサブエージェントであり、作者が知っていることを知ることはできません。このエージェントは要件とユーザー向けドキュメントを読み、何が起こるべきかを判断し、それを試し、現実が異なる箇所を報告します。modamaクローラーでは、これにより1回の午後で20の実験に相当する動作が見つかり、テストスイートが固定化していた欠陥も含まれていました。
2つのモードがあり、多くの場合組み合わせて使用します:
- 動作テスト: テスターがテスト入力を構築し、実行前にそれぞれの期待値を書き出し、ツールを実行し、比較し、分類します。
- 目視テスト: 人間向けの出力の場合、テスターは実際のターミナルでツールを操作し、スクリーンショットを評価します。これにより、テキスト解析では決して見えないもの（スクロールアウトした出力、ノイズに埋もれたシグナル、折り返し行、診断情報を隠すページャーなど）を捉えます。バンドルされているドライバー
${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.pyは、仮想Xサーバー上でxtermを起動し、キーを送信してスクリーンショットを撮影します。これにはxvfb、xterm、xdotool、imagemagick（ImageMagickのimport）がインストールされている必要があり、devcontainerで準備できます。
借りてきたチェックリスト（感謝を込めて）: MITライセンスのcli-ux-testerスキル（ali5ter作）の11のCLIユーザビリティ基準。${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md にあり、コマンドラインツール向けの追加パスとして使用します。
起動前
以下の事項をユーザーと確定します。これらがテスターのブリーフィングになります:
- テスターが読んでよいもの。初めてのユーザーが持つであろうもののみ: 要件、ユーザードキュメント、コマンドのヘルプ。ファイルやディレクトリを指定し、残り（ソース、テスト、仕様、デザインノート、git履歴）は明示的に禁止します。テストのポイントは新鮮な視点であり、余分なドキュメントはすべてそれを弱めます。
- ツールとその実行方法。コマンドラインまたはエントリポイント、テスト入力をどこに作成するか（スクラッチディレクトリ、リポジトリは不可）、何をインストールしてよいか、何に触れてはならないか（読み取り専用データマウントは読み取り専用）。
- 必須のカバレッジ。テスターがカバーしなければならないケースのリスト。要件から、前回のプレイテストのギャップから、さらに「自分で実験を追加する」を含みます。目視テストの場合: シナリオ、ターミナルサイズ、押すキー。
- 質問に答える人。テスターは、要件に何が起こるべきか書かれていない場合にメインセッションに質問します。メインセッションは設計から回答し、自信を持って答えられなかったことをTODO項目としてオーナーに記録します。
- レポートの保存場所と要約の長さ。
ブリーフィング
バックグラウンドで汎用サブエージェントを起動し、${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md のテンプレートから作成したブリーフィングを与えます。これには以下が含まれます: ペルソナ（「このツールを初めて使う、批判的な初期ユーザーとしての研究ソフトウェアエンジニア」）、厳格な読み取りルール、ユーザーが得るであろうコマンドリファレンス、方法（作成→最初に期待値を書き出す→実行→比較→一致/バグ/驚きだが妥当/ギャップ/質問に分類）、必須カバレッジ、質問する指示、レポート構造。目視テストの場合は、${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md のブリーフィングを使用します。これはドライバーを説明し、テスターがスクリーンショットのみを判断することを要求します。
モデル: 目視テストテスターにはより安価なモデルで十分です（見て報告するだけ）。動作テストテスターはセッションと同じモデルを使用すると効果的です（何が起こるべきかを推論するため）。
実行中
テスターの質問に設計から回答し、その理由を示し、質問がバグを露呈した場合はその旨を伝えます（その後、通常の方法でバグをテストとともに修正し、テスターにツールが変更されたことを伝えます）。自信を持って答えられなかったことを実行中のリストに保持します。これらは、あなたの推測ではなく、決定事項としてオーナーに渡されます。
実行後
- レポートを読みます。各バグの主張を受け入れる前に、コードに対して検証します。ソースにアクセスできないテスターは症状を説明するだけで、原因は異なる可能性があります。
- プロジェクトがデザインノートを保存する場所に永続的な記録を書きます（例:
design/playtest.md）。内容: 何が引っかかったか、テストと仕様シナリオで何が修正されたか、与えられた回答、オーナー向けのTODOリスト（各項目にあなたの考えを添えて）。 - すべての欠陥について、「何がこれを捕捉できたか」を回答し、それを追加します: テスト、ルール、チェック。その回答なしの欠陥は半分しか修正されていません。
- テスターのツリーとスクリーンショットを再現可能に保ちます。任意の実験を再実行する小さなスクリプトを、レポートの横またはスクラッチディレクトリに保存し、パスをレコードに記載します。
ルール
- テスターはリポジトリを決して変更せず、禁止されたものを決して読まず、与えられたもの（ハーネスが要求せずに添付したものも含む）をレポートに記載します。
- 期待値は実行前に書き出されます。そうでなければ比較は無意味です。
- 発見は瞬間的なものです: 正確なコマンド、期待されたこと、観察されたこと、関連するstderr行またはスクリーンショットファイル名。
- テスターが質問として報告したことをテスト中に修正しないでください。まずそれがバグなのか設計上の選択なのかを判断し、その後テストとともに修正します。