第192回： 「ソフトウェアテストしようぜ」9 CDプレイヤー（2. テスト分析の中編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「CDプレイヤー」のテスト分析の前編を書きました。
内容は、「テスト対象を分解してテストアイテムを識別する」まででした。
テストアイテムとは、ISTQBの用語集によると「テストプロセスで使用するテスト対象の一部分。」ですが、簡単に言えば、“これなら自信を持ってテストをつくれるほど、小さくてシンプルだ”と思える粒度まで分解したテスト対象物のことです。
“大きくて複雑だからテストを作るのが難しい”ので、小さくシンプルになるまで分解しましょうというだけの話です。
最近のISTQBの用語集って、短文なんだけど難しく書いてないですか？ 昔の用語集の方が分かりやすかったような気がします。正確さを優先しているのかな。
前回はテストアイテムを時間軸で並べ直して優先度をつけながらグルーピングするといったこともしました。
開発者よりもテスターの方が商品やサービスについて詳しいということがよくあります。
もちろん人によるのですが、開発者は自分が担当したモジュールについては、隅から隅まで何を聞かれても深く答えられるものです。ところが担当したモジュール以外は「知らない」と言われることがあります。
“仕様書を読み込むことが嫌なので知らない”というよりも、“知ってしまうと余計な口出しをしたくなるのが分かっているので遠ざけている”感じがします。
ペアプロやプルリクを日常的にしているチームでは、そのようなことはないのかもしれません。
また、“知っていて質問に答えられる”と思うことができる知識レベルの想定が高いのかもしれません。そのジャンルに詳しくなると「軽々に滅多なことは言えないぞ」と思うようになるものですから。
一方で、テスターは、テストのためにシステム全体を理解する必要があります。また、お客様との接点があることが多いので、開発者ほど深い話はできないかもしれませんが、全体的にお客様や営業職の人よりは商品やサービスの仕様に詳しくなります。
特に、前回の「テスト対象を分解してテストアイテムを見つける」活動を実施すると、テスト対象を隅から隅まで網羅的に把握しますので詳しくなります。
今回の「テスト分析中編」では、「見つけたテストアイテムを評価（テスト）する方法」を考えます。具体的には、
個々のテストアイテムからテスト条件を見つける
テストアイテムのグループ間の関係からテスト条件を見つける
の2つの話を書きます。
……と思ったのですが、1だけで長文になってしまったので、2は次回に回します。
すみません。🙇♂️
≡ 個々のテストアイテムからテスト条件を見つける
まずは、「個々のテストアイテムからテスト条件を見つける」方法です。
「個々のテストアイテムからテスト条件を見つける」とは、前回作成したフィーチャーツリーの末端のノードに焦点を当てたテスト条件を見つけることです。
前回つくったフィーチャーツリーを再掲します。
一番上にある末端ノードは「電源オン・オフ」というテストアイテムです。例として、この「電源オン・オフ」から「テスト条件」を見つけてみます。
「テスト条件」とは、ISTQBの用語集によると、以下の通りです。
テスト条件（test condition）
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
Synonyms: テスト要件（test requirement）, テストシチュエーション（test situation）
簡単に言えば、「テストによって確認できるもの/こと」がテスト条件です。
■ 電源オン・オフによって確認できるもの
電源が切れている状態で電源（OnOff）ボタンを押したときに起こること
1. 電源オフする直前の状態に復帰する？
（ラジオを聴いているときに電源オフした状態で、電源（OnOff）ボタンを押したらラジオが鳴っても違和感はないかも。CDは違和感がありそう。）
2. 購入直後（工場出荷状態）のときには、ラジオ局のプリセットを促す？
3. 電源コンセントの抜き差しで電源オフ状態になっているときに電源オンしても同じ動作になる？電源が入っている状態で電源（OnOff）ボタンを押したときに起こること
4. 電源が切れるか（どの状態でボタンを押すか、アラーム鳴動中はスヌーズ機能となるため別のテストで行う）
5. “起動中”や“シャットダウン中”や“CD読込中”などの状態遷移中に電源（OnOff）ボタンを押しても電源が切れるか
6. 聴いていたCDは自動的にイジェクトされるか
電源（OnOff）ボタンの押し方
7. ボタンを押したときにリモコンから信号が発信するのか、押したボタンを離したときか
8. ボタンを押し続けるとどうなるのか
こんな感じでしょうか。
他にもあると思います。こういったテスト条件を見つける作業のときに「いいのに気づいたぞ！」って自画自賛することがあります。笑
「電源オン・オフからテスト条件を見つける方法」ではなく、「（一般的な）個々のテストアイテムからテスト条件を見つける方法」を知りたいんだと怒ってしまった人がいるかもしれません。
そんな方法は世の中にありません。“NGT/VSTeP”や“ゆもつよメソッド”や“FV表と6W2Hツリー”をつくったら見つかるのでは？と思われた人もいると思います。
確かに上に書いたメソッドを使うと、「MECEを確認することによって見つけたテスト条件のバリエーションに気が付く」ことや「一般的なテスト条件のモデルからテストアイテムに対するテスト条件を見つける」ことはできると思います。また、それは有効なプラクティスだと思います。
でも、「テスト条件はテスト対象のテストアイテムごとに必死になって頭を絞ってひねり出すもの」です。今回の「電源オン・オフ」というテストアイテムでも、「テスト対象は、CDプレイヤーで、操作はリモコンによるものしかなくて、ボタンは１つのボタンに複数の機能を割り当てていて、一般家庭で普通の人が扱う」といった、特有のこみ入った前提でテスト条件を見つけることが大切です。そうしませんと、意味のないテストをたくさんしなければならなくなるからです。
なお、テストの前提まで明らかにしたいときには、6W2H（When, Where, Who, What, Why, Whom, How to, How much）をつくります。6W2Hについては、以前facebookに書いたものを下記にコピペしましたので興味のある方はご覧ください。
ビジュアルな資料としては、JaSST東北の方の資料がとても分かりやすいのでお勧めです。（書籍では、『事例とツールで学ぶHAYST法』に書きましたが、JaSST東北の資料の方が良いです）
① 6W2Hツリーの作成手順
6W2Hのツリーを作成するときの手順について説明します。
手順は、下記(1)～(5)の5つのステップとなります。
(1) コンテキストを小さな直交表で作成する
スマホの天気予報アプリを例に、その利用コンテキストとして、L4直交表から
いつ どこで だれが
－－－－－－－－－－－－－－－
１ 朝 自宅 若者
２ 朝 会社 お年寄り
３ 晩 自宅 お年寄り
４ 晩 会社 若者
－－－－－－－－－－－－－－－
という4つのコンテキストを導きます。
まずは、ツリーを描く前にこの4つのコンテキストを頭の中で想像（空想）することが頭を柔らかくして自由に因子を見つけるコツになります。準備体操のようなものと考え、10分くらい想像しましょう。なお、コンテキストに正解はありませんので自由に空想してくださってかまいません。
ただし、空想する際には、「朝」といった抽象的概念そのものではなく「目覚めた直後」といった具体的なシーンを想定してください。たとえば、本ケースでいえば、
朝 → 目覚めた直後
晩 → 帰り間際
自宅 → 自分の家
会社 → 勤務先
若者 → 自分（あるいは職場で最も若い○○君）
お年寄り → 父親
といった具合です。具体的に想像できるものに置き換えることによって豊かなイメージが得られますので、良い6W2Hツリーに育ちます。
(2) 6W2Hのフレームワークを描く
次に、A3用紙を横長に置き6W2Hのフレームワークをツリー状に描きます。
freemindのようなマインドマップ作成ソフトを使ったほうがやりやすい人はそれでも構いませんが、紙に手書きのほうが良いアイデアが浮かぶという人もいます。みなで同時におこなうなら模造紙やホワイトボードにポストイットを貼ってもよいでしょう。
私は枝の細かいところを非表示にできることと、ノードを狭い範囲にたくさん描ける点からfreemindを使用しています。
(3) 6W2Hの枝を伸ばす
テスト対象が小さい場合は上記のA3用紙に直接書き込んでください。しかし、テスト対象が大きなものについては、A3（297×420mm）という紙の面積が発想を拡げる制約になりかねませんので、6W2Hそれぞれについて1枚ずつ、計8枚描いてください。8枚がMustということではなく、「狭いから（書くところが無いから）思いついたけれど書かない」という失敗を防止できればかまいません。
（逆に、顧客視座からのWhen,Where,Whoの3つの視野は1枚にするなど、工夫してください）
ただし、ひとつの視野を複数の紙に分割することは避けたほうが良いので最大8枚がお勧めです。テスト対象が大きすぎてひとつの視野でさえ1枚に収まらない場合には、先に、テスト対象を分割したほうがよいです。
なお、ツリーを描く順番はWhat、すなわち仕様の分解を一番初めにしてください。
といいますのは、仕様のツリーは仕様書を単語に分解して線でつなげるだけですので一番描きやすいからです。
6W2Hは記憶するためのツリーではありませんので、記憶用のマインドマップのようにカラフルにしたり線の太さを変えたりする必要はありません。
6W2Hツリーはできるだけ高速に（1分間で5つくらいの単語を）描きます。ノードは、文ではなく単語としたほうが発想が拡がります。ノード（＝視点）がダブることよりも視点が漏れることのほうを心配してください。
したがって、MECEを意識せずに思いついたことを一つ残らず書き尽くすほうが良いツリーができます。ただし、MECEを意識しないといっても、一つのノードにあまりにも多くの子ノードをぶら下げると後の整理が大変になります。子ノードは5つ以下にするほうが無難でしょう。
What以外の7つの視野についての順番は特にありません。テストベースがあるものから描くと早く完成します。
(4) 抜け漏れをチェックする
区分原理を使用して抜け漏れをチェックします。
各自が個人チェックしたあとに、それぞれの結果を持ち寄ってレビュー会を行うことをお勧めします。テスト対象の共通理解になりますし、その後のテストケースの理解にもつながるからです。
(5) A3用紙1枚に重要な所だけを抜書きする
A3用紙1枚に6W2Hで見つけたすべての視点を描くことは、通常不可能です。では用紙をつなぎ合わせて巨大なツリー図をつくるのかというと、それもあまり意味がありません。一度は眺めるかもしれませんが、そんな大きなツリーは誰も見直しません。また、仕様や設計変更時のメンテナンスが非常に困難です。細かい視点は頭の中にぼんやりと残っているだけで良いのです。
この(5)では、(3)と(4)で何枚もできたツリーのノード（＝視点）の中からキーとなる重要な視点を抜き出してA3用紙1枚にまとめて全体を俯瞰できるようにします。全体のバランスを見て大きな視点の抜け漏れや検討漏れを発見したいからです。
他部門へ開示する6W2Hツリーは(5)の視点が1枚にまとまったものになります。（元の何枚にも渡るツリーは捨ててしまっても構いませんが、念のためスキャンかデジカメで撮っておくとよいでしょう。これまで読み返して役に立ったことはありませんが、万が一の保険のために）
②作成のコツ
①でも書きましたが、高速に描くのがコツです。頭に思いついたものは吟味せずにとにかく書き出すこと。ここは発散思考でいきます。整理・整頓はあとでゆっくりと行えばよいのです。
③詳細化レベル
「6W2Hツリーの作成方法は分かったのですが、どこまで細かく分解すればよいかが分かりません」という質問を受けることがあります。6W2H
では、
・ どのような条件（因子）をテストすべきか（粗く）識別する
・ 通常、水準は識別しない
です。
因子をざっと抽出するのが6W2Hです。条件漏れを防ぎたいので因子というよりも要因（＝結果に影響を与えるもので因子の候補）というほうが、より正確かもしれません。
話は、「テスト条件はテスト対象のテストアイテムごとに必死になって頭を絞ってひねり出すもの」に戻ります。
こうして、ひねり出したテスト条件は次のテストでも使えそうな気がします。そこで、多くの組織では見つけたテスト条件をテストノウハウとして記録し学習しています。例えば、以下のツリーは、ASTER主催のテストセミナーで2020年あたりから私がテスト条件をまとめるときのスケルトン（骨格）として紹介しているものです。
上のツリーを使ってテストアイテムからテスト条件を見つけるときには、
テスト条件を見つけようとしているテストアイテムがピンク色の10種類のテスト観点のどれに当てはまるか調べる
その下にぶら下がっている末端のノードをコピペする
そのノードに記載の事項から「テスト条件」を見つける
です。
例えば、「CSVァイル書き出し」というテストアイテムのテスト条件を見つけようとしていたら「8. ファイル」に着目し、深掘りしていきます。上の図の赤い線で示しました。「コンテンツ」→「文字コード」→「UTF-8」→「BOM」→「有り」と。（ここだけ深いのは、ここだけノードを展開しているからです。全部を展開してしまうと画面に収まりません）
で、「CSVァイル書き出し」というテストアイテムに対して、「文字コードがUTF-8で、BOMが有り」のテスト条件を見つけます。
上記のツリー自体は、「過去のテストケース」や「過去の不具合情報」を分解して作成します。
このように書くと、技術伝承もできて、とても良い方法のように思えます。ところが、やってみるとすぐにわかるのですが、上の図ですら50個も超えるノードがあります。隠れているものを数えたら、ノード数は千のオーダーになります。しかも、つくった人しかわからないものになりがちです。MECEに分けたと言っても人によって分類箇所は異なります。つくった人ですらしばらくすると「どこに置いたっけ？」「何をテストする気だったんだっけ？」となります。（私はなりました）
先の「UTF-8 BOM有り」にしても、「その文字コードでファイルをつくるのは分かるけど、つくったファイルについてどんなテストをするんだっけ？」となりがちです。
ということで、つくる過程は楽しいですし、つくる過程で自分の記憶の整理が出来るので時間の無駄ではないのですが、つくったものを標準として横展開するにはもう一工夫が必要です。
方向はあっていると思いますが、実用のためには、AIによるアシストシステムがほしいです。
≡ おわりに
今回は、「CDプレイヤー」の「テストアイテムからテスト条件」を見つける作業の片方の、
個々のテストアイテムからテスト条件を見つける
についてでした。巷で優秀と言われるテスターの頭の中にはこのようなツリーが存在し、しかも、その情報を最新になるように、更新し続けているのだと思っています。
次回は「テストアイテムのグループ間の関係（ユーザーストーリーマッピングのようなもの）からテスト条件を見つける」方法について、書く予定です。