テスト対象の知識の習得

1.マニュアル、機能仕様書、テスト仕様書、テスト計画書などからテスト対象の仕様や操作方法、テストの実行範囲を確認する

【学習のポイント】
テスト対象の知識を得るための情報にはどのようなものがあるかを理解する

【解説】
テスト対象の情報を得るための情報には以下のようなものが挙げられる。

　・製品マニュアル

　・機能仕様書

　・テスト仕様書（テスト詳細設計書、テストケース、テスト手順書などのドキュメント）

　・テスト対象の旧バージョン、プロトタイプなど実際に動作可能な参考情報

　・テスト計画書

上記から得られる情報として、テスト対象の全体概要、機能、画面デザイン、画面遷移、操作手順な
どが挙げられる。

テスト中に不明点が発生した場合など速やかに確認することができるよう、どのような情報がどこに記載されているかを把握する。

2.旧バージョンが存在する場合、そのバージョンのテスト仕様書を入手し、テスト対象との差分を把握する

【学習のポイント】
旧バージョンのテスト仕様書から得られる情報を理解する

【解説】
旧バージョンで起きていた不具合、旧バージョンの仕様、テスト対象となる新バージョンで追加され
た機能を把握する。

特に旧バージョンの開発ドキュメントからは実績のある既存仕様が確認できる。

新旧バージョンのテスト仕様の差分を理解し、重点評価を行うべき箇所を把握する。

3.競合製品が存在する場合は、仕様の調査・分析を実施する

【学習のポイント】
競合製品を調査する目的を理解する

【解説】
競合製品とテスト対象の差分の機能など、予備情報を得ることができる。

また競合製品の性能や使い勝手などテスト対象と比較することで、テスト対象の製品価値を高めるためのベンチマーク情報として活用することができる。

1.テストの目標を設定する

【学習のポイント】
テストの目標を設定する目的を理解する

【解説】
テスト実行範囲、テストの目的によってテストケースの優先度が変わる場合、またテストサイクルやフェーズでテストの目標が設定される。

テストの目標により、テスト実行内容とゴールが明確になり、テスト実行担当者にテストの目標を理解してもらうことでチーム活動がまとまり易くなる。


主な内容は以下の通りである。

　・テスト実行範囲

　・実行するテストケースの選択

　・選択したテストケースの優先順位付け

　・検出する不具合の目標件数

テストケースの選択は、テスト計画書やテスト詳細設計書を参照し、作成済のテストケースから、テスト実行範囲に該当するテストケースを選択する。

なお、テスト実行管理者は、テストの目的、テストサイクル、フェーズなどの要素を考慮してテストケースの優先順位付けを決定する。

2.テスト実行スケジュールを作成する

【学習のポイント】
テスト実行スケジュールの立案、テストの担当分担で考慮すべき内容を理解する

【解説】
テストスケジュールの作成は、テストサイクル、フェーズ、テストタイプなどの目的を考慮して決定する。

またテストの担当分担は、テスト終了期限などのマイルストーン、テスト実行に必要な作業項目と各作業項目に必要な工数、要員を考慮して決定する。

実行中にスケジュール変更が頻繁に起こるプロジェクトでは柔軟に対応できるスケジュールを作成することが必要である。

3.テストの組織図を作成する

【学習のポイント】
テストの組織図を作成する目的を理解する

【解説】
テストの組織図は、テストチームの体制だけでなく開発チームの体制やプロジェクトの責任者などのステークホルダーを明確にする。

またテストに関する情報の連携、進捗の確認、各種問い合わせ先、ステークホルダーの役割と責任所在の明確化、緊急時の連絡先を明確にする目的がある。


テスト実行中は、日次の進捗報告や不明点の確認など、テストチーム以外とも連絡を取ることがある。

ステークホルダーの名前や連絡先（電話番号、メールアドレス、連絡手段となるコミュニケーションツールの担当者 ID など）を明記することで、速やかに対応することができる。

4.テスト実行の要員計画を作成する

【学習のポイント】
テスト実行の要員計画に必要な要素を理解する

【解説】
テスト実行の要員計画では以下の要素を明確にする。

　・要員数

　・担当するテスト実行範囲

　・アサイン期間

　・役割（テスト環境や機材管理者など、テスト実行に伴う付帯作業の役割分担）


テストケースとスケジュールを加味してテスト実行および付帯作業に必要な工数を試算し、要員計画を作成する。

なお作成した要員計画は、テストプロジェクト管理者やプロジェクトの責任者との合意が必要である。

