ソフトウェアテストの基礎

ソフトウェアテストは、多くの分野や業界で使われます。プロジェクトごとに新たな課題があります。テストを始める前に、顧客の視点と対象分野を理解しましょう。必要なテスト手法もプロジェクトによって異なります。基礎をしっかり理解することが、成功への第一歩です。

なぜソフトウェアテストが必要なのか

開発者は、意図せず誤りや欠陥、バグを作り込むことがあります。現代のソフトウェアは複雑で、理解のずれが論理やコードの誤りにつながります。

テストで問題を見つけて修正することで、ソフトウェアの品質が向上します。目標は、バグのないアプリケーションを開発し、提供することです。企業が顧客向けの開発を引き受けると、法令、契約、業界固有の要件が作業を左右します。品質を重視する企業は、テストを標準的な実践の一つに位置づけています。

どこまでテストすれば十分かを判断するのは難しいものです。綿密な計画と適切に設計したテストケースが、質の高い納品を可能にします。

誰がソフトウェアをテストするのか

誰がテストを担当すべきでしょうか。開発者はコードを引き渡す前に何度も確認することがあります。それでも、自分の誤りには気づきにくいため、欠陥が残ることがあります。

テスト担当者は、顧客の視点から先入観なく製品を見て、仕様と要件に注目します。これにより、開発者が見落とした問題を発見できます。そのため、テストは常に開発から独立した担当者が実施するのが望ましい方法です。

開発チームとテストチームを分けることには、欠点もあります。意思疎通が滞ることがあります。品質はテスト担当者の責任だと考えた開発者がコードレビューを怠ると、テストチームの負担が増えます。

開発者が互いの成果物をテストすることもあります。これはバディテストと呼ばれます。各開発チームにはテスト専任の担当者を置くべきで、通常はプロジェクトに少なくとも一つの専任テストチームがあります。使いやすさ、性能、セキュリティなど、テストの種類ごとにチームを分ける企業もあります。専門会社、独立したテスト担当者、コンサルタントに委託する企業もあります。

実際に何をテストするのか

プロジェクトの要件と、ソフトウェアが実際に使われる環境を理解しましょう。これにより、何をテストするかを判断し、適切なテスト戦略を立てられます。

原寸大の図を開く ↗

実際に何をテストするのか

ソフトウェアはいつテストするのか

早くテストを始めると、開発者は期限を守りやすくなり、時間、費用、労力を節約できます。開発の後半で見つかった欠陥には、高い修正費用がかかることがあります。開発を段階に分け、次に進む前に各段階の成果をテストしましょう。これにより、期限どおりの納品と良い結果につながります。各モジュールを仕様に照らして事前に個別テストしておけば、統合も容易になります。

どのくらいの頻度でテストするのか

開発と並行してテストし、早い段階でできるだけ多くの欠陥を見つけましょう。テストの頻度は、求める品質によって異なります。問題を早く発見すれば、変更が簡単で費用も低いうちに設計を直せます。開発が進むと、大きな変更は難しくなり、費用も増えます。

原寸大の図を開く ↗

どのくらいの頻度でテストするのか

ソフトウェアテストの規格とは

テスト規格は顧客にもソフトウェアを作る側にも重要です。顧客は費用をかける以上、ソフトウェアの品質が購入に見合うと確信したいものです。

信頼できる企業は、公に認められた規格に基づいて製品の品質を管理します。規格に従うことで、製品とその期待される動作に一定の保証が得られます。顧客は求める水準のソフトウェアを購入できると確信できます。

作る側にとって、規格は最終製品の品質を高める助けになります。企業は一度選んだ規格を、その後のプロジェクトの土台として使い、最初からやり直さずに済みます。多くのテスト規格は、品質を評価し、テストの効果を高める助けになります。ただし、一つの規格ですべての側面をカバーすることはできません。

より広い要件の一部としてテストを扱う規格も、テストを直接支援する規格も、作業の指針になります。

ソフトウェアのテスト容易性とは

テスト容易性は、ソフトウェアシステムがどれだけテストしやすいかを表します。早いうちに評価し、テストに必要な資源を見積もりましょう。テストは欠陥を明らかにします。テスト容易性を評価すると、欠陥が見つかりにくい箇所を見極められます。テスト容易性が高いとテストしやすく、低いとより多くの手間がかかります。次の要素を考慮しましょう。

1. 制御性があると、テストの進め方を制御し、最適化できます。
2. 観測性を確保するには、動作や結果に影響する要因が見え、テストできる必要があります。
3. 利用可能性とは、テストのためにシステムにアクセスできることです。
4. 一貫した設計、分かりやすい機能、単純なコーディング手法は、テストの複雑さを減らします。複雑なソフトウェアほどテストしにくくなります。
5. 安定性があると、テストしやすくなります。頻繁に設計が変わると、テストが妨げられることがあります。
6. ソフトウェアについて入手できる情報は、テストの効率に大きく影響します。

