第196回： 「ソフトウェアテストしようぜ」13 CDプレイヤー（テストケース 後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CDプレイヤー」のテストケースの中編を書きました。
内容は、“「CDプレイヤー」のテストケースを書いてみることで、テストケース一覧表の作り方を知る”でした。テスト条件とカバレッジアイテムについて理解が深まったのではないかと勝手に思っています。
今回は、「デシジョンテーブルや組合せ表は、テストケース一覧表に書くのか？」という疑問について書きます。私も昔悩んだので、そのころの自分に向けて。
≡ これもテストケース一覧表に書くの？
テストケース一覧表（Excelやテスト管理ツールやチケットシステム）をつくっていると、「これもテストケース一覧表に書くの？」と思うことがあります。
たとえば、キャッチイメージ（GIHOZのヘルプより）のようなデシジョンテーブルです。『この表をわざわざテストケース一覧表に書き直す意味あるのかな？』と思います。
キャッチイメージは複雑なので簡単な例にします。
GIHOZを使って、以下のデシジョンテーブルをつくったとします。
これは、うるう年を判定するためのデシジョンテーブルです。
GIHOZではこのあとに、[テストケースを生成]ボタンを押すと、テストケースを生成します。こんな感じです。
上記について、前回のテストケース一覧表のフォーマットに記入することもできます。下表は、その結果です。Excelファイルも置いておきます。
テストケース一覧表に記入すると、「カバレッジアイテムを書くことによって、どこまでテストするのか（同値分割をして各同値パーティションから1つずつテストをしたい）が明確になる」、「具体的な入力（西暦年： 2000, 2100, 2020, 2022）とその期待結果（うるう年、平年）をテスト内容に書くことによって、テスト実行時のミスが減る」ことが期待できます。
このように、デシジョンテーブルをテストケース一覧表に書き直すことのメリットはあります。
≡ 本当のほんとうに書くの？
結論から言うと私は書きません。
■ 理由1： めんどくさいから
「プロセス」とは入力を出力に変更する「活動」のことです。
ただし、活動が無駄にならないためには、「入力」よりも「出力」の方が高い価値となっている必要があります。
例えば、ウェブで配送先などを入力するときに、郵便番号を入力すると住所が検索され自動入力された経験がありますよね？
私の場合は、「194-0041」と入力すると「東京都町田市玉川学園」が一気に入ります。いつも便利な機能だなあと思います。
このときの動きをプロセスで考えると、「郵便番号を住所検索プロセスに入力することで、郵便番号よりも価値のある住所を得ることができる」ということです。
さて、デシジョンテーブルをテストケース一覧表に書き直す活動について同様に考えてみます。
既述のとおり、「どこまでテストするのかが明確になる」、「テスト実行時のミスが減る」という価値が増えています。価値が増えていますので、「デシジョンテーブルをテストケース一覧表に書き直すプロセス」には意味があります。（書き直すときにミスが生じることはないとします）
でも、めんどうなので、私はしたくありません。それに、デシジョンテーブルをつくった本人なのでテストの意図は明確ですし、テスト実行ミスもしなそうな単純なテストですから。
■ 理由2： トレーサビリティのコストが増えるから
ここから先は、「めんどくさいからやりたくない」の理論武装（やらない言い訳）だと思うので話半分なのですが、まずは、テスト設計とのトレーサビリティを取りにくいです。デシジョンテーブルとテストケース一覧表のテストケース行との関係について、どこに書けばよいでしょうか。テストケース一覧表に列を追加すると、表が横長になるので私はしたくありません。
また、バグが見つかった時には、デシジョンテーブルに戻って追加するテストケースを考えたくなるのですがトレーサビリティが高くないと「そこまでしなくてもいいか」という気持ちになりそうです。
というように、トレーサビリティを取るための手間が増えるので、気が進みません。
■ 理由3： テスト設計変更が億劫になるから
デシジョンテーブルは仕様書から作ることが多いので、それほど変更が加わりません。ところが状態遷移図や組合せテストの因子・水準はテストの直前に「あっ、このイベントを忘れてた」、「この条件も組み合わせたい」と閃くものです。
そのようなときには、状態遷移図や因子・水準一覧表をチャチャッと修正してツールでテストを生成したいものです。状態遷移図を直して、ツールが生成したテストケースとテストケース一覧表の行を突き合わせるのは時間がかかりますので、イベントを忘れたことに気がついても修正が億劫になり、「まっ、いいか」となおざりになりがちです。
せっかく、イベントの条件に気が付いたのに、テストをしないなんて、もったいない！≡ どうするか
上に書いたとおり、私は、デシジョンテーブルや組合せ表は、テストケース一覧表に書きません。では、どうしているかというと、こうしています。
■ テストタイプでテストのまとまりを分ける
先日（2022/9/23）、佐世保でテストエンジニアの勉強会があったのですが、そのときに、N大のK先生から「素人質問で恐縮ですが、テストレベルとテストタイプとテスト技法って似ているのですが、違いについて分かりやすく教えてください」と質問を受けました。
「素人質問で恐縮ですが……」の上位バージョンに「それは20年前に私が学会で発表したものですが……」があるらしいです。
学の世界こわい。😝
勉強会ですので、「テストレベルとテストタイプは、似たテストケースをまとめたものを指します。
テストレベルの方は要求獲得、仕様書作成、設計、コーディングなどの“そのテストが対応している開発工程の成果物の切り口”でまとめたものをいいます。一方で、テストタイプは性能テスト、信頼性テストなど“確認したい品質特性の切り口によってグルーピングしたもの”をいいます。
一方で、テスト技法は、テスト設計方法を体系的にしたものです」と答えたと思いますが、「テストレベルとテストタイプとテスト技法はだいたい同じもので、“テストのまとまり”のことです」という答えでもよかったかもしれないと思っています。
実際のところ「リグレッションテストは、テストレベルとテストタイプとテスト技法のどれですか？」と訊かれたら「なぜ、それを知りたいの？」って質問に質問で答えるという反則技を使うと思います。
ということで、この節の小見出しは「テストタイプでテストのまとまりを分ける」としていますが、テストレベルでもテスト技法でもいいです。また、「テストレベル×テストタイプ」でテストのまとまり（テストスイート）をつくることも一般的です。「システムテストで実施する互換性テスト」などです。
そこで、デシジョンテーブルはデシジョンテーブルのまま一つのグループ（テストスイート）としてテストケースを管理するようにしています。
■ 教育
テストケース一覧表をつくることによって得られる「どこまでテストするのかが明確になる」、「テスト実行時のミスが減る」という価値についてですが、デシジョンテーブルをつくった本人がテストをする場合はともかく、他の方にテストをしてもらうときには、欲しいメリットです。
そこで上記2つの価値については「教育で補う」必要があります。つまり、デシジョンテーブルの各列に書かれた内容が、うるう年のデシジョンテーブルのように、ハイレベルテストケース（抽象度が高いテストケース）だったとしても、そこからカバレッジアイテムをテスターが自力で見つけ、具体的なローレベルテストケースにすることができるように教育をします。また、期待結果についても、それがデシジョンテーブルに書いていなくても、どこに注目してテストをしたら良いのかを教育します。
「教育」と書きましたが、集合教育ではありません。「テストのエキスパートと組んでテストする（ペアテスト）」によってスキルアップします。
野中郁次郎先生のSECIモデルがいうように「経験をなんらかの形で共有しないかぎり、他人の思考プロセスに入り込むことは難しい」からです。
≡ おわりに
今回は、「デシジョンテーブルや組合せ表は、テストケース一覧表に書くのか？」という疑問について書きました。
読んでいただいた方のなかには、「分けてしまったら、テストの進捗管理についてどうするの？」と思った人がいらっしゃるかもしれません。
そんなときは、何を進捗を管理したいのかについてみんなで話し合ってみるとよいと思います。デシジョンテーブルや状態遷移テストの多くは日を跨いでテストするようなものではありませんし、表の中の列のテストの粒度は同じですが、それとマージしようとしているテストケース一覧表のテストケースの粒度とは違うことの方が多いです。その場合、同じ一件としてよいのでしょうか？
また、バグの観点で考えてみます。デシジョンテーブルテストや状態遷移テストや組み合わせテスト等々は、単機能テストが終わった後に実施する方が効率的です。したがって、単機能テストをテストケース一覧表に書いて、そのほかはテスト技法ごとにテストを分けて管理するのがやりやすいです。単機能テストが終わっていれば、バグも少ないです（全体の7割以上のバグは単機能テストまでに検出されているはずですし、そうなっていなければ、テスト対象のアーキテクチャが悪いか単機能テストでカバレッジアイテムを考慮していないと思いますので、その点を確認しましょう）
要は、テストスイートを１つのファイルにする目的を考えて、まとめることのメリットとデメリットを考えましょう。
今回書かなかったこととして探索的テストのテストケースの文書化をどうするかの課題があります。結論は“バグが見つかったときだけテストケース一覧表には書く”なのですが、理由は次回に書きます。
さらに言えば、表形式になっているテストは自動化しやすいですので、自動化して、毎日実行すると良いです。
さて、「ソフトウェアテストしようぜ」の「CDプレイヤー編」は今回で終わりです。（今回はCDプレイヤーそのもののテストの話はありませんでした）
次回からは、ウェブアプリのテストについて書きたいと思っています。まずは、GIHOZのテストを考えてみようと思っています。
ただ、CDプレイヤー編が長かったので、来週はお休みします。来週は、9月に出版された本と10月出版予定の本について書く予定です。
来週は、宣伝回です。
◀前の記事へ 次の記事へ▶
この記事が気に入ったらサポートをしてみませんか？