5.コミュニケーションの手段を計画する

【学習のポイント】
コミュニケーションの手段を計画する目的を理解する

【解説】
コミュニケーション手段の計画は、テスト活動において迅速 かつ 確実なコミュニケーション方法について、予め明確にすることが目的である。

コミュニケーション手段には、以下のようなものがある。

　・コミュニケーションツール（メール、チャット、グループウェアなど）

　・電話

　・会議（対面会議、オンライン会議）


仕様変更が発生した場合など、テスト実行に影響がある情報が迅速かつ漏れがなく正確に伝達されるよう、あらかじめ連絡方法を明確にする。

またテスト実行時に開催される会議体の種類、主催者、出席者、役割などを明確にする。これらは関係者全員が事前に把握しておく必要がある。

6.テスト実行の見積りを実施する

【学習のポイント】
テスト実行の見積り方法と必要性を理解する

【解説】
テスト実行の見積りは、一人が一日に担当するテスト実行数、テスト計画等で想定されている不具合数を考慮し、スケジュール通りにテストを完了することができる工数を算出することが目的である。

一日あたりのテスト実行数が見積りと大幅に異なることが判明した場合は、再見積りを実施する。

旧バージョンや類似テスト対象の見積りデータや実績データがある場合は、それらを参考に算出する。

7.テスト実行時のリスクを検討し、テスト実行を阻害する要因の検討と発生時の対応を検討する

【学習のポイント】
テスト実行時に想定されるリスクと対応策を検討する目的とリスクとなりうる要素を理解する

【解説】
テスト実行管理者は、テスト実行を阻害するリスクの予測、リスクが顕在化した際の対応方法、責任の所在を検討する。

予めリスクを想定しておくことで、リスクを事前に回避することが可能である。

また事前に回避が困難なリスクは、リスクが発生した場合の対応手順を決定しておく。

テスト実行の阻害要因となりうるリスクには以下のようなものが挙げられる。


　・プロダクト品質に関する想定リスク

　・不具合の発生状況および修正状況

　・不明確な仕様などの Q&A の発生状況や解決状況

　・環境面に関する想定リスク

　・テスト環境（テスト対象、テストツール、インフラ環境など）のトラブル

　・テスト仕様書に関する想定リスク

　・テスト仕様書の内容不備（手順、期待値など）

　・その他の想定リスク

　・テスターのスキルや要員不足

　・コミュニケーションのトラブル

8.【学習のポイント】

リスク管理表を作成する目的を理解する

【解説】
リスク管理表は、想定リスクを検討した結果を一覧化し、リスクが発生した際に速やかに対応する目的で作成する。そのため、過去に発生したトラブルを参考に対応方法を含めて一覧にする。

また想定されるリスクと対応策をテストチーム内で共有しておくことが重要である。

テストチーム特有のリスクなども十分に考えられるので、過去に発生したトラブル集を作成しておくことが望ましい。

9.調達すべき機器や環境を調査・検討し、調達計画を立案する

【学習のポイント】
調達計画の立案に必要な内容を理解する

【解説】
調達計画に必要な要素は、以下の通りです。

　・機器や環境の種類

　・必要数

　・調達日時
　
　・調達方法

　・保管/保存方法


いつ、誰が、どこで、どのような機材や環境をどのような手段で入手するか、また保管方法、機材管理者を検討する。

機材や環境を複数人で共用する必要がある場合には、機材管理表などの管理方法を検討する。

1.レビューの計画とレビューメンバーのアサインを実施する

【学習のポイント】
テスト実行計画のレビューにアサインすべきレビューメンバーの役割を理解する

【解説】
テスト実行計画レビューの参加者を検討する。テストチーム内のアサインだけではなく、開発者などテストチーム以外からもアサインすることがある。

2.セキュリティを考慮して、機密情報の保管方法や廃棄方法を確認する

【学習のポイント】
セキュリティリスク管理（機密情報管理）の重要性を理解する

【解説】
セキュリティリスク管理として、以下のような点に注意が必要である。

　・紙媒体の持ち出し、廃棄漏れ

　・外部記憶媒体（USB メモリ、ポータブルハードディスク等）を介したデータ流出

　・クラウドストレージを介したデータ流出

　・電子メール、チャットなどのコミュニケーションツールを介したデータ流出

情報流出を防ぐための対策として、機密情報の保管場所と管理方法、廃棄時期と廃棄方法を明確にする。

なお印刷物などの紙媒体には、コピーや手書きメモなどを含む。

