バグレポートでテストエンジニアとプログラマが持つ“認識の違い”を埋めるには

ここまでで、バグレポートの項目の定義により、コミュニケーションのオーバーヘッドを減らすための方法を紹介しました。完了プロジェクトの結果から将来のプロジェクトに役立つ改善を目指しています。

以降では、同一プロジェクトのテスト実施に先立って事前合意をしておくことによって手戻りを減らす方法を紹介します。求められる品質やプロジェクトの背景が伝えられず、少しずれたテストになってしまったなぁと感じたことはないでしょうか。例えば、以下のような状況です。

テストエンジニアA：
「よくテストできていると思うけど、印刷機能に不備が多いなぁ。もともと計画しているテストに加えて、もう少し細かくテストした方がいいな。」

レポート1

レポート2

レポート3

レポート4

プログラマB：
「妙に印刷機能を細かくチェックしたテスト結果が届いているな。テスト結果自体は細かくチェックしてもらっていて、どれも修正しないといけないレベルではあるけど、今回のシステムは、まだIT化できずに残っている書類による業務を完全にペーパレスに置き換えるためのものだから、印刷機能の優先順位はそれほど高くないんだけど・・・。別の機能のバグ修正もあるし、対応の優先順位を下げたいなぁ。最初に十分打ち合わせしておけば、こうはならなかったなぁ。」

このような行き違いはなぜ起きてしまうのでしょうか。

認識の違いを明確にできていない

十分に意思疎通できていない場合には、上記のようなやりとりが起こってしまいます。テストエンジニアは「せっかく少し深追いしてバグ出しして、よりよい品質になるよう手間をかけたのに・・」という思いがあるでしょうし、プログラマは「そこよりももっと時間をかけてもらいたいところがあるんだけどなぁ」という思いもあるでしょう。

特に、テストエンジニアが開発プロジェクトの途中から合流してくるような場合には、プロジェクト計画、品質計画、仕様書に明示的に書かれていないことが伝わらず、前のページのようなやりとりが起きてしまいます。企画部門や顧客・ユーザとはもちろんのことですが、テストエンジニア側とプログラマ側で求められる品質やテストに配慮が必要な部分を事前に合意しておくことが大切です。

プロジェクト計画やテスト計画の時点で品質やテストで確認すべきことについて相談しておくことが重要ですが、テストエンジニア、プログラマだけの思いだけですぐに変えることは難しい場合が多いでしょう。そこで、以下ではテスト計画の時点でもテストを実際に実行しはじめた時点でも通用する、すりあわせの方法を紹介します。

テスト計画の相談時や少しだけテストを進めた後ならば具体的な議論ができる

とはいえ「ドキュメントに書いていないけれどもテストで注意すべきことは何ですか？」と聞かれてすぐに回答が出てくることは少ないでしょう。テストの項目を列挙して実際に実施するテストを選んでいく計画時点や少しだけテストを実施した後のように、具体的な題材が手元にできた時点ですり合わせることをお勧めします。

いかがでしたか。普段あまり意識せずに作成、参照しているバグレポートも見直すと改善の余地がいろいろと出てきます。本記事がそのきっかけになれば幸いです。

筆者も参加しているバグ票ワーストプラクティス検討プロジェクトでは、皆さまの周りにある困ったバグ票の事例を募集しています。集めた事例から知見やガイドラインを作り、公開することを目指しています。ぜひアンケートにご協力ください。
→　バグ票ワーストプラクティス検討プロジェクト