第249回： 「ALTAのテキストをつくろう」12 （テスト設計 テストケースの設計 中編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の「テストケースの設計」の前編として、「テストケースの構成要素」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「1.4.2 テストケースの設計」の中編（期待結果）について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、3が64.9%と最も多く、正解も3です。
回答数が少なめで、正答率がまずまずなのは、ALTAを学習したことがある人には簡単だけれど、そうでない人には難しい問題ということでしょうか。
2番目に多かった、
TCに書く「目的」は観測可能なものとは限らない
ですが、ALTAのシラバスでは、
目的（観測可能で測定可能なテスト実行の目的）
と明確に「観測可能」と書いてあります。
テストは合否を判定する行動です。全てのテストケースは、合否を判断できるように書いていなければなりません。
これは、今回のテーマである「期待結果」につながる話なのですが、テストの合否はテストした結果（実際の結果：actual result）と期待していた結果（期待結果：expected result）を比較することで行います。今回のキャッチイメージはそのことを表現しています。
「実際のテスト結果」と「期待結果」を比較して、両者が同じなら合格、違っていたら不合格というわけです。
さて、比較をするためには、テストした結果（実際の結果）が観測できる必要があります。観測できなければ期待結果と比較するものがないためです。
ここで、ISTQBの用語集を引いてみました。
まず、「実行結果」を用語集で検索してみたのですが、検索結果の先頭に現れずにあれ？ってなりました。
さらに「Matching synonyms」にあるのはなぜ？？？？？とたくさんの？マークが頭に浮かびました。
“actual result”は、「実行結果」ではなく、「実際の結果」が本訳なんですね。
# 「の」で検索したところ、ISTQBの用語集には「○○の■■」といった用語がいくつかあるようです。「○○」と「■■」を別の用語として登録するか、意味が通じるなら「の」を削除するか、「の」のあとの体言から「の」が入らない新たな用語をつくるほうが良いと思いました。
「テストの四象限（testing quadrants）」のような、訳語が定着してしまっているものはしかたないけど。
以下は、ISTQBの用語集で両者を引いた結果です。
以上で復習は終わりです。
≡ 期待結果
今回のテーマです。
期待結果の概略と使い方はFLの範囲の話ですし、上に書いたとおりです。ALTAのシラバスには、もう少し詳しい話が書いてあります。
■ テストオラクル
ISTQBが日本にやってきたのは2005年のことです。
当時ISTQBのトップをしていたRex Black氏がJaSST '05 Tokyoで基調講演をされた2005年1月24日～25日のときのことです。
Rex Black氏からJaSST実行委員に「日本でもテスト技術者の資格認定試験を始めませんか？」という話がありました。
1年の準備を経て「トライアル Foundation Level試験」が実施されました。
2006年1月31日のことです。
当時、「テストオラクルってなんだろう？」と話題となりました。「テストオラクル」という用語を仕事で使っている人が一人もいなかったからです。
そもそも、“オラクル”はデータベースの商品名としてしか馴染みがありませんでした。
当時のISTQBの定義は、今より詳しく書かれていました。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
「うーん。ピンとこないなあ」とみんな思いました。「期待結果のソース」ということで、「期待結果を生成するツール」を思い浮かべてみたものの、最後に「コードであってはならない」とあり、その前の具体例にも「期待結果を生成するツール」がなかったからです。
最終的には、「コードであってはならない」の意味はテスト対象のソースコードに書いてあることを期待結果にしてはならないということだろう（何故なら、テスト対象の欠陥を見つけるためにテスト対象そのものを期待結果にしたらみんな合格してしまうから）という話に落ち着いたように思います。
現在の用語集は、
テストオラクル（test oracle）
テスト対象のシステムの実行結果と比較する期待結果のソース。
と前半だけのシンプルなものになっています。「期待結果は何をもとにしてつくったか。期待結果の元（＝ソース、源、発生源や情報源）」のことをテストオラクルと呼びます。
ですからマイヤーズの三角形問題でテストケースの期待結果に「正三角形という出力がでる」と書いてあったら、「仕様と有識者の知見」がテストオラクルでしょう。
銀行のシステムのテストをしたときに「現新テスト」というテストタイプがありました。
これは、現在稼働中の銀行の現行システムと、開発中の新システムを用いて「同じ条件のもとで、それぞれのシステムに同じ入力を与えたときに、同じ結果になること」を突き合わせて確認するテストでした。（大量の自動テストを行いました）
「現行システム」が新システムのテストケースの期待結果をつくっている関係なので、現新テストのテストオラクルは「現行システム」となります。
上のコラムっぽいものを書いていて思い出したのですが、テストの自動化でもテスト結果の準備が大変ですよね。テストオラクルをどうするか悩みました。
■ 期待結果
テストオラクルが何かわかったところで、ALTAシラバスに書いてある期待結果作成時の注意事項を箇条書きで整理します。
① 可能な限り、自動化されたテストオラクルを見つけるか作成する
② 期待結果は、画面上の出力だけではない
（データの変化および環境的な事後条件も考慮する）
③ 仕様書などのテストベースに期待値が載っていない場合は、専門家の知見もしくは、専門情報にアクセスして期待結果を識別する
④ 複雑な応答の複合的な相互作用により、期待結果の定義が困難になるときには、自動化されたテストオラクルが必須となる
⑤ アジャイルソフトウェア開発では、テストオラクルはプロダクトオーナーかもしれない
説明が必要なものは④くらいでしょうか？
④では、原因結果グラフやそこからデシジョンテーブルをつくるCEGTestツールがテストオラクルにあたります。
≡ 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. アジャイル開発ではPOの考えが期待結果となることがある
2. 期待結果生成ツールの開発は推奨しない
3. 仕様書の記載内容を期待結果としてはならない
4. 期待結果は出力のみ。事後条件は期待結果とならない
答えは次回に書きます。
≡ おわりに
今回は、「期待結果」の話題でした。
テストケースの作成ではどのようなテストを行うのか、すなわち、動作前の条件、状態のセット、入力値に注目が集まります。ところが実際のテストでは意外と、「どう動くのが正しいの？？」と迷うことがあります。
ひどい現場では「（期待結果が満足に書かれずに）テスターがおかしいと思ったら報告して」と丸投げされる事があります。「私の判断をテストオラクルとして良いのですね？」と質問してみましょう。
そういった質問をする人なら、テストの知識はありそうなのでテストオラクルの資格は十分かも。（ドメイン知識がゼロだと困るけど、そこは質問をしてきそうですし）
それから、複雑な金融計算のソフトウェアの期待値を生成するテストオラクルをつくることは難しいです。また、法律の改正などの外的な要因によって期待値が変わることがあります。
たとえば、出退勤管理システムの開発で、
めんどくさい難しいのは、法律の改正への対応と、想定外のケースです。
深夜残業を超えて翌日の午後2時まで働いて、昼休み休憩しか取っていなかったときには、「8時間連続時には1時間の休憩を取ること」の法律が守られていないかもしれません。
そんなときに何時間働いて、割増時給は何時間分支払われるのか、、、？
期待結果をつくることがテスト工数の大半を占める場合もあります。
今回、ALTAテキストの追記はありません。1.4.2についてはまとめて書きます。
次回は「1.4.2 テストケースの設計」の続きです。後編として、「テスト設計時の注意事項」について書きたいと思っています。