1.テスト実行計画に基づき作業用環境の準備をする

【学習のポイント】
作業用 PC やインフラ環境など、準備すべき作業用環境の内容を理解する

【解説】
作業用環境として、作業用 PC や機材、メールやチャットなどの作業環境アカウント、作業用ストレージ、およびテスト管理用のツール、機密情報を保存する場所など、プロジェクトに応じた作業用環境を準備する。

テスト実行計画に基づいて必要数および準備の方法を確認する。

2.テスト実行計画に基づきテスト環境の準備をする

【学習のポイント】
テストの実行に必要なハードウェア、ツール、インフラ環境など、テスト環境の準備内容を理解する

【解説】
テスト実行に必要な機材や環境、テストツール、テストベンチ、テスト用のインフラ環境、テストのログ収集するツール、シミュレータ、およびそれらのマニュアルなど、テスト実行計画に基づいて、必要数を準備する。

またテスト対象に接続する機材の確保やそれらのマニュアルについても必要数を準備する。

3.テスト実行計画に基づきテスト対象の準備をする

【学習のポイント】
テスト実行に必要なテスト対象の準備内容を理解する

【解説】
テスト対象となるシステムや機器、付随する機器やツール、テスト対象のアカウントなど、テスト実行計画に基づいて準備する。

テスト対象の不足はスケジュールに大きな影響を与えることが予想されるので、テスト対象の不足がないようにする。

4.テスト環境の設置や設定をする技術者のアサインを実施する

【学習のポイント】
テスト環境の設置や設定に注意が必要な点を理解する

【解説】
テスト環境のシステム、機器、機材について、設置や設定が必要な場合はテスト実行開始前に準備が必要である。

テストチーム内に設置や設定について熟知している担当者がいない場合には、他チームや他部署へ支援を仰ぐことがある。

5.テスト対象を動作させることができる環境であることを確認する

【学習のポイント】
テスト対象を実行させる環境の動作実績を確認する目的を理解する

【解説】
テスト実行開始前にテスト対象を実行させることが可能な環境であることを確認する。

テスト対象の起動や接続エラー、組み込み機器などのハードウェア初期不良等がないかを確認し、直前になってテストが開始できない状況になることを防ぐことが目的である。

事前にテストチームで確認が困難な場合には、開発チームへ確認が必要な場合がある。

6.専門知識に関する用語集を準備する

【学習のポイント】
テスト実行開始前にテスト対象に関連する用語集を準備する目的を理解する

【解説】
テスト対象について使われる専門用語は、特定の業種、テスト対象のプロダクト内およびプロジェクト内でのみで利用される専門用語が多いため、それらの用語集を準備する。

テスト実行時には正確な情報を迅速に入手する必要があるため、テスト実行管理者は事前に準備する。

不明な用語を速やかに調べられるようにし、テスト実行時の調査時間などのロスを減らす。

1.テスト実行計画に基づき、コミュニケーションツール（連絡表、仕様変更、質問表など）と運用ルールを用意する

【学習のポイント】
コミュニケーションツール（連絡表、仕様変更届け、質問表等）と運用ルールを理解する

【解説】
テストを行うにあたり、迅速かつ正確にステークホルダーとのコミュニケーションを図る手段として、連絡表、仕様変更届け、質問表などが挙げられる。

テスト実行管理者は、テスト実行計画に基づいてそれらを用意し、使用方法、保管場所などをテスト実行担当者に周知徹底させる必要がある。

2.組織図を用意する

【学習のポイント】
組織図を作成する目的と重要性を理解する

【解説】
テスト実行計画に基づいて組織図を作成する。

組織図は、ステークホルダー（テストチームの体制や役割分担、開発担当者など）を明確にすることによってコミュニケーションのトラブルやロスを抑止することができる。

またステークホルダーの役割と責任の所在が明らかになる。

3.テスト実行に必要な管理表を準備する

【学習のポイント】
テスト実行で必要な管理表の種類を理解する

【解説】
テスト実行に必要な管理表には、環境・機材管理、進捗管理、質問管理、仕様変更管理、不具合ステータス管理などがある。テスト実行管理者はテスト実行計画に基づいて、テスト実行を始める前に必要な管理表を用意する。

1.チェックリストを用意する

【学習のポイント】

【解説】
テスト実行で使われるものが全て揃ったかどうか、チェックリストを使用して確認する。

作業用環境、テスト環境、テスト対象、管理表などテスト実行に必要な環境に準備漏れがあると、スケジュールに影響を及ぼす可能性があることに注意する。

