サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

改善 旧館より 開発プロセス

テストにおけるバグレポートの書き方

投稿日:2008年4月6日 更新日:


あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。

具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断することです。

それらのバグレポートを管理するツールとしてRedmine(使い方はこちら)を使っていました。

そのバグレポートの書き方、テスターとしてのTipsのようなものを少し書いてみます。
#再現手順、発生したソースのリビジョン、可能であればエラーログやスタックトレースを書くなどは当たり前の前提です。

1:実装者の感情面を理解して書く

その機能のプログラマとテスターが異なる場合、何度か同じようなバグに遭遇しているとレポートには「同様の機能でも同じバグが出ていました。きちんと内容の再チェックをお願いします。」などと書きたくなったりします。

実際には正しい行為なのかもしれませんが、重箱の隅をつつくようなバグを見つけ、バグレポートを無慈悲に起票するテスターの存在はプログラマーにとって気持ちの良い存在で無いと感じる人も多いようです。
正確な比喩ではありませんが、(例えそれが正当な内容であっても)自分の作品に「ケチ」をつけられるわけですから。

忙しかったりするとついテスターに向かって「テストのやり方が間違っているんじゃないの?もう一度確認してみてよ!」と感情的に答えたりして、テスターも「(品質の)いい加減なプログラムだからバグになるんでしょ」と応酬が始まってしまいます。こうなると品質の維持、担保などできません。

なので以下を参考にしたりして配慮した書き方をしてみませんか?という提案です。

2:技術面では客観性と主観を混ぜずに書く

1や3に通じるのですが、テストをしていると「あれ?自分の理解ではAと思うが、Bになるな」ということがあります。
そのような場合、バグレポートに客観的に書く部分と主観の部分が混じってしまうことがあります。

管理者としては、客観的な事実(テスト結果)を過不足なく知りたいわけです。
それを読み取れにくくなる主観と客観が入り混じったバグレポートは「テスターへの確認」という余計な時間が取られる存在になります。

もちろん「こう思う」とか「これでテストケースが失敗しているのだから、類似の機能も見た方が良いと思う」という主観を気づきとして書くのは非常に良いことで、問題なのはその書き方です。

3:本来どうあるべきかも書く

テストケースには「~となること」と合格条件が記述しており、「本来どうあるべきか」が明確になっています。

テストフェーズ中では(偶然にせよ)テストケースにない操作の結果、明らかにおかしかったり、「これは仕様と違うのでは?」という動きを見つけることもあります。
その時のバグレポートに「これこれが発生」という事象だけではなく、「本来は~であるべき」とあるのが良い書き方だと考えています。
その根拠となる設計書などドキュメントへのポインタがあればより良いです。

4:修正時に「なぜ?」(真因)を書く

テストフェーズ全般のTipsとして、修正時にバグレポートに対応内容などを書き込みますが、その時に「修正しました」だけでなく「なぜ」そのバグが発生した(混入した)のかという理由もあると未来の類似不具合の防止にもなります。

例えば、条件分岐の書き方を間違えていたとして、それが言語仕様を理解していなかったことがその根本であれば、同様の記述が無いかgrepしてみたりするアクションをするのも良いと思います。

また、設計書の記述を誤解していたのであれば同様の誤解をしていないかどうか、他のメンバーに確認してみたり、言葉なの揺れなどが見つかれば、記述を修正する必要があるかもしれません。

テストフェーズを意義あるものに

どうしてもテストフェーズは後の工程になり、スケジュールにも余裕がないことが多く、開発メンバーはそれまでのプログラム工程で疲弊していることも多々あります。
#それはプロジェクトマネジメントとしては失敗なのですが。

ただ上に書いたような点に少しでも留意すれば、品質の担保をできる最後の砦であるテストフェーズを意義あるものにできるのでは?と思っています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像:http://www.flickr.com/photos/sajith/3161725149/

-改善, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ[読書感想]

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ 著者:横田 尚哉 問題解決がテーマの本は色々読みましたが、その中でも良書の部類に入ると思います。 ポイント …

「先読み力」で人を動かす(リーダーのためのプロアクティブ・マネジメント)[読書感想]

「先読み力」で人を動かす(リーダーのためのプロアクティブ・マネジメント) 著者:村中 剛志 ◆目次 序 章 先読み力ってなに? 第1章 あなたの先読み力を知る 第2章 先読み力を鍛えるタイムマネジメン …

リーダーには説明責任がある

リーダー『論』なんていう大げさな話題ではありませんが、数年前、ある上司と「リーダーとメンバー(特にサブリーダー)との関係」について話したことをふと思い出しました。  「目的を達成するために人を動かす必 …

UltimateAgileStories1で書いた内容

最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊 …

自分のテンションを維持する方法

コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。 #CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。