　近年のソフトウェア開発の短納期化で、しわ寄せがきているのがテスト工程でしょう。テスト工程は、純粋なデバッグフェーズやテストフェーズだけでなく、仕様書、設計書、コーディングでも必要なので、新規開発の工数や時間の40～50％が必要になります。ソフトウェア開発技術者は、日々、膨大なテスト作業と格闘しています。

　テストが面倒で大変なのは、仕様やプログラムを作成する「前へ進む作業」ではなく、「後を振り返る作業」であるためです。「振り返る作業」とは、例えば、テスト項目の作成、テスト実施、評価ですね。「前へ進む」作業であるプログラムの作成よりも大変で、漏れなく完全に検証することは困難でしょう。「バグが無いことが当たり前」、というユーザーの要望に応えるのは簡単ではありません^※1）。

※写真はイメージです

　学生時代の期末テストを思い出してください。期末テストでは、全問解答して、時間が残っていれば、自分の書いた答えが正しいか見直しますが、全部の答えを書いた瞬間にチャイムが鳴れば、「書いた答えが間違っていないことを祈って」提出しますし、難問ぞろいだと、そもそも全問に解答できないこともあり、「難しかったな。もっとまじめに試験勉強しとけばよかった」と少し後悔します。プログラム開発ではこれは許されません。制限時間内に（開発期間内に）、全部の問題を解答し（全機能を実装し）、答えが正しいことをチェックする（プログラムの検証をする）必要があります。社会人は大変なのです。

　テストでバグが見つからなければ、相応の作業量をこなすだけで、大きな苦労はありません^※2）。Excelにテスト項目を記述し、結果を確かめ、評価をします。バグが見つからなければ、すぐに終了するフェーズですが、現実はそう簡単にはいきません。大抵は、何らかのバグが見つかります。

※1）プログラムを作った経験がない人に、「世の中のソフトウェアにはバグが無いものはありません」と言うと、驚かれることがあります。そんな時、「誤植がない本はほとんどないのと同じです」と言うのですが、なかなか納得してもらえません。競合他社が多数存在するIT業界では、そんな人の期待に応えて、短期間で高品質ソフトウェアを開発するのは簡単ではありません。

※2）テストで一番つらいことは、バグが見つかった時の原因の特定です。日々のスケジュールが切り詰められていく中、バグの原因を探す時は、胃がよじれるように苦しいものです。逆に、全くバグが見つからない場合は、「何のためにテストしているのだろう」と感じたり、「バグを見つける能力のないテスト項目なんだろうか？」と不安になったりします。

　バグの原因の特定にはエンジニアの腕とセンスが問われます。今までの知識と経験から、バグの原因を限られた時間と情報から見つけねばなりません。場合によっては、保守フェーズのように、開発した時とは別のエンジニアがソースコードを見ることもあります。他人が作ったプログラムのバグの原因を見つけ、最善の解決策を提案するためには、長年の経験と知識が必要です。

　今回は、第三者が作った「三角形の判定」に関するテストの問題を出題します。保守を担当したプログラムの中にバグがあるという設定です。さまざまな所にバグが隠れています。以下のステップを実施し、バグをシステマチックに検出してください。