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

はじめに

今回から2回に分けてテスト実行に関するシラバス読解を進めていく。

テスト実行

テストの種類や目的、テストサイクルとテストケース実行予定の確認

学習の目的

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

機能動作の確認、画面デザインなどの表示処理の確認、状態遷移の確認など、テストの目的やテスト
サイクル（初回テスト、2 回目のテストなど）によって不具合になりうる事象が異なる。例としては、
最初のテストサイクルでは未実装機能や制限事項により細かな表示や性能面の不具合は報告対象と
せず、機能動作に関する不具合のみ報告対象となるケースなどがある。誤った認識で不具合を報告し
た場合にはテストチームと開発チーム双方でロス工数が発生するなど、スケジュールに影響を及ぼす
可能性がある。

自分たちがどんなテストを行うかはテスト計画書などのドキュメントから把握しておくこと。
どういう種類のテストを実施するか把握しておくことで、目的に沿ったテスト実行を推進できる。
テストを行う際、機能未実装によって一部のテストが保留または実施不可という制約事項も起こり得るため、自身の担当するテストはどの段階のテストかを意識して臨むこと。

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

割り当てられたテスト仕様書をいつまでに完了すべきかを把握する必要がある。またテストの割り当
ては、テスト実行全体の進捗によりテスト実行開始後に担当範囲が変更される可能性がある。テスト
実行の進捗遅れはスケジュールに影響を及ぼすため、テスト実行担当者は予定されたテスト実行数に
近づくようなペースを守り、テスト実行管理者はテストの阻害要因が発生した場合は速やかに対処を
行う。そのためには、テスト実行担当者、テスト実行管理者ともに、事前に予定数と予想時間を把握
しておく必要がある。

テスト実行計画で立てたスケジュールに従い、いつまでにテスト完了させるかは事前に確認する。
テスト実行担当者は担当のテストをいつまでに終わらせるかを確認し、テスト完了に向けて1日どれくらいの生産性で進めていくかを認識した上でテストに臨むこと。
テスト実行管理者はテストの阻害要因発生時に、必要に応じて担当者やスケジュールの再調整を行うため、作成したテスト実行スケジュールを基にテストの進捗をモニタリングすること。

テスト実行

学習の目的

テスト実行担当者の心得

① テストの種類、テストサイクルおよび目的と視点を理解する
前項の通り、テストの種類、テストサイクルによってテストの目的や視点が異なる。状況に応じて不
具合の報告対象となりうる事象が異なる可能性がある。
② テストケースやテスト手順の行間を読む
テストの実行は、テスト対象を起動した時から始まる。テストケースの目的を理解し、テスト環境、
テストの事前条件や事後条件など、期待結果として記載されていない部分についても不具合が発生し
ていないかに注意する。
③ 不具合を見逃さないポイントを理解する
テストケースとテストケースの間で不具合が発生することがある。テスト実行担当者は些細な疑問を
残さず、気になる部分を発見した場合にはテスト実行管理者に報告し不具合の見逃しを防ぐ必要があ
る。
④ チームでのテストを実施する意味を理解する
テスト活動はチームによって成立する活動である。進捗の遅れはチーム全体の活動に影響が生じる可
能性があるため、進捗遅れの兆候がある場合は速やかにテスト実行管理者へ報告する。テスト実行管
理者はチーム活動における影響を理解し、チームメンバーの関係性やフォローしやすい体制づくりが
必要である。

①：テスト実行担当者は自分の行うテストがどんなテストかをテスト実行計画書から確認しておくこと。
②：テストケースにのみ焦点を当てるのではなく、テスト対象に目を向け、少しでも違和感のある場所がないか探す姿勢が重要である。
③：テストケースに書かれている内容とは関係ない場所でも違和感のある動作や、前提条件を作る段階で仕様と矛盾するような振る舞いが見られれば、不具合としてテスト実施管理者に報告すること。
④：テストはチーム活動によって成立するものである。例えば、メンバー1人のテスト進捗が遅延している場合、他メンバーが巻取れるようリカバーしやすい体制をとることで、チームで1つのテストに臨めることができる。

事象の発生（遅れ）

