第245回： 「ALTAのテキストをつくろう」8 テスト設計2（テスト設計のプロセス 中編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の前半について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「テスト設計のプロセス」の後半について書きます。（1つ残ってしまったので中編とします）
≡ 前回の復習
以下は前回出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果は、ほとんどのひとが「ローレベルテストケースは“具体的テストケース”の同義語」を選択しました。正解です。
「ハイレベル」については、ツイートした問題文を読んでいるうちに思い出したことをツイートしました。
上のツイートに書いた「概算見積」ですが、CMMIのアソシエイト試験の問題文に「High level estimate」との記載があったのです。
以下は、Google翻訳とDeepLの結果です。Google翻訳の「大まかな見積もり」は概算見積と同じだから良いとして、DeepLの「高水準の見積もり」、「高いレベルの見積もり、ハイレベルの見積もり、高レベルの見積もり」は頭の中でひとひねり必要ですね。
「High level」を「ざっくり」と言い換えるのは、身構えなくてよくなるのでおすすめです。
※ 「低水準言語（low-level programming language）と高水準言語（high-level programming language）」のように、長年使われ続き、市民権を得ている用語は、そのままで良いと思います。
（抽象度の違いを意味しているという点で同じだなーって思っていただければ幸いです。）
前回の問題は簡単だったとは思うのですが、ソフトウェアテストの大事なテクニックなので、必ず使いこなせるようになりましょう。
というのは、ソフトウェアテストが主張したい「バグは、もう残っていない」ことの証明は、いわゆる悪魔の証明（devil's proof： 「ない」という消極的事実の証明）なので、論理的に証明することは不可能だからです。
「バグがない」ことの証明は不可能として、それへの実務的な対処手段はないのか？ というとそんなことはなく、「この範囲にはバグはありません」というテスト結果の積み重ねを示すことになります。
バグがないことは証明できなくても「マニュアルに書いてあることはその通りに動きます」とか、「1000人が同時にアクセスしてもダウンしません」といったことはテストで確認した結果を証拠として示すことができます。
そして、「XXしても問題ない」というテスト結果は、「バグがないこと」への確信を高めます。
テストによってバグがゼロになったことの確信を得ることは永遠に不可能です。しかし、「実用に耐えること」や「許容できる軽微な問題しか残っていないこと」を確信させる(assure)」テスト結果をつくることは可能です。
これは「アシュアランスケースによってディペンデンス（きちんと動くことへの信頼感）を高める考え方」です。
保証したいことを【トップゴール】にして、議論を重ねながらそのゴールをサブゴールへ分解するしかたを[合意]して、末端のゴールについてテスト結果などの証拠を示すことでトップゴールについて保証します。
ハイレベル・テストケースを段階的に詳細化して、最終的につくったローレベル・テストケースをテストして、そのテスト結果のエビデンスを残すことでプロダクトを保証するのと同じです。
したがって、このときに大切になるのは、【トップゴール】と【（分解のしかたの）合意】です。
テスト分析とテスト設計のときに「トップゴール」と「分解の仕方の合意」（特に分解に際して、下位のゴールに抜け漏れはないか？の合意、、、重複はあっても仕方ないと考える）について意識すると良いでしょう。
より詳しく知りたい人はアシュアランスケースやD-Caseを調べてみてください。
以上で復習は終わりです。
≡ テスト設計のプロセス
今回は、前回の続きです。ALTAシラバスの以下の箇所（番号は勝手に振りました）を対象とします。前回は、6つのうち2つしか進んでいませんでした。
テストプロセスは、テスト計画時に決定した範囲に従い、テストアナリストがテストケースを設計し、それを実装および実行するテストプロセスが続いていく。テスト設計のプロセスは、次の活動を含む。
1. ローレベルテストケースまたはハイレベルテストケースがどのテスト領域で最も適切であるかを判断する。
2. 必要なカバレッジを確保するテスト技法を決定する。使用する可能性がある一連の技法は、テスト計画時に決めてある。
3. 識別したテスト条件をカバーするテストケースおよびテストケースのセットを設計するために、テスト技法を使用する。
4. テスト条件とテストケースに準じた必要なテストデータを識別する。
5. テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
6. テストベース、テスト条件、テストケースなどの間で双方向のトレーサビリティを確立する。
リスク分析およびテスト計画で識別した優先度基準は、分析や設計の段階から実装や実行の段階に至るまで、プロセス全体を通して適用すべきである。
それでは前回に続き、3から見ていきます。
■ テスト技法の使用
3. 識別したテスト条件をカバーするテストケースおよびテストケースのセットを設計するために、テスト技法を使用する。
2番目と何が違うんだろう？ 2番目について再掲します。
2. 必要なカバレッジを確保するテスト技法を決定する。使用する可能性がある一連の技法は、テスト計画時に決めてある。
2で決定したテスト技法を使用して、「テスト条件をカバーするテストケースおよびテストケースのセットを設計する」のが3でした。
前回書いたことですが、ISTQB ALTAのシラバスでは、ISO/IEC/IEEE29119-2:2021と違って、「テストモデルの作成」と「テストカバレッジアイテムの識別」という2つのタスクが明示されていません。この2と3あたりで行うと考えると良さそうです。
ということで、3に戻ります。
「テストケースおよびテストケースのセットを設計する」とあります。セットは集合の意味と思いましたが、「テストケースのセット」ってなんだろう？と思ってISTQB用語集を検索してみました。
でした。「テストケースのセット ＝ テスト」でいいのかな。テストスイートの同義語に「test set」がありますので、テストスイートでも間違いではないと思います。しかしながら、テストスイートの方は、テスト実行を意識して、テストケースをまとめた物の印象です。
ところで、日本語で「テスト」というと、「テストをする」というように、テストを実行する動作を指していることが多いです。
ところが英語では、testは「テストケースのセット」（ドキュメント）を表します。テストを実行することのほうはtestingとして区別します。
「ソフトウェア開発の時に、プログラミング（programming）を行って、プログラム（program）コードができるのと同じと考えると分かりやすいよ」と湯本さんに教わりました。
ですから、テストタイプやテストレベルの名前の方は英語では、testingです。例えば、「ユースケーステスト」は「use case testing」ですし、「システムテスト」は「system testing」です。
※ 実は「system test」でも普通に通じますし、そう書いてある本も多いです。ただし規格書とか論文等の“用語を厳密に定義して使用するとき”には気を付けましょう。
■ テストデータの識別
4. テスト条件とテストケースに準じた必要なテストデータを識別する。
実際のテストデータを準備するのは「テスト設計」ではなく「テスト実装」のタスクです。
ここでは、どのようなテストデータを用意したらよいのか、テストデータの要件や仕様を決めます。
■ テスト環境の設計
5. テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
こちらも、実際のテスト環境を準備するのは「テスト設計」ではなく「テスト実装」のタスクです。
ここでは、どのようなテスト環境を用意したらよいのか、テスト環境や必要なツールを決めます。
テスト環境については、いわゆるエンタープライズ系のソフトウェア開発においては特に重要です。本番環境をテスト環境として使ってしまって、現業を止めてしまったり、現業のデータを壊してしまったりという失敗は相変わらず続いています。
また、テスト環境をつくったときには、本番環境とテスト環境の違いに着目する必要があります。特に、対向ソフトの種類とバージョンの確認不足はトラブルの元です。（たとえば、本番環境と同じデータベースマネジメントシステムのバージョンをテスト環境で使えるのかどうかは大切です。テスト環境では動いていても本番環境では動かないということが無いようにする必要があります）
≡ JSTQB ALTA試験対策
前回確認したとおり、今回のnoteの範囲は1.4.1の前なので、明確な「学習の目的」はありません。そこで、今回も記載した内容についての全体的な理解を問う問題とします。
《問題》
テスト設計プロセスで実施しないことを1つ選べ。
1. テスト技法を使用してテストケースのセットをつくる
2. テストデータを識別する
3. テスト環境を設計し、必要なツールを識別する
4. 自動テストスクリプトを作成する
答えは次回に書きます。
≡ おわりに
今回は、「テスト設計1（テスト設計の手順）」の途中（5/6）まででした。キャッチイメージの説明はしませんでした。SQiPシンポジウム2023の併設チュートリアルで説明したものです。近いかなと思ったのですが、そんなに近くはありませんでした。（笑）
今回もテキストの追加ページはありません。「テスト設計の手順」で1ページにまとめたいからです。
次回も引き続き「1.4 テスト設計」を書きます。