はじめに
はじめまして、ヌキです。
今回は組み合わせテストの設計技法、特に、HAYST法と呼ばれる技法について考えてみたいと思います。
ソフトウェアテストには様々な設計技法があります。同値分割法と境界値分析、デシジョンテーブルテスト、組み合わせテスト、状態遷移テスト、などなど。その中でも、最も理解と適用が難しい設計技法とは何でしょうか。人それぞれとは思いますが、色々な研修や勉強会に参加したときの実感としては、最も多くの人が頭を抱えているのは組み合わせテスト技法でした。
ここでは、そんな組み合わせテスト技法の最難関（だと思う）HAYST法について改めて勉強し、この技法の勘所を整理したいと思います。
組み合わせテストとは何か
まず、組み合わせテスト技法とは何でしょうか。
JSTQB AL TAの2012年版シラバスによれば、「複数の値を持つ複数のパラメータを含むソフトウェアをテストする場合で、組み合わせ数が、許容される時間内にテスト可能な数よりも多く存在するときに使用する」テスト技法です。
例として、4桁式ダイヤル錠を考えてみましょう。このとき、0～9の数字（＝値）を選べる4つのダイヤル（＝パラメータ）があります。
その全組み合わせ数は、10の4乗＝10000通りとなります。
さて、10000通りの組み合わせを全てテストするのは、現実的な工数や納期を鑑みたとき難しい、というか絶対に不可能という場合があります。こんなときに使用するのが組み合わせテスト技法です。
組み合わせテスト技法では、「事前に定義した度合いのカバレッジを達成するために、これらの組み合わせの適切なサブセットを識別する手段を提供」します。つまり、全組み合わせとはいかないまでも、充分にソフトウェアの品質を保証できるような網羅率をあらかじめ決めておいて、それを満たす組み合わせの数とパターンはこれだ！と教えてくれるものなのです。
そしてシラバスによれば、組み合わせテスト技法には「ペアワイズテストおよび直交表テスト」があります。
※SQuBOKを参照したところ、「All-Pair法」および「実験計画法」という表現もあるようです。ちなみに、2018年版のJSTQBシラバスでは直交表テストの文言が削除され、ペアワイズテストのみの記述となっているので要注意です。
HAYST法とは何か
いよいよ本題、HAYST法とは何でしょうか。
名著『ソフトウェアテスト技法ドリル』によれば、HAYST法とは「直交表を用いた組み合わせテスト技法」です。
また、HAYST法は「仕様上は機能と機能の間には関連がないことが前提になっているテスト技法」です。
他の技法との違いを確認しておきましょう。
デシジョンテーブルテストでは、複数の条件の間に関連が「ある」ことが前提になっていました。だからこそ、条件と条件の組み合わせごとに異なるアクションを整理してデシジョンテーブルを作成しました。
しかし、HAYST法は逆に関連が「ない」ことが前提になります。
例として、次のような動画配信サービスの入力画面を考えてみましょう。
・ログイン画面（ユーザーID入力欄とパスワード入力欄がある）
・ユーザー設定画面（性別選択欄と生年月日入力欄と決済方法選択欄がある）
ログイン画面では、2つの入力欄の間に関連があります。ユーザーIDに無効な値を入れた場合は、パスワード入力が何であれログインに失敗します。
他方で、ユーザー設定画面では、3つの選択欄の間には関連がありません。性別が男でも女でも生年月日の入力結果に影響はないし、年齢が成人済でも未成年でも決済方法の選択結果に影響はないはずです。もしそこに妙な相互影響があり、ユーザー設定に失敗したり不具合が発生したら大変ですね。
HAYST法は、こうした「意図しない組み合わせで問題が発生しないことを確認するテスト技法」なのです。
※余談ですが、HAYST法のHAYSTは、Highly Accelerated and Yield Software Testingの略だそうです。超かっこいい…！
もちろん、HAYST法にはメリットだけではなくデメリットもあります。
まず、全ての組み合わせテスト技法がそうなのですが、全組み合わせよりも網羅率が落ちるため、問題を見逃す可能性は常にあります。
また、直交表を用いた組み合わせテスト技法は、ツールを用いたペアワイズテストよりもテスト数が膨大化しやすいとされています。
直交表の使いかた
HAYST法では因子（＝パラメータ）と水準（＝値）を抽出して、それを直交表に割り当てて組み合わせます。
さっそく先ほどの例について、直交表ツールに値を入力してみましょう。
例：動画配信サービスのユーザー設定画面
・性別選択欄：男性か女性かを選択する
・生年月日入力欄：自由入力できる（システムの処理に関わるのは、未成年か成人済か）
・決済方法選択欄：クレジットカード決済かコンビニ決済かを選択する
この画面の因子（＝パラメータ）は3個、各因子の水準（＝値）は2個です。
因子1：性別 ……2水準（男性・女性）
因子2：生年月日 ……2水準（成人済・未成年）
因子3：決済方法 ……2水準（クレジットカード決済・コンビニ決済）
その全組み合わせ数は、2の3乗＝8通りになります。
これを直交表に割り当てたのが、次の図です。
その組み合わせ数は、4通りになります。
なぜ組み合わせ数を削減できるのでしょうか。それは、直交表が「2因子間網羅」という考えに基づいているからです。
つまり、全因子の組み合わせを網羅しなくたって、因子1と因子2の組み合わせ、因子2と因子3の組み合わせ、因子1と因子3の組み合わせ……という2ペアごとの組み合わせを網羅すれば、ソフトウェアの品質保証としては充分さ！という考えを採用しているわけですね。
とはいえ、8通りが4通りに減っても、ありがたみは大して感じられません（失礼）。そこで、先ほどの例に仕様変更が入り、もう少し複雑になったと想定してみましょう。
例：動画配信サービスのユーザー設定画面（複雑Ver.）
・性別選択欄：男性・女性・その他・未回答
・生年月日入力欄：自由入力できる（システムの処理に関わるのは、レーティングに関わる年齢：0～11歳・12～14歳・15歳～17歳・18歳以上）
・決済方法選択欄：クレカ決済・コンビニ決済・キャリア決済・コード決済
・プラン選択欄：プランなし・お得プランA・高級プランB・最高級プランC
・オススメ動画選択欄：不要・洋画・韓流・邦画
この画面の因子（＝パラメータ）は5個、各因子の水準（＝値）は4個です。
その全組み合わせ数は、4の5乗＝1024通りになります。いい感じに大変そうな数ができました。
さて、これを直交表に割り当てたのが、次の図です。
その組み合わせ数は、16通りにまで削減されます。
おお……これはありがたい…！
HAYST法の深みへ ……6W2Hツリー、FV表、ラルフチャート、FL表
HAYST法では因子（＝パラメータ）と水準（＝値）を抽出して、それを直交表に割り当てて組み合わせます。この時点ですでに、ソフトウェアテストに大いに活用できる便利な設計技法であることが分かりました。
でも、HAYST法で使用するのは直交表だけなのでしょうか。
実は違います（なので、JSTQBシラバスの「直交表テスト」と「HAYST法」は厳密にはイコールではありません）。
HAYST法は、因子（＝パラメータ）と水準（＝値）を抽出するために、
・6W2Hツリー
・FV表
・ラルフチャート
・FL表
以上4つのフレームワークを駆使する、とても難しいテスト技法なのです（『事例とツールで学ぶHAYST法』では、HAYST法はテストプロセスとも記載されています）
では、さっそく順に見ていきましょう。
1)6W2Hツリー
『事例とツールで学ぶHAYST法』によれば、6W2Hツリーは次のようなものです。
このフレームワークは、最初に、必要な因子（＝パラメータ）と水準（＝値）を抜け漏れなく抽出するために使用します。
HAYST法は「仕様上は機能と機能の間には関連がないことが前提になっている」テスト技法です。なので、ただソフトウェア仕様だけを見るだけでは、テストに必要な因子と水準は分かりません。
開発側の視点（なぜ実装するのか、何を実装するのか、どのように実装するのか）、顧客側の視点（いつ、どこで、誰が使用するのか）を考慮する必要があります。
先ほどの例に戻って考えてみましょう。
例：動画配信サービスのユーザー設定画面（複雑Ver.）
・性別選択欄：男性・女性・その他・未回答
・生年月日入力欄：自由入力できる（システムの処理に関わるのは、レーティングに関わる年齢：0～11歳・12～14歳・15歳～17歳・18歳以上）
・決済方法選択欄：クレカ決済・コンビニ決済・キャリア決済・コード決済
・プラン選択欄：プランなし・お得プランA・高級プランB・最高級プランC
・オススメ動画選択欄：不要・洋画・韓流・邦画＆邦ドラマ
この画面の品質を保証するために、必要な組み合わせは本当に16通りでしょうか？
答えはNOです。
では、簡単に洗い出してみましょう。
Who：動画配信サービスの利用者が変更するだけだろうか。機械に不慣れなユーザーのために、サービス提供者がサーバー側から変更することもあるのでは。
Where：PCやスマートフォンのブラウザ上で変更するだけだろうか。専用アプリが配信されていたらアプリ上でも変更するのでは。
When：様々なタイミングが考えられる。新規登録後すぐに訂正したり、動画視聴の前に思い立って変更することもある。
How to：新規登録フローのユーザー情報入力画面にも同じ機能があるはず。どのように設計したか開発者にヒアリングする必要がある。
What：性別選択機能、年齢入力機能、決済方法選択機能、プラン選択機能、オススメ動画選択機能の仕様を改めて把握する。
How much：決済方法変更やプラン変更はお金に関わる重要な機能。動画の購入＆レンタル機能、割引キャンペーン表示等との組み合わせに問題はないだろうか。
Whom：親子間でアカウントを共有している場合、レーティングに関わる生年月日は頻繁に変更するかもしれない。動画選択画面や視聴履歴画面の表示に問題はないだろうか。
これだけでも、付け加えるべき因子と水準が見えてきます。
もちろん、ユーザー設定機能と、他の機能や実行環境との間に直接的な関連はありません。どのような組み合わせでも、ユーザー設定は問題なく変更・維持できるはずです。
しかし、本当にそうでしょうか？HAYST法は、こうした「意図しない組み合わせで問題が発生しないことを確認するテスト技法」です。
2)FV表
『事例とツールで学ぶHAYST法』によれば、FV表は次のようなものです。
このフレームワークは、6W2Hツリーで必要な因子（＝パラメータ）と水準（＝値）を抽出したあと、テスト対象の目的機能、検証内容、テスト技法を整理するために使用します。
まず、HAYST法ではソフトウェアを目的機能ごとに切り分けます。
6W2Hツリーでは必要な因子（＝パラメータ）と水準（＝値）を抽出するために、開発側の視点だけではなく顧客側の視点も考慮しました。ユーザーは漠然とソフトウェアを動かしているのではなく、はっきりとした目的のためにサービスを利用しています。こうした目的単位で切り出されたソフトウェアの機能を、HAYST法では目的機能と呼びます。
次に、目的機能に問題がないことを確認する検証内容を書き出し、最後に、この検証内容に適用するテスト技法を明記します。
先ほどの例に戻って、簡単に見ていきましょう。
No.1
目的機能：動画配信サービスの利用者が、ブラウザ上あるいはアプリ上で、どのようなタイミングでも問題なくユーザー設定を変更・維持できること。
検証内容：ユーザー設定画面の各選択欄・入力欄だけではなく、他の様々な機能や実行環境と組み合わせて、問題なくサービスを利用できること（動画を視聴できること）を確認する。
テスト技法：全組み合わせ数が膨大になるため、直交表を適用する。また、生年月日入力欄で全ての日付をテストすることは難しいので、同値分割法を適用する。
No.2
目的機能：動画配信サービスの提供者が、サーバー側からユーザー設定を変更できること。
検証内容：ユーザー設定APIの動作を確認する。
テスト技法：ユーザー設定のそれぞれの値について、同値分割法を適用する。
このように書き出すことで、どの目的機能にどのテスト技法が必要なのか見えてきます。
HAYST法は単なる組み合わせテスト技法ではなく、組み合わせテスト技法が必要なテスト対象機能が何なのかを教えてくれることが分かりますね。
3)ラルフチャート
『事例とツールで学ぶHAYST法』によれば、ラルフチャートは次のようなものです。
このフレームワークは、FV表で目的機能を切り出したあと、さらに必要な因子（＝パラメータ）と水準（＝値）を整理するために使用します。
ユーザーがソフトウェアに対して何かを入力すると、ソフトウェアはユーザーに対して何かを出力します。この一連の流れがユーザーの目的を達成します（そのため、ラルフチャートの真ん中には目的機能を記載します）。
しかし、洗い出す必要があるのは入力と出力だけではありません。ソフトウェアの目的機能は、何らかの内部ステータスを読み込んでユーザーの入力を待っていたり、ユーザーに出力すると同時に、それを内部ステータスの側にも書き出していたりします。
また、ユーザーもソフトウェアも常に行儀よく入力と出力を行えるわけではありません。ネットワーク環境やサーバー負荷の影響を受けることもあれば（ノイズ）、ユーザーが不穏な操作を行うこともあります（アクティブノイズ）。
また先ほどの例に戻って考えてみましょう。今回は、FV表の節で2つ書き出した目的機能のうち、No.1に注目して簡単に洗い出していきます。
目的機能：動画配信サービスの利用者が、ブラウザ上あるいはアプリ上で、どのようなタイミングでも問題なくユーザー設定を変更・維持できること。
入力：利用者自身がユーザー設定画面で各値を入力・選択する。
出力：ユーザー設定が様々な画面に反映される。たとえば、生年月日を変更したら動画選択画面でレーティング対象の動画が増えたり、プランを変更したら動画購入画面に「無料で見る」の選択が増えたり、決済方法を変更したら購入履歴画面の表示が変わったりする、などなど。
状態：ログインするとき、ソフトウェアはデータベースからユーザー設定を読み込んで各画面に反映する。ユーザー設定画面で各値を入力・選択すると、その設定がデータベースに書き込まれる。
ノイズ：操作の途中でネットワークが切断したり、サーバーが重くなったりするかもしれない。
アクティブノイズ：ユーザーが同じ入力欄を何度もクリックしたり（連続操作）、入力欄ではない場所をクリックしたり（無効操作）するかもしれない。スマートフォンを使用する場合、複数の入力欄を同時にタップするかもしれない（同時操作）。複数人のユーザーが別々の値を同時に設定したりするかもしれない。もし、サービス提供者側がサーバーを動かしている最中にユーザーが値を変えたりしたら？
こうして見てみると、まだまだ考慮すべき要素が残っていることが分かりますね。
ラルフチャート、恐るべし。
4)FL表
『事例とツールで学ぶHAYST法』によれば、FL表は次のようなものです。
この表は、6W2Hツリーとラルフチャートで必要な因子（＝パラメータ）と水準（＝値）を洗い出し終えたあと、実際にテストに使用する因子と水準を整理するために使用します。※書籍によっては、水準タイプも書き出すことがあるようです
なお、『事例とツールで学ぶHAYST法』によれば、FL表は実際にテストするための表なので、水準の欄には具体的な値を指定する必要があります。
先ほどの例で言えば、「生年月日」の入力欄が要注意です。システムの処理に関わるのは、レーティングに関わる年齢（0～11歳・12～14歳・15歳～17歳・18歳以上）の部分ですが、FL表の水準に、「12～14歳」と記載するのは避けるべきです。具体的に何歳なのか、その年齢を指定するために「何年何月何日生まれ」にするのか、具体的に指定する必要があります。
下記がその一例です。
FL表を作成したら、あとはそれを直交表に割り当てて、テストケースを作成していきましょう。これで、組み合わせテスト技法を適用したテスト設計は終了です。
※ちなみに、今回は深く触れませんが、直交表に割り当てる際、論理的にありえない組み合わせを避けるように注意が必要です。
たとえば先の動画配信サービスに、もしさらに「12歳未満のユーザーは最高級プランCを選択できない」という仕様が追加されたら、「0～11歳」と「プランC」の組み合わせが発生しないようにしましょう。これを禁則処理と呼びます。
おわりに
いかがだったでしょうか？
今回は組み合わせテスト技法の最難関・HAYST法について改めて勉強し、この技法の勘所を整理したい思いで話を進めてきました。
重要なポイントをひとつ挙げるとすれば、それは、「因子（＝パラメータ）と水準（＝値）の抽出に細心の注意を払うべし」になるでしょう。
HAYST法では、ただテスト対象の全組み合わせ数が多いからといって闇雲に直交表を持ち出すことはしません。
・6W2Hツリーで、開発側と顧客側の視点を考慮した因子と水準を洗い出す
・FV表で、テスト対象を目的機能ごとに切り分け、その検証内容とテスト技法を検討する
・ラルフチャートで、さらに目的機能に影響するステータスやノイズ・アクティブノイズを考慮する
・FL表で、実際にテストする因子と水準を整理する
これだけの手順を踏まえた上で、直交表に割り当てて組み合わせ数を削減しています。
それは、組み合わせテスト技法を適用するべきテスト対象機能を特定し、さらに、因子（＝パラメータ）と水準（＝値）を抜け漏れなく組み合わせ、具体的なテストケースを作成する必要があるからです。でないと、「意図しない組み合わせによる問題」を見逃してしまうおそれがあります。
実際にHAYST法を使わなくても、この考えかたは、ソフトウェアテストのあらゆる場面に活用できると思います。
「テストが必要なパラメータと値は、本当にこれだけで全部だろうか？」
「この技法を適用すべき対象機能は、本当にこれで合っているのだろうか？」
このような疑いを持ち続けることが、ソフトウェアテストをさらによりよいものにすることは間違いありません。
ここでは、それを教訓として終わりにしたいと思います。
（「直交表テストとペアワイズテストって結局どちらが良いのか」「禁則処理が難しいんだけど、なにか良い方法はないだろうか」という問題については、いずれ別の機会に考えてみたいと思います）
ありがとうございました。
参考文献
吉沢正孝・秋山浩一・仙石太郎『ソフトウェアテスト HAYST法入門 品質と生産性がアップする直交表の使い方』（日科技連、２００７）
秋山浩一『ソフトウェアテスト技法ドリル テスト設計の考え方と実際』（日科技連、２０１０）
秋山浩一『事例とツールで学ぶHAYST法 ソフトウェアテストの考え方と上達のポイント』（日科技連、２０１４）
関連記事
※こちらの記事では、組み合わせテスト技法のうち、ペアワイズテストのほうが扱われています。
