第194回： 「ソフトウェアテストしようぜ」11 CDプレイヤー（テストケース 前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CDプレイヤー」のテスト分析の後編を書きました。
内容は、「テストアイテムをグルーピングしてつくったユーザーストーリーマッピングのような表からテスト条件を見つける方法」でした。具体的には、「ハッピーパステストの探索的テスト」「存在しない仕様のテスト」「組合せテスト」をつくるという話でした。
今回は、「見つけたテスト条件からテストケースをつくる方法」について書きます。「CDプレイヤー」のテストケース一覧表の実例は次回となります。今回は前編でテストケース一覧表の説明です。
≡ テスティングとテスト
「ソースコードを書くことをプログラミングと言い、できたソースコードをプログラムというよね。それと同じでテストケースをつくり実行することをテスティングと言い、できたテストケースのことをテストというんだ」と教えてくださったのは、ゆもつよメソッドでお馴染みの湯本剛さんです。
「テスト、何件する？」と聞かれたら、テストケースの数を答えます。このように、テストを語るうえで、最も基本的な要素の一つであるテストケースですが、改めて「テストケースって何？」と聞かれると答えられないものです。ISTQBの用語集を引いてみます。
テストケース（test case）
実行事前条件、入力値、アクション（適用可能な場合）、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの。
ぼんやりとは分かるのですが、「実行事前条件と入力値とアクションの切れ目はどこ？」とか「適用可能な場合ってなんのこと？」とか「期待結果と実行事後条件の違いは何？」とか「テスト条件に基づいて開発されたものとあるけど、開発なんてしてたっけ？」と。
モヤっとしませんか？
けど、いいんです。厳密な用語の定義や要素間をつなぐモデルなどは、モデリングが得意な人にお任せして、まずは、テストケースとして何を書けばよいか自分なりの答えが見つかれば。
以下は、標準規格を参考にしつつ私が使っているテストケース一覧表のフォーマットで説明していますが、みなさんが使っているテストケース一覧表とは微妙に違うと思います。自分が使いやすいもので良いと思います。
■ テストケース仕様
以下の表は、『ASTERセミナー標準テキスト[Ver3.1.1]』の218ページにあるものです。
出典にあるように、国際標準（ISO/IEC/IEEE 29119-3:2013 ）から抜粋したものですので、世界のテストのエキスパートの知恵と経験が詰まった良い項目が並んでいます。
「一意なテストケース番号」、「タイトル」、「トレーサビリティ」、「前提条件」、「入力」、「期待結果」、「実行結果」、「判定」の8項目です。
≡ テストケース
■ テストケース一覧表
通常は、テストケースの一覧表をつくると思います。テストケース一覧表をつくらずに、Redmineなどのチケット管理ツールを使うことも増えているとは思うのですが、私はExcelでつくる方が見やすいので好きです。こんな感じです。（Excelファイルも置いておきます）
この表は、右上の集計表と下のテストケース一覧表に分かれています。
そして、テストケース一覧表は、さらに左側（2/3）のテストケース（青色）と、右側（1/3）のテスト結果（茶色）に分かれています。
そして、これが大切なのですが、1920 × 1080のディスプレイ解像度で全ての列が収まります。（Excelの横スクロールは極力避けたい）
A3横にプリントしたときに文字が読める大きさであることも大事です。
■ Excelかよ
ひげじい「ちょっと待った～！」
やっぱでてきてしまいましたか。
ひげじい「そりゃそうですよ。」「令和の時代になっても、Excelでテストケースの管理ですか。ふる過ぎるんじゃないですか？」
それが、そうとも言えないんです。ちょっと聞いてください。
と、「ダーウィンが来た！」を観ていない人には何だかわからない小ネタをはさみつつ話を続けます。
「テストは、テストを管理するツールで管理しなさいよ。たとえば、QualityForwardを使ったらいいんじゃないんですか？」と、ひげじいが言いそうです。
確かに、テスト管理ツールを使うことでテストケースの管理や進捗報告の効率化が図れたり、うまく使えばテストケースの再利用が促進されます。テスト業務のDX化です。
私も、過去、市販のめちゃ高いテスト管理ツールを導入したり、テスト管理ツールをつくったりしてきました。でも、Excelを使うメリットも大きくて一部の大規模テストとアジャイルのテスト以外では、Excelに戻ってしまっています。
■ 大規模ソフトウェアの場合
大規模なソフトウェアの場合は、リリース後もバージョンアップを続けていきますので、過去のテスト資産（テスト条件やテストケース等）を再利用することが起こります。そんなときに、Excelでつくったものだと、何がどこにあるのか分からなります。
また、大規模ソフトウェアの場合、バージョンアップのたびに、全テストケースの一部しかテストできないので、どこをピックアップしたのかを管理することができるテストケース管理ツールが役立ちました。
■ アジャイル開発の場合
アジャイル開発の場合は、テストケースを独立して管理するのではなく、開発の要素（例えば、個々のバックログ）にテストが含まれているように管理しないとうまくいきませんでした。
■ Excelを使うメリット
つくったテストケースを開発者に見ていただくときに読みやすい表になっていることが大切です。テスト管理ツールからExcelへテストケースをエクスポート出来ますが、そこに注目してほしいことを書き込むのは手間ですし、そういった注目してほしいことはテストを実施する人にも伝えたいものです。Excelだとその辺（文字の色付けやシートを追加してそこに仕様書を切り取って貼るなどの加工）を自由に出来ます。
ということで、テスト管理ツールは、使うメリットが大きい場面では使うとして、今回は、「そもそも、テストケースに何を書いてどんな集計をしたらいいんだっけ？」という基本的な話を、上に置いた「テストケース一覧表」を使って続けたいと思います。どのテストでも必要となる情報の話です。
■ 集計表
上記のExcelの右上にある集計表は、テストケース一覧表を埋めていくと、セルに書き込まれた内容から集計されるものです。青い行は作成したテストケース、薄茶色の行はテスト結果、灰色の行は参考情報です。
何を数えているかが気になる人は、セルの中の数式を見てください。
順に見ていきます。まずは、青い行のテストケースの集計です。
「テスト条件数」は見つけたテスト条件の数です。「テスト項目合計」はテストケース数です。そして「有効テスト項目数」はテストケース数からボツにしたN/Aのテストケース数を引いた数です。
「ボツにしたN/Aのテストケース」がピンとこない人もいらっしゃるかと思います。
意味的には「テストケースをつくったのだけれど実行する意味がなくなったのでボツにしたもの」です。たとえば、「機能がドロップして、なくなった」場合、そのテストケースを実行する意味はありません。
テストケース自体を削除しても良いですが、次のスプリントで「機能が復活する」ことがありますので、判定をN/Aにして消さない方が良いのではと思います。
次は、薄茶色の行のテスト結果の集計です。「未実施テスト数」、「OK」、「NG」、「N/T」です。
「OK」と「NG」と「N/T」は、国際標準にならって「Pass」と「Fail」と「Block」に変えても良いですし、どちらでも集計できるようにしておいても良いと思います。
「未実施テスト数」は、「残テスト数」の意味です。
たとえば、1時間に10項目実行できるとしたときに、「未実施テスト数」が100件あれば、あと10時間ですから2日あれば終わるかなというように、概算見積もりに使います。
そうそう、管理をするときには過去のことを悔やむよりも「これからどうなる、どうする」を考えるほうがいいです。
灰色の行は参考情報です。N/Aは先に書いたとおり、「ボツにしたテストケース」です。「修正済みNG」は、「いったんはバグがでたけど、直ったことを確認できたテストケース数です」
集計表に昔は載せていたけど、集計をやめたものもあります。「テスト時間」です。実施日の情報から何日間テストをしたかを集計していました。でも、テストのし直し（リグレッションテスト）を同一行にしていることから、一つのセルに複数個の実施日を記入することがあるのと、日付のフォーマットには多くのパターンあって集計のExcel計算式を書くのが面倒になってしまったので止めました。
他にも、テストケースの表に「正常系と異常系」の列を追加し、その割合を集計したことがありますが、例えば「エラーメッセージがでることを確認するテスト」について、（仕様にあるのだから）正常系とする人と、（エラー確認なんだから）異常系と考える人がいてこちらも入力が面倒なだけで使い道がないのでやめました。
メトリクスを測定するときには「測定結果を何に使うの？ それは役立つの？？」って考えた方がいいです。自動でとれるやつは無害なのでマシだけど、「正常系と異常系」のようなものは、人が考える時間がかかるから慎重にしましょう。
■ テストケース一覧表
テストケース一覧表は、テストケースと、テスト結果を入力する表です。
それぞれの項目（列）を確認していきます。
テストケースには大きく「識別子」、「テストの目的と網羅性」、「テスト内容」、「検証事項」、「テストデータ」があります。
「識別子」には、テスト分析で見つけた「テスト条件」の識別子と同じものをつけます。トレーサビリティ（追跡）をしやすくするためです。テスト条件からつくったテストケースの識別子は「テスト条件の識別子-枝番」とします。ですから「1-1」、「d-27」、「電源オン・オフｰ１ｰ１」などとなります。大切なことは「トレーサビリティ」と「重ならないこと（ユニークで同じ識別子がないこと）」です。
「テストの目的と網羅性」は、「テスト条件（何を）」と「カバレッジアイテム（どこまで）」の2つの情報からなります。
「テスト条件」は前々回やった、「テストによって確認できるもの/こと」です。「テストは、個々のステークホルダーが知りたい情報を確認する活動」ですから、「テスト条件（の結果確認）」がそのテストケースを行う目的にあたります。
「カバレッジアイテム」は聞き慣れない言葉ですが、「カバレッジ＝網羅」、「アイテム＝項目」ですので、「何を網羅するのか」を書きます。網羅基準は本当は、「カバレッジアイテムをどこまで深く網羅するのかの基準」ですので、カバレッジアイテムとは違うのですが、列を増やしたくないので、この列に書いています。
「テスト内容」には、「具体的に何をするのか」、【前提】と【入力】を書きます。私はテスト手順のように細かくは書きません。そこは、テスト対象を理解するための集合教育をしています。
「テストケース」と「テストステップ」と「テストプロシジャー」の関係について私はよくわかっていないのですが、今は、テストケースを実行するときの操作手順のようなものを「テストステップ」と呼んで、複数の「テストケース」をテストの実行効率を上げるためにまとめたものを「テストプロシジャー」と呼んでいます。
正式な？用語との対応は違うかもしれないけれど概念的にはそういう区別はできますよね。
テスト内容に書く中身の説明に戻ります。【入力】はユーザーがソフトウェアに対して「これをしろ」と伝える命令です。【前提】はユーザーが入力することができる直前の状態のことです。【前提】を満たすために【入力】をすることもあるのですが、あくまでも、テスト条件に対してどうかで切り分けています。
例えば、ジュースの自販機で「150円のジュースを購入する」というテスト条件があったとします。
【入力】はユーザーがソフトウェアに対して「これをしろ」と伝える命令ですから、「150円のジュースの購入ボタンを押す」ことが【入力】になります。このときの前提として「適温の商品があり、前の商品が排出済みで、150円以上のお金が投入済みである」等々があります。
≡ おわりに
今回は、「テストケース一覧表」の説明でした。
次回は、前回見つけたテスト条件（テストによって確認できるもの/こと）をもとにテストケースを作ってこの表に埋めるところを書こうと思っています。
