IVEC テスタークラス シラバス読解 Part2

はじめに

前回の続きで、テスト実行計画に関するシラバス読解です。

テスト実行計画の立案

学習の目的

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

テスト実行の要員計画では以下の要素を明確にする。
・要員数
・担当するテスト実行範囲
・アサイン期間
・役割（テスト環境や機材管理者など、テスト実行に伴う付帯作業の役割分担）
テストケースとスケジュールを加味してテスト実行および付帯作業に必要な工数を試算し、要員計画
を作成する。なお作成した要員計画は、テストプロジェクト管理者やプロジェクトの責任者との合意
が必要である。

実際にテスト活動を推進する前に、どういうテスト実行計画で推し進めるかを関係者間で合意を取る必要がある。
要員数については、お金に関わる部分であるため、テスト計画者はテスト実行で発生する作業工数や要員のスキル面という点から妥当性のある要員計画であることを説明できなければならない。

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

コミュニケーション手段の計画は、テスト活動において迅速 かつ 確実なコミュニケーション方法に
ついて、予め明確にすることが目的である。
コミュニケーション手段には、以下のようなものがある。
・コミュニケーションツール（メール、チャット、グループウェアなど）
・電話
・会議（対面会議、オンライン会議）
仕様変更が発生した場合など、テスト実行に影響がある情報が迅速かつ漏れがなく正確に伝達される
よう、あらかじめ連絡方法を明確にする。またテスト実行時に開催される会議体の種類、主催者、出
席者、役割などを明確にする。これらは関係者全員が事前に把握しておく必要がある。

プロジェクトによってコミュニケーション手段は異なることはよくある。
Zoom、Teams、Slack、Outlook等コミュニケーション手段は企業によって様々であり、業務連絡・周知事項の連絡に加え、会議体の設定にも影響してくるので、それらをキックオフで認識合わせしておくこと。

個人的な体験として、重要性及び緊急性が高い不具合が検出した時に備え、関係者にいち早く共有する手段を事前にすり合わせしておくと、そうした事態になった時に慌てずに済む。
理由としては、開発チームは開発チームで数多くの通知が飛んでくる中で業務を行っているため、不具合に関する情報が追加されても、軽微な不具合と同じ通知方法だとスルーされるリスクがある。
なので、テストチーム側は軽微な不具合と緊急性の高い不具合の通知方法を区別して発信する方が親切かと考えている。

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

テスト実行の見積りは、一人が一日に担当するテスト実行数、テスト計画等で想定されている不具合
数を考慮し、スケジュール通りにテストを完了することができる工数を算出することが目的である。
一日あたりのテスト実行数が見積りと大幅に異なることが判明した場合は、再見積りを実施する。旧
バージョンや類似テスト対象の見積りデータや実績データがある場合は、それらを参考に算出する。

テスト実行計画を立てる中で、どのくらいの生産性でテストを進め、いつテストが完了するのかは見積もった上で計画を立てる必要がある。
特にテスト完了がスケジュールギリギリになるような計画の場合、予期せぬトラブルが発生した際のリカバリーが取りづらく、結果として要員に負荷を強いる可能性がある。
そうしたリスクに備えておくため、ある程度バッファを持たせた上で1日辺りの見積もりを立てておくのがリスクヘッジとして有効であると考えている。

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

テスト実行管理者は、テスト実行を阻害するリスクの予測、リスクが顕在化した際の対応方法、責任
の所在を検討する。予めリスクを想定しておくことで、リスクを事前に回避することが可能である。
また事前に回避が困難なリスクは、リスクが発生した場合の対応手順を決定しておく。
テスト実行の阻害要因となりうるリスクには以下のようなものが挙げられる。
・プロダクト品質に関する想定リスク
・不具合の発生状況および修正状況
・不明確な仕様などの Q&A の発生状況や解決状況
・環境面に関する想定リスク
・テスト環境（テスト対象、テストツール、インフラ環境など）のトラブル
・テスト仕様書に関する想定リスク
・テスト仕様書の内容不備（手順、期待値など）
・その他の想定リスク
・テスターのスキルや要員不足
・コミュニケーションのトラブル

