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

はじめに

プロジェクト管理（個人進捗管理も含む）

チーム管理

学習の目的

テスト目標管理：テスト実行の目標と終了基準の管理

テスト終了基準となる基本的な内容は以下の通りである。
・計画したテスト実行が完了していること
・定義済みのテストカバレッジ（要件、ユーザーストーリー、受け入れ基準、リスク、コードなど）
を達成していること
・未解決の不具合が残存している場合、件数や対処方針が合意されていること
・不具合の収束状況などから、想定される残存不具合が十分に少ないと判断できること
・テスト実行計画に基づいてテストすべき品質特性を十分に評価していること
なお、上記以外にプロジェクト固有の内容がある場合は、その内容も含めて管理する。

テスト終了基準はテスト計画書内で定義し、その内容をステークホルダーと整合を取る必要がある。
また、終了基準について、ステークホルダーとテストチームがそれぞれの基準を持ち、双方の意見を基に着地点を見つけていくことで、テスト終了に向けたアクションを固めることができる。

スケジュール管理：テスト実行スケジュール管理

スケジュール管理は、テスト実行計画に基づいた日次報告、週次報告、進捗管理方法、定例会議など
の情報を基に行う。スケジュールを維持するにあたって、人的要因の欠如やテスト環境の変化、テス
ト対象の品質状況などによって予定していたスケジュール阻害要因となる項目を理解し、阻害要因が
発生することを防ぐ。また阻害要因が発生した場合の対応もスケジュール管理の一つである。

テスト実行管理者は、テストスケジュールを引いてテスト全体を見渡し、テストの進捗を可視化することで、ステークホルダーへテスト状況を報告していく。
スケジュール通りにテストを進める中で、ステークホルダーへの調整やチーム内のリソース管理を並行して進めることで、テスト実行の阻害要因を先回りして潰しておくことも重要なタスクの1つである。

テスト工数管理：テスト実行時間の管理

テスト実行時には、予め見積りを行ったテスト実行の予定工数と実績工数の差異を日次で分析する。
差異が生じた場合は原因の追究と改善を行い、翌日以降のスケジュールへ反映を行うことで、全体的
なスケジュールへの影響を最小限にすることが必要である。

テストスケジュール作成時に、テスト実行で発生する工数の見積もりを立てる。
テスト実行中は継続的にモニタリングし、見積もりと実績工数に著しい乖離がないかを確認すること。
もし、スケジュールに遅延が発生した場合、問題箇所に対して、原因究明とリカバリー策をとっていく。

テスト実行の品質管理：テスト実行における品質の管理

テスト実行中は、テスト対象の品質状況を常時把握しておく必要がある。テスト対象の品質が悪い場
合は、不具合の多発、ある機能が実装されないなどの制限事項、リリース時期の遅れ等により、テス
トのスケジュールに影響を及ぼす可能性がある。テスト実行管理者は品質が悪い場合、または品質状
況の急変を検知した場合は開発チームなどへのエスカレーション、対応方法の協議を行う。なお、品
質状況の把握不足や対策の遅れが発生した場合には、リリース時期の遅れやリリース後の不具合流出
につながる可能性がある。

テスト期間中にテスト結果や不具合発生件数の推移を注視することで、テスト対象の品質状況について把握してくこと。
特に不具合件数については、開発終盤につれて収束に向かわなければならないはずだが、不具合検出が継続していたり、緊急度の高い不具合が検出された場合、テスト対象の品質が悪い可能性があることを疑わなければならない。
そうした事象を検知した場合、ステークホルダーへ現在の品質状況をエスカレーションし、今後の対応状況を協議していく必要がある。

要員管理：テスト実行要員のスキルと作業状況の管理

