「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の２４日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回は，マインドマップから始めるソフトウェアテストで書いたことをベースとして検討して実践しているテスト分析設計手法「TAME」について紹介します。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■TAMEとは
TAMEとはTesting Aid using Mindmap Effectively の略で，マインドマップを利用したテスト分析設計手法です。JaSST’09Tokyoで発表した際の資料は次の資料です。
[slideshare id=33986501&doc=jasst09tokyo-140426225047-phpapp02]
JaSST’09Tokyo当時の資料ということで内容は古いのですが，今回はこの資料をベースに簡単に紹介します。
■テスト分析設計を対象とする
マインドマップから始めるソフトウェアテストで挙げたテストプロセスは「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト報告」をベースとしたものですが，このうちもっとも創造性が必要になるのは「テスト設計」です。従って，マインドマップの効果をもっと生かしやすいのはこのテスト設計ということになります。ですからシンプルには「マインドマップをテスト設計作業に生かそう」というのがTAMEの基本的な考え方です。
しかしTAMEでは，テスト分析についても手法が取り扱う対象としています。テスト設計を行う上でテスト分析の出力は重要ですが，実際にテスト設計を実施してもらうとわかると思うのですが，思考のうえで分析と設計を行ったり来たりします。思考が分析になった場合，作業自体も分析作業によっています。そしてまた設計の思考に戻ります。これが振り子のように頻繁に起こります。ですので，テスト分析と設計をフェーズとしてきっちり分けるよりは，そういった性質のものとして作業場はいっしょに実施するのがよいと考えています。
■テスト分析におけるマインドマップの使い方
テスト分析では発想は必要があるの？という疑問を持つ人もいるかと思います。TAMEにおいてテスト分析でのマインドマップは発想法としては利用しません。リーディング法として利用します。マインドマップについて調べていただくとすぐに情報が得られると思いますが，フォトリーディング技法としてマインドマップを利用します。テスト分析での作業はようするにテスト対象を分析するということなのですが，そのためにはテスト対象の情報が書かれているドキュメントを読み込む必要があります。その際，情報を設計情報としてそのまま把握するとともに，テストという軸でも認識・把握・整理・変換などが必要です。単に読んで理解すればよいという単純な話ではなく，そこにフォトリーディング技法が適用できます。フォトリーディングによって開発のためのドキュメントをテストのための理解情報として再構成し，その結果がマインドマップとして表現されます。
■テスト分析に３色ボールペンも利用する
テスト分析にはマインドマップだけでなく３色ボールペン法も利用することが可能です。TAMEではこの3色ボールペン法については利用を推奨しています。TAMEではフォトリーディングによるテスト分析作業の前にドキュメントのチェック（理解）を３色ボールペン法を利用して実施します。これにより事前のチェックを強化しています。またこの時点でドキュメントに不備がある場合，テスト分析の対象にあるレベルではないという判断も可能となります。
ドキュメントをチェックする ・・・３色ボールペン法
↓
マインドマップによるテスト分析を実施する ・・・フォトリーディング技法
↓
アウトプットであるマインドマップをレビュー
■テスト設計におけるマインドマップの使い方
テスト設計におけるマインドマップの使い方はシンプルに発想法です。テスト分析の結果，テスト対象の情報は頭の中に叩き込まれているはずです。その情報をベースとしてテスト観点を発想していきます。
さて，ここでよくある誤解を一つ。マインドマップを使えば発想が得られるという説明を見かけることがありますが，ベースがあってこその発想です。マインドマップを使ったとしても無からは何も生み出せません。なにかのヒントや手掛かりとなる情報があるから，それらから近しい別の発想を得ることができますし，とっぴなことであってもかならずそれに至るまでのヒントとなる情報があったはずです。ですから，テスト分析をどれだけしっかりやれているかによってテスト設計やマインドマップでの発想力は影響を受けます。テスト分析が足りていないことのひとつの兆候は「セントラルイメージが描けない」「（自由発想における）BOIが描けない」です。この時点で思考にブレーキがかかっている場合，テスト分析作業をもういちど見直すことをお勧めします。
■テスト観点と作業観点
TAMEはテスト手法としての美しさよりはテスト作業としての活用しやすさを優先しています。
TAMEはテスト観点ベースのテスト分析設計手法ですから，テスト設計で行うことはテスト観点のモデリングですし，出力もモデリングされたテスト観点の全体像ということになります。それらを導くために，発想についてははマインドマップを利用します。このとき，テスト観点だけではなく作業観点についても発想します。
マインドマップによってテスト観点を発想し構造化しますが（構造化は別ツールでもよい），その下に作業観点を付加します。この作業観点は実際の作業内容を抽象化したものであったり，利用するテスト技法，テストカテゴリといったものです。他のテスト分析設計手法ではテスト観点と作業観点は明確には分けていないか，作業観点は別に扱っていますが，TAMEでは同時に扱います。これは現実として，テスト観点と実際の作業はセットで扱われますし，観点と作業の距離を離したくないという意図もあります。もちろん発想したテスト観点に対してテスト実装（テスト詳細設計）に移る前に実現性を検証しておきたいという意図もあります。どんなによいテスト観点を発想したとしてもそれが現実として対応する作業が困難であると，のちの作業に悪影響を与える場合もありますし，きちんとリスクとして識別しておくためにも必要です。
■マインドマップを使うことで段取り化できる
マインドマップは作業品質を高めてくれるのはもちろんなのですが，TAMEではマインドマップを描くことそのもので作業が段取り化でき，テスト分析設計の作業結果が中間/最終成果物として見える化できることに価値を見出しています。現実としてテストの実施現場では（国内において）テストエンジニアが専任でことにあたるということは少ないですし，テストは新人が行うべきことというイメージもいまだに強いです。そういった状況ではテストの作業として本来押さえておかなければならないあれこれが漏れてしまいます。マインドマップという成果物の作成状況である程度作業の漏れは防げるようになりますし，その人がどれくらいの理解度なのか，どのような考えでテストをしようとしているのかを見える化されたメイン度マップにより確認することが可能となります。マインドマップを使うというのはテスト設計品質の向上だけではなくて，テスト作業品質の向上にも目を向けていることを理解していただくと良いと思います。
■おわりに
TAMEについて簡単に解説しました。参考になればと思います。
さて，現在のTAMEはさらに拡張を行っています。そのうち2016年内には一度まとめたいと考えているので，もしまとめられたらまた本Blogか16年のカレンダーで紹介できればと思います。
