テスト設計の知識の整理

この記事の概要

テスト設計のプロセスを分解して解説しています。
テストのプロセスの全体像についてはこちらに過去のまとめがあります。

テスト設計

目的

当たり前のことを言います。
テスト実装と実行をする際、それは最適な進め方で行いたいですよね。

しかし、テスト実装とテスト実行を複数人で進めたり、大規模で複雑なソフトウェアを開発する場合、個別に判断を下すことになります。そして最適じゃないやり方に沿って進められることがあります。
例えば、Aさんはテストケース作成時に過去のテストケースを流用したが、Bさんは新規に作成した、としましょう。そして、流用で十分だったとします。すると、新規作成してたら無駄が発生したことになります。
このように、テスト関係者全員の判断が最適解に到達し、一致するとは限りません。

そのため、もれなく最適なやり方に従ってテスト実装がなされるよう、個別判断を排し、やり方を予め決めて関係者に共有するのが良いでしょう。
そこで、テストプロセスにテスト設計というタスクが加わります。

プロセス

まずプロセス全体は以下の通りです。

1. テストでフォーカスする機能や処理、性能などをもとに、テストケースを作成する。ただし、ここでのテストケースはハイレベル。
2. テストケースの作り方と使用法について以下を検討する。
   • テストタイプ(注)分け
   • テストサイクル
   • テスト環境
   • 自動化の有無
   • テストケース再利用の有無
   • ローレベルテストケース作成の優先度や順序
   • テスト実行の優先度や順序
3. テストタイプに応じたテストケースの構造を決める
4. テスト技法に沿ってローレベルテストケースを作成

(注)テストタイプ = テストする対象ごとにテストを分類した際のタイプ。
例えば、機能テスト、性能テスト、負荷テスト、セキュリティテストなど。

1. ハイレベルテストケースの作成

• テストケースはテスト対象のプログラムやコンポーネントへの入力の情報とその時の期待結果の情報を持つ。

• これらの情報の抽象度が高いテストケースをハイレベルテストケースと呼ぶ。

• 例えば、「ユーザーがア〇ゾンギフトコードをア〇ゾンに登録する」「ユーザーが誤ったギフトコードを入力したときにエラーが表示される」だとハイレベル。「ユーザーがア〇ゾンギフトコードの13985...をア〇ゾンに登録する」「ユーザーが@@@@@を入力すると、"ギフトカード（ギフト券）番号は無効です"というエラーが表示される」だとローレベル。

• このようなハイレベルテストケースの要件

  • テストケースの事前条件
    • 例：ユーザーがア〇ゾンにログインしている
  • テスト対象への入力情報
    • 例：ギフトコード
  • テスト対象の期待動作結果
    • 例：1000ポイントがユーザーに登録される
  • 期待動作結果のほかに、見ておくべき事後条件
    • 例：登録されたギフトコードは再登録できなくなっている

注：以下、このアマ〇ンギフトコードを登録する機能をテストするという前提で例をあげます。

2. テストケースの作り方と使用法を検討

ハイレベルテストケース間の関連を捉える
→テストケースの実行順序や再利用するかを判断しよう

• テストケース（TC）に対してあれこれ判断する。

  • TCがどのようなテストタイプに使えるか？
  • TCの実行に必要な環境は？
  • イテレーティブな開発の場合、テストをイテレーティブに実施するか
  • テストを自動化するか

• また、以下の判断には、テストケース間の関連の情報が必要。

  • TCたちの実行順序
  • TCの再利用の可否
  • テストケース作成の優先度や順序
  • テスト実行の優先度や順序

• では関連とは何か？　2種類挙げられます。

  • 依存
    例：TC1がギフトコード登録の履歴の一覧表示のテスト、TC2が一覧表示までにかかる時間のテストの場合、TC2はTC1が成功していないと実行できない。そのため、TC2はTC1に依存している。

  • 細分化
    例：TC1がギフトコード登録の履歴の一覧表示、TC2はレコード数が20件以下の場合の履歴表示、TC3はレコード数が20件より多い場合の「もっと見る」ボタンの表示、TC4は「もっと見る」ボタンを押下した際の残りレコードの表示とする。この場合、TC1を分解して、TC2, TC3, TC4ということになる。

※イメージ

3. テストタイプに応じたテストケースの構造を決定

