QA テストの手順はすべてスクリーンショットで残すべきか

QA の記録には2種類の読み手がいます。当日に承認するレビュー担当者と、数か月後にリグレッションを調べる担当者です。どちらも、何をどのデータでテストしたか、結果がどうだったかを確認する必要があります。すべてのクリックのスクリーンショットは必要ありません。

本記事では、手動テストの記録の構成と、スクリーンショットが証拠として有効な場面を説明します。例はすべて、Mac 上の Temposhot のワークフローです。

例では1つのテストケースを使います。TC-142 は、ステージング環境のサイトでのパスワード再設定です。テストは4つの手順からなり、チェックポイントのみの記録は5ページになります。同じテストをすべてのクリックで記録すると、11ページになりました。

テストの目的を1つに絞る

各テストケースは、1つの動作を検証します。「有効なメールのリンクでパスワードを再設定できる」は1つの目的です。「アカウント設定が動作する」はテスト計画であり、テストケースではありません。

目的は、真か偽かを判定できる文で書きます。最終のスクリーンショットで、どちらかがわかります。

2つのテストを含む目的を分ける

目的に「and」が含まれると、2つのテストが隠れていることがよくあります。「パスワードを再設定し、メールアドレスを変更できる」は、片方だけが壊れても全体が失敗扱いになり、記録からはどちらが原因か判別できません。2つのケースに分け、それぞれ ID と記録を持たせます。

狭い目的は、記録を短くすることにもつながります。TC-142 は、ユーザーが新しいパスワードでサインインできた時点で終わります。古いパスワードが使えないことの確認は、別のケース TC-143 とし、独自の開始状態を持たせます。

ユーザーの視点で目的を書く

ユーザーの視点で書いた目的は、ユーザーが画面で確認できる結果を指します。「有効なメールのリンクでパスワードを再設定できる」は、サインイン後のダッシュボード画面で終わります。「再設定エンドポイントが 200 を返す」は、ログで終わります。このような目的には、スクリーンショットの記録は適していません。

1つのケースで両方を扱う場合は、ユーザーに見える結果を目的とし、ログの行はテキストとして添付します。スクリーンショットはユーザー向けの結果を示し、テキストはその背後にあるシステムの動作を示します。

前提条件とテストデータを記録する

手順1の前に存在している必要があるものを列挙します。これにより、誰でもテストを再現できます。

項目	例
テストケース ID	TC-142
ビルドまたはバージョン	テスト対象のビルド番号
環境	ステージングの URL、macOS のバージョン、ブラウザとそのバージョン
アカウント	役割とテスト用アカウント名。実在の顧客は使用しない
テストデータ	テストで使う注文、ファイル、レコード
前提条件	フィーチャーフラグが有効、カートが空、ユーザーがサインアウト済み

テストデータには合成データを使用します。テスト記録は広く共有され、長期間保管されます。

最初のページで前提条件を示す

書面にしただけの前提条件は、後から確認できません。記録の最初のページには、開始状態を画面上に示します。たとえば、ステージング環境の URL が見えるサインアウト状態のサインインページです。レビュー担当者は、問い合わせなしで環境を確認できます。

TC-142 では、テスト用受信トレイが空であることが重要です。古い再設定メールが受信トレイに残っていると、テスト担当者が誤ったリンクを開くおそれがあります。その場合、記録にはテスト対象ではないリンクによる合格が残ります。

明らかに偽のテストデータを使う

合成データは、一見して偽物だとわかる必要があります。「QA Reset 01」のような名前や、テスト用ドメインのアドレスを使うと、後から読む人にも実在の人物が含まれないことがわかります。本物らしい氏名を使うと、記録に顧客データが含まれているのかという疑問を招きます。

明白なテストデータは、ぼかし作業も減らします。個人データを含まない記録には Blur が不要なので、無料プランで対応でき、ページ全体を覆いなしで表示できます。

期待されるチェックポイントを付けて手順を書く

各手順には操作を書きます。観測できる結果が起きるはずの手順には、期待結果も書きます。

1. サインインページを開く。Expected: 「Forgot password」リンクが表示される。
2. Forgot password を選択し、テスト用のメールアドレスを入力する。Expected: 確認メッセージが表示される。
3. テスト用受信トレイから再設定リンクを開く。Expected: 新しいパスワードのフォームが表示される。
4. 有効な新しいパスワードを入力して送信する。Expected: サインイン済みになり、ダッシュボードが表示される。

