テスト設計のプロセス
ソフトウェアテストにおけるテスト設計とはテスト計画において定めた目的と方針に沿って、どのようにテストするのかを具体的に決めることです。テスト設計のプロセスはテストプロセス全体の中の以下になります。
テスト計画をもとにして、「テスト設計方針」ではテストで確認したいことを具体的に考え、「テストケース設計」でテストケースを作成します。
テストケースとは、テストの具体的な作業手順や条件、期待値などを記述したドキュメントです。テストの実行は、テストケースに沿って進めるため、正しくテストが実行できるかはテストケースの記述内容に左右されます。
テストケースをつくる前に、テストケースをどのように作成すべきかといったテストケースの設計方針である、テスト設計方針を考えておくことが重要です。
なぜなら、テスト設計方針を策定する前にテスト設計者がいきなりテストケースを作成しようとすると、テストケースにばらつきが生じてしまい、テスト計画で検討したテストが実現できずに、テストの目的が達成できないことがあるからです。
テスト設計方針の作成により、テスト設計者にとっては自分がどのようなテスト設計を行えばいいかの把握が容易になります。また、案件管理者やテスト設計チームのリーダーから見ると、テストケースの作成に入る前に認識を共有することができ、手戻りが減ることもメリットです。
テストケースに関してはこちらもご覧ください。
＞＞テストケースとは？書き方や満たすべき要件について解説のページへ
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
テスト設計方針
テスト計画で検討したテストレベルとテストタイプごとに、テスト設計方針では具体的に「テスト範囲」「テスト観点」「テスト条件」の3つを決めていきます。「テスト範囲」とは、テストを実施する範囲です。テスト計画で洗い出されたテスト対象のなかでも、テストをするところ、しないところがあります。「テスト観点」とはテストで確認すべきことです。「テスト条件」とは、確認したい入力データや操作のバリエーションのことです。
SHIFTでは、「テスト範囲を決め、どのようなテスト観点があるかを考え、テスト条件を決める」という作業は「箱を置く範囲を決め、範囲内で箱を積み、箱のなかに粒を入れる」というイメージで捉えていきます。
▼あわせて読みたい▼
＞＞ソフトウェアテストとは？種類や目的、重要な7原則を紹介のページへ
＞＞テスト観点とは？必要性や洗い出すための要素、つくり方を解説のページへ
テスト設計方針のイメージ
1.テスト範囲
箱を置く範囲です。システム全体でどこをカバーするのかをあらわします。
2.テスト観点
箱です。一つの箱は一つの確認したい事項をあらわします。確認したい事項の数が多ければ、積む箱の数は多く、高さが高くなります。
3.テスト条件
箱のなかの密度です。テスト結果に影響するテスト条件のバリエーションをあらわします。箱のなかに粒をつめていく、確認したいバリエーションが多いほど粒の数は多くなります。
前述の3点を実際にテスト設計方針書に記述すると以下のようになります。
1.テスト範囲
テスト範囲は要件と要件を実現する機能の対応から考えます。また、要件に直接ひもづく範囲だけでなく、影響範囲も合わせてテスト範囲とします。影響範囲はユーザーの使い方と改修箇所から考えます。ユーザーの使い方を想定し、使用順序やデータの流れから影響がありそうな機能をテスト範囲に追加します。また、改修箇所から影響範囲を考える際には、プログラムやデータ定義などの改修箇所を参照している機能を洗い出し、テスト範囲に追加します。
テストで確認したい要件と対象のシステム名、機能名を記述します。
例：テスト範囲
| 要件 |
システム名 |
機能名 |
|
消費税率の改定対応
新税率が適用されること
|
■■■システム |
売上情報参照画面
|
|
売上情報登録画面
|
|
売上情報更新画面
|
|
会員情報参照画面
|
|
会員情報登録画面
|
|
･･･
|
2.テスト観点
テスト計画で決定したテスト目的から、テストで確認したいことは何かを記述します。
例：
＜テスト目的＞
新税率対応後の金額計算の処理が正しく行われることを確認する
＜テスト観点＞
・端数処理：1円未満の端数が切り捨てられていること
・日跨ぎ：購入中に税率改正日を跨ぐ場合、改正後の税率が適用されること
テスト観点を考える際には、仕様書通りに動くかどうかだけでなく、仕様書には記述がなくともユーザーが行う一般的な操作から推測したり、過去に発生した障害から類推したりすることが重要です。
(テスト観点の作り方についてはこちら：テスト観点の作り方 講座～ゼロから導くテストの切り口～)
3.テスト条件
テスト観点ごとにどのようなテスト条件で確認をすべきか、網羅の基準とその理由を記述します。テスト設計方針の段階では、テストで実施するデータの組み合わせの検討はしません。しかし、「どういったテスト設計技法を使用するのか、網羅する基準はどうするか」まで決めることが必要です。網羅する基準が決まっていると、テストケース作成時のデータパターンの検討がスムーズになります。
例：
端数処理：同値分割法を用いて端数のありとなしに分け、それぞれ1パターンずつ行う
理由：端数処理は既存の関数を使用しており、動作確認済みのため
テストケース設計
テスト設計方針を決定した後は、テストケースを作成することになります。テスト計画、テスト設計方針通りにテストが実施できるようにするために、テストケースに以下の内容を記述します。これらを明確に記述することで、確認すべき項目の漏れや不足を防ぐことが可能です。テストケースのフォーマット(下図)は現場やプロジェクトによって異なりますが、テストケースに記載すべき5つの要素はテスト実行時に必ず考慮すべき事項に変わりありません。
SHIFTでは、以下のようにテスト実行に必須の5項目をテストケースに書くことを基本としています。
| 項目 |
説明 |
|
テスト対象
|
テストするべき対象 |
|
テスト観点(確認内容)
|
そのテストで確認したいこと |
|
テスト条件
|
与えるデータ、操作方法などのバリエーション |
|
テスト手順
|
テストで確認すべき結果が出力されるまでの作業手順 |
|
期待値
|
どのような結果になっていれば合格か、期待される結果 |
まとめ
今回は、テスト設計の基礎的な概要について解説を行いましたが、実践に移していくとなると体系的な理解とスキルが必要になります。
SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。
また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
また、SHIFTではソフトウェアテスト・品質保証のプロが教える実践的体験型講座「ヒンシツ大学」を運営しております。テスト設計の体系的な学習や実践は以下の講座にて行えますので、ぜひご覧ください。
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
資料ダウンロード/動画視聴
ダウンロード
