« イタチ | メイン | 不具合の修正 »

2008年10月05日

不具合の記録

ソフトウェアを完成されるためには、不具合を見付け修正する必要がある。
実際の開発に携わったことがないような人の場合、不具合の改修プロセスがぐでぐでで、それはダメだろうと思うこともあるので、書いてみることにした。
後、issue 管理システムへつなげるためにも。

まず、テストなどで見つかった不具合は全て記録しておく必要がある (不具合が記録され、公開されることを以降、起票という)。
記録する内容には、不具合の内容を端的に表したタイトルと日付、発見者、発見したソフトウェアのバージョン、不具合内容詳細、発生した状況、再現手順が最低限必要。
この他現場によってより詳細な記述が必要な場合も多い。

日付はソフトウェアバージョンや再現手順に影響するのと、不具合の収束を見るために必要。

発見したソフトウェアのバージョンは、テストしているソフトウェアのバージョン。
テストする時は、基本的にソフトウェアのバージョンを固定して行う。
テスト量が膨大でテスト期間が長い場合などは日々バージョンを更新したりするが、その場合は影響範囲チェックなどを念入りに行う必要がある。(影響範囲チェックは次回にでも書く)
ただし、その場合も必ずテストした時のバージョンのソースコードを取り出せるようにしておく。
バージョンが異なってしまうと不具合が再現できなくなってしまったりするので、テスト時のバージョンの取り扱いは重要。
そのため、バージョン管理システムは必須ともいえる。
バージョンなど気にせず適当にテストしているところなどもあるが、それは避けたほうが良い。

発生した状況は、その時行った操作や保存してあったデータを出来るだけ細かく記録する。
再現しない場合は、特にこの記録内容が重要。

再現手順とは、その不具合を発生させるための手順。
不具合を見つけたら、まずその時の状況を記録し、次に再現を試みる。
再現できないような不具合は、基本的に修正されないので、再現させることは重要。
再現は、発生した時の状況を繰り返し、もう一度同じ不具合が発生するかどうかを確認することで行う。
同じ不具合が発生したとしても、中には無駄な手順が入っていることもあるので、出来るだけそのような操作は取り除く。
そのため、少しずつ手順を削って同じ不具合が発生する最小の手順を見付けていく。
なぜ最小限の手順にするかと言うと、それによって不具合の修正の手間が大きく軽減されるから。
自分でプログラムを作った直後などは、不具合を見てある程度見当が付く場合もあるが、時間が経っていたり、他者が作ったものである場合などは、なぜ発生するのか見当が付かない場合がある。
このような場合、再現手順の各プロセスに関連するソースコードを順に確認していく(以降、ソースを追うと言う)。
当然、手順が多ければ多いほど追わなければならないソースコードが増えて、確認に時間がかかる。
そのため、再現手順は出来るだけ最小の手順にしておく必要がある。

もし、再現を何度か試みても発生しない場合も起票はしておく。
再現しない不具合は修正されないから起票せずに放置しておけと言われる場合もあるが、起票しておいた方が良い。
そして、この再現しない不具合の取り扱いは現場によるが、3通りくらいの方法があると思う。
まず、再現試験を行う方法。
再現試験とは、起票された不具合の発生手順を何度も繰り返し、再現を試みること。
不具合箇所を担当したプログラマがいるのであれば、その人に聞くとたちどころに見付かる可能性もある。
(テストと開発を同じ部署で行っているような場合は、再現出来た時、再現できない不具合を見付けた時、まずはプログラマに相談すると起票内容の精度が上がるし、その後の取り扱いもスムーズに進む)
見付からない場合は、不具合によるがタイミングを変えたり、手順を少し変えたりしてみて再現を試みる。
(プログラマに相談すれば、ある程度試験の方針が決まる)
何度も再現を試みても発生しない場合は、その不具合は close する。
(close とは、起票された不具合を以降取り扱わないことを意味する。不具合が修正され、修正が確認されて close されるのが理想)
何度再現を試みるかは不具合による。
タイミング系の不具合の場合は、多くの回数が必要。
実際の回数は経験の豊富な上長判断になるが、数十回や数百回は普通に行う。

次に、観察扱いにする方法。
みんなに知ってもらって、もう一回発生したら教えてねと言っておき、次回発生した時に修正する。
開発の最終段階になっても発生しない場合は、なかったことにして close してしまうことが多い。

最後に無視する方法。
再現できない不具合はないのと一緒という事で、ないことにしてしまう。
さすがにこれはどうかと思うが、そういうこともある。
試験者がプログラマの場合、この不具合はどうしようもないなと思った場合など、起票自体しないこともある。

不具合の発見から修正手順を全て書こうと思ったけど、長くなったので今回は発見部分のみ。

投稿者 Takenori : 2008年10月05日 10:58


トラックバック

このエントリーのトラックバックURL:
http://kaede-software.com/mt/tb-ping.cgi/1726


Total : Today : Yesterday :