2024.02.22

ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説

著者株式会社SHIFT　マーケティンググループ

Introduction

ソフトウェアテストとは、ソフトウェアの実装後にテストを行い、バグや欠陥をつぶしていくためのものです。しかし「テストをひととおり行えばバグはすべてつぶせる」「とにかくたくさんテストすれば品質が上がる」などの誤解をしている人も多いかもしれません。

効率のよいテストを行うためには、テストに関する正しい知識をもち、テスト対象や開発プロジェクトの状況にあったテストを計画する必要があります。

この記事では、効率のよいテストを正しく行うために必要な、JSTQBによるソフトウェアテストの7原則と、テストに必要な考え方についてご説明します。テストに関する正しい知識をもとに、効率のよい正確なテストを行うために役立ててみてください。

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

ISTQBの『テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01』では、ソフトウェアテストの7原則を定義しています。ソフトウェアテストの7原則とは、ソフトウェアテストを行う際に、開発担当者やテスト担当者が理解しておく必要があるガイドラインです。

ここでは、ソフトウェアテストの7原則とは何か、実務を行ううえでどのような点に気をつけるべきなのかを具体的にご説明します。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ソフトウェアテストについてはこちらもご覧ください。
＞＞ソフトウェアテストとは？種類や目的、重要な7原則を紹介のページへ
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

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

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

テストにより、テスト対象に欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない。

実務上の課題と解決策

【実務上の課題】

ソフトウェアテストを十分に行ったからといって、そのソフトウェアに欠陥がないとはいえません。存在しないことを証明することは「悪魔の証明」と呼ばれ、そもそも証明ができないのです。

「ツチノコ」が世のなかに存在しないことを証明できないのと同じで、バグや欠陥がひとつもないと断定することは不可能です。

【解決策】

テストを実施した結果「バグや欠陥がない」とはいい切れませんが、テストを行った条件では「欠陥が見つからなかった」ということはいえます。それぞれのプロジェクトにあった適切なテストを計画、分析、設計、実行することで、「欠陥が見つからなかった」部分を増やしていくことで、「欠陥がない」状態に近づけていく必要があります。

たとえば、テストの目的を明確にして目的にあったテスト計画を行う、テストレベルごとに適切に分析するなどで、見つけたい欠陥を探します。また、過去に行った同様の規模や機能、開発難易度の開発プロジェクトのテストを参考にすることもあります。

テストをすれば欠陥がないことを証明できるわけではありませんが、テストの精度を上げて欠陥が見つからないことを確認した部分が増えることが重要なのです。

原則② 全数テストは不可能

2．全数テストは不可能

すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて、テストにかける労力を集中すべきである。

実務上の課題と解決策

【実務上の課題】

テストを行う際には、考えられるパターンをすべてテストする、網羅的なテストを求められることがあります。たしかに全パターンを網羅すれば、欠陥をしらみつぶしに探せるかもしれません。しかし、現実的ではないうえに、テスト効率が大幅に下がってしまいます。

たとえば、日付入力エリアのテストを行う場合、1月1日から12月31日までのすべての日付を入力するのは、効果の高いテストとはいえません。それよりは、数字以外の文字列、うるう年、13月33日のようなありえない日付などもテストした方が、より多くのパターンをテストできます。

【解決策】

テストを行うリソースや期間は限られているため、全数テストに労力をかけるのではなく、より効果の高いテストを計画する必要があります。

重要な機能や難易度が高い機能、過去に不具合が起こったことがある機能を重点的にテストするなど、状況にあったテスト計画が必要です。

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

3．早期テストで時間とコストを節約

プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。SDLC の後半に発生する故障が少なくなるため、品質コストは削減される。早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである。

実務上の課題と解決策

【実務上の課題】

要件定義や基本設計、ドキュメントを作成したときに、プログラム品質には影響しないと考えて、十分にレビューを行わないで誤りが残ったまま先に進んでしまうことがあります。