期待結果を書かない手順は準備です。期待結果を書く手順はチェックポイントであり、スクリーンショットを残すのはチェックポイントです。

期待結果を観測可能にする

「正しく動作する」は期待結果になりません。スクリーンショットでは示せないためです。期待結果には、画面上で見えるもの（メッセージの文言、項目、値、ページタイトル）を書きます。「確認メッセージ: Check your email for a reset link」は、画面の文言と1語ずつ照合できます。

画面に表示されない期待結果、たとえばメールの到着時刻は、ページの説明にテキストとして記録します。スクリーンショットは画面を示し、説明が値を示します。

手順番号を変えない

テストケースの手順番号と、記録のページタイトルの番号は一致させます。後からケースを編集して手順を挿入する場合は、番号を振り直さず、2a のような接尾辞を付けます。古い記録は正しい手順を指し続け、「手順4」でのリグレッション検索は、すべてのビルドで同じ操作を見つけます。

タイトルは Page Inspector の Page title で編集します。下書きのタイトルは、テストケース ID と手順 ID で始まるように書き直します。その後、Description に期待結果と実際の結果の行を追加します。

準備手順と確認ポイントを分ける

TC-142 には、記録に表示されない準備作業があります。テスト用受信トレイを開く、メールアドレスをコピーする、メールの到着を待つ、などです。これらを記録から外すことで、記録は5ページのままです。準備手順が失敗した場合は、欠落を隠さず、独自のページを持つ Blocked の結果として記録します。

実用的な判定基準は次のとおりです。ケースに「Expected」の行がない手順にはページを作りません。行がある手順には、ちょうど1ページを作ります。

QA テストの手順はすべて撮影すべきか

いいえ。次の場面を撮影します。

• 開始状態: 前提条件が満たされたことを示します。
• 各チェックポイント: 期待結果または想定外の結果を示します。
• 最終結果: 目的が達成されたかどうかを示します。
• 失敗したとき: 食い違いが生じた時点の画面と、その直前の手順の画面。

単純なナビゲーションのクリックのスクリーンショットは、証拠を増やさずにページだけを増やします。記録のレビューも遅くなります。

Temposhot では、チェックポイントだけを撮影できます。Action Capture（Command+3）を開き、Configure を選択して、Mouse click capture を、修飾キーを押したクリックだけを撮影する設定、またはクリックを一切撮影しない設定にします。次に、各チェックポイントで Shift+Command+2（手動撮影ショートカット）を押します。Start Action Capture を選択し、Specific Window を選んで、テストを実行します。最後に Finish capture を選択します。Document には、チェックポイントごとに1ページが開きます。

失敗したテストですべての手順が必要な場合は、Mouse click capture をすべてのクリックに戻します。記録対象となったクリックごとに、そのクリックの直前のウィンドウを保存します。撮影モードの一覧は Action Capture ガイド を参照してください。

2つの記録方式を比較する

2つの方式は、異なる問いに答えます。チェックポイントのみの記録は、「各チェックポイントで期待どおりの結果が表示されたか」に答えます。すべてのクリックの記録は、「テスト担当者が正確に何をしたか」に答えます。後者は、失敗したときに最も重要です。

無料プランでは、Action Capture の1回の実行につき手順は5件までです。チェックポイントのみの TC-142 の記録は、開始状態と4つのチェックポイントの計5件で、無料プランの1回の実行にちょうど収まります。すべてのクリックの実行は、5手順の後で一時停止し、それまでの手順は保持されます。Temposhot Pro では上限がありません。

チェックポイントのみの実行を設定する

Configure Action Capture の設定は Mac に保存されるため、次のテストセッションでもチェックポイントの設定が残ります。チュートリアルやバグ報告を録画する前に、元に戻します。

Mark clicked area は、手動ショートカットで追加した手順にも適用されます。チェックポイントの記録では、マーカーはポインタが止まっていた位置を指すため、レビュー担当者を誤らせるおそれがあります。そのため、オフのままにします。

ショートカットで TC-142 を実行する

1. 開始状態を撮影する

   カウントダウンの後、サインアウト状態のサインインページで Shift+Command+2 を押します。これがページ1になります。

2. 各チェックポイントを撮影する

   各手順を実行します。期待結果が画面に表示されるべきときに、ショートカットを再び押します。ページ2から5が4つのチェックポイントです。

3. 終了する

   Command+. を押すか、Finish capture を選択します。Document には5ページが開きます。

すぐに消える確認ポイント

