バグ検出ドリル（20）「三角形判定」のテスト項目を設計できますか【出題編】：山浦恒央の“くみこみ”な話（120）（1/3 ページ）
バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第20回と第21回は、「三角形を判定」するプログラムのテスト項目設計がテーマです。まずは今回の出題編を読んで、じっくり問題に取り組んでみてください。
1．はじめに
本連載では、エンジニアのバグ検出力の向上を目指し、バグ入りの問題を出題して読者のみなさんに見つけていただいています。今回は、テストの演習です。バグ入りのプログラムを出題しますので、テスト項目を作成し、バグを見つけていただきたいと思います。
2．ソフトウェアのテスト
近年のソフトウェア開発の短納期化で、しわ寄せがきているのがテスト工程でしょう。テスト工程は、純粋なデバッグフェーズやテストフェーズだけでなく、仕様書、設計書、コーディングでも必要なので、新規開発の工数や時間の40〜50％が必要になります。ソフトウェア開発技術者は、日々、膨大なテスト作業と格闘しています。
テストが面倒で大変なのは、仕様やプログラムを作成する「前へ進む作業」ではなく、「後を振り返る作業」であるためです。「振り返る作業」とは、例えば、テスト項目の作成、テスト実施、評価ですね。「前へ進む」作業であるプログラムの作成よりも大変で、漏れなく完全に検証することは困難でしょう。「バグが無いことが当たり前」、というユーザーの要望に応えるのは簡単ではありません※1）。
学生時代の期末テストを思い出してください。期末テストでは、全問解答して、時間が残っていれば、自分の書いた答えが正しいか見直しますが、全部の答えを書いた瞬間にチャイムが鳴れば、「書いた答えが間違っていないことを祈って」提出しますし、難問ぞろいだと、そもそも全問に解答できないこともあり、「難しかったな。もっとまじめに試験勉強しとけばよかった」と少し後悔します。プログラム開発ではこれは許されません。制限時間内に（開発期間内に）、全部の問題を解答し（全機能を実装し）、答えが正しいことをチェックする（プログラムの検証をする）必要があります。社会人は大変なのです。
テストでバグが見つからなければ、相応の作業量をこなすだけで、大きな苦労はありません※2）。Excelにテスト項目を記述し、結果を確かめ、評価をします。バグが見つからなければ、すぐに終了するフェーズですが、現実はそう簡単にはいきません。大抵は、何らかのバグが見つかります。
※1）プログラムを作った経験がない人に、「世の中のソフトウェアにはバグが無いものはありません」と言うと、驚かれることがあります。そんな時、「誤植がない本はほとんどないのと同じです」と言うのですが、なかなか納得してもらえません。競合他社が多数存在するIT業界では、そんな人の期待に応えて、短期間で高品質ソフトウェアを開発するのは簡単ではありません。
※2）テストで一番つらいことは、バグが見つかった時の原因の特定です。日々のスケジュールが切り詰められていく中、バグの原因を探す時は、胃がよじれるように苦しいものです。逆に、全くバグが見つからない場合は、「何のためにテストしているのだろう」と感じたり、「バグを見つける能力のないテスト項目なんだろうか？」と不安になったりします。
バグの原因の特定にはエンジニアの腕とセンスが問われます。今までの知識と経験から、バグの原因を限られた時間と情報から見つけねばなりません。場合によっては、保守フェーズのように、開発した時とは別のエンジニアがソースコードを見ることもあります。他人が作ったプログラムのバグの原因を見つけ、最善の解決策を提案するためには、長年の経験と知識が必要です。
今回は、第三者が作った「三角形の判定」に関するテストの問題を出題します。保守を担当したプログラムの中にバグがあるという設定です。さまざまな所にバグが隠れています。以下のステップを実施し、バグをシステマチックに検出してください。
- 全ての機能に関して、「同値分割」「境界値分析」などの手法で、自分なりのテスト項目を作成する（今回のドリルの主目的がこれです）
- バグが見つかった場合、原因を特定する（再現条件を明らかにする）
- バグを修正する
- バグが正しく修正されたことを確認する
なお今回は、解答、解説までを全て掲載すると長くなるので、問題だけを出す【出題編】になります。次回の【解答編】まで、じっくり問題に取り組んでください。
Copyright © ITmedia, Inc. All Rights Reserved.