1.テスト実行計画書に基づき、テスト仕様書を準備する

【学習のポイント】
テスト実行に必要なテスト仕様書の準備作業を理解する

【解説】
テスト実行に必要なテスト仕様書を準備する。なおテスト実行の結果を記録するテスト実行結果報告書を含む場合がある。

またテストデータが必要な場合は、テスト仕様書とあわせて準備する。

テスト仕様書は、仕様変更などバージョンに応じて変更が発生するため、テスト実行を行うバージョンと合致しているかに注意が必要である。

2.テストケースを理解する

【学習のポイント】
テスト実行前にテストの目的とテストケースの内容を理解する

【解説】
テストを実行する前にテスト仕様書を確認し、テストケースに記載されているテストの目的を理解する。

テストケースは、テストの目的、実行事前条件、入力値、アクション、期待結果、実行事後条件のことである。

事前に把握することでテストケースで実施する内容の理解を深めることができる。

テストケースを確認し、不明点や確認事項があれば質問表などを利用してステークホルダー（テスト設計者や開発担当者）に確認する。

なおテストケースには、必要とされる技術・スキルが記載されていることがある。

3.テスト対象の不明点を明確にする

【学習のポイント】
テスト実行前にテスト対象の不明点を確認する目的を理解する

【解説】
テストを実行する前に、テスト対象に関する不明点や確認事項があれば質問表などを利用してステークホルダー（テスト設計者や開発担当者）に確認する。

不明点や確認事項がテスト実行中に判明すると、スケジュールに影響を及ぼす可能性があるため、可能な限り事前に不明点を解決しておくことが重要である。

4.テスト実行時に使用するリファレンスを準備する

【学習のポイント】
テスト実行時に使用するリファレンスの内容や使用する目的を理解する

【解説】
テスト実行中、期待結果の比較に用いられるリファレンスを準備する。

リファレンスには仕様を確認するための機能仕様書やマニュアルなどがある。

またテスト対象の過去バージョンをリファレンスとして使用することがある。

なおリファレンスのドキュメントは、どの部分にどのような内容が記載されているかを把握しておくことで、不明点などを迅速に確認することができる。

1.チェックリストを用意する

【学習のポイント】
テスト仕様書に関する準備物をチェックリスト化する目的を理解する

【解説】
テスト実行の際に必要なテスト仕様書、テストデータ、不具合報告書のフォーマット類、リファレンスが全て揃ったかどうか、チェックリストを使用して確認する。

準備漏れがあるとスケジュールに影響を及ぼす可能性があることに注意する。

1.実行するテストの種類やテストサイクルを確認する

【学習のポイント】
テストタイプなどのテストの種類や目的、テストサイクルによって、テスト実行時の視点が異なることを理解する

【解説】
機能動作の確認、画面デザインなどの表示処理の確認、状態遷移の確認など、テストの目的やテストサイクル（初回テスト、2 回目のテストなど）によって不具合になりうる事象が異なる。

例としては、最初のテストサイクルでは未実装機能や制限事項により細かな表示や性能面の不具合は報告対象とせず、機能動作に関する不具合のみ報告対象となるケースなどがある。

誤った認識で不具合を報告した場合にはテストチームと開発チーム双方でロス工数が発生するなど、スケジュールに影響を及ぼす可能性がある。

2.予定のテストの実行数と予想時間を把握する

【学習のポイント】
予定のテストの実行数と予想時間を把握する目的を理解する

【解説】
割り当てられたテスト仕様書をいつまでに完了すべきかを把握する必要がある。

またテストの割り当ては、テスト実行全体の進捗によりテスト実行開始後に担当範囲が変更される可能性がある。

テスト実行の進捗遅れはスケジュールに影響を及ぼすため、テスト実行担当者は予定されたテスト実行数に近づくようなペースを守り、テスト実行管理者はテストの阻害要因が発生した場合は速やかに対処を行う。

そのためには、テスト実行担当者、テスト実行管理者ともに、事前に予定数と予想時間を把握しておく必要がある。

1.テスト実行担当者の心得

【学習のポイント】
テスト実行担当者の心得を理解する

【解説】
① テストの種類、テストサイクルおよび目的と視点を理解する
前項の通り、テストの種類、テストサイクルによってテストの目的や視点が異なる。
状況に応じて不具合の報告対象となりうる事象が異なる可能性がある。

② テストケースやテスト手順の行間を読む
テストの実行は、テスト対象を起動した時から始まる。
テストケースの目的を理解し、テスト環境、テストの事前条件や事後条件など、期待結果として記載されていない部分についても不具合が発生していないかに注意する。

