バグが見つからないのはいいことか？（355号）

システム開発は人が行う作業です。
ですから、ミスや誤解は必ず生じます。

こういったミスや誤解のことをバグと呼びます。

バグが実運用に入ってから見つかると困りますので、バグがないことを運用に先立って確認する作業を行います。
これをテストと呼びます。

今回は、テストとバグのお話をします。


1. テストって学生の時の？

定期テストや入学試験で良い点数を取ることは（もしくは追試を受けないようにやりすごすこと）は学生にとって重要なテーマです。

学生にとってのテストは自分自身の勉強の成果を評価する場でした。

システム開発にとってのテストは、プログラムだったり仕様書だったりデータだったりといった開発の成果を評価する作業のことです。

学生テストでは、学生自身がテストを受けますが、システム開発でテストを受けるのはヒトではなく開発成果物です。

例えば、プログラムを動かしてみて、意図したとおりに動くかを調べる、仕様書に必要なことがもれなく記載され、矛盾がないかを調べる、必要なデータ（取引先や過去のデータ）が正しく投入されていることを調べる、といった作業を行ってミスや誤解がないことを確認します。

テストで見つかった不具合のことをバグ（Bug:もともとは南京虫のことで、小さな不必要なものを指すようです）と呼びます。

ちなみに、テストもバグも現在では一般的な表現ですが、テストを試験と読んだり、バグを障害と呼ぶことも多いです。


2. テストってどうやってやるの？

システム開発でのテストというのは言ってみれば単純な作業です。
実際に業務で使いそうな手順を試してみて、結果が正しいかを確認する作業です。

プログラムを作ったり設計するのは、いかにも技術が必要そうですが、テストなんて誰でもできそうに思います。

ところが、これが意外なほどやっかいな作業なのです。

そもそも「使いそうな手順」ってなんでしょうか？
また、「結果が正しい」ってどうなれば正しいのでしょうか？

そう。テスト対象となる手順はナニか？どうなれば正しいと言えるか？といったことを事前に「正確に」決めておかないといけないのです。

実際のシステム開発ではテストの前に入念な準備を行います。

まず、テスト仕様書（試験仕様書）を作ります。

それも複数の視点でのテスト仕様書を作成します。

各プログラムの動作確認は単体テスト仕様書で、複数のプログラムを連携させる時の動作確認は結合テスト仕様書、さらにそれが業務として問題ないことを確認する総合テスト仕様書（システムテスト仕様書、運用テスト仕様書）といったものを作成します。

それぞれの仕様書には、それぞれどんなデータを用意して、どんな手順でテストを実施して、結果としてどんな値が得られるのか？といった手順と期待する結果を書いておきます。

3. （余談）自動テスト

余談となりますが、最近は自動テストという技法が一般化しつつあります。

2000年以前は、テスト仕様書は全て文書化し、修正を行うたびに手作業でテストするのが当たり前でした。
2000年以降（特に2010年以降かな）は効率的なテスト技法がいろいろと考案され、自動テストが採用されることが増えています。

せっかくコンピュータ使うんだから、テストをコンピュータ自身にさせようという発想です。
こう書くと「そうかAIを使ってテストをさせるのか！」と早合点する方もおられるかもしませんが、そうではありません。

ここでいうテスト専用プログラムというのは、人が手作業で作るものです。
「こんな値を与えれば結果はこうなるのが正しい」ということをAIに理解させ、自動的にプログラムを作成させることは（現段階では）難しすぎるからです。

テスト専用プログラムというのは「この値を与えられた時は、こうなる」という計算を考えらえる限りのパターンで羅列したプログラムになります。
かなり泥臭いプログラムで、作るのは非常に面倒くさい作業です。

このテスト専用プログラムが効果を発揮するのは、バグ対応などでプログラムを修正した時です。
それまでなら、実際にプログラムを何度も動かして人手でその修正に誤りがないことを確認していたわけですが、テスト専用プログラムがあれば、それを動かすだけで、後は事前に作っておいた全パターンでテストを行ってくれるというわけです。

テスト専用プログラムを作る手間と、修正を行う都度手作業で修正確認をする手間とどちらが大きいんだ？という話ですが、最近はテスト専用プログラムの方が圧倒的に効率的だという評価が定着しつつあります。


4. バグは見つかる方がいい？

ちょっと前置きが長くなりましたが、今回の本題です。

果たしてバグは見つかった方がいいのでしょうか？
それとも、見つからない方がいいのでしょうか？

