第195回： 「ソフトウェアテストしようぜ」12 CDプレイヤー（テストケース 中編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CDプレイヤー」のテストケースの前編を書きました。
内容は、「テストケース一覧表」の説明で、CDプレイヤーの話は出てきませんでした。
【このシートを使うように】というつもりは全くありません。いつも職場で使っているものが一番良いと思います。
もちろん、前回のテストケース一覧表が気に入ったのなら、自由にご使用ください。シンプルなエクセルファイルですので、プロジェクトの特性に合わせて修正していただいて構いません。
社外発表などでは、社内のフォーマットを見せたくないと思いますが、そういうときに使っても良いかもしれません。
と言わずもがなのことを書いているのは、こういうファイルを公開すると「使ってもいいですか？」とか「ちょっと直して使いたいんですけど」というお問い合わせをいただくことがあるからです。
著作権に配慮される丁寧なかたなのだなと思うのですが、お問合せとお返事の手間を省くために。
今回は、これまでテスト分析をしてきた「CDプレイヤー」のテストケース一覧表を書いてみることで、テストケース一覧表のつくり方の基本を腹落ちする回となります。←上手くいけばの話だけれど。
≡ テスト条件
今回は、テストケース一覧表の書き方ということですので、第192回で見つけたテスト条件を使います。以下はテスト対象の「CDプレイヤー」のテスト条件の一部（再掲）です。
■ 電源オン・オフによって確認できるもの
・電源が切れている状態で電源（OnOff）ボタンを押したときに起こること
1. 電源オフする直前の状態に復帰する？
（ラジオを聴いているときに電源オフした状態で、電源（OnOff）ボタンを押したらラジオが鳴っても違和感はないかも。CDは違和感がありそう。）
2. 購入直後（工場出荷状態）のときには、ラジオ局のプリセットを促す？
3. 電源コンセントの抜き差しで電源オフ状態になっているときに電源オンしても同じ動作になる？
・電源が入っている状態で電源（OnOff）ボタンを押したときに起こること
4. 電源が切れるか（どの状態でボタンを押すか、アラーム鳴動中はスヌーズ機能となるため別のテストで行う）
5. “起動中”や“シャットダウン中”や“CD読込中”などの状態遷移中に電源（OnOff）ボタンを押しても電源が切れるか
6. 聴いていたCDは自動的にイジェクトされるか
こうしてみると、どれがテスト条件なのか分からなくなる人がいらっしゃるかもしれません。
どれがというのは、「(A) 電源オン・オフによって確認できるもの」、「(B) 電源が切れている状態で電源（OnOff）ボタンを押したときに起こること」、「(C) 電源オフする直前の状態に復帰する？」の３階層（A, B, C）のうち、どれがテスト条件なの？という疑問です。
第192回では、「テスト条件」の説明に、ISTQBの用語集（下記）を引用しました。
テスト条件（test condition）
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
Synonyms: テスト要件（test requirement）, テストシチュエーション（test situation）
こちらを読んでも、A, B, Cのどれもテスト条件にあてはまりそうでよくわかりません。
このように、テスト分析・設計について、疑問を持ったときには、『JSTQB ALテストアナリストのシラバス』（以下、ALTAシラバスと略す）を読むと解決する場合があります。ALTAシラバスの該当箇所を転記します。
結論から言えば、JSTQBの考え方は、「A, B, Cの全てがテスト条件であり、Aが一番ハイレベルなテスト条件の定義である」ということです。
この結論は、用語集の定義とも矛盾しませんし、このように定義するのが良いのだろうと思います。
でも、「テスト条件は、テスト観点を〇〇レベルまで具体化したもの」というような定義にしてくれる方が使いやすいと思うので、ちょっと不満だったりもします。（笑）
ということで、すべての行がテスト条件と分かりましたが、私がテスト設計に直接利用しているテスト条件はローレベルのＣです。
AとBも間接的には利用しています。（間接的に参照している例は今回のnoteの後の方にでてきます）
「間接的に」というのは、テスト条件Cを求めるために使っているという意味もあるのですが、テスト設計をしているときに、AとBを確認することがあるということです。
「テスト条件Cって、そもそも何を確認したかったんだっけ？」の答えがハイレベルのテスト条件に書いてあることがあるためです。
実は、テストケースのほうも「ハイレベルテストケース」と「ローレベルテストケース」にわけてつくるとALTAシラバスに載っています。でも、私は、そこは頭の中でやっていることにして、テストケース一覧表には、「最も具体化されたテスト条件からローレベルテストケースを作る」ことしかしていません。
検討途中のメモなどあれば、それらは、捨てずにスキャンして同じ場所に保存します。また、CFD法の原因流れ図や、CEGTestの原因結果グラフや、状態遷移図等々は、テストケース一覧表のExcelの別シートに張っておきます。
余談ですが、大きなExcelファイルを作る人はメモリをPCに積めるだけ積んだ方がいいです。少なくとも16GBは積みましょう。
16GB搭載可能なスロットがないPCの場合にはパワー不足と考えて、買い替えるほうが良さそうです。
テスト条件が抽象的なものから具体的なものまで無段階であり、テストケースもハイレベルなものからローレベルなものまで無段階にあるという主張は、その通りと思います。
≡ テストケース一覧表
私が、テストケースをつくるときに、直接利用するテスト条件は、上に再掲した1の「電源オフする直前の状態に復帰する？」です。以下では、こちらに対するテストケースをつくります。
それでは、前回アップした「テストケース一覧表.xlsx」のサンプルシートをコピペして、なかの記述を置き換えていきましょう。
■ テスト条件
まずは、テスト条件を置き換えます。
こんな感じです。（赤文字が置き換えた箇所です）
置き換えていない黒い個所はサンプルのままですので、そこは無視します。また、疑問形に引っ掛かりを覚える人は「電源オフする直前の状態に復帰すること」と平叙文に変えてもOKです。
■ カバレッジアイテム
次に隣のセルの「カバレッジアイテム（どこまで）」のところを置き換えます。
テスト条件は、「電源オフする直前の状態に復帰する？」です。
このテスト条件で確定していないことをみつけて、そのバリエーションを「どこまで」やるかを決めるのがカバレッジアイテムです。「電源オフする直前の状態に復帰する？」というテスト条件のなかで、≪決まっていないこと≫は「電源オフする直前の状態」です。
「電源オフする直前の状態」には、「CD再生中」、「早送り中」、「ラジオ視聴中」、「ミュート中」、「CD排出中」、、、等々、細かく見たら無限と言ってよいほどあります。
ISTQBの用語集で確認してみます。
カバレッジアイテム（coverage item）
テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する。
ちょっと頭痛がしてきたので、先に進みます。
ところで、第192回でテスト条件を出したときにこんなメモを残しています。
ラジオを聴いているときに電源オフした状態で、電源（OnOff）ボタンを押したらラジオが鳴っても違和感はないかも。CDは違和感がありそう。
このことから考えるとそのときの私は「音の入力ソース」を意識していたようです。
ということで、カバレッジアイテムに「音の入力ソース（CD、ラジオ、MP3、AUX）」と記入します。
もしも、気になるなら、例えば、「ミュート状態」を追加しても良いです。
テスト分析とテスト設計を行きつ戻りつしながら良いテストケースをつくることが大切です。テスト分析のあとの工程でテスト分析の問題に気が付くことは普通にあることですので、柔軟に考えて、テスト分析結果を直してしまいましょう。
■ テスト内容
次は「テスト内容」（テスト手順）です。こんな感じでしょうか。テスト条件からつくっているテスト手順ですから抽象度が高く、ふわっとしたものになります。
「【前提】入力ソースを設定（音あり）」と音を出しているのは、このカバレッジアイテムには関係ありません。したがって、電源オフする直前の状態は音が鳴っていても鳴っていなくても、どちらでも良いです。（“どちらでもよいならテストしやすい方を選ぶか”という程度です）
「【入力】電源をオフ→オン（電源（OnOff）ボタンを2回押す）」の方は、テスト条件として選んだ「電源オフする直前の状態に復帰する？」より上位のハイレベルテスト条件である「電源が切れている状態で電源（OnOff）ボタンを押したときに起こること」をチラ見して、『そうそう、そういうことを確認したかったんだ』と、テストの目的を思い出して書いています。
■ 検証事項
最後は検証事項です。期待結果を書きます。
以上で、テスト条件の行が埋まりました。この行はテスト条件の行で、テストケースではありません。テスト条件の行は実行しません。テストケースは、テスト条件の下の階層の1-1や1-2です。
■ テストケース
だいぶ慣れたと思いますので、テストケースは一気につくってしまいましょう。こんな結果です。
テスト条件は同じものなので書きません。集計表ではこの違いを使って集計しています。
初心者にテスト実行をしてもらうときには、期待結果を丁寧に書いた方が良いです。テストするときに何に注意するかを知っていればバグの見落としが減るからです。
逆に期待結果のところに「問題なきこと」とか「出力が正しいこと」とか「画面に乱れがないこと」とか「適当な速度であること」とか「違和感が無いこと」と曖昧に書いていたら要注意です。期待結果は出来るだけ具体的に書きましょう。
サンプルシートにあった不要な行とテスト結果を消すと、集計表の方は、埋め込まれた計算式により、テスト条件が1つで、テストケース（テスト項目）が4つとカウントされています。
作成したファイルを置いておきます。
≡ おわりに
今回は、「CDプレイヤー」のテストケースを書いてみることで、テストケース一覧表の作り方を知る回でした。テスト条件やカバレッジアイテムを同じ場所に書くことで、テストの目的や意図がより伝わるようになります。
テスト条件を書くことで何をテストしているのかが明らかになり、カバレッジアイテムを書くことでどこまで深く網羅的にテストするかが明記されるからです。
また、誰が実行しても同じ結果が得られるように、曖昧さが無く、 テスト結果の合否をYes/Noで答えられるテストケースをつくることが大切です。入力についても、「任意の値」、「異常な値」、「すばやく」といったテスターによって入力するものが異なる書き方はよくありません。
テストケースは具体的に書くようにします。
次回は、割と悩んでいる人が多い、「デシジョンテーブルや組合せ表は、テストケース一覧表に書くのか？」という疑問について書こうと思っています。私も昔悩んだので、そのときの気持ちを思い出しながら。