第246回： 「ALTAのテキストをつくろう」9 （テスト設計のプロセス 後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の中編について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「テスト設計のプロセス」の後半について書きます。
≡ 前回の復習
以下は前回出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、4分の1のひとが「自動テストスクリプトを作成する」を選択しました。正解です。
投票ありがとうございます。このnoteを書けるのはあなたのおかげです。
「自動テストスクリプトを作成する」は、テスト設計の次のテスト実装でおこないます。
これは、次回の「1.4.1 ローレベルテストケースとハイレベルテストケース」の話に出てくると思うのですが、究極のローレベルテストケースは、キャプチャーした瞬間に作られる自動テストスクリプトだと思っています。
JSTQBのALTAの試験問題としては、他のものはテスト設計のアクティビティリストに入っていますので、選択肢の4が正解ですし、間違いやすいと思って出題したわけです。
しかしながら、実務では、水と油のように分離できるものではありません。むしろ、虹のグラデーションのように「どこまでが緑色で、どこからが青色か」を議論する意味がないように、「どこまでがテスト設計でどこからがテスト実装か」を議論することは意味のないことです。
以上で復習は終わりです。
≡ テスト設計のプロセス
今回は、前々回・前回の続きです。ALTAシラバスの以下の箇所（番号は勝手に振りました）を対象とします。今回は最後の1つです。
テストプロセスは、テスト計画時に決定した範囲に従い、テストアナリストがテストケースを設計し、それを実装および実行するテストプロセスが続いていく。テスト設計のプロセスは、次の活動を含む。
1. ローレベルテストケースまたはハイレベルテストケースがどのテスト領域で最も適切であるかを判断する。
2. 必要なカバレッジを確保するテスト技法を決定する。使用する可能性がある一連の技法は、テスト計画時に決めてある。
3. 識別したテスト条件をカバーするテストケースおよびテストケースのセットを設計するために、テスト技法を使用する。
4. テスト条件とテストケースに準じた必要なテストデータを識別する。
5. テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
6. テストベース、テスト条件、テストケースなどの間で双方向のトレーサビリティを確立する。
リスク分析およびテスト計画で識別した優先度基準は、分析や設計の段階から実装や実行の段階に至るまで、プロセス全体を通して適用すべきである。
■ 双方向トレーサビリティ
テストベース、テスト条件、テストケースなどの間で双方向のトレーサビリティを確立する。
双方向トレーサビリティとは、「テストベース → テスト条件 → テストケース」の方向と、「テストケース → テスト条件 → テストベース」のどちらの方向でも情報を追跡できるという意味です。
情報が追跡できれば、例えばテストベースの一つである仕様書で仕様の変更が発生したときに、その仕様変更が影響するテストケースを簡単に見つけることができます。
双方向トレーサビリティを実現するために、トレーサビリティマトリクスをつくることが多いです。
トレーサビリティマトリクスとは、ただの表のことです。例えば、「テストベース → テスト条件」のトレーサビリティであれば、行見出しをテストベース、列見出しをテスト条件にした表をつくって、列と行の交点に〇マークをつけるなどします。
ググるときには「トレーサビリティマトリクス」よりも、より一般的な「DSM Dependency Structure Matrix」のほうが良いかもしれません。
ただ、「トレーサビリティマトリクス」も「DSM」も二元表なので、複数の表をつくります。
具体的には、「テストベース ←→ テスト条件 ←→ テストケース ←→ バグ」の双方向トレーサビリティを取るためには、「テストベース ←→ テスト条件」「テスト条件 ←→ テストケース」「テテストケース ←→ バグ」の3つの「トレーサビリティマトリクス」をつくります。
双方向といっても２枚つくるわけではありません。縦横が違うだけなので１枚つくれば双方向で使えます。
この３枚のトレーサビリティマトリクスを主に使います。
ただし、私は全体を俯瞰したいので、抽象度をあげたトレーサビリティマトリクスを4軸QFDで１枚つくっていました。
4軸QFDは、聞き慣れない言葉だと思うのですが、富士ゼロックス（現在の富士フイルムビジネスイノベーション）が考案した表です。
以下のような表ですが、上記3つの「トレーサビリティマトリクス」を1枚にまとめて全体を俯瞰して眺めるときに使います。（下表の行列見出しはイメージを持ってもらうために書いたものです。）
それぞれの項目が多いと巨大な表になってつくるのが大変ですし使う方も大変なので、ハイレベル“ざっくりと抽象化したレベル）の項目でつくります。
プリントして１枚に収まるような大きさにします。詳細が見たければ個々のトレーサビリティマトリクスを見れば良いからです。
≡ JSTQB ALTA試験対策
前々回確認したとおり、今回のnoteの範囲は1.4.1の前なので、明確な「学習の目的」はありません。そこで、今回も記載した内容についての全体的な理解を問う問題とします。
《問題》
テスト設計では、テストケースに加えて確立するものがあります。それは次のうちのどれですか？
1. テストベースとテスト条件の双方向トレーサビリティ
2. テスト条件とテストケースの双方向トレーサビリティ
3. 1と2
4. 1と2（ただし双方向でなく時系列の上位方向から下位方向のみ）
答えは次回に書きます。
≡ おわりに
今回は、「テスト設計1（テスト設計の手順）」をようやく終えました。
ALTAのシラバスには、テスト設計の手順に続いて、「テスト設計時にテストアナリストが留意しなければならない7つのポイント」についての記載があります。割と当たり前なことと、高度な話が混ざっていてちょっと生煮えなので、本noteではパスします。受験する人は目を通しておいてください。
以下に今回までのテキストを置きます。
14ページまでです。今回は2ページしか進みませんでした。実質はキャッチイメージだけです。この図を使ってテスト設計プロセスをひとに説明できるようになりましたでしょうか？
パワポのノートについても追加しています。
次回は「1.4.1 ローレベルテストケースとハイレベルテストケース」に進みます。