たくさんバグが見つかったらどうでしょうか。
たくさんのバグが修正できるわけですから、バグの少ないプログラムになりそうです。

では、全くバグが見つからなかったらどうでしょうか？
ひょっとすると、もともとバグが少ない優秀なプログラムだったのかもしれません。

一体、どちらが正しいのでしょうか？

これ、どちらもあり得るのですが、通常は前者のパターンが圧倒的に多いです。

人はミスをするものですから、バグがないことはまずありません。

「バグが見つからない」のと「バグがない」は全く違うことです。

バグが見つからない時には２つのパターンが考えられます。
　A. テスト仕様書の質が高く、プログラムの質も高い
　　→バグがない
　B. テスト仕様書の質が低い。プログラムの質は関係ない
　　→バグが見つかっていない

パターンAに該当するなら素晴らしいことです。本当にバグが少ない優秀なプログラムといえますが、こんなことはめったにありません。

パターンBは本当によくあることです。テスト仕様書の質が低ければ当然ながらバグは見つけられません。「バグがない」ではなく「バグが見つけられていない」のがポイントです。

ですので、新人さんが「テストを行いました。バグは見つかりませんでした（えっへん）」などと報告すると、リーダさんは「テスト仕様書を見せろ。オレがチェックする」となるのが通常です。

これはベテランであっても同様で「テストを行いました。バグは見つかりませんでした（がっかり）」と報告すると、リーダさんは「えええ、それはマズいなぁ。テスト仕様書を見直すか。オレもいっしょにチェックするわ」となります。

要は誰がやろうとパターンＢを前提とする方が安全なわけです。

このあたりは統計学の領域です。
確かにプログラムは人が作るものですので、人によってバラツキはあります。
ですが、全体としては、意外なほど統計学の常識にあった結果となります。

ベテランや優秀な人がたくさん参加していたとしても、意外にバグの検出率というのは変わらないものです。


5. バグが見つかるのはおかしい

ところが、世の中には「そもそもプログラムにバグがあるなんておかしい。作ってる奴の気がたるんでる。真剣にやれ！」という方がおられるのもまた事実です。

ですが、ここには誤解があるように思います。

このような発言をされる方は「ミスが許されない業務」と「ミスの検出が重要な業務」を混同されているように思います。

確かに一歩間違うと重大な結果を招くミスというのはあります。

例えば、飛行機の整備作業などがそうです。
ですから、飛行機整備では一つのミスが致命的な結果（墜落など）を引き起こさないように幾重にも安全確保を行っています。
こういった事業は「ミスが許されない業務」と言えます。

ですが、ミスを正しく検出することが重要な業務もあります。

例えば、製造業での不良検出がわかりやすいでしょう。

製造業では製造時の不良検出をとても重視します。
不良品を出荷してブランドに傷をつける方が大変だからです。
もちろん、製造不良を検出すれば、その発生原因を調査して対策を取られます。

これは、システム開発でのバグも同じです。
バグは検出すべきものですし、検出したバグは発生原因を突き止めて対処しなければなりません。

製造業やシステム開発では「ミスは許されない」ものではありません。

製造業では出荷前にミスを検出することが重要です。

同様にシステム開発では運用前にミスを検出することが重要なのです。


6. まとめ

システム開発では、作ったプログラムなどのテストを必ず行います。

それによって、意図しない動作や、間違った計算結果などのバグを検出します。

バグはどんなシステムであっても存在しています。
特にプログラム規模が大きくなればなるほどバグの検出は難しくなります。

これは、複雑なプログラムになればなるほど、動作パターンが爆発的に増えてしまうため、全てのパターンのテストが行えなくなるためです。

一般にバグが見つからないプログラムは質が高いように思いがちですが、むしろテストのやり方が悪いためにバグが見つかっていない可能性の方がずっと高いです。

つまり、バグは潜んでいるけれど、テストのやり方が甘くて検出できていないということです。

中には「バグが見つかるなどありえない」といった発言をされる方もおられますが、バグは見つけるべきものですし、見つかったことを喜ぶべきものです。

ちなみに、いつまで経ってもバグがなくならない（修正しても修正しても次々とバグが見つかる）ケースもありますが、これは元のプログラムの質が悪すぎることを示しています。
このようなプログラムは品質だけでなく作り方に問題があることも多いのです。
こんな場合は、全てを捨てて最初から作り直す場合もあります。

今回はテストとバグの関係についてお話しました。
次回もお楽しみに。

（本稿は 2024年5月に作成しました）