フォーム送信後のトーストメッセージのように、数秒しか表示されない結果があります。メッセージが表示されたら、すぐにショートカットを押します。ショートカットを押す前にメッセージが消えた場合は、その手順を繰り返し、指をキーの上に置いたままにします。

撮影が間に合わないほど短い結果は、説明に書き、その後に続く画面を撮影します。たとえば「Expected: トースト「Password updated」。Actual: トーストを確認。約3秒後に閉じ、ダッシュボードが表示」のように書きます。レビュー担当者は、トーストが確認されたこと、そしてページに写っていない理由を把握できます。

ウィンドウをまたぐテスト

TC-142 は、ブラウザからテスト用受信トレイへ移動し、ブラウザに戻ります。受信トレイが別のブラウザウィンドウで開くと、Specific Window の対象は最初のウィンドウだけを撮影し続けます。複数のウィンドウを使うテストでは Full Screen を選び、実行前にテストに関係のないものをすべて閉じます。

チェックポイントが失敗したら撮影モードを切り替える

手順4が失敗した場合、チェックポイントの記録には結果は示されますが、正確な入力は残りません。すべてのクリックのモードでテストを再度実行し、失敗までの経路を記録します。2回目の実行はバグ報告に添付し、1回目の記録はテスト結果として残します。

元の記録を書き換えずに実際の結果を記録する

記録には、起きるべきだったことではなく、実際に起きたことを示します。Document エディタでは、次のように操作します。

• 各ページのタイトルに、手順 ID と操作を書きます。例: 「TC-142 手順4: 新しいパスワードを送信」
• Page description に、期待結果と実際の結果を別々の行に書きます。
• 失敗したチェックポイントでは、誤った値の周囲に Rectangle（R）を描き、Text（T）のラベルで「Fail」と書きます。

レビュー担当者が必要とする文脈は切り取りません。URL やビルドラベルがこれに当たります。Framing は、関係のないウィンドウを取り除く場合にのみ使います。個人データは Blur（B、Pro）でぼかします。結果を正しく見せるために値を編集することはしません。

証拠のための注釈ルール

Temposhot の注釈は非破壊です。矩形やラベルの下にあるスクリーンショットは変更されません。これにより証拠は保たれますが、書き出した PDF の読み手には描画後のページしか見えません。注釈でできることとできないことのルールを定めると、書き出しの信頼性が保たれます。

説明を固定の形式で書く

2行の固定形式にすると、5ページでも50ページでも説明を読み比べやすくなります。1行目は「Expected:」で期待結果を書きます。2行目は「Actual:」で、スクリーンショットに写っている内容を書きます。

TC-142 のページ5の説明は、「Expected: サインイン済みで、ダッシュボードが表示される。Actual: 「Reset link expired」というバナーが表示され、サインインフォームが表示される。」となります。レビュー担当者は、Actual の行をスクリーンショットと一目で照合できます。

この QA 実行記録の構成を使う

• テストケース ID、目的、ビルド、環境、テスター、日付
• 前提条件とテストデータ
• 期待結果付きの手順
• 開始、チェックポイント、終了、失敗時のスクリーンショット
• チェックポイントごとの実際の結果
• ステータス: Pass、Fail、Blocked のいずれか
• 失敗ごとに紐づけたバグ報告

テスト管理ツールに添付するには、Document から Export PDF で書き出します。インラインの証拠として使うには、More export formats から PNG ページを書き出します。ファイル名はケース ID とビルドで付けます。例: TC-142_build-2026-08-27.pdf。形式の一覧は 書き出しガイド を参照してください。異なるビルドで同じ画面の2枚のスクリーンショットを比較するには、ブラウザツール Compare Images が差分をローカルでハイライトします。

テスト記録の PDF 設定

Export PDF の既定設定は、ほとんどの記録に適しています。A4、横向き、表紙あり、手順番号とページ番号を表示、説明は画像より前に配置、という設定です。表紙には文書タイトルと手順数が表示されるため、「TC-142 build 2026-08-27 Fail」のようなタイトルにすると、結果が1ページ目に示されます。PDF 設定のカスタマイズには Temposhot Pro が必要です。

Pro を使い、米国の用紙に印刷するチームは、Paper size を Letter に切り替えます。Image quality を Small file に設定すると、添付サイズに上限があるツールでも、50ページのリグレッション記録を小さく保てます。

証拠からステータスを設定する

ステータスごとに必要な証拠は異なります。対応するページがないステータスを見たレビュー担当者は、記録を差し戻します。

