IVEC Level2試験の傾向と対策を予想します2

この記事は前回の記事の続きです。

・テスト実行スケジュー ルの策定
・テスト環境準備
・テスト実行担当者の管理
・不具合の管理
・テスト実行報告書の作成
・プロジェクトリストの抽出
・探索的テストの管理
・テスト実行の振り返り
本稿では上記の項目について「不具合の管理」「テスト実行報告書の作成」にスポットを当て、シラバスを独自解釈し、解説していきます。

不具合の管理

関連する項目:不具合対応への動機付け,プロジェクト固有の不具合報告書のルールを確認する,不具合報告書の登録時の注意事項(チェック項目)を理解する,不具合報告書のステータス(状況)を管理する,不具合報告書のステータス(状況)の報告

テストのお仕事なので、なんだかんだで重要です。
主に2つの観点で試験が出題されます。
・不具合報告書の品質を担保する
・不具合のライフサイクルをコントロールする

不具合報告書の品質を担保する

ある不具合報告書について、テスト実行管理者として内容を指摘していく問題が出ます。
不具合報告書には優先度、重要度、サマリ、期待値、手順、ステータスなど、様々な記入項目がありますが、ここで問われることは「プロジェクト固有の不具合報告書ルールに合致した評価が設定されているか」です。
例えば、ブロック要因になる不具合であるにもかかわらず優先度が低くなっていたり、プロジェクトとして重要視してない品質に対する不具合にも関わらず重大度が高いといった、矛盾したステータス設定について指摘することが求められます。

不具合のライフサイクルをコントロールする

不具合管理の問題ではこっちの問題がメインになります。
テスト実行管理担当者はテストの進捗や品質に関するタイムリーな情報を正確に開発者様様へ提供する必要があります。
特にテスト実行の中盤以降になってくるとテスト実行とベリファイテストをパラレルに進めていく必要があります。できるだけ早いタイミングで効率よく不具合を摘出し、修正していくためには不具合対応の優先度やベリファイテストの優先度についてきめ細かくハンドリングし、場合によっては(特に試験においては)急かしたりトレースするようなムーブが必要になります。

この問題では、不具合の重要度※と最終更新日と不具合ステータスの状況を確認して、対処が必要な不具合を探し出します。
※重要度と優先度の違いは不明です。まさかseverityを重要度になんて訳さないでしょうさすがに。

対処が必要な不具合の典型的な状態としては、「修正版がリリースされているにも関わらずベリファイテストが実施されていない」「再現手順について実行者へ質問が投げられているにもかかわらず答えられていない」「ブロック要因にも関わらず、開発者が対応していない」などです。
これらの多くは優先度の設定が誤っており、不具合の記述やステータスを十分に読み込んで、誤りを探すことが攻略の鍵になります。

テスト実行報告書の作成

関連する項目:テスト実行工程で実施した作業の記録を報告書にまとめる、テスト実行報告書には、原則的に未報告の項目があるべきではない。この原則を理解する、テスト実行時の問題の発生と実施した対処の記述や次回のテスト実行での対策(未然に 防ぐ為の)を理解する、テスト実行結果の水平展開や垂直展開でテスト実行結果を用いた改善・反映する方法を理解する

この問題はLevel1では出ない様子なので、Level2では確実に出ます。

テスト実行から得られる様々な情報について、ステークホルダ(プロジェクトの予算管理者、設計担当者、開発者、テストマネージャ、テスト設計担当者など※)に対して正確な情報提供することがテスト実行管理者には求められます。
※IVECの世界観ではこれらの上下関係は厳格に定められています。

試験では報告書を書きます。
報告書にはテスト実行件数(OK/NG/未実施/ブロック),摘出した不具合件数,テスト実行中に発生した問題点と解決策,テスト実行工程や体制などに関する次回への要望といった項目を書きます。

これらは「事実に基づいて記載する」ということが重要になります。数字や記載内容の事実と、リスク、問題などの予測は分けて記載してください。
ただし、テスト実行管理者として肌で感じる所感や提言によってステークホルダたちの意思決定を促すようなムーブも必要になります。
これらについてはみなさんが持ち合わせる空気読み力を存分に発揮して臨んでほしいと思います。

今日はここまでです。気が向いたらテスト報告書については続きを書きます。