Veriserveさんからリリースされた、テスト設計モデリングツール「GIHOZ」のおためしを、2回の記事で紹介しました。
www.kzsuzuki.com www.kzsuzuki.com
今回は、GIHOZへの期待と、テストプロセスのツールってこうなるのかなーという想像について書きます。
GIHOZ、こうなったらいいな！
所詮は無課金ユーザの勝手な要求ではありますが、軽く触ってみての感想です。
状態遷移テストにおけるイベント・トリガー以外の要素だとか、ペアワイズにおけるエイリアス・重みづけなど、個々の機能の「あったらいいな」もあるのですが、もう少し全体について、三つほど。
1. 「意図」を残したい
ソースコードに、コードそのものだけでなく、人類向けのコメントを含めるように、テスト設計モデルにも設計意図を明示するためのコメントを残しておきたいです。
たとえば同値分割で、同値パーティションで特定の値を「ひいきして」選んだ意図は何なのか。デフォルト値なのか、平均値なのか、ランダムなのか。
あるいはペアワイズにおける制約について、対応する仕様は何を意味しているのか。
テストとしての意図だったり、仕様についてのメモだったりを残せたらいいなと思います。
2. 「あともどり」をもう少し許容してほしい
これは単にわたしがウカツなだけかもしれませんが、同値分割の境界設定や、ペアワイズにおける制約式/制約表の選択が、一度やってしまうと戻れないのが、せっかくのサクサク感をやや損ねていると感じます。修正させてほしい！
3. ヘルプが充実するとさらに嬉しい
もちろん、GIHOZを動かすうえでの必要な情報は、今のヘルプでも整っています。
そのうえでゼイタクをいえば・・・、
今の内容はあくまでもGUIの操作方法。テスト設計技法はある程度理解している前提で、具体例＋考え方＋モデリング方法くらいまであると、とても有益だと思います。
ツールってこういう風につながっていくの？
ツールチェーンとかいうとカッコいいのですが、また、適当なパワポお絵かきです。
GIHOZのようなツールって、こんな風に位置づけるとかっこいいでしょうか？
黄色枠: テスト設計モジュール
GIHOZは、テストアーキテクチャ（というものがあるとして）に記述された観点に基づいて、テスト設計を行うのがこのモジュールです。GIHOZはここにあたりますね。モデルを描いて、そこからテストケースを導出するところまでを担当しています。
なおVeriserveさんの場合、「TESTRUCTURE」というツールも提供しています（すみません、使ったことありません）。
- STEP1: テストベースの理解・分析
- STEP2: 階層的整理
- STEP3: 詳細化対象の決定
- STEP4: テストケースの作成
以上のような機能をサポートしているということで、上の絵でいうと緑の部分までカバーしているのかも。またGIHOZは、TESTRUCTREの補助ツールという位置づけなのかもしれませんね。
オレンジ枠: テスト管理モジュール
テストケースそのものや、その実行を管理するモジュールです。
有名どころだと、Test Rail、PractiTest、Test Pad、TestLinkなどがあります。
Veriserveさんでいうと、Quality Forwardが対応するでしょうか（これも使ったことがなくてすみません・・）
テスト設計モジュールから、テストケース*1を受け取り、テスト手順と組み合わせることで、手動で（も）行えるテストケースになります。
ここで、テスト手順はデータ駆動テストの考え方に基づき、パラメタライズされている*2ことが期待です。上位からパラメタを受け取ることで、一つ以上の具体的なテストケースとして実体化されます。
このようにできたテストケースの実行状況・実行結果までを管理することになります。
なお、テストケースは、GIHOZでサポートしているようなテスト設計技法から導出されるものばかりではないことには留意が必要です。
青枠: テスト自動化モジュール
テスト手順が標準化された記述になっていれば、キーワード駆動テストにつなげることができるでしょう。
自然言語に近い形で記述されたテスト手順の各ステップをスクリプトに対応付けておくことで、テスト手順＋スクリプト→実行可能な自動テストケースとなります。
これによって、モデルの作成/変更→テストケースの実装→自動テストの生成→自動テストの実行 とつながるようになって幸せそうですよね。
自動テストの生成と、その自動テストを何らかのトリガー*3で自動実行するところまでが、テスト自動化モジュールのお仕事ですかね。
実行結果の管理もここで行うかもしれないし、テスト管理モジュールに統合するかもしれない。
ピンク枠: イシュー管理モジュール
テスト実行の結果から、テストアーキテクチャを洗練させていくことになります。
たとえば、テストケースの目的とは違うところで欠陥が発見されたなら、それを新たなテスト観点として還元し、反映するでしょう。あるいはプロダクト要因でなくテストの誤りでテストがコケた場合は、その誤りをモデルから修正する必要があります。
まあ、こんな感じでぐるぐる回るとかっこいいよね！というお話です。
絵のキレイさを優先しているので、細かいことは気にしないでいただきたい！
連携のための標準化
さらに妄想です。
ツール間の情報のやりとりのために、二つの標準化を行う必要があります。ここでは、TDMP と、MTCP と呼んでおきます。言いたいだけです。
TDMP（Test Design Modeling Protocol）
TDMPは、テスト設計モデルの記法に基づいて作成されたモデルの情報を、ツール間・プロセス間で受け渡しするための標準形式です。
入口は二つ考えられます。
一つ目は、仕様・設計からのインプットです。上の絵でいうと、「Spec Model」がテスト設計モジュールに入ってくるところですね。
設計段階で作られたモデルをテストの入力情報として受け取り、テスト側でそれをテスト設計モデルとして拡張して、テストの生成につなげていく。あるいはその過程で得られた知見を設計側にフィードバックします。
二つ目は、他のモデリングツールからの/へのインプットです。
テスト設計モデリングをするためのツールはGIHOZに限らず登場すると思いますが、あるツールで作成したモデルがそのツールでしか使えないというのは辛過ぎます。データ形式を標準化し、ツール・サービスの乗り換えが容易にできると幸せそうです。
MTCP（Model-based Test Case Protocol）
MTCPは、テスト設計モデルから生成されたテストケースの情報を、ツール間で受け渡しするための標準形式です。
生成されるテストケースの形式は、テスト設計技法ごとに異なります。状態遷移テストであれば、最低限「前状態」「トリガー」「後状態」がセットになりますし、デシジョンテーブルテストであれば条件部のパラメタ値の組み合わせと、動作部のパラメタ値の組み合わせというセットになります。これを明示し、受け取り側が理解できるようにする必要があります。
MTCPによるデータの受け取り手は、テスト管理ツールです。上の絵でいうと、「Test Cases」がテスト管理モジュールに入ってくるところです。上位からのインプットは、前回差分の情報を持ってくれていると嬉しい。あるいはそれはテスト管理モジュールのお仕事なのかな？
ええ、なんか、プロトコルって書くとカッコいい気がしてそういう名前にしましたが、別に通信規約ってわけでもないので、変ですね。まあいいか・・・。
おわりに
GIHOZを触ったおかげで、たくさんの妄想を膨らませることができました。本当にありがとうございます。
こういうことをいい加減に書いたり描いたりするのは簡単ですが、実現はすごく難しそうで、でも楽しそうですよね。
効果的・効率的で、同時にワクワクするテストをしたいので、それを支援してくれるVeriserveさんを応援しています！