しかし、ドキュメントの誤りは後続の工程で文字通りに受けとられてしまうと、それが新たな欠陥を生んでしまうことになります。その結果、テスト工程に入ってから欠陥に気がつくと、もともとはひとつの誤りだったものでも、多数の欠陥を修正しなければならないことになり、修正コストが増大してしまいます。

ソースコードでも、工数がひっ迫しているときなどは、レビューや単体テストを十分に行わず、統合テスト以下の工程に丸投げしてしまうこともあります。

書いてすぐに確認しておけば、欠陥があってもその場限りの問題で済むのですが、時間が経ってから欠陥が見つかると、修正するには内容を思い出すところからはじめなければなりません。関連する機能の再テストも必要となり、結果的に工数が多くかかることになります。

【解決策】

バグや欠陥を効果的に除去するには、バグや欠陥を熱いうちに消し込むのが一番です。そのため、ドキュメントは書いてすぐにレビューする、ソースコードは書いてすぐにレビューして単体テストをするという基本を守れば、その後にかかる時間とコストを大幅に節約できます。

初期段階の設計のミスや漏れなどで生まれる「要件バグ」「仕様バグ」「コーディングミス」をつぶしておくことで、プロジェクト全体の生産性の向上につながるでしょう。

原則④ 欠陥の偏在

4．欠陥の偏在

通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する。この現象は、パレートの法則を示している。予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる。

実務上の課題と解決策

【実務上の課題】

テストケースの数を、ソースコードの実装量に比例した指標として考えている人も多いのではないかと思います。しかし、それは本当に正しいのでしょうか。

テスト工程でテストの分析を行うと、特定のモジュールに欠陥が集中している事象が見つかることもあります。とくに、複雑な機能、実装難易度が高いモジュール、過去に開発経験のない機能などに集中する傾向が見られます。実装量だけでテストケースの数を決めると、このような欠陥の集中する部分のテストが不足し、欠陥を残したままリリースしてしまうかもしれません。

【解決策】

テストを設計するときには、実装量だけではなく、機能の複雑さや実装の難易度、過去の経験なども含めてテストケースの配分を決める必要があります。テストの実行をはじめてからでも、欠陥の状況を判断して以降のテストケースの配分を修正することも考えます。

たとえば、どの機能やモジュールにバグが集中しているか、テストの消化が進むにつれバグ件数は収束しているかなどを分析します。バグが集中しているモジュールを見つけたら、設計の見直しや追加テストなどを行うことで、リカバリーが可能です。

原則⑤ テストの弱化

5．テストの弱化

同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテストを繰り返すことが有益な結果を示すことができる場合がある。

実務上の課題と解決策

【実務上の課題】

テストの弱化は、同じ開発担当者やテスト担当者が繰り返される機能追加開発を、何度も対応しているプロジェクトで起こりがちです。具体的には、過去のテスト内容と同じようなテストケースしか思いつかない、いつも問題ないから今回も大丈夫だろうと油断してしまうなどです。

【解決策】

このような事態を防ぐためには、複数人によるレビュー体制を整える、テスト観点を定期的に見直すなどの対策が必要です。

原則⑥ テストはコンテキスト次第

6．テストはコンテキスト次第

テストに唯一普遍的に適用できるアプローチは存在しない。テストは、コンテキストによって異なる方法で行われる。

実務上の課題と解決策

【実務上の課題】

テストの方法は、開発するソフトウェアの性質やプロジェクトの状況などによって大きく異なります。いつも同じテストを実施すればよいというわけではありません。

【解決策】

たとえば、短い開発を繰り返すアジャイル開発の場合には、効率よくテストを実施するためにテストの自動化が必要です。開発期間が長いウォーターフォール開発の場合には、基本設計、詳細設計での静的テストを重点的に行うことで手戻りを減らせます。

コスト最優先のプロジェクトでは、限られた工数を最大限に生かすことを考えなければなりませんし、納期最優先のプロジェクトでは、厳密なスケジュールの管理が重要となるでしょう。

このように、それぞれの状況にあった適切なテスト計画を進めていく必要があります。

