Vietnamese
Englishテストの7原則
ソフトウェア検証はソフトウェアが生まれた時点とともに生まれてきたのです。今まで、検証が効果的に行われるよう、いろいろな原則が立てられました。そのうちに、基礎的で重要な原則が7つあります。
１．検証は欠陥があることを示せるが、欠陥がないことは示せない
欠陥を発見したら、そのソフトウェアに欠陥があることが言い切れます。しかし、どうしても欠陥が発見できなかったら、そのソフトウェアはもう欠陥がないことが言い切れません。なぜかというと、検証したテストケースが欠陥が発生するパターンを含んでいないかもしれないのです。
例: データベース格納機能を検証する時、指定されたレコードのみ更新して、それ以外更新なしという仕様があります。指定されたレコードが更新されたか検証して、残りのレコードは更新されていないか検証していませんでした。結果として、残りのレコードも更新されましたが、気づかなかったです。
そこで、検証における重要なのは故障が発見できるテストケース、テストパターンを立ち上げることです。
２．全数テストは不可能
全数テストとはソフトウェアに入力できるデータとテストを行う条件のすべてのパターンを検証することです。
例: 8文字数以内で入力できるプログラムがあるとします。8文字以内を入力してテストしたら、正常に入力できていることを確認します。これは正常系のテストパターンと言います。逆に、9文字以上入力してテストしたら、エラーメッセージが返されていることを確認します。これは異常系のテストパターンと言います。全数テストしたら、正常系のパターンをテストするために、１文字入力するケース、2文字入力するケース、。。。、8文字入力するケース、合計8ケースがあります。しかし、異常系のパターンをテストするために、9文字入力するケース、10文字入力するケース、。。。無限にテストしないといけないです。当然それは無理です。そうしたら、どのように検証したら時間がかからなくて、テスト漏れにならないでしょうか。ソフトウェア検証には様々なテスト技法があります。この場合、同値分割というテスト技法を採用することができます。上記のように、正常系と異常系の2つのパターンに分けることができます。その2つのパターンにそれぞれ1つのケースを選んで、テストしたら良いです。例えば、6文字を入力して、エラーメッセージが返されなかったらプログラムが正しく動いていることが確認できます。そして、9文字を入力して、エラーメッセージが返されたらプログラムが正しく動いていることが確認できます。逆に、6文字を入力して、エラーメッセージが返されたら、プログラムが正常に動いていないことが確認できます。そして、9文字を入力して、エラーメッセージが返されなかったら、プログラムが正しく動いていないことになります。
そのため、実際の検証現場でソフトウェアの性質、目的や使われる方などから力を注ぐ必要な場所を絞ったり、優先順位を決めてテストしていきましょう。
３．早期テストで時間とコストを節約
故障を発見するのが早ければ速いほど修正する時間やコストを節約することができるのです。事務所のビルの電気の設置を考えてみましょう。デザイン段階で電気の色が適切ではないことに気づいたら、電気のデザインを修正したらよいです。 もし、電気が購入済みの段階で気づいたら、電気を取り替えたりして、取り替える費用もかかるようになります。そして、もしかして、電気をすべて設置した後に、適切ではないことに気づいたら、電気の解体費用、新しい電気の購入、再度設置コストなど多くの費用がかかるようになります。ソフトウェア検証も同じです。
そのため、テストは開発プロセスに早ければ早いほど実施すればよいです。
４．欠陥の偏在
ソフトウェアはUI、データベース、計算機能、データ格納などの各機能、コンポーネントから作られています。それぞれの機能やコンポーネントの開発の難しさも異なります。そして、規模が大きい案件ではいくつかのチームで一緒にやって、指定された機能、コンポーネントを担当して、完成した後は組み合わせることもあります。そのため、故障は各機能やコンポーネントにおいて同じほど発生することではありません。故障はある機能やコンポーネントに集まります。パレートの法則によると、8割の結果は2割の原因から起こされたのです。
というと、過去の検証結果と最近の検証結果を見て、故障が発生する可能性が高い構成や機能を予測できます。それから、検証する時に、その構成や機能に気を付けたら効果的に検証が実施できます。
５．殺独剤のパラドックスに気を付けよう
殺独剤のパラドックスとはずっと同じ殺独剤を使うと、だんだん効果がなくなるということです。その殺独剤に堪えられる虫が出てきます。ソフトウェア検証には、ずっと同じテストケースを使うと、だんだん故障が発見できなくなります。そのテストケースで発見できた故障が修正されたからです。
そのため、テストケースを常に新しい内容で更新する必要があります。新しいテストケースで故障を発見するたびに、必ずソフトウェアの質の向上に貢献することができます。
しかし、レグレッションテストでは元のテストケースが役に立ちます。レグレッションテストとはプログラムの一部を修正したことでシステムに予想外の影響が現れていないかどうか関連する機能、もしくは、ソフトウェアの全部の機能を確認するテストのことです。修正しない部分を検証する時に、もとのテストケースでテストできます。この場合、故障を発見したら、レグレッションバグと言います。但し、日本の企業ではその故障はデグレードバグと呼ぶことが多いです。
６．テストは状況次第
各ソフトウェアはそれぞれの目的、システム構築、使用条件などがあるため、それぞれの適切なテスト技法を採用しなければなりません。例えば、会計ソフトウェアの検証とニュースを読むソフトウェアの検証が異なります。会計ソフトウェアを検証するには計算ロジックに力を注いで、計算が正しくされていることを確保しないといけないということです。それに対して、ニュースを読むソフトウェアを検証するには、ニュースが読みやすいか、正しいフォーマットで表示されているかなどUIに集中してテストしなければならないということです。
つまり、ソフトウェアの目的、システム構築、使用条件などによって、適当なテスト技法とテストケースを作成しなければならないということです。
７．「バグゼロ」の落とし穴
報告された故障をすべて修正したことで、ソフトウェアが完璧に動いているわけではありません。これは「バグゼロ」の落とし穴ということです。故障の報告をもらい、調査を進めると要件を満たしていなかったことや、使い勝手が悪いということがあります。テストを全て完了させたからといって、全ての欠陥がなくなったわけではありません。
以上の7つの原則を覚えて応用することで、ソフトウェア検証をより効果的に行うことができます。しかし、ソフトウェアの検証において、一番大事なのは実際の検証現場で起こる可能性があるケースを想像して、理解することです。
※練習問題：