（解説なしです。すみません。）

4.テスト技法を用いてローレベルテストケースを作成

テスト技法の種類

ローレベルテストケースを作成する際に用いるテスト技法とはどのようなものでしょうか。

大きく分けて3種類

• ソフトウェアの要求や仕様を踏まえたテスト技法
  • いわゆるブラックボックステストによく使われる
• プログラムコードを踏まえたテスト技法
• 人の情報に基づくテスト技法

参考 テスト技法マップ
引用元 IPA 高信頼化ソフトウェアのための
開発手法ガイドブック

それらの下位の技法

ソフトウェアの要求や仕様を踏まえたテスト技法

• ユースケーステスト
• 同値分割
• 境界値分析
• 状態遷移テスト
• デシジョンテーブルテスト
• ペアワイズテスト

プログラムコードを踏まえたテスト技法

• 制御フローテスト
• 記号実行に基づくテスト

人の情報に基づくテスト技法

上二つの技法の補完として行う。恣意性高め。

• エラー推測テスト
• リスクベーステスト
• 探索的テスト

これらの技法の内、
ユースケーステスト、エラー推測テスト、リスクベーステストのみ解説します。
(自分の業務に関連が深いため備忘録として..)

ユースケース/エラー推測/リスクベーステスト

ユースケーステスト

• 使いどころ：非機能のテストの際のシナリオを使う。たとえばレスポンスタイムをテストする際には、何かしらのシナリオをもとに行う。その際のシナリオとしてユースケースに基づく。
• 適用方法：基本シナリオ、代替シナリオ、例外シナリオ、ごとに1つ以上テストケースを作成する。
  • 例：
    • 基本シナリオ：ギフトコードを入力して登録する。
    • 代替シナリオ：クレジットカードによるチャージによって登録する。
    • 例外シナリオ：ギフトコード番号に誤りがある場合はエラーを表示する。
• 注意点：ユースケース記述にも見落としている代替シナリオ、例外シナリオがあるかもしれない。そのため、ユーザーのペルソナを想定し、その目線で代替シナリオ、例外シナリオを考えてみるのが良い。

エラー推測テスト

• 使いどころ：ソフトウェア要件・仕様とプログラムコードに基づく技法では発見しづらい故障を発見したい時
• 適用方法：ともかく経験等から設計者や実装者が犯しがちなミスを推測する。それをもとに埋め込まれそうな欠陥を見つけるためのテストケースを作成する。
• 例：日本語で書かれた仕様書を英語に翻訳した際の翻訳ミスに起因する欠陥
• 注意点：ミスを推測するため、組織内のナレッジを活用する。

リスクベーステスト

• 使いどころ：テストケースに優先度の区別をつけたい時
• 適用方法：故障によるリスク(事象の種類、事象の発生確率、影響度)を特定し、アセスメントする。
  そのアセスメントに基づき、リスクを低減するためのテスト設計をする。
• 例：ユーザーに金銭的損失をもたらす故障が起きる確率が、仕様の事情から高い→故障がないようにカバレッジを大きめにする

さいごに

参考資料

この記事は主にこちらの参考書に基づきました
『土台からしっかり学ぶーーソフトウェアテストのセオリー』

ソフトウェアテストに関する標準は以下のリンクをご参照ください。ここにはテストの一般的概念、プロセス、ドキュメンテーションなどテストについて包括的に示してあります。これは、ISO, IEC, IEEEが合同で発行したものです。
Software and systems engineering Software testing

ポエム

• 2023年はテストケース作成と入力データの定義の仕事を担当しました。
  これは、ハイレベルテストケースとローレベルテストケースを作っていたことになると思います。
• 自分の経験と参考書をもとにテストケースの基礎づけを図示すると以下のようになると思います。自分の判断が何に基礎づけられているべきかを知るには、先人の知恵を参照するか、プロアクティブにチーム内で聞くかが必要だと思いました汗
  
• 自分の仕事の反省点。
  • 自分の担当したテスト設計の大枠は他のメンバーが既に決定済みでした。テスト技法はユースケーステストに近かったです。
  • しかし、私はユースケーステストにあるように、ユーザー目線でシナリオにモレがないかは加味できていませんでした。
  • また、プロダクトの要件上、リスクベーステストの観点も大切にしたいです。