『テスト設計の実例と解説』 小田部 健 著

はじめに

2016年9月15日。SQiPシンポジウムの基調講演の直前に東洋大の井上円了ホールのロビーで待ち合わせ、カードゲームのバグッパと一緒に著者ご本人から購入させていただいた薄い本（同人誌）です。サインしてもらうのを忘れたのが残念です。

さて、そのときに小田部さんから「感想をブログか何かに書いてもらえたらうれしいです。でも、この本の内容をブラッシュアップして、テスト設計コンテスト（以降テスコンと略す）の予選会に出す予定なので、予選会の11月5日までは（ブログ等の感想文を書くのを）まってください」と言われました。

その気持ちはわかりますので、11月に書こうと思っていたのですが、予選を通過してしまったので、「それでは決勝戦（2月23日）以降に書こう」と思っていたら今日（2017年3月17日）になってしまいました。

感想

1. 本書の構成

本書は
　第一章　テスト設計の基礎知識
　第二章　テスト設計の実例と解説
　第三章　テスト設計の進め方
の3章構成になっています。
そして、それぞれの章末に、えびたこ氏のカラオケ小説が分割して掲載されています。

第一章では、第二章以降を理解するために必要となる小田部さんが考える「テスト設計」のプロセスと意義、そしてテスコンの審査ポイントに対する小田部さんの理解について書いています。

第二章は、本書の中心である小田部流のテスト設計方法をテスコンの提出物を使って解説しています。

第三章は、第二章の補足といいますが、TIPS集といった感じです。

2. 小田部流テスト設計

本書の中心である「小田部流テスト設計」の特徴的なところについて感想を述べます。

2.1 魅力の調査

テストベースの分析において「テスト対象（＝今回ならカラオケ）の利用者にとって『何が魅力』なのかを調査した」そうです。
とても良いと思います。
利用者だけでなく利害関係者（ステークホルダ）にとっての魅力分析も行うとさらに良いです（「欲しい」分析はしてはいるのですが、ステークホルダに対しては調査では無く推測です）。調査できないときに推測すること自体は悪くないのですが、その後のフェーズで事実なのか推測なのかについて曖昧になりがちですので注意が必要です。

ところで、テスト設計・実装にこの「魅力の調査結果」が活かされていない点が残念です。
本書を読む限り、テスト設計・実装では「仕様の検証」が中心で「調査した魅力が作りこまれたか」の確認の視点が少ないように感じました。テスコンの審査をしていたときに良く思ったのですが、それぞれのプロセスをみるといい感じであっても、全体を貫く幹が無いと残念感のほうが大きくなり評価が上がりません。

2.2 ステークホルダアクションの全体図

ステークホルダの行動を分析して全体像を作っているところはとてもよいです。
でも、いわゆる「業務フロー図」の作り方のセオリーを無視しているので粒度がそろっていなかったり抜け漏れが散見されます。
要求獲得技術の基本は抑えておいたほうが良いと思います。（もしくは専門家と協業するか）

2.3 Fujiブロック図

本書では、テストケースをテスト開発用に書き直す（最適化する）ことを推奨しています。
そのうちの一つが筆者が考案したFujiブロック図です。

Fujiブロック図は複数の機能の呼び出し関係と入出力がモデル化されたものです。
図にロジック（分岐条件等）は描かれませんのでFujiブロック図からテストケースを自動生成することは困難と思われます。たとえば「機能図式」のような既存のモデルと比較すると良いと思いました。

でも、Fujiブロック図自体は、手軽に描けてフリーに情報を書き込める点が実用的だなあと思いました。
ひょっとしたら「ブロック」という（比較的粗い）粒度で描くことで、抽象的なシステムが苦手な利用者やステークホルダーと一緒に描きながら、テストベースの合意を取るという使い方なのかもしれません。
なお「ハード」というブロックは「コントローラ」や「アイテム」のほうが良いのでは？と思いました。

2.4 マインドマップをロジックツリーにリライト

本書では、マインドマップでは観点漏れが発生するため、Excelを使用して表形式でロジックツリーに書き直すことを推奨しています。
そうすることで、手書きの良さと（表にすることでの）抜け漏れチェックのしやすさの両立をはかることができます。
しかし、二度手間（そんなに手間ではないですが）であり、現場に受け入れられるかな？と思いました。

そろそろ手書きマインドマップをスマホで読み込んで、その先の作業が続けられるようになるマインドマップツール（もちろん、逆方向もシームレスに変換するツール）が生まれてもよさそうです。

2.5 各種テスト技法

本書では、デシジョンテーブル、CFD、PictMaster、状態遷移図、そしてユーザー視点の非機能チェックリストとシナリオ等々の適用例が載っています。
ただ技法に当てはめる前の要素について「抽出した」という一言で終わっているため、読んでいてモヤモヤしました。

3. 全体を通して

全体を通して、自分のアイデアを隠すところ無く丁寧に書いてある点がすばらしいと思いました。「ここは俺様のノウハウだから書かない」といったところが無くてよいです。
ただ、記述の前後はあまり練られていないようにも思いました。どうしたら読者に伝わるかをもう少し考えるとさらに良くなると思います。

こういうテスト本ってこれまでありませんでしたのでユニークで貴重ですよね。