一日で消化しなければいけないテスト項目数を消化することが難しい場合、スケジュールに影響を及
ぼす恐れがある。テスト実行担当者は進捗に遅れが生じることがわかった場合、速やかにテスト実行
管理者へ報告する。

テスト進捗に遅れが発生する見込みの場合、テスト担当者は実行管理者に速やかに報告する必要がある。
その際、テスト担当者が注意すべき点は報告するタイミングである。
進捗遅れの報告が1日の最後だと遅すぎるため、1日の目標数に対して到達出来そうにないと思った時点で、テスト実行管理者に打ち上げた方が良い。
私自身の目安としては、テスト開始から2,3時間実行した上で、1時間当たりの生産性を連続して下回るようであれば、テスト実行管理者へ打ち上げを行う。

テスト実行管理者も打ち上げタイミングについて、途中経過をヒアリングするなどの工夫が必要になる。
午前中にテストを開始し、午後から再開する前に現状の進捗をヒアリングする等のコミュニケーションを図ることでより正確なモニタリングが可能となる。

インシデントの発生

テスト実行担当者は、インシデントが発生した際に事象のエビデンス取得、発生内容の確認、再現手
順の確認を直ちに行う。またインシデント報告の手順に従い、再現手順の確定、仕様書やリファレン
スの確認、および発生したテスト内容、事前条件、再現手順、事後条件、発生時の環境、期待動作を
特定する。インシデントは自分の判断で不具合と断定せず、テスト実行管理者の判断を仰ぐ。
テスト実行管理者は、テスト実行者からの報告内容に不足がないことを確認し、ステークホルダー（テ
スト設計者や開発担当者）に確認する。不具合と認められた場合には不具合報告書にて報告する。テ
ストの種類やテストサイクルによって不具合の判断基準が決まることがある点に注意が必要である。

インシデント発生時は、インシデント発生時のプロセスを踏んでステークホルダーへ報告する。
ここでいうプロセスとは、インシデント発生時のテスト担当者のやるべきこと及びインシデント発生時のフローをテスト実行計画に記載し、ステークホルダーへ整合を取ることでスムーズに運べることができる。

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

不具合修正確認テストとは、報告した不具合が正しく修正されているかを確認するテストである。以
下の原則に基づいて実施する。
①不具合修正確認テストは、修正対応された不具合報告書の修正結果を確認のうえ、期待結果の通り
に修正されていることを確認する。修正ミスなどにより期待動作の通りに修正されない可能性がある
ため、不具合修正確認テストの結果が NG になるケースがあることに注意すること。
②不具合修正確認テストの依頼があった場合は速やかに不具合修正確認テストを実施する。また確認
結果を問わず、不具合修正確認テストの結果を速やかに報告する。
③不具合修正確認テストは不具合を報告した本人が実施することが原則である。不具合報告者以外が
確認した場合、不具合の再現条件や手順、期待結果について認識誤りが発生することがある。何らか
の理由により報告者以外が確認を行う場合は、報告者へヒアリングを行うなど、認識誤りが発生しな
いよう注意が必要である。

不具合修正確認テストを行うに当たり、どんなフローで行うかを予めテスト実行計画書に定め、実際にテスト実行の段階で不具合が検出した際、定めたフローに則って不具合修正確認テストを進める。
また、不具合修正確認テストを行う際は不具合を検出した本人が確認を行うこと。

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

テスト実行中、テスト仕様書やテスト対象の仕様に不明点や疑問点がある場合は質問表を利用して確
認する。テスト実行担当者は、質問表へ記載する前に以下の点を確認すること。
・仕様書などのドキュメントに質問したい内容が記載されていないこと。
・他のテスト実行担当者が既に質問している内容ではないこと。

テスト実行中に仕様に関する不明点が出てきた場合、緊急度の高い内容でない限り、質問票などで運用することで不明点を解消できる仕組みを作ること。
また、質問表を作成しても即座に返ってこないこともあるため、ステークホルダーとの定例ミーティングの場で返答を促すようコミュニケーションを取っていく工夫も必要である。

おわりに

次回はテスト実行のシラバス読解の続きを進めていきます。