テスト容易性と欠陥の関係を押さえましょう。

1. テスト容易性が高いと、より良いテストができ、欠陥が減りやすくなります。
2. テスト容易性が低いと、テストの質が下がり、システムに欠陥が多く残ることがあります。

ソフトウェアの検証と妥当性確認

検証と妥当性確認は、異なる種類の分析です。妥当性確認は、作っているシステムが顧客にとって正しいものかを問います。顧客の要件を満たしているでしょうか。

検証は、システムを正しく作っているかを問います。技術的な品質と、求められる規格への適合が中心です。

妥当性確認は、仕様が顧客のニーズを満たすかを確かめます。検証は、開発が組織のソフトウェア品質規格と技術上の実践に従っているかを確かめます。

原寸大の図を開く ↗

ソフトウェアの検証と妥当性確認

すべての開発段階で検証を行い、妥当性確認を最初の要件分析と最後の受け入れテストに集中させる考え方もあります。しかし、実際に従うのは簡単ではありません。開始時にすべての顧客要件を把握するのは難しく、開発が始まってから要件が変わることも珍しくありません。開発チーム自身が変更を求める場合もあります。そこで、開発全体を通して検証と妥当性確認の両方を行いましょう。

テスト担当者は検証と妥当性確認（V&V）を使い、ソフトウェア品質の異なる側面を調べます。

ソフトウェアテストとデバッグ

テストとデバッグは目的が異なります。テストは欠陥を見つけます。デバッグは欠陥が見つかった後に行い、その原因を取り除きます。

テスト担当者が欠陥を報告すると、開発者は根本原因を調べます。関係するモジュールを調べ、コードの問題箇所を特定して修正します。デバッグでは、一段階ずつ原因を見極め、解消します。

修正を試みる前に、欠陥の原因として何が考えられるかを把握しましょう。情報が足りないままデバッグすると、つながりのあるモジュールに新たな欠陥を作り込むことがあります。手当たり次第に試すのは避けましょう。修正後は、テスト担当者にモジュールを戻し、十分にテストしてもらいます。

1. テストは欠陥を見つけます。デバッグはその原因を特定して修正します。
2. テストは開発の重要な一部です。デバッグは、テストで見つかった欠陥に対応します。
3. テストは開発の早い段階から始まります。デバッグは欠陥が報告されてから始まります。
4. テストには検証と妥当性確認（V&V）が含まれます。デバッグは欠陥の原因を調べ、修正します。

欠陥とは

欠陥とは、ソフトウェア要求仕様から外れていることです。コードや設計に欠陥があると、プログラムの実行時に誤った出力が生じることがあります。

1. 欠陥の多いコードは、よくバグだらけと呼ばれます。
2. バグ報告には、欠陥の内容を記載します。
3. バグ追跡ツールで、システムの欠陥を追跡します。
4. テスト技法の一つに、意図的にコードへ欠陥を入れる方法があります。結果を観察して、システムがその問題に対して想定どおりに反応するかを調べます。

原寸大の図を開く ↗

欠陥とは

重大度と優先度とは

重大度は、欠陥がシステムに及ぼす影響の大きさを表します。影響は次のように分類できます。

1. 致命的な欠陥では、システム障害やデータ破損によってアプリケーションが正常に動かず、利用者は先に進めません。
2. 重大な欠陥では、システムに障害が起こることがありますが、利用者は追加の訓練なしに別の方法で目的を達成できます。致命的な欠陥より影響は小さくなります。
3. 中程度の欠陥では、システムは動き続けますが、誤った結果や矛盾した出力が生じます。
4. 軽微な欠陥では、システム障害が起きず、使いやすさにも影響しません。修正は容易です。
5. 外観上の欠陥は、システムの見た目に影響します。

欠陥報告には、重大度と優先度の両方を記録します。優先度は、開発者が欠陥を解決する順番を示します。

1. 優先度が低い欠陥は、優先度が高い欠陥の後で解決します。すぐに対応する必要はありません。
2. 優先度が中程度の欠陥は、より優先度が高い欠陥への対応後、速やかに解決します。
3. 優先度が高い欠陥にはすぐに対応し、できるだけ早く解決します。

対応の緊急度は、報告された重大度と優先度を合わせて判断しましょう。

原寸大の図を開く ↗

重大度と優先度とは

1. 優先度と重大度がともに高い場合、基本機能の問題によって利用者がシステムを使えません。すぐに解決しましょう。
2. 優先度が高く、重大度が低い例として、会社名の誤字やロゴの問題が挙げられます。機能への影響は小さくても、すぐに修正する必要があります。
3. 重大度が高く、優先度が低い場合、重大な欠陥の影響が、利用者がすぐには使わないモジュールに限られます。修正は後回しにできます。
4. 優先度と重大度がともに低い例は、機能に影響しない見た目の問題です。通常、最後に修正します。