ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第7回は、プログラムのバグを見つける作業である「テスト」がテーマです。テストの作業次第では逆にバグを作り込むこともあり、「テストのテストのテスト」のように無限ループに陥りかねません。
バグ百科事典では、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。
ソフトウェア開発の中で、非常に重要で、同時に、粘りと根気が必要なフェーズが、テストです※1)。このフェーズでは、作成したソフトウェアにさまざまなデータを入力し、出力結果が期待値と一致するか確認します。
※1)米国に駐在している時に、「米国式のソフトウェア開発」にドップリ漬かり、いろいろ考えました。一般に、日本人のソフトウェア開発エンジニアは、「作ったら検証する」という「確認のための後戻り」をしながら、階段を一段ずつ上るように確実に進めることが非常に得意ですね。その反面、一挙に階段を幾つも跳び越して、誰も考えなかった新技術を見つけるのが苦手です。米国人のソフトウェア技術者は、「一歩一歩確実に進める作業」や「後戻り」が不得手で、発想を大きく飛ばし、夢物語的なアイデアを考えるのが大好きです。
米国人技術者の「国民性」が、「自由を求める」と「常に称賛を期待する」であり、ソフトウェアの新製品開発では「新規性」と「次世代のとがった先端技術」を重視します。キーワードは「挑戦」で、企画会議では斬新な製品がどんどん出てきます。ほとんどが「斬新過ぎる」か「実用的でない」ため、製品化しても全く売れませんが、数千個の「クズ石」の中に、ダイヤモンドが1つ混じっているのです(ギャンブルですと、超高配当の大穴狙いですね)。これが「インターネット」や「スマートフォン」であり、次世代を引っ張る画期的な技術となります。
日本人のエンジニアの「国民性」は、「正確さを求める」と「安全を優先する」であり、ソフトウェアの新製品の開発では「工業化」と「安全」を重視します(ギャンブルですと、低配当ながら当たる確率の高い本命狙いですね)。キーワードは、「確実であること」で、冒険をおかさないありきたりの製品企画となり、アメリカで発明した斬新な技術の後追いになったりします。
確実に製品を作る工業化は苦手だけれど、斬新な製品を考えつく米国と、発想を飛躍させるのは苦手だけれど、高品質の製品を着実に作る日本。両者がうまく融合できればと、いつも思います。
例えば、次のプログラムを例として考えます(リスト1)。
/* 2つの入力値から合計を求めるプログラム(ex1.c) 仕様:2つの数値をスペース区切りで入力して、合計を求める。 */ #include <stdio.h> main() { int a, b; int sum = 0; printf("2つの入力値を入力してください\n"); scanf_s("%d %d", &a, &b); sum = a + b; printf("合計 = %d\n", sum); }
リスト1は、2つの入力値の合計を求めるプログラムの例です。上記のプログラムのテストとして、以下のテスト項目を作成するとします。
No. | テスト入力 | 期待値 | 良否 |
---|---|---|---|
1 | 10 20 | 30 | 良 |
2 | 100 30 | 120 | 否 |
リスト2 テスト項目作成例 |
テスト担当者は、リスト2のようなテスト項目を作成、実施し、期待値と一致することを確認します。例えば、「10 20」を入力し、結果が正しく30となるか確認しますね。なお、例題のプログラムでは異常処理は考えていませんので、あくまでも例題とお考えください。また、テスト項目のフォーマットも組織によって異なります。
テストは、プログラムのバグを見つける作業ですが、作業次第では逆にバグを作り込むことがあります。例えば、テスト項目を間違えて記述したり、良否の判定を間違えたりする場合です。
テストのバグの大半は、数件の再テストで済むのですが、内容によっては全件再テストとなる可能性があるため注意が必要です。
テスト項目にバグがあるのなら、「テストのためのテスト」が必要でしょうか? 必要と考えると、「テストのためのテスト」にもバグがあり、「テストのテストのテスト」のように無限ループします。非常に難しい問題ですね。筆者は、テスト項目、使用する環境(プログラムや使用機器のバージョンなど)、何をもってOKとしたかを確認すべきだと考えています。
Copyright © ITmedia, Inc. All Rights Reserved.