組合せテストにおける因子と水準はどちらを最優先で考えるべきか

ソフトウェアテストの組み合わせテストでは、因子と水準の考え方が重要になる。
組合せテストにおける因子と水準はどちらを最優先で考えるべきか、考えたことをメモ。

【参考】
システム開発で組合せテスト技法を使いこなすには？ 4つのポイントを紹介| Qbook

組合せテストの考え方 - Qiita

駆け出しテストエンジニアと組み合わせテスト技法：Bugs Life ～テストエンジニアは不具合と戦い共に生きる：エンジニアライフ

ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ: プログラマの思索

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ: プログラマの思索

【1】水準はパラメータの値、因子はパラメータの値をグルーピングしたカテゴリ。
一般に、設計書からテストケースを作成する場合、因子と水準のどちらを最優先で考えるのか？

【2】基本的に考えると、因子を決めて、因子のインスタンスである水準を洗い出すように考えがち。
たとえば、都道府県という因子から、東京都、大阪府のような水準をトップダウンで導き出す。
つまり、因子→水準の順番を考えるように思ってしまう。

しかし、実際の仕様書は、魑魅魍魎な日本語という曖昧な自然言語で書かれている。
因子をきちんと書き出してくれていない場合が多い。
実は、仕様書やユーザーストーリーには、水準だけ記載されていて、因子が明示されていない場合が非常に多い。

たとえば、映画館の入場料金は、学生や老人は20％割引、深夜時間帯は30％割引、水曜はレディースデーで女性は割引、団体客は一括割引などの仕様が書かれていたとする。
すると、水準である実際のパラメータの値はたくさん書かれているが、因子は明示されていない。
因子は年齢、曜日、時間帯、性別などが出てくるが、たとえば、年齢と曜日の組み合わせならどの割引になるのか、が不明確なのだ。

つまり、実際の仕様書、ユーザマニュアル、ユーザストーリーには、水準はあちこちに散らばって記載されているが、因子は明確に記載されていない。
よって、組合せテストを作成する前には、まず仕様書から水準をすべて抽出し整理して、因子を改めて定義し、デシジョンテーブルに落とし込む必要がある。

すなわち、水準→因子の順番で考える場面のほうが非常に多い。

すると、因子の組合せパターンから、仕様書に記載されていないパターンが不明点としてたくさん出てくるだろう。
そんな内容をすべて特定し、ユーザに逐一確認して、仕様を決めていく必要が出てくる。
そういう作業こそが本来のSEの仕事なのだろう。

【3】映画館の入場料金の例のように、因子と水準を抽出してデシジョンテーブルを作成していく研修を実施した時がある。

すると、時間内にデシジョンテーブルを正確に作成できる人と、いくら時間があってもデシジョンテーブルを作成できない人の２つの集団に分かれるように認識した。

デシジョンテーブルを作成できない人は、因子→水準の順番で抽出しようとしているので、いつまで経っても、自分の頭が混乱した状態になっているようだ。
つまり、たくさんの水準のデータを抽出するが、因子と完全に対応して整理できないので、たくさんのデータに混乱してしまっているようだ。
一方、デシジョンテーブルを作成できる人は、まず水準を抽出して、因子でグルーピングする順番なので、水準→因子で作業しているから、漏れなく整理でき、組合せのパターンや関数従属性も考慮して、デシジョンテーブルを作成できているようだ。

どうやら、デシジョンテーブルを作成する能力は、ある人とない人では、作業工数が10倍以上も違うように思えた。
つまり、デシジョンテーブル作成の生産性は、人によって大きなバラツキがあるわけだ。

【4】僕は、水準から因子を定義し、デシジョンテーブルを決めていく作業は、データモデリングの作業にも近いように思う。
なぜならば、それらの因子はテーブルの1項目に普通は対応しているので、項目間に関数従属性が発生し、その制約によってデータモデルが出来上がっていくからだ。

換言すれば、水準から因子を抽出して定義する作業は、組合せテスト技法だけでなくデータモデリングにも通じる技術ではないか、と思う。

しかし、「水準→因子の順番で整理してデシジョンテーブルを作る」という手順さえ理解すれば、新人のプログラマであってもすぐに慣れていくだろうと考えている。
組合せテストのようにテストケース作成の技術は、教科書を習うよりもたくさんの経験をこなす方が重要だ。
まずはたくさん試して、失敗もして、慣れた後に教科書を見直す方が、経験が整理されるので良いと思う。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索