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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者:


comment

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

関連記事

会社を移ることになりました

2012年6月末で会社を移ることになりました。 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。 思い出1:Rubyとの出会い 入社後しばらくして …

マルチスレッド

仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 …

テスト工程

…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。 今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。 しかし現実は単体テスト …

【引継ぎ】タスクへの考え

 『トラックナンバー』について以前書きました。 そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。 ほとんどのプロジェクトでは、後工程に …

報告を受ける側も少しだけ努力してくれるとウレシイ

上司、また年に1,2回しか会話を交わさない(そもそもそんなに会わない)ような、えらい人に報告をする時に「報告を受ける側も少しだけ努力してくれるとみんながハッピーになれるなぁ」と思いました。 報告のセオ …

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