リスク発生時の対応方法について、予め関係者と整合を取っておくことはテストチーム側のリスクマネジメントとして重要な要素であり、テスト実行計画書に盛り込んでおくことで不測の事態にもスムーズに対応できる。

例えば、仕様変更発生によりテストへの影響範囲が広く、結果としてテスト件数が〇〇%増加したとする。
そうした場合、テスト計画作成当初のスケジュールで収まりきらず、テスト期間内に終了できないこともリスクとして十分考えられる。
上記のようなリスクが発生する前に、テスト実行計画書内に想定しうるリスクが発生した際の対応方法を明文化しておくことで、リスクが顕在化する前に先回りして対応策を講じることができる(テスト期間の延長、テスト実行範囲に優先度を設ける等)

また、仕様に関するQAを開発側が回答してくれず、テストを進められない状況の場合、定例会議の場で直接答えてもらう場を設けることも有効な手段である。

過去に発生したトラブルを参考にリスク管理表を作成する

リスク管理表は、想定リスクを検討した結果を一覧化し、リスクが発生した際に速やかに対応する目
的で作成する。そのため、過去に発生したトラブルを参考に対応方法を含めて一覧にする。また想定
されるリスクと対応策をテストチーム内で共有しておくことが重要である。テストチーム特有のリス
クなども十分に考えられるので、過去に発生したトラブル集を作成しておくことが望ましい。

過去に起きたリスクを参考に、リスク管理表を作ることは有効な手段である。
このシラバスを最初に読解した際、顧客側で発生したトラブルと解釈し、そもそもリスクに関する情報を文書として残しているかという疑問があったが、テストチーム側で過去に起きたリスクという解釈で見れば、管理表を作るのは難しくないと考える。

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

調達計画に必要な要素は、以下の通りです。
・機器や環境の種類
・必要数
・調達日時
・調達方法
・保管/保存方法
いつ、誰が、どこで、どのような機材や環境をどのような手段で入手するか、また保管方法、機材管
理者を検討する。機材や環境を複数人で共用する必要がある場合には、機材管理表などの管理方法を
検討する。

限られたリソースで効率よくテストを回すには、テストで使用する機材・環境の綿密な計画が重要である。
数に限りある機材や日程調整が必要な機材の場合、機材が不要なテストと必要なテストの実行順の調整が必要となる。

また、機材やテスト環境について、テスト期間内は専有できるのか、そうでないかの事前確認が必須である。
前者であれば問題はないが、後者の場合だと借用できないことで一時的にテストが出来ない期間が出てくる。
また、テストできない期間が長引いたことで、テスト期間内に完了できませんでしたということにならないよう、テスト環境の調達計画は入念に行うこと。

その他

学習の目的

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

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

テスト実行計画のレビューは、チーム内と開発チームを交えて行うこと。
テスト計画のレビューに開発チームを交えることで、開発側の進捗状況からスケジュールの調整やテスト環境の提供可能時期の細部まで把握できる。
テスト実行計画は作ってチーム内共有に留まらせず、関係各所への共有を前提に作ること。

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

セキュリティリスク管理として、以下のような点に注意が必要である。
・紙媒体の持ち出し、廃棄漏れ
・外部記憶媒体（USB メモリ、ポータブルハードディスク等）を介したデータ流出
・クラウドストレージを介したデータ流出
・電子メール、チャットなどのコミュニケーションツールを介したデータ流出
情報流出を防ぐための対策として、機密情報の保管場所と管理方法、廃棄時期と廃棄方法を明確にす
る。なお印刷物などの紙媒体には、コピーや手書きメモなどを含む。

客先常駐で行う業務形態の場合、必ず顧客のセキュリティルールを確認しておく必要がある。
テストリーダーはテストメンバーに対し、セキュリティの啓蒙と具体的なルールの周知を行うことで、機密情報漏洩による社会的影響の重大さ認識してもらい、慎重な言動・行動をコントロールすることも業務の1つである。

終わりに

前回の内容も踏まえ、テスト実行に入る前の準備でスムーズにテスト実行できるかが決まると言える。
かくいう自分自身は社内でジュニアクラスであり、テスト計画を作成する担当ではないが、実際に作る側に回った際に、シラバスで取り上げた内容を考慮して計画を立てていく。
次回はテスト環境準備のシラバスを読解していく。