FV表とFL表

テスト仕様書を作る一つの方法として、直交表を用いたHAYST法がある。
HAYST法で重要な概念は、FV表とFL表の二つ。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
ソフトウエアテスト分析の方法

テスト分析 テスト設計

受入テストのテストケースを作る場合、要求に対してテストケースを作る。
そのテストケースのレベルは、プログラムレベルではなく、顧客の観点になる。
だから、いきなりテストケースを作ったとしても、粒度や網羅性が不十分になりやすい。

「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」にも書いてあるように、テスト設計で最も重要な観点は、テスト対象の因子・水準を漏らさず抽出することにある。
因子とは、テスト対象のパラメータ。
水準は、パラメータが取りうる値。

例えば、MSのOffice製品をテストする場合、OSやCPU、HDDなどは因子であり、因子OSの取りうる値であるWindows XP, Vista, 7は水準になる。

実際のテスト設計では、因子そのものを漏らしてしまう時も多く、そこから必ずテスト漏れになって、バグが出る。
更に、水準を全て抽出しきれなければ、バグの温床になる。
特に、因子同士の組合せで特別な処理が発生する場合も多いので、それら全てを網羅したテストケースを作るのは実際は非常に大変。

HAYST法では、まずFV表(機能検証表：Function Verification Table)を作る。
FV表とは、機能単位の検証内容の一覧表。
僕のイメージでは、FV表は、テストの観点であり、テストケースを作る元ネタ。
ソフトウエアテスト分析の方法にFV表の例が書かれている。
FV表がしっかり書けていれば、実際のテストケースは1日で500ケースぐらいは簡単に作れる。

次に、FL表(因子水準表：Factor Level Table)を作る。
FL表とは、テスト対象の因子と水準の一覧表。
僕のイメージでは、テスト対象のパラメータの組合せを作る元ネタ。
特にデシジョンテーブルの入力条件を洗い出す時に使っている。
ソフトウエアテスト分析の方法にFL表の例も書かれている。
FL表がしっかり書けていれば、テストに必要なデータパターンを機械的に洗い出すことができる。

ソフトウエアテスト分析の方法では、FV表とFL表から作られたテストケースをTestLinkにインポートした画面で終わっているのが印象的。

FV表とFL表という言葉は今まで知らなかったけれど、それに似たような作業はやっていたので腑に落ちる。
実際のテストケースレビューでは、テストの観点に相当するFV表を何度もレビューして、漏れが無いかチェックしていた。

FV表やFL表を作る元ネタは実際は、画面遷移図だったり、システムの状態遷移図だったりする。
つまり、要件定義や外部設計、内部設計の成果物の品質が悪ければ、FV表もFL表の質も悪くなる。
逆に言えば、FV表を作りながら設計書を作れば、自分の設計を自分で検証しながら作っているのだから、機能設計書の品質は良くなるはず。
又、FL表を意識しながら状態遷移図を作れば、システムの状態や状態遷移の漏れをチェックできるので、システムの状態遷移図の品質も良くなるはず。

「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」によれば、FV表に出てくる機能は「名詞＋肯定形の動詞」で表現でき、その否定形である故障モードは「名詞＋否定形の動詞」で書けるらしい。
すなわち、その故障モードに影響度を追記した表はFMEA(意味：故障モードとその影響の解析）になるので、トラブルの予測に使える、とのこと。
確かに、FMEAがあれば、業務システムの運用保守や組込製品の故障分析で威力を発揮するように思う。

テストケース作成技法を持っていれば、テスト駆動開発と組み合わせることもできるはず。
テストケースが分かっていれば、それに基づいて実装すれば、自然にテスト駆動開発になるからだ。
つまり、Agile開発にテストケース作成技法を組み合わせれば、品質をより強化できるはず。

テストケース作成技法は日本の品質管理技法の中でかなり研究されてきた分野なので、奥も深い。
色々調べてみる。