ソフトウェアテストには7原則があり、ISTQBテスト技術者資格制度 Foundation Level シラバスに記載されています。一般的なガイドラインであるため、ソフトウェアの開発者やテスト担当者は理解をしておくことが重要です。
この記事では、ソフトウェアテストの7原則について詳しく説明していきます。
「ソフトウェアテストの7原則」とは？
ソフトウェアテストの7原則とは、ソフトウェアテストを進めるために必要な知識であり ISTQBテスト技術者資格制度のFoundation Levelを勉強する際に使うシラバスに記載しているガイドラインです。
【原則1】テストは欠陥があることは示せるが、欠陥がないことは示せない
ソフトウェアテストをすることで、バグがあることは証明できます。しかし、バグがないからといって問題のないソフトウェアであると証明することはできません。
JSTQBテスト技術者資格制度 Foundation Level シラバスにおいてもこのことが記されています。
「テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。」
引用：テスト技術者資格制度 Foundation Level シラバス
生じやすい課題
必要と判断したテストケースをすべて終わらせても、バグが残っていないとは言い切れません。バグがなくなったと証明することは不可能です。
本番を稼働したあとに想像しなかったような処理をおこなったり、一部の条件においてバグが発生したりする可能性があります。
ソリューションの例
テスト計画を作成する際、リリース時や実際にユーザーが活用したあとの障害対応を明確に計画してテストカバレッジを高めることが重要です。該当部分以外にもリグレッションテストなどをすることによりバグを早期に発見できる可能性が高まります。
【原則2】全数テストは不可能
生じやすい課題
具体的な根拠がなく、ステークホルダーからバグがでないことを証明するように求められることがあります。また、テスト担当者が問題ないと判断することもあるでしょう。しかし、ソフトウェアテストではバグが存在しないことを証明できません。
ソフトウェアテストで証明できるのは「特定の機能や画面に対して特定のプロセスでテストをした場合にバグが発生しなかった」といったかなり限定した言い方になります。この特定したテストを重ねることにより、バグがでにくい状態につなげていきます。
そのため、テストの目的や優先順位、テスト観点などについて十分に検討することが重要です。
ソリューションの例
プロジェクトのプロセスや予定は限界があることからテスト計画を効果的に進め適切にテストをすることが重要です。それぞれのフェーズにおいてどのようにソフトウェアテストをするべきか常に検討する必要があります。
それぞれのプロセスにおいて不具合見地立や機能の重要度を確認しましょう。これらをことを進めることによって、ステークホルダー間の出戻りを防げます。
【原則3】早期テストで時間とコストを節約
ソフトウェア開発ライフサイクルにおいて、動的テストや性的テスト活動をおこなうことでバグの早期発見につながります。また、早期にバグを発見することで、プロセスが減りコスト削減が可能です。
生じやすい課題
ソフトウェアテストを外注する場合、要件定義や受け入れテスト、基本設計を自社でおこないほかの工程を委託会社がおこなうことが一般的です。結合テストやシステムテストにて、工程が増え予定が伸びてしまうような課題が起きることがしばしばあります。
そのことから、受け入れテストをする時には、スケジュール調整や参加プロセスのリクエストが必要になることが少なくありません。その結果リリースが遅れ、作業が増えることからコストが増えるリスクがあります。
ソリューションの例
設計をする時点で静的テストをしたりインスペクションを進めたりすることで、要件漏れのリスクを減らします。このことで、仕様バグに対して早い段階で対応することで、手戻りが減り生産性を高められます。
【原則4】欠陥の偏在
ソフトウェアをリリースする前にテストの段階で発見される故障や欠陥のほとんどは、特定の章週数モジュールに該当します。欠陥の傾向を予測することでテスト業務の負担を減らし、テストや運用での結果に応じてテストを進めるのです。
生じやすい課題
テストが難しい場合や要件が複雑であった場合、テスト担当者のスキルが十分でなかった場合などさまざまなケースにおいて特定の領域にて問題が発生する可能性があります。また、十分な開発リソースが提供出来なかった場合でも同じリスクがあるのです。
ソリューションの例
それぞれのプロセスにおいて、不具合検知率があった場合、さらに重要な機能に対してなどソフトウェアテストをするべきか艇的に検証することが重要です。さらに、それぞれのテストにおいてわかりやすいようにリソースの最適化を考える必要があります。
【原則5】殺虫剤のパラドックスにご用心
同じテストを継続的に何回もおこなうことで、新しいバグを発見できない可能性があります。テストやテストデータは一度で終わりではなく、継続的な見直しが必要です。場合によっては改善したり新しくテストを作成したりする必要があります。
同じテストを何度も繰り返すことで、バグを見つけられる能力は下がると考えましょう。しかし、リグレッションテストや自動化されている場合は同じテストを何度もおこないリグレッションが下がっているといったメリットのある結果を示せます。
生じやすい課題
開発者がテストまでおこなうことが一般的のため、経験に依存してしまい十分なテストができない場合があります。また、プレッシャーがかかりすぎたり逆に大丈夫だろうと考えすぎて十分な確認をしていないリスクがあるのです。
ソリューションの例
殺虫剤のパラドックスを防ぐためには、開発担当者とテスト担当をわける、さらにレビューの手順を定義するなどと開発からテストまで1人で進めない方法がおすすめです。また、テストの仕方を内容によって変える方法もあります。
このように、工夫したテストをおこなうことがパラドックスの防止につながるのです。
【原則6】テストは状況次第
これまでソフトウェアテストの経験豊富であったとしても、ソフトウェアそのものの内容や環境がかわればそれぞれに適応したテストが必要です。例えば、eコマースモバイルアプリケーションと産業用制御をするためのソフトウェアでは、おこなうべきテストが異なります。
生じやすい課題
それぞれの状況に応じたテストをイメージするのは決して容易ではありません。特に、アジャイル開発において適したテストを見つけ出すのは経験豊富な開発者やテスト担当者でも苦労する部分です。
ソリューションの例
アジャイル開発では、開発をしながらテスト担当者がソフトウェアテストを進めることが一般的です。そのため、開発の進行具合に合わせてソフトウェアテストをする必要があります。
アジャイル開発に対応できるようなテスト自動化をすることで、業務効率化につながることがあります。
【原則7】バグゼロの落とし穴
テスト担当者ができるかぎりのテストをおこなうことで、バグがゼロになると考える人がいます。しかし、どれだけテストをおこなってもバグがゼロになったと証明をすることは不可能です。
さらに、バグを大量に見つけて修正することで適切な構築ができるといった考えも間違いです。仮に、発見したバグをすべて直してもユーザビリティが低ければ適切な構築だといえません。
生じやすい課題
テスト担当者や開発担当者はバグをゼロにすることを目指すでしょう。
しかし、バグをゼロにすることばかりに意識をとられると要件定義において保守的になりすぎたり、チェックポイントを設定しすぎたりするリスクが発生します。テストを十分したからバグはでないと考えてしまう可能性もあります。
ソリューションの例
ソフトウェアの開発やテストをおこなう上で、バグはゼロにならないことを認識しましょう。プロジェクトトランジションやリリース後の運用過程を規定することが大切です。
リリースをするかどうか判断するテストにおいても、継続的インテグレーションの観点で設計をしましょう。
まとめ
ソフトウェアテストにはISTQBテスト技術者資格制度 Foundation Level シラバスにも記されている、一般的なガイドラインがあります。7つの原則があり、ソフトウェアテストの7原則とよばれます。
ソフトウェアテストをおこなう上で共通して知っておくべきことであるため、内容を把握することが重要です。
