ソフトウェアテストの7原則とは？ 実務での課題と解決策も徹底解説（ソフトウエアテストの7原則）

更新：2024.5.16
著者：Ｓｋｙ株式会社

ソフトウェアテストに対する2つの誤解と正しい認識

一般的に「ソフトウェアテスト」という単語からは、「開発したソフトウェアが仕様通りに動くかどうかを確認すること」のみをイメージしがちです。しかし、ソフトウェアテストが果たす役割はそれだけにとどまりません。

ソフトウェアテスト技術者の国際的な資格認証団体であるISTQBによると、ソフトウェアテストに関するよくある誤解として以下の2点が挙げられています。

テストはソフトウェアを動作させ、その結果を確認するだけの工程ではない

「テストを実行して結果を確認すること」は、ソフトウェアテストのプロセスの一部分に過ぎません。テストプロセスにはテストの実行だけでなく、計画や分析、設計、実装、進捗・結果の報告、テスト対象の品質評価といった作業も含まれます。

テスト対象のソフトウェアを動かして行うテストを「動的テスト」と呼びますが、ソフトウェアを動かさずに行う「静的テスト」と呼ばれるテストも存在します。静的テストでは例えば、要件定義書やユーザーストーリー、ソースコードなどの成果物をレビューして、誤りや脆弱性を検出します。なお静的テストには、規格からの逸脱などシステムの内部構造に関する欠陥の検出に強く、開発プロセスの早期に実施できるというメリットがあります。

テストは要件やユーザーストーリー、仕様等の検証だけがすべてではない

ソフトウェアテストでは、要件や仕様通りに動くかどうかといった部分的な検証だけに重点を置くべきではありません。「開発したソフトウェアはユーザーにとって本当に意味があるのか」という観点でテストを行い、妥当性を確認することも大切です。仮に開発したソフトウェアが意図通りに正しく動作したとしても、実際の運用環境においてユーザーやステークホルダーのニーズを満たしているものでなければ意味がありません。

こうした妥当性の確認は、先に挙げた静的テストや、テスト工程の最後に実施される受け入れテストを通じて行われます。手間をかけて開発したソフトウェアを快適に使い続けてもらうためには、開発者の視点だけでなくユーザー視点での検証も必要不可欠です。

ソフトウェアテストの7原則を徹底解説（ソフトウエアテストの7原則）

ソフトウェアテストの7原則とは、ソフトウェアテストを行う上で共通して理解しておくべき考え方のことです。具体的には「テストでは欠陥があることしか示せない」「全数テストは不可能」「早期テストで時間とコストを節約」「欠陥の偏在」「テストの弱化（殺虫剤のパラドックス）に注意」「テストは状況（コンテクスト）次第」「欠陥（バグ）ゼロには落とし穴がある」で、ISTQBテスト技術者資格制度 Foundation Level シラバスに記載されています。

以下ではそれぞれの原則の詳細と、各原則に対して実務ではどのような課題と解決策が考えられるのかについてご紹介します。なお、実際の現場では、この7原則が必ずしもあてはまるわけではありません。しかし、ソフトウェアテストを適切かつスムーズに実施する上で大いに役立つ考え方といえます。

原則1：テストでは欠陥があることしか示せない

ソフトウェアテストを行って欠陥が何も見つからなかったとしても、そのとき想定したケースでは欠陥が出てこなかっただけで、想定外の処理や極めて珍しい状況下では欠陥が検知される可能性も残されています。テストによって欠陥があることは示されますが、欠陥がまったく存在しないことの証明はできません。

実務における課題と解決策

この原則は、テスト担当者の努力や新たな技術の適用で変えられるものではありません。成果物のリリース前にどれほど手厚くテストしていても、本番環境での障害は発生するものです。

発注者側から「一切のバグをなくしてほしい」といった現実的でない要求をされる機会こそ減ってきてはいるものの、ITシステム全般の導入に不慣れな人の中にはソフトウェア開発におけるこのような限界を知らない場合も考えられます。トラブルを防ぐためにも、この原則を前提としてテストを進めていくことを、お客様をはじめとするステークホルダーに開発初期の段階で認識してもらうことが必要です。

なお、テストを実施した結果、欠陥がないと単純に言い切ることはできませんが、「この条件下では欠陥が見つからなかった」と主張することは可能です。個々のプロジェクトに適したテストの設計と実行を繰り返し、欠陥が見つからなかった事例を増やすことで、結果として「欠陥が少ない」状態に近づけられます。

発注者への最終的な報告としては「今回のテスト範囲内では、こういった観点でこれだけの数の欠陥が見つかりました」というかたちをとると、誤解のないやりとりが行えます。また同時に、本番環境での障害対応についての計画や、仕様変更・機能追加時に欠陥を検出できる仕組みづくりも大切です。

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

全数テストとは、可能性のあるすべてのパターンをテストすることです。膨大なテストケースを洗い出して網羅的にテストすることは、ごく単純なソフトウェア以外では実質的に不可能といえます。実際には、ソフトウェアの性質や目的などを考慮し、優先順位をつけてテストを行う必要があります。

