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

はじめに

前回の続きでテスト実行に関するシラバス読解を進めていく。

テスト実行

テスト実行の管理

学習の目的

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

テストは各開発工程の後半に行われることが多い。特にシステムテストなどの開発スケジュールの終
盤に行われるテスト工程は、進捗状況や品質状況によりリリーススケジュールに影響を及ぼす可能性
がある。不具合が多すぎてテストが進まない、機材が足りない、テスト手順に不明瞭な点が多くテス
トの進行に支障をきたすなど、阻害要因がある場合は速やかにテスト実行管理者に報告し、阻害要因
を排除することが必要である。またテスト実行管理者は、テスト実行担当者のテストの担当範囲や担
当者のレベルによって進行にばらつきがある場合は、分担範囲の見直し、進捗スピードアップのため
のフォローを行う。

テスト担当者はデイリーの目標達成に向け、どのくらいの生産性(例：1時間当たりの生産性)で進めていければスケジュール通り進められるかをテスト開始前に整理し、その結果を頭に入れてテスト実行を進める。
また、阻害要因が発生した場合はテスト実行管理者に速やかに報告すること。

テスト実行管理者は、シラバスにもあるようにチームの進捗をモニタリングし、進捗の遅れを検知した場合は、テコ入れするなどのフォローを行うこと。

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

質問表で報告した内容がテストの進行に大きく影響する場合は、一刻も早い回答を期待していても速
やかに回答が得られないことがある。開発チームなどのステークホルダーから回答が遅い場合は質問
表に優先度や回答期限を設ける、定期的に状況を問合せするなど速やかに回答を得るための運用方法
を検討することが必要である。

質問表でステークホルダーとやり取りする中で、いつまでに回答を貰いたいかを明確にして運用しないと、いつまでも回答が貰えない状態が続く。
特にテスト実行に影響をきたすような質問に対し、すぐに回答が貰えない状況が続くことがないよう、元々設定していた優先度を上げるなどの対応が必要になる。

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

リリースバージョンを確認する目的は以下の通りである。
・テスト実行の記録
どのバージョンでテストを行った結果であるかを特定する。
・不具合報告
どのバージョンで発生した不具合であるかを特定する。
・不具合修正確認
どのバージョンで修正された不具合であるかを特定する。
・テスト実行の制限事項
制限事項が存在するバージョン、または制限事項が解消されるバージョンを特定する。開発中のテ
スト対象は、機能の動作制限が生じることがある。制限事項の発生および解消はリリースバージョ
ンから判断する。
テスト実行の記録やインシデントの報告、テスト実行の制限などを確認する為に、リリースのバージ
ョンと改修項目および制限事項を確認する。開発においてどのバージョンで発生した不具合なのかは
最も重要な項目である。
開発期間中は、頻繁にバージョンアップリリースが行われる。どのバージョンで発生した不具合かを
明確にすることで、いつ不具合が混入したか、どのような原因により不具合が混入したかを特定する
ための重要な情報になる。なおバージョン情報は英数字が羅列されている場合もあるため、システム
のバージョン表示情報やバージョン情報に関するドキュメントを確認し、正確にバージョン情報を特
定する必要がある。

テストを実行する上でテスト対象のバージョンを継続的に確認する必要がある。
どのバージョンでテスト実施するかという情報に加え、定期的なデプロイが1週間の内にどれくらいの頻度で、どういったアップデートが発生するかは分かる範囲でステークホルダーへ確認する。

アップデート内容について、リリースノートが運用されているようであれば、共有してもらうことが望ましい。
アップデートにより、テスト開始当初は実装されていなかった機能が実装されることを把握できれば、テストの実行順も調整がつけやすくなる。

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

テスト対象や環境の故障や破損、要員の稼働工数不足はテスト実行を阻害する大きな要因であり、い
ずれの要因もスケジュールに大きな影響を及ぼす可能性がある。テスト実行担当者は、テスト対象や
環境に故障や破損が発生していないかを管理し、発生した場合には速やかにテスト実行管理者へ報告
する。
またテスト実行担当者の体調やモチベーションの管理もスケジュールや品質に影響を及ぼす要素で
ある。人員の欠員もテスト実行の大きな阻害要因となるため、良好なコミュニケーションが可能な風
通しのよい環境を構築する。

テストリソース管理も常に全てのリソースを効率よく運用できれば、問題なくテストを進められるが、各リソース毎に要求されるものが異なってくる。

