テスト設計の基礎

テスト分析とは

ソフトウェアテストの設計は、テスト対象の機能仕様書等を読み込むところから始まります。機能仕様書に記載されていることを単に確認するだけでは、妥当なテストとは言えません。テスト対象をきちんと分析し、要求や仕様をテスト可能な形に整理していくことが非常に重要です。
本記事では、テスト分析に必要な作業とその利点について解説します。

テスト分析の目的とテストベース

テストの重要なプロセスのひとつに、「テスト分析」があります。
テスト分析の目的は、テスト対象のシステムの仕様や要求を分析することで、以下の内容を洗い出すことです。

・何に対し、どんなテストが必要か
・機能仕様書等で定義すべきものにヌケは無いか、あいまいな点は無いか、矛盾しているところは無いか

このように、機能仕様書等の読み込みは、単に仕様を把握するだけにとどまりません。その段階から、テストの設計は既に始まっています。この意識は非常に重要なので、きちんと念頭に置くようにしましょう。

テスト内容を検討するために使用する仕様書や画面設計書などの情報源のことをまとめて、「テストベース」と呼び、テスト分析の対象にもなります。
テストベースには、大きく分けて以下の4種があります。

1. 要求(要件)仕様

要求仕様には、ビジネス要求やシステム要件があり、一般的に要求仕様書、要件仕様書、ユースケースなどでまとめられています。また、アジャイル開発などであれば、ユーザーストーリーやプロダクトバックログという形でまとめられることもあります。これらの資料のように、システムやソフトウェアに対して、期待されている機能要件や非機能要件が記載されている情報源が対象となります。
ここで大切なのは、機能要件や非機能要件は、なぜそれが要求されているか、誰のための要件なのか、その要件が設定されている理由や背景を理解することです。このことが、テスト対象の利用シーンの想定に繋がり、テスト設計に活かしていくことになります。

2. 設計仕様

システムの設計仕様と呼ばれる資料群です。具体的には、機能仕様書、アーキテクチャー構成図、ER図やCRUD図などのデータベース設計資料、画面仕様書、インターフェース仕様書、クラス図やシーケンス図などが当てはまります。求められるシステムやソフトウェアによって差異はありますが、それをどのように構築するかを具体的にまとめたものが対象となります。

3. 実装したシステムやプログラム

開発資料だけではなく、実装作業を行ったプログラム自体もテストベースとなります。ソースコードやデータベースのSQLなどがそれにあたります。

4. プロダクトリスク分析結果

システムの機能面や非機能面などのさまざまなリスクを分析した結果です。リスクをもとにテスト活動を推進する手法をリスクベースドテストと言います。プロダクトリスクの分析は、主に開発プロジェクトの計画段階で検討されます。

これらのテストベースの情報を整理し、テスト分析を進めていきます。

テスト分析の内容

テスト分析では、下記の作業を実施します。

・テストベースの分析と不明点の整理

テストベースを精査し、あいまいな点や抜け漏れがある場合はそれを明らかにしていきます。このとき、資料を作成した開発者へのヒアリングを行うことが重要です。資料に記載されていない内容やあいまいな点は、その資料を作成した人に聞くことがもっとも早い確認方法になります。また、実際に動作するシステム環境があれば、それを触ってみて確認することもあります。旧バージョンのシステムなどであっても参考になる場合は多く、そういった環境を用意することも有用でしょう。

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

テストベースから、テストすべき機能と、テストしない機能を明確にします。また、対象機能についてテストしやすいように機能や要素を細分化します。そして、テスト対象へのテスト観点を定めるために、機能面、非機能面の特性や、ビジネス面・技術面の要因、リスクとそのレベルを洗い出します。

これらの分析と整理を行っていく上で、仕様上の不明確な点は表や図などにまとめ、分かりやすく、かつ網羅的に整理していくことが重要です。その際に、デシジョンテーブルや状態遷移図・表などのテスト技法を用いることが有効です。

テスト分析作業中に、仕様上の欠陥を検出することは頻繁に発生するものです。システムの仕様をテスト可能な形で整理していくということは、テスト対象を実際に使用する立場の視点で整理し直すということです。そうすることで、仕様のあいまいな点が発見できたり、仕様には書かれていなかった要件の妥当性を確認することができます。つまり、テスト分析はテストベースのレビューという役割も担っているのです。

テスト分析の進め方

実際のテスト分析作業は、テスト設計作業と並行して進められることも少なくありません。「何をテストするのか」と「どのようにテストするのか」は密接な関わり合いがあり、単独で作業を進めるよりも効果的に、効率的に行うことができるからです。

また、テスト計画の段階でもある程度分析作業を行う必要があります。特にテスト対象および非対象の整理は、テスト工数の見積もりやスケジュール策定作業に大きく影響するためです。テスト計画の段階では詳細な機能の細分化や、細かい仕様の整理・確認という作業まで実施することはありません。しかし、後で詳細なテスト分析を行うことを、テスト計画に含めておくことは欠かせません。

つまり、テスト分析は独立した工程という形ではなく、個々のテスト工程の中で、その粒度を変えながら継続的に進めていくと理解すればよいでしょう。

まとめ

ここでは、テスト分析作業について解説してきました。

テスト分析は、対象となるシステムによって実施内容が大きく変わるため、一般的な解説にとどまっています。

「QUINTEE(クインティ)」のテスト設計プロセスでは、テスト分析とテスト設計を独立した過程としては扱わず、定義された一連の成果物を作成していく中で、繰り返し検討していきます。具体的な作業内容や具体例については、QUINTEEの解説をご参照ください。