テスト設計とは、システム開発における以下の項目を決定します。
・テスト工程でどのように実施するのか
・どういった工程で実施するのか
・どういったテストをするのか項目決定
・テストを実施するにあたっての目的
テスト設計書を作成せずにテスト工程まで進めることで不具合を発見できず利用者に大きな損害が発生してしまう可能性も・・！？
テスト設計書の必要性、書き方
1. テスト設計の必要性
バグを最大限に見つけ出す・テスト実施のコスト・時間を最大に生かすために、テスト設計は大切な工程となっております。
以下はテスト設計をしないでテスト項目を作成した場合に生じる問題点です。
・テストの抜け漏れ
バグを見逃してしまう可能性が高くなってしまう。
・テストの項目が増えてしまう
目的から外れた項目を実施してしまう可能性。コスト・時間のロスが発生してしまう。
逆にテスト設計をしっかりしてテスト項目を作成すると以下のメリットがあります。
・抜け漏れがないテスト項目が作成される
バグを発見する可能性を高めることができる。
・より詳細に細かくテスト項目を作成することができる
バグを見逃す可能性を下げることができる。
・テスト項目の数を最小限にできる
コスト・時間の最適化を実現できる。
抜け漏れがない・必要最低限のテスト項目を作成することは、バグの検出・コストや時間の最適化を図るためにもテスト設計という工程は非常に重要です。
以上はテスト項目を作成するための必要性を伝えましたが、それ以外にも
・情報の共有
テスト実施者、関係者にテストの目的・内容の共有・共通理解を深めることができる。
・保守・運用への活用
過去のテスト結果や内容を元に追加の開発やテストケースの流用や障害対応をスムーズに行うことも可能になります。
といったテスト項目以外でもメリットが存在します。
2. テスト設計手順
2-1. テスト範囲
テストするべき対象を決めること。テスト対象の中でテストを実施する箇所と実施しない箇所を見極めて範囲を絞っていきます。
実現したい内容とそれを実現するための機能から考える必要があります。
ユーザーがどういうふうに使用するのかを想定して、どういった手順で利用するのか・データの流れ等から影響を与えそうな機能をテスト範囲に追加していきます。
テスト範囲の作成の際は、
・実現したい内容
・対象のシステム名
・実現するための機能
を決めてから次の工程に進みます。
2-2. テスト観点
テストで確認するべき内容のことになります。
その際はテスト目的から外れないようにすることが重要です。
テスト観点を考える時には、仕様書の通りに動くかどうかというのが基本になります。
しかしそれ以外にもユーザーが利用する際の一般的な操作から予測・過去に発生している障害から似たような事象を推測することも重要になっています。
・テストの目的を決める
・目的を実現するためにはどういった観点が必要なのかを考える
2-3. テスト条件
確認をしたい入力データ・実施するための手順のバリエーションです。
テストの観点ごとにどういった条件で実施すべきかを決定する必要があります。
それらを決めることでテスト項目を作成する時のパターンを検討する際にスムーズに行うことができるようになります。
・どういったテスト技法を利用して実施するのか
・確認したいことを網羅するための基準はどうするのか
を決めることが必要になってきます。
2-4. テストケースの作成
1〜3の工程が完了したら、テストケースを作成する工程になります。
1〜3で決定した範囲、観点、条件が漏れないようにテストケースには必ず決定した内容を記述します。
これらを記述することで確認するべき項目の抜け漏れ防止、テスト実施する際に具体的な情報としてテスト実施者や開発者に共有されます。
一般的には
・テスト対象（1.テスト範囲で決定したテストをするべき対象）
・テスト観点（2.テストで実現したいこと・テスト目的）
・テスト実施の際の条件（3. テスト条件）
・テストをする際の手順 (3. テスト条件)
・期待値（仕様書通りの結果になっている・期待する結果）
・テストの実施日
・テスト実施者
・実行結果
・備考
を記述します。
テスト設計とは？プロセスと作成方法について解説
テストケースには必ず期待値という項目が必要になります。
1〜3 が曖昧なままだと期待値が定まらない・本来の期待する結果とは異なってしまうことがあります。
しっかりと期待値を確認するために工程の1〜3が大変重要な役割になっております。
3. テスト設計のポイント
テストを実施する際にはテスト設計手順の[1〜3]で決定した項目と[4. テストケース作成] の際に追加した「期待値」を含む５項目は必ず考慮しなければいけません。
これらが１つでも抜けたり、間違った内容で実施した場合、テスト作成時に期待した合格・不合格の判断ができなくなってしまいます。
実施者が気をつけるのはもちろんのことテストケース作成者が気をつけることでもそういったミスを減らすことができます。
・テストで確認したいことを明確にする
具体的な値を記述すること（⚪︎％・⚪️割・⚪︎円・⚪︎個等の単位・細かい条件）
なにを確認したいからその値が必要なのかを実施者がわかるようにしなければいけない。
・期待値を曖昧なものにしない
処理が正しい・正しく動作すると記載しないようにする。
処理が正しい・正しく動作するとはどういった結果になるかが一目でわからないのでわかるようにする。
実施者と作成者で解釈が異なっていた場合に気づかずに不具合を見逃してしまう可能性もあります。
・項目名やデータの内容など仕様書に記載してある結果で記述する
〇〇項目に△△のデータが登録されている。
××画面に◻️◻️という文言が表示されている。というような形で具体的に書くようにする。
項目名・画面名・表示内容等が誰が見ても同じものが確認できない場合、作成者と実施者とのズレが発生するため確認する作業に手間が取られてしまう。
詳細に記述することが必要。
・テスト条件を明確にする
反対の条件でも確認をするように作成をする。
「Aの時は〇〇できること」というケースを作成した場合は、「Aではない場合（B・Cの時）は〇〇できないこと」というケースを作成する必要性がないかどうかを必ず考えなければいけません。
片方ずつのみだった場合、どちらかの不具合を見逃してしまう可能性が出てきてしまいます。
・偏ったパターンをなくす
俯瞰的・客観的な視点をもってテストケース作成後の見直しをする。
意図せずに発生すること、慣れた作業の繰り返しになってしまうことで起きてしまう。
テストケースの網羅性の偏りによってテストの結果にも影響がでてしまう。
そうすると品質を保つことが難しくなってしまう。
・フィードバックをもらう
フィードバックをもらうことで第三者からの客観的な視点が入ります。
そうすることで作成時の観点の抜け漏れ・期待値のズレ等を修正することができます。
そうすることで品質の向上・完成度も高くなるため、非常に有効な解決策になります。
あまりスケジュールの余裕がない場合は、テストの観点だけでもレビューしてもらうだけで、テストするべき範囲の限定・抜け漏れが減らせるので一定の品質を保つことができます。
4. まとめ
テスト設計はバグを見逃さないため、コスト・時間の効率化を最大限に発揮するために必要不可欠である。
また効率を最適化するためにはテスト設計をする際の「テストする範囲を決める」「テストの観点を決める」「テストの条件を決める」という工程が非常に重要な役割をしている。
いかに作成者が効率を図ったとしてもテストを実施する人がテストケースで確認したいこと、曖昧な表現などで作成者の意図しないことが起こってしまってはテストの目的が外れてしまう。
そのため作成する際には誰が見ても一目でわかるような記述を心がける必要がある。