バグをのぞく時バグもまたこちらをのぞいているのだ（ソフトウェア分析）
バグを捕まえるために
プログラムを走らせると、ときたま期待しない結果が出ます。期待しない画面が表示され、期待しない状況に陥ります。これが、バグが出たということです。人間の期待が間違っていた可能性もありますが、多くはプログラムやデータ、設定を間違えていたのが原因です。
このバグを捕まえるためにどうしているでしょうか。バグの原因を特定し、特定した原因の対処をし、対処方法が妥当であるかどうかを確認するために、試験をするということをしていると思います。本当にご苦労様です。
ここで一番難しいのは、バグの原因を特定することです。難しくて、対応時間や工数を見積もることができません。そもそも滅多に発生しないバグだと、発生待ち、出待ちしなければなりません。発生しやすくするための工夫もしなければなりません。本当にご苦労様です。
バグの原因を探るために
バグの発生ができるようになれば、いよいよバグの原因を探ることになります。ニーチェの言うように、バグの原因を探る時、バグの原因もまたこちらを探っているかもしれません。
バグに悟られずに、バグの原因に影響を与えないように、そっと罠を仕掛けて、バグの原因を探ります。不確定原理により、バグを観測する行為そのものが、バグに影響を与え、バグは不確定になります。そっと、罠をしかけてください。
バグの原因がプログラムのたった1行だけであるときも、設計仕様そのものの間違いであるときも、原因はいろいろあります。ここで言えることは、バグはその作りこんだときに、直ぐに発見できるようにしたいものです。設計のバグなら設計レビューで、プログラムのバグならコードレビューや単体テストで発見できれば、ラッキーです。直す手間が小さくなります。
でも作りこんだときと、それを発見したときが離れているときは、大変です。どのように対処するかで、たぶん悩むでしょう。きっとそこで、手軽な方法を採用し、後悔することになるでしょう。気をつけてください。
バグを管理するために
バグを管理するために、どのようにしているでしょうか。まずはバグ件数をどのように計測しているでしょうか。テストを実施して期待しない結果が出た件数、現象数を管理しているでしょうか。それとも、バグの原因を特定した原因数を管理しているでしょうか。
現象数はテストを実施すれば、機械的に得られる数字です。コストはあまりかかりません。一方、原因数はバグの原因を特定して、やっと原因数が分かります。これを管理するコストもかかります。なお1個の原因で複数の現象を起こすことが多いので、一般的に現象数よりも原因数は小さくなるでしょう。
なお原因数を測るためには、複数の現象が同一の原因であるかどうかを判断する必要があります。このときは同じ「ような」原因であったのを同じ原因とみなすかどうかを後でもめないために決めておきます。そして原因別にカテゴライズした現象は価値があり、後々、役に立つでしょう。
ここで大事なのはバグ管理にコストをあまり掛けないことです。原因数のことをここで紹介しましたが、原因数のデータが集まらないときは現象数で代替することになります。それでいいのです。大事なのは管理することでコストを掛けることではないのです。
バグを飼いならすために
今回はバグの原因を特定し管理することについて考えてきました。でも別の道があります。
バグゼロは神話であり、現実世界ではバグゼロは存在しません（きっぱり）。だからバグはあるものだと決意してください。さらに積極的に考えて、バグが見つかっても、バグの原因を特定せずに、または特定できずに、でも何らかのバグの処置をし、バグを管理する道があります。これがバグを飼いならすことになります。
バグによって起こるであろう不可解な現象に対応できるかどうかです。飼いならすためにはこれが必要です。バグが出現しそうな環境、たとえば、メモリが圧迫されてきたとか、CPU負荷が大きくなったとかが現れたときに、事前に予防線を張るようにします。これもバグを飼いならすことになります。
ということで今日の結論。「バグは手抜きで管理、飼いならせ」以上です。
マンガFAQの引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
いいなと思ったら応援しよう！
