第250回： 「ALTAのテキストをつくろう」13 （テスト設計 テストケースの設計 後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の「テストケースの設計」の中編として、「期待結果」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「1.4.2 テストケースの設計」の後編（20ページ： 注意事項＝より良いテスト設計のためのヒント）について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、1が56.3%と最も多く、正解も1です。正答率は少し低めでした。順番に解説します。
1の「アジャイル開発ではPOの考えが期待結果となることがある」はシラバスの以下の箇所です。
アジャイルソフトウェア開発では、テストオラクルはプロダクトオーナーかもしれない。
スクラムガイドによると、プロダクトオーナーの役割には以下のものがあります。（他にもあります）
● プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。
● プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、プロダクトゴールを策定し、明示的に伝える。
今後、スクラムをするしないは関係なく、ソフトウェア工学の基礎知識のひとつとして『スクラムガイド』は読んでおいたほうがよさそうです。
２の「期待結果生成ツールの開発は推奨しない」（間違った主張）に対応するシラバスは以下の通りです。
テストの期待結果を定義することが、特に課題となることがある。これを手動で計算することは単調で時間のかかる作業で、エラーも発生しやすいので、可能な限り、自動化されたテストオラクルを見つけるか、または作成することを推奨する。
3の「仕様書の記載内容を期待結果としてはならない」が間違っている理由は、テストオラクル（＝期待結果の源泉）としてはいけないものは、「仕様書の記載内容」ではなく「（テスト対象ソフトウェアの）コード」だからです。
もっとも、妥当性確認（ユーザーのニーズそのものに応えることができるシステムとなっていることの確認）をおこなうテストケースをつくるときには、仕様書の記載そのものの間違いも見つけたいのですから、「仕様書の記載内容」をテストオラクルにしてはなりません。
ただし、仕様書の検証の場合は仕様書の記載内容をもとにしてテストケースをつくります。したがって「仕様書の記載内容を期待結果としてはならない」は間違いです。
4の「期待結果は出力のみ。事後条件は期待結果とならない」は、消去法で選んだ人が多かったのかもしれません。
こちらについてシラバスには、以下の記載があります。
（テスト設計では）影響を受けたデータ、テスト実行後のシステムの状態、後続処理のためのトリガーなどの事後条件（のアイテムを識別する。）
「識別する」と書いてあるだけで「期待結果として取り扱う」とまでは書いていません。また用語集の記載も以下の通りです。
ここで、「事後条件は振る舞いではないので期待結果ではない」と主張することもできると思います。しかし、選択肢1と比較すると弱いと思います。
また、「期待結果」と考えることで「テストで確認しなくては」というモチベーションになることが期待されます。そこで、今回の正解は1とします。
以上で復習は終わりです。
≡ テスト設計の注意事項
今回は、「テスト設計の注意事項」がテーマです。でも、「○○をしてはいけない」という、何かを禁止したり制約条件を与えたりするほうの注意事項ではありません。
いわゆる「注意」というよりは、「より良いテスト設計のためのヒント（先輩からのアドバイス）」が書いてあります。
前々回に私はこんなことを書きました。
実はALTAシラバスの中で私が一番好きな箇所は今回から始まった「1.4.2 テストケースの設計」です。
経験豊富なテストエンジニアがテストを始めたてのテスト担当者にテストのノウハウを丁寧に一生懸命伝えようとしている文章だと感じるからです。
・・・以下略
トピックスは以下の5点となります。
ドキュメント
品質特性
静的テストとの組合せとレビューを考慮する
テストインフラストラクチャーの要件
テスト設計の終了基準
以下、順番に説明します。
■ ドキュメント
何を文書化するかを考えることが大切です。考えるときのポイントについてシラバスでは以下の５つを挙げています。（下記は要約せずにシラバス記載のままです）
1. プロジェクトリスク（文書化する必要のあるもの、文書化してはいけないもの）
2. ドキュメントがプロジェクトに提供する「付加価値」
3. 準拠する必要のある標準および満たす必要のある規制
4. SDLCまたは使用するアプローチ（例えば、アジャイルアプローチでは、「必要最小限」の文書化を目標にする）
5. テストベースからテスト分析およびテスト設計を通してのトレーサビリティの要件
1に書かれているように、プロジェクトリスクをドキュメント化することは大切です。
ところで「プロジェクトリスクの観点で文書化してはいけないもの」ってなんでしょう？メンバーの個人情報やプライバシー（例えば、健康状態）とかでしょうか。
確かに、例えば、おめでたいことだったとしても、本人が言う前に、「○○月から産休（男女問わず）に入る可能性がある」といったことを文書化したり共有したりしてはなりません。
ところでプロダクトリスクは？と思った人がいるかもしれません。リスクベーステストではテスト分析のフェーズでプロダクトリスクを明らかにします。
2, 3, 4は、「ドキュメントを書くことでプロジェクトにどのような価値を提供するか」について考えようということです。
前回のプロジェクトでつくったドキュメントを持ってきて、今回のプロジェクトの内容に書き換えるということが行われがちです。また、上司から「前回の『テスト仕様書』を真似してつくってこい」、もしくは、「標準テンプレート○○を埋めてこい」と指示されることも多いものです。
仕事ですから、手を動かしてアウトプットを粛々と期日に間に合うようにつくることは大切です。でも、少しの時間、手を止めて、ここに書いてある2, 3, 4を読んで「なんのためにドキュメントをつくっているのだろう？」と考えるのも悪くありません。
最後の5の「トレーサビリティの要件」は、第246回で書いた「双方向トレーサビリティ」の話です。該当箇所を引用します。
テストベース、テスト条件、テストケースなどの間で双方向のトレーサビリティを確立する。
■ 品質特性
テスト対象の品質特性にテスト設計を対応させるために「ISO 25010」の規格が参考になります。FLにも出てきた話です。
詳しくは、「69号：品質特性」で紹介している、『つながる世界のソフトウェア品質ガイド』をダウンロードして読むのがお勧めです。
開発者、特にQAエンジニアは「品質特性」を避けて通ることができませんので、一度は読んでおきましょう。
■ 静的テストとの組合せとレビューを考慮する
「静的テスト」と「動的テスト」を別々に独立してつくるのではなく組み合わせて考えましょうということです。
動的テストの「テスト分析」は見方を変えれば「静的テスト」そのものかもしれません。
逆に考えると、良い静的テストになるように「テスト分析・テスト設計」を行うというアプローチも有効でしょう。
特にRBT（要求ベースのテスト）は、要件の良いレビューになります。例えば、要求から原因結果グラフを描き、できあがったデシジョンテーブルをチェックすることで要求の不備に気づくことがあります。
「シフトレフト」や「Wモデル」の文脈で語られることもあります。
■ テストインフラストラクチャーの要件
テスト環境に対する完全な要求は、具体的なテスト内容が決定するテスト実装が終わるまで決まりません。
しかしながら、全てを決めることはできなくてもテスト設計の段階で決めることができるものもあります。
テスト環境を用意するにはお金も時間もかかりますので、早め早めに準備を進めることが大切です。
具体的には、場所、機器、担当者、ソフトウェア、ツール、周辺機器、通信機器、ユーザー権限等々の調達をどうするか？ 決められるものは決め、粛々とテスト環境の構築をおこないましょう。
私は開発部門など、他部門からお借りするものの調整に苦労しました。
開発環境そのものをお借りしたり、高価なソフトウェアをお借りしたりします。
しかしながら、数が限られた高価な試作機（試作機はだいたい販売価格の10倍はします）や1台しかないシミュレータを借りる調整は面倒なものです。
開発部門でもテストでバグが見つかれば、デバッグをする環境が必要となります。ですから、同じ環境を共用したり譲り合ったりすることが大切です。
■ テスト設計の終了基準
シラバスに以下の記載があります。
重要なのは、終了基準が測定可能であり、以降の手順に必要なすべての情報が提供され、必要なすべての準備が実施されていることである。
終了基準をもとに終了できるかどうかを判定する会議のことを「クォリティゲート」、もしくは、「フェーズ移行審査会」と呼ぶことがあります。
フェーズ移行審査会では、例えば、「システムテストを終了して受け入れテストに移っても良いか」を判断します。受け入れテストはお客様に実施していただくものです。
もしも、受け入れテストで（基本的な部分であり、“テストをしたら見つかるはずだろう”といった）恥ずかしいバグが見つかったら信用を落としてしまいます。
太字にした「終了基準が測定可能」であることと「次のフェーズを開始しても困らない」ことが重要です。
≡ JSTQB ALTA試験対策
いつものことですが、まず、テスト設計の「学習の目的」を確認します。
1.4 テスト設計
TA-1.4.1 （K2）ステークホルダーがテスト条件を理解する必要がある理由を説明する。
TA-1.4.2 （K4）特定のプロジェクトシナリオに対して、テストケースの適切な設計レベル（ハイレベルまたはローレベル）を選択する 。
TA-1.4.3 （K2）テストケース設計で考慮すべき問題を説明する。
今回の範囲（1.4.2）については、TA-1.4.2を問う問題とします。K4なので、「分析」という深いレベルで使いこなせることを確認するテストとなります。
《問題》
テスト設計時は静的テストと組み合わせると良い。以下の選択肢から正しいものを選びなさい
1.静的テストと動的テストを同時に行う
2.静的テスト結果を使用して期待結果を生成する
3.テスト設計時にテストできない要件が見つかることは滅多にない
4.テスト設計は良いレビューとなる
答えは次回に書きます。
≡ おわりに
今回は、「テスト設計の注意事項」の話題でした。
当たり前のことしか書いていませんし、ALTAのテストにもなりにくい個所とは思うのですが、読むたびに新しい気付きがあるので書きました。
みなさんも、騙されたと思ってJSTQBのALTAシラバスの20ページを読み返してみてください。
さて、今回、ALTAテキストの追記はありません。すみません。
1章が終わったタイミングでまとめてつくります。
テスト設計を先につくるとテスト設計のボリュームだけが増えそうで、他（テスト分析、テスト実装、テスト実行）とのバランスが悪くなりそうな気がするのです。
次回は「1.5 テスト実装」に移ります。こちらも2ページ半あります。次回は前編として、「テスト実装のアクティビティ」について書きたいと思っています。