③ 不具合を見逃さないポイントを理解する
テストケースとテストケースの間で不具合が発生することがある。
テスト実行担当者は些細な疑問を残さず、気になる部分を発見した場合にはテスト実行管理者に報告し不具合の見逃しを防ぐ必要がある。

④ チームでのテストを実施する意味を理解する
テスト活動はチームによって成立する活動である。
進捗の遅れはチーム全体の活動に影響が生じる可能性があるため、進捗遅れの兆候がある場合は速やかにテスト実行管理者へ報告する。
テスト実行管理者はチーム活動における影響を理解し、チームメンバーの関係性やフォローしやすい体制づくりが必要である。

2.事象の発生（遅れ）

【学習のポイント】
テスト実行中に予定通りに完了しないことが判明した場合に、随時テスト実行管理者あるいはテストプロジェクト管理者に報告する必要があることを理解する

【解説】
一日で消化しなければいけないテスト項目数を消化することが難しい場合、スケジュールに影響を及ぼす恐れがある。

テスト実行担当者は進捗に遅れが生じることがわかった場合、速やかにテスト実行管理者へ報告する。

3.インシデントの発生

【学習のポイント】
インシデントが発生した場合に行うべき手順を理解する

【解説】
テスト実行担当者は、インシデントが発生した際に事象のエビデンス取得、発生内容の確認、再現手
順の確認を直ちに行う。

またインシデント報告の手順に従い、再現手順の確定、仕様書やリファレンスの確認、および発生したテスト内容、事前条件、再現手順、事後条件、発生時の環境、期待動作を特定する。

インシデントは自分の判断で不具合と断定せず、テスト実行管理者の判断を仰ぐ。

テスト実行管理者は、テスト実行者からの報告内容に不足がないことを確認し、ステークホルダー（テスト設計者や開発担当者）に確認する。

不具合と認められた場合には不具合報告書にて報告する。

テストの種類やテストサイクルによって不具合の判断基準が決まることがある点に注意が必要である。

4.不具合修正確認テストのタイミングや原則を理解する

【学習のポイント】
不具合修正確認テストは不具合報告をした本人が早急に実施する必要があることを理解する

【解説】
不具合修正確認テストとは、報告した不具合が正しく修正されているかを確認するテストである。

以下の原則に基づいて実施する。

①不具合修正確認テストは、修正対応された不具合報告書の修正結果を確認のうえ、期待結果の通り
に修正されていることを確認する。
修正ミスなどにより期待動作の通りに修正されない可能性があるため、不具合修正確認テストの結果が NG になるケースがあることに注意すること。

②不具合修正確認テストの依頼があった場合は速やかに不具合修正確認テストを実施する。
また確認結果を問わず、不具合修正確認テストの結果を速やかに報告する。

③不具合修正確認テストは不具合を報告した本人が実施することが原則である。
不具合報告者以外が確認した場合、不具合の再現条件や手順、期待結果について認識誤りが発生することがある。
何らかの理由により報告者以外が確認を行う場合は、報告者へヒアリングを行うなど、認識誤りが発生しないよう注意が必要である。

5.テスト実行時に不明な点が発見された場合は、質問表などを利用して確認する方法を理解する

【学習のポイント】
質問表で確認する際に必要な手順を理解する

【解説】
テスト実行中、テスト仕様書やテスト対象の仕様に不明点や疑問点がある場合は質問表を利用して確
認する。

テスト実行担当者は、質問表へ記載する前に以下の点を確認すること。

　・仕様書などのドキュメントに質問したい内容が記載されていないこと。

　・他のテスト実行担当者が既に質問している内容ではないこと。

1.常にテスト実行のスピードを意識して、テスト実行の進捗状況を把握する

【学習のポイント】
テスト対象の品質によって、テスト実行の進捗に大きく影響を与えることを理解する

【解説】
テストは各開発工程の後半に行われることが多い。

特にシステムテストなどの開発スケジュールの終盤に行われるテスト工程は、進捗状況や品質状況によりリリーススケジュールに影響を及ぼす可能性がある。

不具合が多すぎてテストが進まない、機材が足りない、テスト手順に不明瞭な点が多くテストの進行に支障をきたすなど、阻害要因がある場合は速やかにテスト実行管理者に報告し、阻害要因を排除することが必要である。

またテスト実行管理者は、テスト実行担当者のテストの担当範囲や担当者のレベルによって進行にばらつきがある場合は、分担範囲の見直し、進捗スピードアップのためのフォローを行う。