実務における課題と解決策

一般的なソフトウェア開発の場合、考えられるすべての条件の組み合わせをテストすることは現実的ではありません。例えば、組み合わせ最適化の分野で有名な「巡回セールスマン問題」を考えるとイメージしやすいです。

巡回セールスマン問題とは、セールスマンが複数の都市をすべて一度ずつ訪問して出発点に戻るときに移動距離が最小になる経路を求める問題です。10都市で組み合わせ総数は18万通りを超え、30都市になると天文学的な数字となり、仮にスーパーコンピュータを用いて100年かけてもその計算は終わりません。限られた時間や人員で効率的にテストを行うためには、このような非現実的な数字と真っ向から向き合うことを避ける必要があります。

そのためには、例えば不具合の検出率を落とさずにテストケース数を削減する「2因子間網羅」や、出力結果が同じテストケースを同等と見なしてグループ化する「同値分割法」といったテスト技法を活用します。また、リスクの種類や重要度を考慮して重点的にテストするべき箇所を知るための「リスク分析」も役立ちます。過去に不具合が起きた機能に焦点を絞るなど、テストにかける労力を集中させることが重要です。

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

人間の手が加わっている以上、どれだけ改善を重ねたとしても完璧なソフトウェアの開発は不可能といえます。そのため、何かしらの欠陥は必ず存在するものだと想定した上で、早期発見により損失の増大を防ぐことが大切です。開発の早い段階でテストを行うことで、大幅な修正や再テストのコストを削減しやすくなります。

実務における課題と解決策

外部委託でソフトウェア開発を行う場合、最初の要件定義や基本設計を自社で行った後、詳細設計やコーディング、システムテストまでを委託し、最後の受け入れテストを再び自社で行うといった手順を踏むことが多くあります。そのため、コミュニケーションコストが増大しやすく、余計な手戻りを減らせるような工夫が求められます。

特に開発工程の初期に生じた誤りは、後の工程で新たな欠陥を生み出す原因にもなりかねないため、注意が必要です。例えば、要件定義の段階で十分なレビューを行わずに開発を進めてしまうことで、システムテストの段階になって初めて多数の欠陥が明らかになるといった事態も起こり得ます。その欠陥が軽微なもので修正が容易であればともかく、プロジェクト全体の工数やスケジュールに影響するような重大な問題が生じた場合には、結果として工数の追加やスケジュールの大幅な遅延を招いてしまいます。

このような状況を防ぐためには、要件定義書の作成段階からドキュメントのレビューをすぐに行う、ソースコードを書いたらすぐに単体テストを実施するなど、静的テストを早期に行って素早いフィードバックを得ることが大切です。なお、開発の上流工程からテスト設計を開始し、開発とテストを同時に進める「W字モデル」というプロセスモデルも存在しています。

「要件定義」「仕様設計」「コーディング」などの開発初期段階で生じる不具合を可能な限り排除しておくことで、後の工程での手戻りを大幅に削減し、プロジェクト全体の生産性の向上が見込めます。

原則4：欠陥の偏在

テストで見つかる欠陥は、要件定義の複雑さや実装難易度の高さ、リソース不足などを原因として、特定の領域に集中する場合が多いです。そのため、過去の分析結果や予測に基づき、欠陥の多い箇所にめどを立ててからテストを計画・実行することで、効率的にテストを進められるようになります。

実務における課題と解決策

開発に際しては、常に豊富なリソースがそろっているわけではありません。スキルの高いエンジニアの不足や余裕のないスケジュールにより、複雑で実装難易度の高いモジュールや開発実績の少ない機能などに欠陥が集中する傾向があります。

よくあるケースとして、テストケースの数を決める判断材料にソースコードの実装量を用いることがありますが、これは得策とはいえません。実装量が多いものの実際には欠陥の存在しない箇所ばかりをテストして、結果として時間が足りなくなり、重大な欠陥を残したまま開発を終えなければならない状況になる恐れがあるためです。

テストの設計は、単純なソースコードの規模だけでなく、機能の重要度や複雑さ、不具合の検知率などを踏まえて行う必要があります。各工程でどのようなテストを行うべきかを常に検証・修正することで、テストにかかるリソースの最適化を進めていきます。そして、欠陥が集中している機能やモジュールを見つけられたら、追加テストの実施や設計の見直しによって、内在している欠陥をさらに可視化して修正を加えます。

ただし、テストには「評価対象の妥当性を確認する」という重要な役割もあるため、領域を絞って欠陥を見つけるべきタイミングなのか、それとも全体を網羅的にテストするべきタイミングなのかについては適切な判断が求められます。

原則5：テストの弱化（殺虫剤のパラドックス）に注意

