QbookジャーナルQBOOK JOURNAL

バグゼロの落とし穴?ソフトウェアテストの7原則とは?

最終更新日時:2020.05.29 (公開日:2019.09.11)

バグゼロの落とし穴?ソフトウェアテストの7原則とは?

ソフトウェアテストはプログラム中に存在するバグや欠陥の発見、品質の保証などを目的に行ないます。しかし、ソフトウェア開発においてバグや作成ミスが全く存在しない成果物を納品することは不可能に近いでしょう。
また、バグをゼロにすることにこだわるあまり、ソフトウェアに要求される仕様を逸脱してしまう本末転倒な事態が起こりえます。これが、タイトルに記載している「バグゼロの落とし穴」です。

この記事では、バグゼロの落とし穴を含めた「ソフトウェアテストの7原則」について解説します。

ソフトウェアテストの7原則

バグゼロの落とし穴とは?ソフトウェアテストの7原則_sub

ソフトウェアテストの7原則とは、さまざまなテストで一般的に使えるガイドラインとして作成されたものです。
これまで50年以上の長きにわたり提唱されてきたさまざまなテストの原則を使いやすくまとめたもので、ソフトウェアテストの認定資格である、JSTQB 認定テスト技術者資格 Foundation Levelシラバスにその内容が解説されています。

JSTQBの資格についてはこちらの記事も参照してください。
エンジニアのスキルアップにつながる!「JSTQB 認定テスト技術者資格」とは
/column/20180427_623.html

それでは、7原則を解説していきましょう。

原則1: テストは欠陥があることは示せるが、欠陥がないことは示せない

テストでエラーや故障が見つかったということは、あくまで「欠陥があった」という事実に過ぎません。
テストで欠陥が見つからない場合でも、実施したテストケース内では見つからなかっただけかもしれません。
ソフトウェアに「欠陥が存在しない」ということはテストでは示せないのです。

さらに、もし見当違いのテストケースであれば、いくら大量に実施しても欠陥は出てこないでしょう。
テストをして欠陥が出てこなくても安心することなく、テストケースが十分かつ適切であるかを確認しましょう。

原則2: 全数テストは不可能

ソフトウェアテストにおいて、すべてのパターンを網羅することはほぼ不可能と言えます。
例えば、入力値A、Bの積をCと出力するソフトウェアがあったとします。AとBの値が1~100の整数に制限されていたとしてもテストケースの組み合わせは1万通りにもなります。

実際のソフトウェアでは入力値も出力値もより膨大となり、ソフトウェアが動作するマシンの状態などの外部要因もテストパターンに関係してきます。そのような場合、テストで使用するパラメータの組み合わせは容易に天文学的数値に達してしまいます。すべての組み合わせをテストするには気の遠くなるほどの時間が必要でしょう。

このように、ソフトウェアで全数テストを実施することは不可能に近いため、ソフトウェアの性質やリスクなどを勘案し、実施可能なテスト範囲に絞り込んで実施しましょう。
先ほどの例では、AとBの入力が1~100の全組み合わせをテストするのではなく100なら正常に処理し、101であればエラーとなることをテストします(境界値分析)。
このようなテスト手法を学ぶことで、効率よく欠陥を摘出できるようになります。

原則3: 早期テストで時間とコストを節約

もしソフトウェアを納品する直前に欠陥が見つかった場合、プログラムを修正し、影響がある箇所をすべて再テストしなければなりません。家づくりで例えると、建物を建てた後に基礎工事からやり直すようなものです。

それに対して、プログラムを書いた直後のテストであれば、プログラムの該当する行のみを修正して再テストすれば欠陥を取り除くことができます。釘1本を打ち間違えても、抜いて打ち直せばいいだけなのです。
さらに、プログラミングを開始する前の段階、家づくりであれば設計図を作成する段階でミスに気付けば、実装段階で間違いが発生することもありません。この実装前に欠陥を見つけることを静的テストといいます。

このように、欠陥を見つけるのが早ければ早いほど修正コストは少なくなります。
テストはなるべく早期に実施するとともに、テスト計画においてテスト実施の順番も十分に検討しましょう。ソフトウェア全体に影響する機能や、欠陥が多く含まれそうな機能を優先的にテストすることでコストを抑えることができます。

原則4: 欠陥の偏在

経済やビジネス用語として使われる「パレートの法則」は、ソフトウェアテストにも当てはめることができます。つまり、8割の欠陥は、わずか2割のプログラムに含まれていると言われています。

この原則を生かしてより効率的にテストを進めるためには、テスト結果を都度分析し、欠陥が多発している箇所がないか確認しましょう。多くの場合、機能や担当者ごとに欠陥は偏在しています。欠陥が多く埋まっている箇所が予測できれば、該当箇所のテストを強化しましょう。

原則5: 殺虫剤のパラドックスに注意

害虫駆除にずっと同じ殺虫剤を使っていると、そのうち虫が耐性を持ち、殺虫剤がだんだん効かなくなります。ソフトウェアテストにおいても同様に、あるテストケースで欠陥を発見して修正していくと、同じテストケースを繰り返し行なっても新しい欠陥を摘出できなくなります。

対策として、各工程でテスト観点を変えたり、開発者目線だけでなくユーザー目線でテストを設計したりするなど、さまざまな観点でテストを行なう必要があります。

原則6: テストは実施内容次第

ソフトウェアの性質によってテストの実施内容や方法は大きく変わります。自動運転のソフトウェアであれば安全が最優先となるよう十分にテストを行なう必要があります。

一方で社内用の簡単なツールであればテストはある程度行い、ユーザーに提供してからブラッシュアップしていく場合もあります。これを実施すればどんなソフトウェアも完璧になる、という万能なテストは存在しません。
ソフトウェアそれぞれの特性を考慮してテストを行ないましょう。

原則7: 「バグゼロ」の落とし穴

欠陥がゼロであっても、高品質なソフトウェアであるとは限りません。機能的な欠陥を無くそうと修正したことによって、セキュリティホールができたり、使い勝手が悪くなったりしては本末転倒です。

高品質なソフトウェアは機能性だけでは判断できず、セキュリティ対策や使い勝手、性能といった非機能要件によっても評価されます。
ソフトウェアテストは欠陥の数を少なくするためだけでなく、ユーザーの要件や期待を満たすために実施するのです。

おわりに

いかがでしたでしょうか。完全無欠なソフトウェア、および完全無欠なソフトウェアテストはありません。
しかし、過去の技術者のノウハウが詰まった「ソフトウェアテストの7原則」を活用することで、より少ないコストでよりよい品質のソフトウェアを作ることは可能です。
ソフトウェアテストの計画、ケース作成、実施、分析すべてにおいて活用して、よりよいソフトウェアを作っていきましょう。

資料ダウンロード

ライター:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。