テスト分析とは？【ソフトウェアテスト基礎知識】

ソフトウェアテストの工程のひとつに、テスト分析があります。ここでは、ソフトウェアテストの基礎知識「テスト分析」について詳しく解説します。

テスト分析とは

テスト分析とは、テスト対象となるソフトウェアが持つ機能のふるまいを調査・理解することをいいます。テスト分析では、システムの使用などを分析することで、何に対してテストが必要か、どのようなテストが必要なのかを洗い出します。さらに、機能仕様に矛盾点やあいまいな点がないかなどを浮き彫りにさせ、改善点を見つけるのです。

テストの設計は、機能仕様書などの読み込みで使用を把握することから始まっています。この仕様書などの情報源のことをテストベースといい、テスト分析の対象となります。

テスト分析の進め方

テスト分析を進めるには、まずテスト計画の段階で分析作業を行う必要があります。テスト対象と非対称を整理することは、テスト分析のスケジュール算定にも大きく影響します。テスト計画を立てる段階では、細かい仕様の整理や機能の細分化といった作業まで行う必要はありません。ただし、あとで作業を行うことは、テスト計画に含めておきます。

テスト分析とテスト設計は、並行して進められることも多々あります。テスト分析とテスト設計を同時に進行することで、より効率的にすすめることができます。

テストベースとは？

テストベースとは、仕様書や画面設計書などの情報源のことを指します。仕様書や画面設計書は、テスト内容を検討するために使用されるものです。どのようなテストが何に対して必要なのか、機能仕様書などで矛盾点やあいまいな点がないかなどを洗い出していきます。

テストベースを大きく分けると「要求仕様」「設計仕様」「ソースコード・データベースSQL」「プロダクトリスク分析結果」の4種類になります。この4つのテストベースを整理し、テストベースを行っていきます。

要求仕様

要求仕様は、システムに対して期待される機能要件・非機能要件が記載されているものが対象になります。機能要件や非機能要件が、誰のための要件でどのような理由があってテストされているのかを、理解することが大切です。このことをテスト設計に活かしていきます。

設計仕様

システムの設計仕様と呼ばれる資料には、機能仕様書、画面仕様書、インターフェイス仕様書などが当てはまります。これらの構築方法を明確にまとめたものが対象です。

ソースコード・データベースSQL

実装作業を行ったシステムやプログラムもテストベースです。ソースコード・データベースのSQLなど、プログラム・システム自体もテストベースになります。

プロダクトリスクの分析結果

プロダクトリスク分析結果もテストベースです。プロダクトリスク分析は、システムの機能面・非機能面などのリスク分析の結果です。プロジェクトの計画段階で検討されます。

テスト分析の主な作業

テスト分析で行われる主な作業は「テストベースの分析と整理」「テスト対象の機能抽出と整理」です。これらの作業について、詳しく説明します。

テストベースの分析・整理

テストベースを精査し、不確かな部分や抜け漏れている点があれば明確にしていきます。テストベースの分析は、実際のシステム環境を利用して確認することもあります。システムの旧バージョンであっても参考になるケースもあるため、実際に触ってみることは効果的です。

資料であいまいな点や記載されていない点があるときは、資料の開発者に聞き取りを行うことも大切です。開発者本人に聞くことで、スムーズに分析ができます。

テスト対象の機能抽出・整理

テスト対象の機能抽出・整理を行い、テストすべき機能としない機能を明らかにしていきます。テスト対象の機能面・非機能面の特性やリスクとそのレベルなどを洗い出し、テスト観点を定めます。テスト分析によってシステムの使用を整理していくことで、仕様の不明確な点が見つかったり、要件の妥当性を見つけることができます。

テスト対象の機能・抽出を行う題は、使用上の不明確な点は図や表でわかりやすくまとめることが大切です。そして、広い範囲にわたって整理していきます。テシジョンテーブルなどのテスト技法を用いることも有効です。

テストレベルごとのテスト対象について

テスト分析では、テストすべきことを明確にしていきます。ここからは、「ユニットテスト」「統合テスト」「システムテスト」「受け入れテスト」について、テストレベルごとのテスト対象を解説していきます。

ユニットテスト

テストユニットのテスト対象になるものは、開発プロジェクトの中で定めた開発の最小単位となる「モジュール」「関数」「メソッド」「クラス」などです。これらを独立してみたものがテスト対象になります。テスト対象になるものが受け付ける入力・出力のパターンをテストします。

統合テスト

統合テストの対象は、ユニットテストで確認したコンポーネントを連携させた状態での各コンポーネントの結合です。インターフェイスやソフトウェアが稼働する予定のオペレーションシステム上で確認を行い、テストが必要なポイントを見極めていきます。ユニットテストと異なる点は、それぞれの連携部分および連携により実現できることに着目することです。

システムテスト

システムテストでは、システムとして完成したものがテスト対象になります。要件定義書や画面仕様書といったドキュメントをベースにテスト分析を行います。システムテストはテストする範囲が広い点が、ユニットテストや統合テストとは異なる部分です。ユーザーの使用頻度が高そうな部分や欠陥が出そうな部分を考慮して、テストポイントを明らかにしていきます。

受け入れテスト

受け入れテストは、システムテストまでが終わったソフトウェアが対象です。環境が本番環境になるといった違いはありますが、テストシステムと同じものが対象になると考えて良いでしょう。受け入れテストのベースになるのは、実際の運用を明記したドキュメントやユーザーの要求などです。システムの操作性や機能性がビジネス要件を満たしていることを確認していきます。

テスト分析作業がうまくいっていない場合のトラブル

テスト分析作業がうまくいっていない場合、さまざまなトラブルが起こります。テスト対象を十分に理解しないままテスト設計を行うと、テストの抜け漏れが起こる可能性があります。過剰にテストをしてしまうという問題が起きることもあるでしょう。

また、仕様の変更があった際に、見直さなければならないテストケースが分からなくなることもあるでしょう。誤ったテストケースが残ってしまう恐れもあります。

要件とテスト条件の関係を紐づけしておくことも大切です。紐づけされていないと、どの要件に対してテストをしているのかが分からなくなってしまいます。作業がうまくいっていないとトラブルが起こることを想定し、テスト分析を進める必要があります。

⽇本語のサポートが⼿厚い！
UIテスト自動化ツールを比較