原則⑦ 「欠陥ゼロ」の落とし穴

7．「欠陥ゼロ」の落とし穴

ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである。

実務上の課題と解決策

【実務上の課題】

効果的にテストを行って可能な限りのバグをとり除き、仕様書通りに万全にシステムを構築したとしても、それが役に立つシステムであるかどうかは別の評価となります。

実際に業務の場面でシステムを使うと、データの入力にとても手間がかかってシステム導入前よりも残業が増えたとか、手作業からシステム入力に変わって窓口の待ち時間が延びたとか、そのような例も多く聞きます。

【解決策】

システムを提供するときには、発注する企業とそれを使う利用者の双方にメリットを理解しなければなりません。

企業はシステムのリリースにより何らかの利益を求めますし、利用者はシステムによって作業が簡単になることを期待します。システムのテストをする場合にも、仕様書とあっているかのみを確認するのではなく、企業や利用者が便益を得ることができているかを確認することが重要です。

正確なソフトウェアテストを行うために必要な考え方

ISTQBの『テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01』では、正確なソフトウェアテストを行うために必要な考え方について、以下のように説明しています。

欠陥や故障に関する情報を建設的な方法で伝える

開発担当者にとっては、テスト担当者から「欠陥があった」と伝えられるのは嫌なものです。開発担当者が「自分が開発したコードは正しいはずなのに、非難された」などと解釈し、聞き入れてもらえないこともあるでしょう。

そのため、テスト結果を伝える際には否定的に伝えるのではなく、建設的な方法で伝える必要があります。具体的には、次のようなコミュニケーション方法が有用です。

・対決姿勢ではなく、高品質のシステムをつくるために互いが協調するという姿勢で対話する
・誰かを責めるのではなく、事実に焦点をあてて伝える
・相手が否定的に反応した場合には、その理由を理解するように努める
・相手が自分の言葉を理解しているか、自分が相手の言葉を理解しているかをその都度確認する

個人的偏見を最小限にする

バグや欠陥を発見したときに「開発期間が足らなかったのではないか」「スキル不足では」などという考えが浮かぶこともあるでしょう。しかし、そのような判断は状況を正しく分析してから下すべきであり、個人的な偏見から安易に口にすべきではありません。事実だけを淡々と分析していく必要があります。

開発担当者とテスト担当者は、異なるマインドセットをもつ

開発担当者とテスト担当者の役割は異なるため、それぞれがもつマインドセットも異なります。そして、その違いをお互いが正しく理解しておく必要があります。

開発担当者のマインドセット

開発担当者は、何か問題が起こったときに、設計や実装内容に関心をもちます。しかし、自分がつくったものは正しいはずという「確証バイアス」が働くため、設計や実装のミスを見つけにくい傾向があります。

そのため、開発担当者がテストも担当する場合、自らの確証バイアスをとり除いてテストしなければなりません。

テスト担当者のマインドセット

テスト担当者は「バグを見つけてやろう」という批判的な視点や細部を見る注意力があります。そのため、開発担当者が開発したものを、異なる人間がテスト担当者としてテストすることは、理にかなっているのです。

SHIFTのソフトウェアテスト・品質保証サービスについて

SHIFTでは、開発プロジェクトの上流工程から下流工程までの品質保証サービスを行っています。ソフトウェアテストや第三者検証、品質コンサルティング、テストの自動化など、ソフトウェアテストや品質保証サービスについて幅広い分野の対応が可能です。

上記でご説明した、ソフトウェアテストの7原則にそった効率のよいテストを実施したい場合には、SHIFTにお気軽にご相談ください。

まとめ

この記事では、ISTQBの『テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01』におけるソフトウェアテストの7原則とテストに必要な考え方についてご説明しました。

ソフトウェアテストとは、ただ網羅的にテストすればよいものではなく、テストをすれば欠陥がないことを示せるものでもありません。テスト対象の性質や開発状況なども考慮して、適切なテスト計画を立てる必要があるでしょう。

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

引用元：

ISTQB｜テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説

Introduction