テストカテゴリの出し方（機能編）をみきおさんから教えてもらった

Twitterでワイノワイノやってたら、みきおさんからテストカテゴリの出し方を教えてもらった。

みきおさんのテストカテゴリの機能側導出の手順。ソースはこちらを参照のこと。 http://togetter.com/li/684105

みきおさんがまとめたアーキテクチャー入りの方はこちら http://togetter.com/li/684589

機能を実現するプログラムを単純に入力、処理、出力とみなします。
入力に関するテストすべき観点は、「入力データチェック」「ボタン操作」
になるでしょう。処理に関する観点は「計算」、出力に関する観点は
「表示」になります。

この取り掛かりはマインドマップ本や、HAYST法のラルフチャートと同じだと思う。まずは3つに分けてそこからブレイクダウンするということ。
シナリオを書いているときも同じ思考かもしれない。

これでだいぶテストカテゴリが洗い出されますが、これだけだと、
p.10のテストカテゴリには不十分です。何が足りないかというと、
「処理」のところです。単純に入力されたデータを演算して出力す
るのではなく、蓄積された値を使うことがあります。

そこで、処理で蓄積された値を扱う場合のカテゴリである「登録、
更新、削除」が現れます。これまでの説明で、論理的機能構造の
入力、変換（処理）、出力、蓄積が現れています。ですから、
p.10のテストカテゴリは機能モデルから導いていることになります。

これはモデルによって変わるんだと思う。例えば、コマンドラインでの計算プログラムだと蓄積された値は無いかもしれない。でもメモリは必ずあるので、この機能モデルの蓄積がファイルまたはDBか、メモリを含むか道考えるかで違うんだろうな～

あるテスト対象の場合、入力、処理－蓄積、出力という機能モデルには
馴染まないものもあるかもしれません。この場合は、別のモデルを
設定すれば良いことになります。

あと、機能モデルはプログラム・スケルトンを用いた
構造化プログラミングっぽいので、クラス図に慣れていると
違和感を持つかもしれませんね。

なるほど。ちょっと納得です。

テスト対象によって、テストカテゴリ名称が変わることはあると思います。
「ボタン」が「リンク」に変わったりとか。さらに、組織の文化も
反映すると思います。エラー発生時のメッセージ確認を重点的にやる組織ならば、
「エラー処理」のようなカテゴリを追加するかも。

「エラー処理」ではなく、状態遷移に関するテストを重視するのであれば、
「状態遷移」というカテゴリを持ってくるかもしれません。
まぁ、公開されているゆもつよマトリクスを分析した結果なので、
非公開のものには当てはまらないものがあるかもしれません。

エラー処理はともかく状態遷移は機能モデルからは出ないと思う。組織（または個人）の経験として持っておくべきなのか。。。

2014/06/25 追記
どうやらやはり状態遷移は機能モデルから導出するらしい。また機能モデルは対象のソフトウェアに依らないが、状態遷移だったり、エラー処理だったり意図を持ってテストカテゴリを導出するとのこと。状態遷移や非同期処理、排他などは機能モデルのサポートから出るみたい。

f:id:nemorine:20140625224941p:plain