※本記事は、ベリサーブアドベントカレンダー2021 4日目の記事になります。
どうも、オムそばです。
「ソフトウェアテストなどプロダクトの品質向上にかかわる内容を書いていきます！」というベリサーブアドベントカレンダーの理念に反しちゃうかもしれませんが、今回は「テスト実行進捗報告」についての記事を書きたいと思います。
一応テストに関することだから、許してほしい。(誰に)
記事の概要
- なぜこのテーマを選んだか
- そもそもの進捗報告の目的とは何か
- テスト実行進捗報告のよくない事例を紹介
- 具体的にどの点が問題かを洗い出す
- 問題に対する解決策の例をあげる
なぜこのテーマを選んだか
ここ数年、テスト実行進捗報告をあげる立場だったり、受ける立場だったりと、私の仕事は常にこの進捗報告という作業と共にあったといっても過言ではありません。
おかげさまで、報告を受ける側が、どういったところを気にしているか、どういったところにツッコミを入れるかなど、ある程度わかるようになってきました。
ツッコミを受ける立場からすると、せっかく一生懸命データを拾い集めてきて報告しているのに、やり直しになるし、怒られるし、嫌ですよね。
今回の記事では、"報告を受ける側が気にするポイント"をご紹介することで、そんな嫌な思いをするテストエンジニアを少しでも減らせればと思っています。
進捗報告の目的とは何か
当たり前の話ですが、テスト実行に限らず、進捗報告には目的があります。
私が考える進捗報告の目的ですが、"仕事(作業)の出し手に対し、仕事の状況を正しく伝達する""仕事の出し手（スポンサー）のみならず、プロジェクト関係者全員（ステークホルダー）に進捗状況を正しく共有すること"です。(12/6 更新)
何を当たり前のことをと思っている方が多数だと思いますが、実際の現場では、「自分が報告したいことを報告する」人が散見されます。
大切なのは、誰のための報告なのか、だと私は考えております。
テスト実行進捗報告の例
前段でお伝えした、「自分が報告したいことを報告する」例を一つあげます。
[前提]
- PRJ責任者に対し、総合テストのチームリーダーが日に1度のテスト実行進捗報告を行う。
- PRJ責任者は実際のテスト現場は基本的に見ておらず、本報告で1日の状況を把握する。
[報告内容]
- 今日は総合テストを50件実施（実施率5％）しました。
- バグは2件でました。
- 進捗はちょっと遅れ気味です。
具体的にどの点が問題かを洗い出す
さて、問題ありありの報告だったと思います。
この報告の中にどういった問題が潜んでおり、どう是正していくか、考えていただき、この後の記事を読んで答え合わせをしていただければと思います。
[問題点]
①全体の件数のうちどれくらい実施したかが明確になっていない。（テストの全体像が見えない）
②OK率が報告されていない。（テスト品質が見えない）
③報告している件数が当日の実施なのか、累計なのかが不明（曖昧な記述がある）
④進捗の遅れが定量化されていない。（定性的な報告は受け手によって認識がぶれる）
⑤バグの全体状況が報告されていない。（テストへの影響が見えない）
⑥遅れに対するリカバリー計画が報告されていない。（遅延の解消目途がわからない）
※他にもあるかもしれませんので、周りの方とぜひディスカッションしてみてください。
問題に対する解決策の例をあげる
現場によって、ステータスのルールや、テスト管理ルールなどあると思います。
そのため、以下の解決策は一つの例だとお考え下さい。
どうすれば誤解がでないよう、正しく情報が報告を受ける側に伝わるか、それを忘れなければ、例と違う解が出てもよいと考えます。
[解決策]
①報告は、総件数、予定数、実績数(OK/NGなど) を報告する
②実施率の他に、OK率を報告する
③誤解を生まないよう、複数の意味を持つ言葉を除外する。
（例：実施数⇒当日の実施数（OK + NG））
④定性的な表現や、主観的な表現は避ける。
（ちょっとの遅れ⇒0.5人日遅延 or 30件遅延 or 進捗率（80%））
⑤バグの総数、オープン中の件数、今週の発生数。それ以外で、クリティカルなバグを合わせて報告されるとよい。
⑥リカバリー策を立てる。先週から対応している場合は、リカバリー策の状況を報告する。
※ほかにも、ネクストアクションや、リスクが簡潔に報告されているとよい。
最後に
どんなに良いテストができても、仕事の出し手(多くの場合はPM)にその成果をうまく報告できなければ、評価されません。
うまく報告できないと、追加で調査が必要だったり、報告の修正の手間が増えたりと、報告者の負荷はどんどん高まっていき、やがて潰れてしまいます。
そうならないよう、上記のポイントをおさえて、スマートに報告できるようにしましょう。