ドメイン分析と言うテスト技法は他のテスト技法と何が違うのか？
今回は、ドメイン分析というテストケースを作るときに使える技法を出来るだけわかりやすく紹介します。境界値分析と何が違うのか？デシジョンテーブルと何が違うのか？という観点で説明するとわかりやすいかも、と思ったのでその作戦で行きます。
この技法もJSTQBアドバンスレベル テストアナリスト試験にでるので、覚えておくとよいです。もちろん資格試験のためだけでなく実務でも十分に使えます。
今回のカバーの写真はこのnoteを書くのに参考にした３冊の表紙になります。
ドメイン分析の定義
ドメイン分析については、いろいろな人が定義をしてくれています。まず、あきやまさんとみっきーさんがJaSST四国2011でやったワークショップの資料の中では以下のように定義しています。
ドメイン分析とは、同値分割や境界値分析とほぼ同じ概念です。ただし、関係性がある複数の変数を同時にテストするときに特にドメイン分析という言葉を使います。ドメイン分析は入力に着目する場合が多いものです。
Practitioner's guide to Software test design（日本語翻訳版のタイトルは「初めて学ぶソフトウェアテストの技法」）ではドメイン分析は以下のように定義しています。
Domain analysis is a technique that can be used to identify efficient and effective when multiple variables should be tested together.
訳すと、ドメイン分析は、複数の変数が一緒にテストされるべきときに、効率的で効果的な識別に使用することができる技術です。となります。
Effective and Efficient Software testing（日本語翻訳版のタイトルは「ソフトウェアテスト実践ワークブック」）ではドメイン分析のことを「ドメインテスト」と呼んでいます。
an advanced technique for black‐box testing in the form of domain analysis that involves an analytical way to deal with the interaction of factors or variables within the business logic layer of a program.
訳すと、プログラムのビジネスロジックレイヤーの中の因子または変数の相互作用を処理する分析的な方法であるドメイン分析の形式によるブラックボックステストの高度な手法(をドメインテストと呼ぶ)。となります。
ドメイン分析はどんな時に使えるのか？
ドメイン分析の基本的なバグをどう見つけるか？という考え方は、境界値分析と同じです。ただし、変数に相関関係があるときには、ちゃんと分析しないと何が境界なのかがわからなくなります。そんなときにドメイン（ここで言うドメインとはテスト使う入力の全体領域のことです、私が同値分割について書いたnoteでも言及しています。）をちゃんと理解してどこが境界だと判断すれば良いのかを教えてくれるのがドメイン分析です。
前述したリーコープランドのPractitioner's guide to Software test designでは、ドメイン分析が必要な理由は以下の2つだ！ってしています。
・We rarely will have time to create test cases for every variable in our systems.（システム内のすべての変数に対してテストケースを作成する時間はほとんどありません。）
・Often variables interact the value of one variable constrains the acceptable values of another. In this case, certain defects cannot be discovered testing them individually.（変数が相互作用し、ある変数の値が別の変数の許容値を制約することがよくある。 この場合、個別にテストしても発見できない不具合がある。）
結論として以下のように書いています。
domain analysis is a technique that can be used to identify efficient and effective test cases when multiple variables can or should be tested together.（ドメイン分析は、複数の変数が一緒にテストできる場合、または一緒にテストすべき場合に、効率的で効果的なテストケースを特定するために使用できる手法である。）
ドメイン分析の例
荷物の宅配をする際の料金を例に考えてみましょう。以下の仕様があるとします。
チルド宅配パックの大きさの最大限は、長さ100cm以下、幅100cm以下でかつ長さ・幅の合計が150cm以下です。また大きさが長さ、幅が共に1cm以上の荷物が宅配の対象となります。
境界値分析との違い
通常の境界値分析であれば、長さの境界値と幅の境界値をテストします。グラフの縦が長さ、横が幅の場合、上記のようなグラフを書くことができます。
境界値はそれぞれ以下のようになります。
・長さの1cm,0cmと100cmと101cm
・幅の1cm,0cmと100cmと101cm
たとえ境界値分析だとしても、長さが100cmで幅も100cmのときもテストしないといけないって考えると思います。そのようなときにどこまでテストするかは、以下のようなグラフで表現できます。
けど、これでは、ドメイン分析になりません。なぜなら、両方合わせて150cm以下でないといけないという境界がテストできていません。それに、そもそも、長さ100cm、幅100cmは境界になりませんのでその辺りのテストは一切余計になります。
ドメイン分析でのテストケースの導き方
このケースでのテスト・ケースを考える際は、まず最初に上記仕様を計算式にして整理します。この例で考えてみると，以下のように式を導き出せます。
・ 長さ <= 100cm , >=1cm
・ 幅 <= 100cm, >=1cm
・ 長さ＋幅 <= 150cm
これらの式をグラフ上で表現すると以下のようになります。（このグラフの表現方法はロバートビンダーのTesting Object-Oriented Syatemsの図10.19を基にしています。）
このグラフに表した式に対して，境界値を見つけていきます。テストケースは各計算式にて，確認対象のパラメータに対して不等式の場合はonポイントとoffポイントの2つを選び、確認対象ではないパラメータは有効になる値（inポイント）を任意に選択します。
不等式は（=>,<=）と（>,<）場合で微妙に違います。また、等式の場合はonポイントと両脇のoffポイントの3つを選択します。以下のを参照してください。
変数が3つ以上の場合
変数が2つまでの場合は、グラフでビジュアル的に表現ができますが、変数が3つ以上になるとグラフでは表せなくなります。3つならかろうじて立体的なものを書くとかあるかもしれませんが４次元、５次元とかは不可能です。そんな場合にどうすれば良いかと言うのは、ロバートビンダーのTesting Object-Oriented Syatemsに書いてあります。1 by1 selection criteria、つまり仕様を式に表して、各式に対して境界値をテストするとした選択基準を適用する際にはドメインテストマトリクスを作ればよいと書かれています。
上記したチルド宅配パックの例でドメインテストマトリクスを作ると以下のようになります。
３次元になるとどうなるか？ですが、「チルド宅配パックの大きさの最大限は、長さ100cm以下、長さ・幅・厚さの合計が150cm以下です。」と仕様が書かれているような例が該当します。これはグラフで表現できませんが、ドメインテストマトリクスだと以下のように列を足すだけで表現できます。（すごく簡単！）
この考え方を応用することで４つでも５つでもどんとこい！って感じですね！
一応追記すると、任意ってかいてあるところはinポイントの中で任意に選ぶってことですよ！
３つの変数のドメイン分析の例は、大昔（2007年くらい？）に日経ソフトウェアでテスト技法の連載をしたときの例題でもわかります。
この日経ソフトの連載では、1つの変数に対する境界値分析、2つの依存関係のない境界値分析、3つの変数で依存関係がある場合にドメイン分析、といった流れで説明しているのでわかりやすいと思います（自画自賛w）。
デシジョンテーブルとドメイン分析の違い
これはレックスブラックのソフトウェアテスト実践ワークブックで説明している題材を使ってみます。
この本でドメイン分析を説明する際には、上記したビンダーのグラフとは違うようなグラフで説明してて、（実は私は）とっても混乱しました。
その題材は「航空会社のマイレージプログラムを用いたドメインの例」というものです。書籍を持ってる方は読んで欲しいのですが、持ってない方もいるので私がエクストリーム仕様表現をすると以下のようになります。
そして、このドメインテストをするためとして以下のようなグラフが出てきます。ちょっとイメージとしてみてください。
正直、最初にこの本を読んだとき「なんだこれ？」って思いました。二つの変数の依存関係を表すグラフではないのでわからなくなりました。
まぁ、ちゃんと読むと理解できてくるのですが、この点は、会員レベルの変更を考慮してるんです。この４本の線は会員レベルを表現しています。一番高い線はプラチナで、プラチナはどれだけ乗ってもプラチナなので点が一つ、一番低い線は通常レベルで、通常レベルは本年度に飛行機に乗れば乗るほどレベルが変わって、最大3つ上までいく可能性があるので点が4つなんですね。
これはデシジョンテーブルで表現したほうがよいのではないか？と思ったんです。
デシジョンテーブルで書くとこうなります。
「これでいいじゃん？」ってなりませんか？
ただし、これを実際にテストする際にはそれぞれの具体的な値を特定しないといけないです。その際には、やっぱりドメイン分析が必要かも。なので、前述したビンダーの1 by 1ドメインテストマトリクスを書いてみましょう。
なるほど、デシジョンテーブルで10パターンだけど、ドメイン分析で出すとそれぞれの境界値もテストすることになるから23パターンになるんだ！ってことがわかるようです。
現在のマイル数0と1を境界値として考えるか？ですが、厳密に言うと境界値は0がONポイントで、強いて言えばマイナス1がOFFポイント（無効の境界値）と言う方が教科書的には正しいです。この例では、マイナス1はありえないからそもそも考えないってことと、0は特殊な数字で、0を入れることによるバグって言うのも多くあるので、0と1をあえて境界値にしています。なので教科書的には不正解で、オレ流で勝手に入れてるって感じです。
任意の値を具体的に適当な数字を入れてみます。また、これによりデシジョンテーブル的にはどのIDに該当するかをトレースできるようにしてみます。
さいごに
境界値分析とデシジョンテーブルを例にしてドメイン分析の違いを説明することで、ドメイン分析について更に詳しく理解してもらうように書いてみました。まとめると以下のようになります。
境界値分析との違い
2つ以上の変数の相関関係（つまり、連立方程式のようになる場合）の境界値を求めてテストケースにするときはドメイン分析を使う
デシジョンテーブルとの違い
テストするパターンの値を特定する際に境界値をテストしたい場合、かつその境界を求めるには複数の変数の相関関係から境界値を求める場合はドメイン分析を使う。（同値パーティションのどの値でも良いとした場合はドメイン分析不要）
と言うことでドメイン分析でした。
いいなと思ったら応援しよう！