害虫の駆除に同じ殺虫剤を繰り返し使うと虫が耐性を持ち、効果が薄れていきます。同様に、同じテストを繰り返し適用し続けると、次第に新たな欠陥を見つけられなくなります。こうした状況を回避するためには、テストデータや手法、観点を定期的に見直すなど改善を続ける必要があります。

実務における課題と解決策

テストの弱化は、同じ担当者が何度も対応しているプロジェクトで起こりやすいといえます。原因としては、過去と似た内容しか思いつかない、いつも問題が起こらないため油断してしまう、思い込みで確認を怠る、といったことが挙げられます。また、余裕のないスケジュールの影響も考えられます。

テストの弱化を防ぐには、複数人でのレビュー・チェック体制の構築や、定期的なテスト仕様の見直し、経験豊富な人員の増加など対策が必要です。すでに確立しているテストケースは自動化を検討し、削減できた工数をテストの改善に費やすのも有効です。

原則6：テストは状況（コンテクスト）次第

すべてのソフトウェアに適用可能な、万能なテストは存在しません。例えば、小さな欠陥が生命に関わる医療機器で用いるテストは、音楽再生アプリのテストとは性質が大幅に異なるはずです。ソフトウェアの特性を考慮したテストを行う必要があります。

実務における課題と解決策

実務においては、開発するソフトウェアの特性だけでなく、開発手法に関しても考慮する必要があります。例えば、短い開発を繰り返すことで従来の手法よりも開発期間を短縮する「アジャイル開発」の場合、効率向上のためにテストの自動化が必要です。一方、各工程を確実に終わらせながら進めることで手戻りを防ぐ「ウォーターフォール開発」の場合には、初期の設計段階から静的テストに重きを置きます。

また、多少の欠陥があっても開発スピードが求められる場合にはテストスケジュールの管理が重要となるほか、限りなく高い精度が求められる場合には規格や法律に従った緻密なテスト設計が求められます。

このように、対象となるソフトウェアの特性や開発手法を深く理解した上で、個別に必要な観点を洗い出してテスト計画を立てることが大切です。

原則7：欠陥（バグ）ゼロには落とし穴がある

修正を繰り返してテストで検出される欠陥がゼロになっても、優れたソフトウェアが完成するとは限りません。そもそも欠陥が一切ないとは言い切れない上、修正によって新たな不具合の発生や使い勝手の悪化が生じる恐れがあるためです。

どれほど機能的な要件を満たしていても、セキュリティ対策なども含め、実際の使用環境で価値を発揮できなければ意味がありません。指定された要件の検証だけでなく、ユーザーのニーズや期待を満たせているのか妥当性を確認することも非常に重要です。

実務における課題と解決策

欠陥を減らすことに必要以上にこだわると、本来の目的と比べて低水準な開発を進めてしまったり、過剰にテストを実施して余裕のないスケジュールに陥ってしまったりする恐れが出てきます。また、「これだけテストをしたのだから大丈夫だろう」という慢心も生まれやすいかもしれません。

リリース直前になって不具合が検出された場合、欠陥をゼロにするためだけに修正を加えることには、特に慎重になるべきです。なぜなら、その修正がほかの箇所に影響を及ぼしているにもかかわらずそのことに気づかない、副作用として生まれた欠陥を修正する時間が足りない、といった本末転倒な状況になる可能性があるためです。例えば、使用頻度の低い機能の欠陥を急いで修正し、その結果としてソフトウェア全体の動作が重くなり、多くのユーザーが使用を控えるようになってしまう、といった状況は避けるべきです。

開発にあたっては、欠陥をゼロにすることにとらわれるのではなく、ユーザーが本当に求めている性能や信頼性をどれだけ実現できているかを、常に念頭に置くことが重要です。

Ｓｋｙ株式会社のソフトウェアテストサービスについて

Ｓｋｙ株式会社は、25年以上にわたるソフトウェア品質保証業務において300社を超えるお客様とお取引を行ってきました。この実績に裏打ちされた経験値と確かな技術力を基盤として、専門資格保有のスペシャリストが全国の拠点で、お客様の課題解決に向けたサービスをご提供しています。

なお、ご支援可能なサービス分野は自動車関連システム、業務系システム、パッケージソフトウェアなど幅広く、近年では実装後の品質テストだけでなく、要件定義といった開発の上流工程から品質管理を行うなど携わる領域も拡大しています。例えば、車載関連では、先進技術を支える各種ECUのシステムテストやドライブレコーダーの品質分析などを通じてソフトウェア品質の向上に寄与しています。

まとめ

ここまで、ソフトウェアテストの7原則について、実務での課題と解決策を示しながら詳しく解説してきました。単純に指定された要件を満たすだけでなく、ユーザーのニーズを満たす満足度の高いソフトウェアを開発する上で、こうした7原則の考え方は非常に役立ちます。

Ｓｋｙ株式会社では、このような体系的な考え方や独自のノウハウに基づき、お客様のニーズに合わせてた柔軟なサービスを提供しています。ソフトウェア評価 / 検証に関してお困りの際は、ぜひご相談ください。