要員管理には以下のような要素がある。
理解度や習熟度などのスキル面は、進捗状況や作業品質に影響を及ぼす可能性がある。要員の記憶力、
要領の良し悪し、集中力や得手不得手などの性格的な特性によるモチベーションの低下にも注意が必
要である、テスト実行管理者はそれら要因の存在を確認した場合は、速やかにそれらの要因を解決す
ることが必要である。

常に同じスキルレベルの人員が集まるとは限らないため、テスト実行管理者は各メンバーのスキルセットだけではなく、性格や業務への取り組み方等の特徴を把握し、必要に応じて的確な役割分担を行う必要がある。

コミュニケーション管理：テスト実行中のコミュニケーションと運用状況の管理

コミュニケーション手段には、仕様変更連絡票、不具合報告書、質問表などによる情報共有や会議、
電話、メールなどの電子媒体による情報伝達など、目的に応じて様々な手段がある。ステークホルダ
ーとのコミュニケーションが行われないと、テストの品質にも影響を及ぼす可能性がある。正確かつ
円滑な情報共有や情報伝達が行われるよう、コミュニケーションルールを決定およびステークホルダ
ーと共有し、適切に運用されているかを把握する必要がある。

ステークホルダーとのコミュニケーションについては、数Part前の読解でも説明したように、キックオフの段階でコミュニケーション方法や運用ルールについて双方で認識を合わせておくこと。
特に緊急性の高い不具合検出やテスト実行がストップするようなトラブルが起きた時のエスカレーション方法について、コミュニケーションの全般的なルールとは別に、緊急時のルールを別個で設けておいた方がリスク発生時に速やかな行動を取れるようになる。

リスク管理：テスト実行中に発生する可能性があるリスク管理

リスク管理には、以下の 2 つの目的がある。
① 過去のテストで発生した問題やプロジェクト固有の想定リスクを明確にする
② リスクが顕在化したときの対応方法を明確にする
リスクには、過去の経験に基づいて想定できるリスクと、想定外のリスクがある。前回のテスト実績
がある場合はそれらを参考に想定できるリスクを検討し、未然に防ぐ必要がある。また未知・想定外
のリスクが発生した際には速やかに対処することができるよう、ステークホルダーの連絡先、または
対応責任者との連絡方法を確認・管理する。想定外のリスクは未知のリスクであるため、具体的な対
応策を決めることが難しいため、リスクが発生した場合の連絡手段、対応責任者を決めておくことが
対応策になる。リスクはテスト実行計画の時点で検討し、リスク管理表によって管理する。

過去のトラブルから想定されるリスクについて、今回のテストで同じようなトラブルに陥ることを防ぐため、何を決めなければならないのかをテスト計画段階で明文化しておく。

想定外のリスクについては、そもそも想定外を考え始めるときりがないため、想定外を0にするための方策を考えるより、想定外が発生した時のダメージで軽減するような制度設計に務めるべきと考えている。
先に述べたように、リスク発生時の専用のエスカレーション方法の確立はその1つである。

調達管理：テスト実行に用いるリソースの管理

テストの対象となるもののほとんどはまだ市場には出ていないものである。それがなんらかの形で外
部に流出してしまうと考えられないほどの責任がのしかかってくる。それを未然に防ぐために、普段
から調達・保存については適切に管理する必要がある。またテスト対象の故障、不足が発生した場合、
スケジュールに大幅な遅れが出る可能性がある。そうなった場合の緊急の対応方法なども予め明確に
しておく必要がある。

テストのリソース管理は効率的なテスト実行に欠かさない要素である。
テスト対象の故障や不足が発生すると、それだけでテストできない時間を作り出し、結果としてスケジュールの遅れを生み出す要因となってしまう。
他のリソースに空きがあればリカバリーは可能だが、リソースが常に余裕があるとは限らない。
テスト実行管理者は、テスト対象や関連する機材を始めとしたリソース管理の徹底及び、トラブル発生時の報告フロー等をテスト前に確立しておくこと。

おわりに

次回はプロジェクト管理について、シラバス読解の続きを進めていく