テストデザインパターンとテスト観点

Yasuharu NISHI @YasuharuNishi

@mkoszk あるテスト観点は、入力－処理－出力といった特定の分け方（親観点）だけから出てくるとは限りません。扱っているデータといった親観点から出てきてもよいでしょう。その意味では、多重継承します。そういう問題？

Yasuharu NISHI @YasuharuNishi

@mkoszk まぁ無理でしょうね。それに、よしんばテスト観点が全部挙げられたとしても、きちんとしたモデリングができないので、それでテストが全部だという説明ができないでしょう。そんなに甘くないですよ。

Yasuharu NISHI @YasuharuNishi

@akiyama924 @mkoszk 例えばA1とA2という2つのファイルフォーマットがあったとします。A2はA1の拡張フォーマット。多くは同じで、一部異なるところや拡張されたところがある、という感じ。

Yasuharu NISHI @YasuharuNishi

何も考えずにテスト観点を挙げると、A1とA2の仕様にしたがって、それぞれ独立に子観点を挙げます。その結果、A1の子観点とA2の子観点には、同じものが多く挙がりますが、A1の観点サブツリーを見てもA2の観点サブツリーを見ても、何が同じで何が違うかはよく分かりません。

鈴木三紀夫 @mkoszk

@YasuharuNishi ファイルを読み書きしたり、画面遷移をしたりするアプリケーションを想定しています。このとき、入出力から考えるのではなく、ファイルの方に意識の中心があります。その延長でレコードレイアウトに関心が移ります。

Yasuharu NISHI @YasuharuNishi

言い換えると、もしA1とA2の共通仕様が同じ実装で実現されており、かつA1がきちんとテストされたとすると、A2における共通仕様部分のテストにおける品質リスクは下げてよいはずですが、そのことはA1とA2のそれぞれの観点サブツリーを見ても分かりません。

鈴木三紀夫 @mkoszk

@YasuharuNishi 数値項目を読み書きするとき、読む（入力）、書く（出力）とみるのではなく、数値項目に関するテストすべき観点としてあげる漢字です。

Yasuharu NISHI @YasuharuNishi

そこで、A1とA2の子観点をそれぞれ「仕様共通部」と「仕様変更部」と「仕様追加部」のように分けます。そうすると、A1とA2の観点サブツリーに、“共通なところがあるから品質リスクを増減させる”という設計思想が反映されます。

鈴木三紀夫 @mkoszk

@YasuharuNishi ですよね。どう言えば分かってもらえるのか思案中です。

Yasuharu NISHI @YasuharuNishi

カモニーの挙げたテストデザインパターンは、ざっとそんな感じです。テスト観点の挙げ方（要求モデリング）というよりも、テスト観点図のリファクタリングのやり方（設計モデリング）のパターンですね。

Yasuharu NISHI @YasuharuNishi

あ、テスト観点図に品質リスクの情報をテスト観点として含ませることが良いか悪いか、という話は置いといてください。 (^^;

Yasuharu NISHI @YasuharuNishi

こんな感じで分かって頂けます？

鈴木三紀夫 @mkoszk

@YasuharuNishi なるほど、派生開発のようなことを意識して、品質リスクを表現しようとしているのですね。

Yasuharu NISHI @YasuharuNishi

@mkoszk 派生開発以外にも、USB1.0とUSB2.0やミドルウェアのアップデートのように、くっつく構成要素の違いなんかにも使えます。

鈴木三紀夫 @mkoszk

@YasuharuNishi 確かに互換性に関するテストも対象ですね。

Yasuharu NISHI @YasuharuNishi

@mkoszk あるデータに関するテストを設計する時に、例えば文字コードのようなデータそのものの属性に関するテストと、データの入力頻度のようなデータの処理に関するテストは、それぞれ別の観点から挙がってきてもよいと思います。もちろんテスト実装時にはまとめるわけなんですが。

Yasuharu NISHI @YasuharuNishi

某ワークショップの企画は、テストの立場とQAの立場と、（悪い意味で）どれでもない第３者的な立場の3つがゴッチャになって議論している感じがするのだが、気のせいか？興味あるテーマかもしれないし、困っているテーマかもしれないけど、企画側に勝算が無いと実現は厳しいぞ。

Yasuharu NISHI @YasuharuNishi

@mkoszk テスト観点を挙げきれば完全なテストができる、ということが幻想だ、ということを納得してもらえるような技術や実例を僕らが提案・開発しなくてはいけないのだと思います。それが智美塾の役目の一つなのかもしれません（そっちの方に話が進めば、ですが）。

Yasuharu NISHI @YasuharuNishi

@mkoszk （一部だけが異なる、などある特定の性質を持ちうる）さまざまな観点（群）に対して汎用的に使える、というのがテストデザインパターンに必要な点です。

鈴木三紀夫 @mkoszk

@YasuharuNishi そう。そのデータに付随する属性のテストと、入力という行為に付随する属性のテストという両方の観点がうまく整理できていないのです。モノとコトと言ったら怒られそうですが、その違いに悩んでいる感じかな。

Yasuharu NISHI @YasuharuNishi

あと「仕様共通部」のような、テスト観点のメタなもの（もしくは役割）と、A1の仕様共通部とA2の仕様共通部が同じといった、メタなもの（もしくは役割）同士の関係とから構成されるのが、カモニーのテストデザインパターンの特徴かと思います。

鈴木三紀夫 @mkoszk

@YasuharuNishi モノを使ってコトを起こすので、コトにモノを紐づけて、つまり、入力にファイルを紐づけて、テスト観点を導きだそうとしています。でも、出力にもファイルはあり、入力と出力では、まったく同じでは無いにしろ、似たような観点が上がるため混乱していたりします。

Yasuharu NISHI @YasuharuNishi

実は@akiyama924さんの挙げたパターンのいくつかは、カモニーが研究の過程で挙げていました。議論の結果彼は、それらは観点の挙げ方であって狭義のパターンではないだろう、と結論づけました。逆に言えば、広義のパターンをいろいろ挙げてみて、それをいろいろ分類するのは楽しそうです。

Yasuharu NISHI @YasuharuNishi

@mkoszk 観点名は似てるんですが、着目しているところは違うんだよ、というのを上手く表現できるようなネーミングが必要なんですよね。でも難しい。 (^^;

Yasuharu NISHI @YasuharuNishi

入力の子観点であるファイルと出力の子観点であるファイルは、同じ名前なんだけど違うんだよ、というコメントを付与するというのが、イチバン安直で現実的な解決策ですね。