ケースとビルドごとに記録を整理する

記録は、日付だけでなく、ケース ID とビルドで検索されることがほとんどです。ケースごとに1つのフォルダ、ビルドごとに1つのサブフォルダを作ると、リグレッション検索で同じケースをビルド間で比較できます。

Document の画像ファイルは、ページタイトルから名前が付けられます。手順 ID で始まるタイトルにすると、ファイル名は手順順に並び、ビルド間でも一致します。

チェックポイントをビルド間で比較する

TC-142 が 2026-08-27 のビルドで失敗し、2026-09-03 のビルドで合格した場合は、両方の手順4の PNG ファイルを Compare Images で開きます。スライダーまたはピクセル差分の表示で、バナーだけが変わったのか、レイアウトも動いたのかを確認できます。失敗した記録はリグレッションの証拠として残します。

証拠をレビューして承認する

レビュー担当者は、テストを実行せずに3点を確認します。前提条件が満たされたこと、各チェックポイントが記載された結果を示していること、最終ステータスがスクリーンショットと一致していることです。レビュー担当者が推測しなければならない場合、記録には確認ポイントがもう1つ必要です。

Temposhot は Document をローカルに保存し、承認のワークフローは提供しません。承認を管理しているテスト管理ツールまたはチケットに、書き出したファイルを添付します。

レビュー担当者の確認手順

5ページの記録は、決まった順序で読めば数分で確認できます。最初に、表紙のタイトルと1ページ目を前提条件と比較します。ビルド、URL、サインアウト状態です。次に、各チェックポイントのページを読み、「Actual」の行をスクリーンショットと比較します。

3番目に、表紙のステータスがページと一致するかを確認します。5ページ目に赤いエラーバナーがあるのに Pass と記録されている場合、記録はテスターに差し戻されます。Fail と記録されているのに紐づいたバグ報告がない場合も、差し戻されます。

Blocked は Fail ではない

テストが、テスト対象の動作とは別の理由でチェックポイントに到達できない場合、ステータスは Blocked です。TC-142 では、ステージングの障害により再設定メールが届かず、手順3がブロックされます。記録には開始状態と、到達できた最後の画面を示し、理由を説明に書きます。

Blocked のテストを Fail とすると、失敗率が実際より悪く見え、バグが誤ったチームに届きます。Pass とすると、欠落が隠れます。Blocked は独立したステータスとして残し、ブロックが解消されたらケースを再実行します。

失敗したチェックポイントから再テストまで

失敗は、決まった経路をたどります。元の記録は、どの段階でも変更されません。

テストセッションのキー操作

1回のセッションで10件から20件のケースを実行するテスターは、キーボードから手を離さないと効率的に作業できます。以下のキーは、記録と最初の編集作業を対象とします。

Mac 上の記録の保持

Document は、記録した Mac に保存されます。セッションの元データは、保持上限まで Capture History に残ります。既定の上限は30セッションで、Settings > History で1から500まで変更できます。テストが集中する時期は、数日で30セッションを超えることがあるため、ケースが完了したら各記録をテスト管理ツールに書き出します。

よくある質問

スクリーンショットはテストの証拠として十分ですか

手動の UI テストでは、スクリーンショットが中核となる証拠です。画面に表示されない不具合では、ログ、コンソール出力、ネットワークデータをテキストとして追加します。スクリーンショットの証拠を参照してください。

自動テストでもスクリーンショットを取るべきですか

自動テストスイートは、通常、失敗時にスクリーンショットを取得します。ビルド間でスクリーンショットを自動比較する方法は、ビジュアルリグレッションテストを参照してください。

QA で見つけた不具合はどのように報告しますか

テストケースに紐づけた、独立したバグ報告を作成します。手順ごとのスクリーンショットで不具合を記録する方法を参照してください。

テスト記録は何ページにすべきですか

開始状態に1ページ、チェックポイントごとに1ページ、失敗ごとに1ページです。TC-142 には4つのチェックポイントがあるため、合格した記録は5ページになります。

チェックポイントのページにポインタを表示できますか

表示できます。Configure Action Capture で Show cursor in shortcut captures をオンにします。ポインタの位置が結果に関係しない場合は、オフのままにします。

クリックを明確な手順ガイドに変える

Action Capture は、実行に応じて、ショートカットまたはすべてのクリックでチェックポイントを記録します。Temposhot をダウンロードし、次のテスト記録を順序付きの PDF として添付します。