ボドゲを愛するテスト屋さん

ソフトウェアテストとか、ボドゲとかを自由気ままに。

テスト実行進捗管理における躓きポイント

※本記事は、ソフトウェアテスト Advent Calendar 2018 の6日目の記事になります。
前日の記事は、___rina___さんによる、受託開発テスターと受託リモートワークテスターとWebサービステスターの違いに関する記事でした。

underscore42rina.hatenablog.com

 

どうも、今年もソフトウェアテストのアドカレに参加しているオムそばです。
これをキッカケにブログの更新を始めたので、書き始めてちょうど一年になりますね、時間が経つのは早いなぁ...。

 

さて、今回は、ソフトウェアテストのアドベントカレンダー 6日目の記事として、テスト実行進捗管理において、私や周りの人がよく躓いていたポイントをまとめてみようと思います。

 

f:id:teamomusoba:20181206052343p:plain

■躓き1:「1ケース1時間かかるから、1日8件消化できる」

※この項目における1人日は、8時間とします。

テスト実行進捗を管理しようとしたときに、陥りがちなミスがこれ。
1ケースの消化見込みが1時間だからといって、1人1日8件進むと見積もってしまう。
これは大きな誤りで、蓋を開けてみると、遅延や残業の嵐になることでしょう。

テストは(他の作業もそうですが)単純にOKがついていくものではありません。障害の発生や起票、疑問点の発生やヒアリング、問い合わせ対応等々、実行する以外の作業が多数あります。
「それらを加味したうえで1hと見積もっている」という方もいるかもしれませんが、作業が詳細化されていないことに繋がり、結果、見積もりが粗くなることでしょう。粗い見積もりは、テスト期間が長くなればなるほど、差が広がります。

対策としては、例えば「テスト実行6h、不具合対応やその他作業2h」と置いたり、そもそもの見積もりを1人日6時間で見積もったりするとよいでしょう。
あえてその他作業を作ったのは、いわゆる"ゆとり時間"(バッファ)です。

f:id:teamomusoba:20181206054604p:plain
 

■躓き2:「進捗率100%だからオンスケです(そのうちNGは25%)」

進捗率を測るとき、大抵の場合、実施率にはOK、NGが含まれます。そうすると、報告の仕方によっては、一見オンスケに見えることがあります。
しかし、もしも計画の中に、「NG箇所の再テストが考慮されていない」としたら、非常に危険です。

状況にもよりますが、大抵の場合、「NGが発生したら、発生したテストフェーズ中に改修し、再テストすること」が求められているはずです。
不具合が起きて、そのテストが問題ないことを確認せずに次のフェーズに行くことは、大きなリスクとなります。

f:id:teamomusoba:20181206060039p:plain


 

■躓き3:「今日テストする予定だったのですが、テスト環境が止まっていて進めません」

環境に対する考慮を忘れていて計画を立てた場合、こうなりがちです。
テスト環境がいつ構築され、リリースされるタイミングがいつで、メンテが入るタイミングはいつで、テストデータはいつ準備されるか、といった環境を加味したテスト計画を立てないといけません。
もちろん、緊急で止まってしまった場合はどうしようもありませんが。

f:id:teamomusoba:20181206060228p:plain

■躓き4:「進捗遅れています」「理由は?」「よくわかりません」

「わからないこと」というのは、プロジェクトにおいてリスクに該当します。
わからないことにはある一定数、爆弾が潜んでいます。
それらの爆弾がないかを事前に把握して、回避可能か、爆発した時の影響はどれくらいか、爆発した後の対処はどうするか、などを考えておく必要があります。

爆弾があるかないかわからない場所を、実行者に歩かせない、もしくは自分が歩かないようにちゃんと確認しましょう。

f:id:teamomusoba:20181206060335p:plain

テスト実行は、予期せぬ出来事の連続です。

その、"予期せぬ出来事"をいかに"予期してコントロールするか""予期せぬ出来事が起きても致命的な問題とならぬようにするか"が、管理者の腕の見せ所です。

全てのテスト実行進捗管理者が、これらの躓きを起こさないようになるといいなと思います。

 

明日はtakemikamiさんの記事です、お楽しみに!