機材管理については、テスト担当者と協力して、阻害要因を起こさせない取り組みが求められる。
機材の破損が発生した場合、エスカレーションは勿論、再発防止の取り組みも考慮しなければならない。
トラブル発生時の対応でテスト工数が逼迫することがないよう、関係各所と協力して機材管理を徹底していく。

人的な要素はイレギュラーな部分が多く、欠員に関してはコントロールが難しい部分である。
但し、モチベーション管理の面については、テスト実行管理者が上手くコントロールすることが重要と考えている。
例えば、制約事項が多さからテストが思うように進まない状況や、日々の目標を達成できないといったモチベーション低下の要因に直面した際、メンバーへのフォローを重点的に行うだけでも大分変わってくるはずである。

テスト仕様書の管理

テスト仕様書はテストを実行する詳細情報を示す最も重要なドキュメントである。複数人のテスト実
行担当者でテスト仕様書を共有する場合など、上書き保存などでデータを削除ないし意図しない修正
をしてしまうこともあるため、日次でバックアップをとるなどの工夫が必要である。またテスト仕様
書に修正が入る場合は認識齟齬が生じることがあるため、テスト実行者自身の判断で先に進むのでは
なくテスト実行管理者に確認する必要がある。

テスト仕様書を運用する際のルールはチーム内ですり合わせてから運用を開始する。
特に複数人で1つのテスト仕様書を共有する場合、意図せぬデータの削除や修正から、手戻りが発生しないよう、業務の開始前にバックアップを取得するなどの対策を予め決めておく。

日次の状況を入力し、進捗状況を報告する

テストの進捗状況や発生した不具合や問題の状況は日次で管理を行う。実行したテスト項目数はスケ
ジュールの変更要否などの判断に関わるため、正確な報告が必要である。またテスト実行担当者全員
にチームの進捗を共有することにより、テストチーム全員がテストチームの進捗状況を把握すること
が可能である。ただし、テストの阻害要因などの緊急度の高い問題が発生した際は日次報告のタイミ
ングではなく、都度の速やかな対応が必要である。

テスト担当者目線で見た場合、日々の進捗を可視化することで、上手くいったこととそうでないことを認識でき、必要に応じてテスト実行管理者からフィードバックが貰え、明日以降のテストの進め方を改善するきっかけになる。
テスト実行管理者からすれば、進捗状況が見えることでスケジュールに対して予定通りに進んでいるか、遅延しているかを判断する材料になる。
また、進捗報告にも定期報告の形と緊急度の高い内容であれば、定期報告を前にテスト実行管理者へ早めに打ち上げるようなルールを設けておくことで、進捗遅れが後になって発覚する前に先回りして対策を打てる。

その他

学習の目的

定例報告会への参加

朝礼、昼礼、または定例報告会などで、進捗状況の報告、またはテスト実行中の不明点・問題点など
を報告する場がある場合は、テスト実行担当者/テスト実行管理者としての報告すべき内容の違いを
理解する。テスト実行担当者はテスト対象、環境などに対する要望、質問などの報告をし、テスト実
行管理者はチームとしての要望、質問、業務改善提案などを報告する。

ステークホルダーとの定例報告会がある場合は積極的な参加が求められる。
テストの進捗や各種報告に加え、テストチームでの困り事や改善提案を直接伝えられる貴重な機会であるため、定例報告会前に報告すべき内容について整理しておく。

テスト担当者とテスト実行管理者とで報告内容は異なるが、テスト実行管理者はテスト担当者の報告内容もある程度を把握しておく必要がある。
テスト担当者がテスト実行管理者を通さずに思ったことをそのまま報告しないよう、予めテスト担当者へのヒアリングも行い、テストチームとしてのスタンスを決めておくこと。

翌日の準備

テスト実行、進捗報告を終えたら、翌日のスタートをスムーズに行えるようにテスト仕様書の準備と
内容の確認、テストデータの準備、テスト環境の設定、テスト対象の保守管理などを行う。翌日のテ
スト実行に影響がありそうな問題が判明した場合は、速やかにテスト実行管理者へ報告を行う。

1日の進捗が達成されていれば、時間ギリギリまでテスト実行を行わず、翌日の準備に移ること。
中にはテストデータを仕込み、翌日に期待結果を確認するケースもあるため、帰り間際に慌てて設定した結果、データミスが混入したなんてことがないよう、時間に余裕を持って行動に移すこと。

おわりに

次回はテスト実行記録についてシラバス読解を進めていく。