2.質問表のステータス状況を管理する

【学習のポイント】
質問表で確認中の内容について、ステータスや回答状況をトレースする必要性を理解する特にテスト実行に影響を与える質問などは、優先度を高める

【解説】
質問表で報告した内容がテストの進行に大きく影響する場合は、一刻も早い回答を期待していても速やかに回答が得られないことがある。

開発チームなどのステークホルダーから回答が遅い場合は質問表に優先度や回答期限を設ける、定期的に状況を問合せするなど速やかに回答を得るための運用方法を検討することが必要である。

3.リリースバージョンの確認

【学習のポイント】
リリースのバージョンと改修項目および制限事項を確認する目的を理解する

【解説】
リリースバージョンを確認する目的は以下の通りである。

　・テスト実行の記録
　どのバージョンでテストを行った結果であるかを特定する。

　・不具合報告
　どのバージョンで発生した不具合であるかを特定する。

　・不具合修正確認
　どのバージョンで修正された不具合であるかを特定する。

　・テスト実行の制限事項
　制限事項が存在するバージョン、または制限事項が解消されるバージョンを特定する。


開発中のテスト対象は、機能の動作制限が生じることがある。

制限事項の発生および解消はリリースバージョンから判断する。

テスト実行の記録やインシデントの報告、テスト実行の制限などを確認する為に、リリースのバージョンと改修項目および制限事項を確認する。

開発においてどのバージョンで発生した不具合なのかは最も重要な項目である。


開発期間中は、頻繁にバージョンアップリリースが行われる。

どのバージョンで発生した不具合かを明確にすることで、いつ不具合が混入したか、どのような原因により不具合が混入したかを特定するための重要な情報になる。

なおバージョン情報は英数字が羅列されている場合もあるため、システムのバージョン表示情報やバージョン情報に関するドキュメントを確認し、正確にバージョン情報を特定する必要がある。

4.テストリソース（機材、要員）の管理

【学習のポイント】
テスト対象や環境の故障・不足、要員の勤怠や欠員などの状況を確認し、状況に応じた対策案が必要であることを理解する

【解説】
テスト対象や環境の故障や破損、要員の稼働工数不足はテスト実行を阻害する大きな要因であり、いずれの要因もスケジュールに大きな影響を及ぼす可能性がある。

テスト実行担当者は、テスト対象や環境に故障や破損が発生していないかを管理し、発生した場合には速やかにテスト実行管理者へ報告する。

またテスト実行担当者の体調やモチベーションの管理もスケジュールや品質に影響を及ぼす要素である。

人員の欠員もテスト実行の大きな阻害要因となるため、良好なコミュニケーションが可能な風通しのよい環境を構築する。

5.テスト仕様書の管理

【学習のポイント】
テスト仕様書の間違いを発見した場合の対応方法を理解する

【解説】
テスト仕様書はテストを実行する詳細情報を示す最も重要なドキュメントである。

複数人のテスト実行担当者でテスト仕様書を共有する場合など、上書き保存などでデータを削除ないし意図しない修正をしてしまうこともあるため、日次でバックアップをとるなどの工夫が必要である。

またテスト仕様書に修正が入る場合は認識齟齬が生じることがあるため、テスト実行者自身の判断で先に進むのではなくテスト実行管理者に確認する必要がある。

1.定例報告会への参加

【学習のポイント】
必要に応じて朝礼、終礼、週間進捗報告会などに参加し、役割に応じた報告を行うことを理解する

【解説】
朝礼、昼礼、または定例報告会などで、進捗状況の報告、またはテスト実行中の不明点・問題点などを報告する場がある場合は、テスト実行担当者/テスト実行管理者としての報告すべき内容の違いを理解する。

テスト実行担当者はテスト対象、環境などに対する要望、質問などの報告をし、テスト実行管理者はチームとしての要望、質問、業務改善提案などを報告する。

2.翌日の準備

【学習のポイント】
原則として帰宅前に翌日のテスト実行の準備（テストケースの確認、テストデータや環境の準備など）を実施しておく必要があることを理解する

【解説】
テスト実行、進捗報告を終えたら、翌日のスタートをスムーズに行えるようにテスト仕様書の準備と内容の確認、テストデータの準備、テスト環境の設定、テスト対象の保守管理などを行う。

翌日のテスト実行に影響がありそうな問題が判明した場合は、速やかにテスト実行管理者へ報告を行う。

引用：https://www.ivia.or.jp/item43