おことわり
- 分かりやすさのために、JSQTBの用語に従っていない部分があります。
その部分は以下です。
テスト条件→テスト項目
テスト分析
テスト項目の分析の方法を以下に示す。
- テスト計画が、何をテストすべきかを定義している。そのもとで、テストの分析を行う。
テストベースの分析
- テストベースとは、テストするシステムを記述したドキュメント。例えば、要件定義書、仕様書、ユーザーストーリーである。
- テストベースの欠陥の発見 要件内の矛盾している点や曖昧な点を発見する
- テスト対象のテスト項目と機能を特定し、優先順位付けをする。
- テスト要件の各要素とテスト項目の間にトレーサビリティを確立する
テストベースの分析のタスクのイメージは以下の図のとおり。
- 拙文だがテスト分析の詳細はこちらの記事でカバー済みのため、その他の内容は割愛させていただきます
テスト設計
テスト分析でテスト項目を定義したら、それをテストケースに変換していく。これがテスト設計である。
方法の概要
- テスト項目をカバーするためのテストケースをテスト技法を使用する。(前提として、使う可能性のあるテスト技法はテスト計画内で定義済みのはず)
- テスト項目とテストケースに合わせて、必要なテストデータを明確にする。
- テスト環境を設計し、必要なインフラやツールを明確にする。例えば、データベースのバージョンは本番環境と同じでないといけないか、対向システムのバージョンはどれである必要があるか、を明確にする。インフラストラクチャーとは、テスト実行のためのもの。テストを行う場書、機器、担当者、ソフトウェア本体、ツール、周辺機器、ネットワーク機器、ユーザー権限などである。
- 要件のドキュメント、テスト項目、テストケースなどの間で双方向のトレーサビリティを確立する。そのもとで、テスト項目につけた優先順位は、テストケース作成、テスト実行の時までプロセス全体を通して一貫させ、その通りに進める。
- テスト項目に合わせて、ローレベルテストケースとハイレベルテストケースのどちらが適切であるかを判断する。
ローレベルテストケースとハイレベルテストケースの違いは、変数レベルで記述されているor値まで記述されているかの違い。
例えば、「ユーザーがア〇ゾンギフトコードをア〇ゾンに登録する」「ユーザーが誤ったギフトコードを入力したときにエラーが表示される」だとハイレベル。「ユーザーがア〇ゾンギフトコードの13985...をア〇ゾンに登録する」「ユーザーが@@@@@を入力すると、""ギフトカード（ギフト券）番号は無効です""というエラーが表示される」だとローレベル。
- この判断の手がかりとなる情報については以下で詳説する。
ローレベルテストケースとハイレベルテストケース
このようにテストケースを2レベルに分割するメリットとデメリットを説明する。
ローレベルテストケースのメリット
- スキルが低いテスト担当者でも、テストの実行と結果の検証ができる。これは、詳細レベルまで指定されているため、自分の経験や知識で判断する部分が少ないからだ。
- テスト結果の再現性が高め。
- 定義が詳細であれば、テストケースについて監査のような検証もできる。
自動化に使うテストケースの実装時間を短縮できる。
ローレベルテストケースを作るデメリット
- 作成と更新の両方に手間がかかりがち
- テスト実行時に、テスト担当者が実行方法を考える自由度が下がりがち。
- 要件などのテストベースが明確に定義されていないと作れない
- テスト条件とのトレーサビリティを担保する時の手間が多くなりがち。これは入力値等が具体的であるためだと思われる。
ハイレベルテストケースのメリット
- テスト実行時の工夫の自由がある。例えば、データや手順を独自に決められる。さらに、テスト対象やテストの方法に関する知識を織り込んで工夫できる。
- 実行のたびに少しずつ異なるテストを行うため、ローレベルテストケースよりもテストカバレッジが上がる可能性もある。
- 要件定義の初期にテストケースを定義できる。(要件が細部まで詰められていなくてもテストケースを作成できる)
- 別のテストにも流用しやすい
ハイレベルテストケースのデメリット
これは、ローレベルテストケースのメリットの裏返し。
- テスト結果の再現性が低め。
- テスト実行のために、テスト担当者のスキルが必要になりがち
- テストの自動化をする際、テストケースの情報が不足している可能性がある。テスト結果の検証にミスが起きる可能性がある
注意点
- テストケースの詳細度にハイレベルかローレベルかを1つだけに定める必要はない。ハイレベルテストケースを先に作成し、後に要件などの情報が集まった段階でローレベルテストケースを作成するということも可能である。
テストケースの要件
- 繰り返し使える
- テスト結果が期待通りか検証可能である
- ソフトウェアの要件までのトレーサビリティが明確になっている
テストケースの構成要素
- テストの目的
- テスト環境の要件
- テストしたソフトウェアのリリース計画
- テストデータの要件。これには、テストケースを実行するため入力データと、システム内に仕込んでおくデータの両方を含む。
- テストの合格/不合格の基準となる期待結果
- テストの事後条件。例えば、変更されたデータ、実行後のシステムの状態、後続処理のためのトリガーなど
考慮すべき点
- テスト手順の詳細度
テスト項目の中には、テスト手順を詳細に指定しない方がよいものもある。むしろ、テスト実行に最低限必要な分だけ、テスト項目を抽象的に記述する方がよいことがある。 - 合格基準
テストケースの合格/不合格の基準を明確にする。 - テストケースの可読性
テストケースは作成者本人以外のテスト担当者も解読できるように記述する。さらに、テストケースをレビューする開発者や、テストケースを承認する管理者も解読できるように記述する必要がある。 - テスト項目の漏れに注意
テストケースは、ユーザーの入力に対する応答を検証するだけではいけない。システムやモジュール間の入出力や処理のテストも含めるべきである。さらに、システムやアプリケーション自体の振る舞いだけではなく、複数の要素の間のインタフェースもテストする。 - テスト設計の費用対効果に注意
テスト設計にかける時間と人員は、リスクレベルとビジネス上の価値に対して割に合うべきである。そのために、テスト設計の優先度も決める。
期待結果を定義する際は、画面上の出力だけではいけない。データや環境面の事後状態も考慮する。 - テストレベルに注意
テスト分析と設計を行う際には、テストレベルとテスト目的に留意すること。それにより、テストケースに求められる詳細度と、必要なテスト環境やツールを特定できる。
※テストレベルとは、単体テストか、結合テストか、ユーザー受け入れテストか...というテストの水準)
テスト設計における困難な点
- 期待結果の定義。
- もちろん、要件が明確かつ単純ならば、期待結果を導出することは可能である。
- だが、手動で期待結果を計算する場合は、ミスを防ぐために自動化が推奨される。
- あるいは、要件の定義が曖昧だったり、矛盾が含まれたりする場合もある。その場合、テスト設計担当者が専門知識または調査によって不足した情報を補う必要がある。
- また、ソフトウェアの処理が複雑な場合、期待結果を定義する別のソースを参照するのがよい。ソースとなりうるのは要件書、ユースケース、RFPなど。
参考資料
ISTQB®テスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト
Version 3.1.1.J03
秋山浩一さんがシラバスの解説をしてくれているnote
ハイレベルテストケースとローレベルテストケースの例は以下の拙文より引用
テストオラクル