第193回： 「ソフトウェアテストしようぜ」10 CDプレイヤー（3. テスト分析の後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CDプレイヤー」のテスト分析の中編を書きました。
内容は、「個々のテストアイテムからテスト条件を見つける」でした。「テスト条件はテスト対象のテストアイテムごとに必死になって知恵を絞ってひねり出すもの」であり「（一般的な）個々のテストアイテムからテスト条件を見つける方法はありません」という残念なお知らせでした。
テストアイテムという用語の使い方に違和感があるとのメンションをいただきました。辰巳さん、ありがとうございます。_(._.)_
私にはまだ、辰巳さんが感じた違和感の正体が理解できていないので、ブログの直しようがないのですが、この辺、似た用語が多くて辟易しますよね。にしさんみたいに、これも、それも、あれも「テスト観点」というのも一つの手ですね。
ついでに、テスト観点についての私の意見も貼っておきます。
テストアイテムは「テストの対象となるソフトウェアアイテム」、ソフトウェアアイテムは「ソースコード，オブジェクトコード，制御コード，制御データ又はこれらのアイテムの集まり」(IEEE 829, 29119など)。ISTQBも同様。
— Keizo Tatsumi (@KeizoTatsumi) September 5, 2022
なので「テスト対象を分解してテストアイテムを見つける」は違和感あります。
テストをモデリングしたいときだけ、「モデリング前の要素」に対して、「テスト観点」という言葉を使うと良いと思います。
— あきやま🌰 (@akiyama924) July 29, 2022
もしも、テスト条件を機械的に見つける方法があるのなら、「自動テスト分析ツール」が生まれていて、テスター（テストアナリスト）という職業は無くなっていると思います。「自動テスト分析ツール」がないということは、逆に言うと「テスト分析は非常に創造的な仕事」ということです。
単純に仕様書を書き写すだけでは良いテストにはなりません。良いテストは創造するものです。
さて今回の「テスト分析後編」では、「見つけたテストアイテムを評価する方法」のもう片方です。具体的には、
個々のテストアイテムからテスト条件を見つける
テストアイテムのグループ間の関係からテスト条件を見つける
のうち2番目の話を書きます。
≡ テストアイテムのグループ間の関係からテスト条件を見つける
「テストアイテムのグループ間の関係から」とは、前々回に作成したユーザーストーリーマッピングのようなものからテスト条件を見つけることです。
前々回につくったユーザーストーリーマッピングのようなものを再掲します。
■ ハッピーパステストの探索的テスト
まずは、この表の１行目の「急ぎ必須」の行に着目します。こちらの行には、もっとも優先度が高いテストアイテムが並んでいます。
（そういうように集めたのですから）
こちらの行を左から順番に実行していきます。
シナリオテストを書いても良いですが、こんな基本的なところの、しかも正常ケースのテストで不具合が発生することは普通はありませんので、私なら表を見ながらリラックスして探索的テストを実施します。
探索的テストですので、例えば、一番左上の「ラジオ局プリセット」というテストアイテムのテストを探索している最中に、プリセットの仕様（以下に再掲）を思い出して、『ボタンを2つ同時に押し続けたらどうなるんだろう？』と気になったら、すぐに試します。
探索的テストの良いところは“気になったことは、論理的に深く考えずに試してしまうこと”だと思っています。
プリセット
・ 押す：プリセットしたラジオ局を呼び出す
・ 押し続ける：ラジオ局のプリセット設定をする
正常系の基本的なユースケースのフローを確認するテストのことを「ハッピーパステスト」と呼びます。要は「最も一般的な使い方はテストしておこう」という話です。
ハッピーパステストは、スプリントのリリースのタイミングで、何度もテストすることになりますので、自動化をしておくことが有効です。
でも、私は、【そのスプリントで追加されたバックログが悪さをするとしたら】と想像して探索的テスト（エラー推測？）をするのが好きです。滅多にバグはみつからないのですが、まぁ、２時間くらいのテストですし、楽しいからいいかという感じです。
■ 存在しない仕様のテスト
時系列でテストアイテムを再構成した表を眺めて、「仕様にはないけど、できるかもしれない」ことを考えます。
こんなことをしているのは、自分だけかも。例えば、今回の表なら、『アラーム機能が充実しているから、アラームで設定した時刻になるとラジオが鳴りだすかもしれない』と考えます。（“考える”というよりも“妄想する”のほうが適当な言葉づかいかもしれません）
次に、「どういう手順だとそうなるかな」と考えてテストします。
こう書くと、想定しているゴールが「エラー」か「隠し機能」の違いだけで、【エラー推測】の手順と同じですね。
そもそも、「ラジオによるアラーム機能」なんてついていないのですから、テストをしても、通常のアラーム音がするだけです。でも、たまに隠し機能を見つけてしまうことがあります。
「そんなことをしていないで働け」って言われそうだけど、間隙を突くような操作をするので、副産物としてバグがみつかることがあるので続けています。楽しいですし。
■ 組合せテスト
3番目は、組合せテストに使います。組み合わせるときのロジックには、ANDとORがあるのですが、表を横方向につなぐのがANDで因子です。そして、縦方向に複数あるもの（チョイスするもの）がORで水準です。
機械的に全ての因子をペアワイズで組み合わせて、ガッとテストすることも有効ですが、現実に良く発生する組合せは、テストアイテムを時系列で再構成した表から作成するとうまくいきます。
例えば、決済方法に、「現金」、「振込」、「カード」、「コンビニ」の4種類があったら、他の列の因子（例えば、商品種別という因子。これには、「書籍」、「日用品」、「貴金属」、「食料品」といった水準がある）と組み合わせたテストを直交表やペアワイス技法を使用して、組合せ表を作成して実施します。
≡ おわりに
今回は、「CDプレイヤー」の「テストアイテムからテスト条件」を見つける作業のうち、「テストアイテムのグループ間の関係（ユーザーストーリーマッピングのようなもの）からテスト条件を見つける」方法について、書きました。
「ハッピーパステストの探索的テスト」「存在しない仕様のテスト」「組合せテスト」と、どれも、バグ出しというよりは、品質保証のためのテストでした。
さて、次回は、こうして見つけたテスト条件（テストによって確認できるもの/こと）からテストケースをつくる話を書こうと思っています。
テストケース管理ツールの話はせずに、どのような項目をテストケース一覧表で管理しているかの話です。大規模のテストになると専用のテストケース管理ツールが有効ですが、少量ならチケット管理システム（Redmine等）が良いと思います。でも、次回はExcelです。Excel好きなのとメリットも大きいから。一番好きだったテストケース管理ツールは内製のものなのですが、どんなステキ機能があったかも書こうかなあ。