「HAYST法」を検索すると、あたかもソフトウェアテストの手法であるかのような解説が目につきますが、そんなことはありません。ソフトウェアテスト以外でも、条件を組み合わせてパターンを考える場面で何にでも使えます。むしろ、私の経験からすると、ソフトウェアテストにはあまり向いていないように思います。その理由については後で解説しますが、まずはHAYST法について解説します。
HAYST法とは、複数の選択肢（HAYST法では “水準” という）を持つ条件（HAYST法では “因子” という）が複数存在する場合に、これを網羅する必要最小限のパターンを求める手法です。
検査項目などパターンの数は、次の３つの要素によって変動します。
①すべての条件の数
②組み合わせる条件の数（確認したい組合せ）
③各条件の選択肢の数
これらが増えると検査項目が指数関数的に増加します。そのため、条件が複雑になるほど検査項目のスリム化が必要になります。HAYST法は、指定された条件下で必要最小限の項目を設定する手法です。
ただし、組み合わせる条件は２個だけです。つまり、HAYST法では上記の②が２個の時を想定しています。この条件における網羅率（ペア網羅率）は100%ですが、３つ以上の組み合わせになると網羅率は下がります。しかし、ペア網羅率100%だけでも効果は大きいと言えます。しかも、項目数を劇的に削減できます。
どの程度減るのか下表に示します。これは、すべての条件の選択肢が２個のときに、条件が増加すると項目数がどれだけ増えるかを示したものです。これを見て分かるように、条件の数が増加するに連れて観点数は急激に増加しますが、HAYST法による項目の増加は緩やかです。
なぜHAYST法で項目数を減らすことができるのか解説します。
HAYST法では「直交表」という手法を用いています。これは、とても難しく簡単には説明出来ないので、難しい理論の説明は省略します。気になる方は他のサイトや書籍を参照してください。
HAYST法の仕組みをざっくりと言うと「複数の観点を１個の項目でまとめて確認してしまう」という方法です。以下、具体的に説明します。条件が３つ（いずれも選択肢が２個）の場合の例です。分かりやすいように、フォントの指定（太字の有無、斜体の有無、下線の有無）を例にします。
条件が３つなので、その内の２つを取り出す組み合わせは 3×(3-1)/2=3 です。それ毎に [なし、なし] [なし、あり] [あり、なし] [あり、あり] の４パターンを考えるので、観点の合計は 3×4=12 です。HAYST法では、この12個の観点を３つずつ１回の検査でまとめて確認します。例えば、項目1では [太字なし、斜体なし] [斜体なし、下線なし] [太字なし、下線なし] の３つの観点をまとめて確認します。その結果、全部で 12/3=4個 だけの項目になります。
この表は選択肢が２個の場合ですが、選択肢を増やすこともできます。それには、直交法の「割付け」というテクニックが必要ですが非常に難解です。HAYST法を使いこなすためには無くてはならないテクニックですが、とても難しく、それがHAYST法が普及しない要因の一つだと思います。簡単に設定できるソフトもあるようなので、興味がある方は探してみてください。解説するサイトや書籍もありますが、理解するまでに相当苦労すると思います。
ご参考に、私が作成した簡易ツールを紹介します。次のパターンで利用できます。
これらのパターンにおける２条件の組み合わせ網羅率（ペア網羅率）は100%。３条件の組み合わせ網羅率は90%です。
サンプルとして、６つの条件（選択肢が４個の条件が３つ、選択肢が２個の条件が３つ）を設定したものを示します。
入力シートに条件と選択肢を入力すると、出力シートに項目が表示されます。
この１６個の項目を実施すると、すべての条件のペア網羅率100%を確認できます。
使ってみたい方は、下記のファイルをダウンロードしてください。
Excelの計算式で実現しているのでそのまま使えます。マクロは使っていません。
—
最後に、HAYST法がソフトウェアテストに向かない理由を解説します。理由は２つありますが、どちらも『複数の観点を１回の検査でまとめて確認する』ことに起因しています。
【理由１】テスト項目数の数え方が根本的に変わる。そのため、工程移行判定や出荷判定などの基準値〈摘出バグ数／テスト項目数〉の見直しが必要になる。
ソフトウェアテストにおいて〈観点数〉と〈実行数〉は違います。〈観点数〉とは「条件Aが〇〇、条件Bが△△のとき、××になる」という “確認する数” です。〈実行数〉とは「条件Aが〇〇、条件Bが△△、条件Cが□□で実行する」という “実行する数” です。
ソフトウェアテストでは、通常〈観点〉毎にテスト項目を作成していたので、テスト項目数は〈観点数〉です。一方HAYST法は、複数の観点を１回で実行するので、テスト項目数は〈実行数〉になるでしょう。そのため〈摘出バグ数／テスト項目数〉という品質指標の意味が変わります。したがって、その基準値を見直す必要があるのです。
過去の資産を捨てて組織全体で取り組むのであれば活用できるかも知れませんが、一部の者だけで生半可な気持ちでやってもうまくいかないと考えます。
【理由２】結果が正しいのか間違っているのか分かりにくい。また、不具合が発生したときにバグ調査に手間がかかる。
これまでのテストでは、「条件Aが〇〇、条件Bが△△のとき、××になる」というように実行条件と結果が明確だったので、不具合をすぐに気がつくことができました。また、確認する狙いが１つではっきりしているため、不具合が起きたときにバグをある程度推測することができました。
しかし、HAYST法は「条件Aが〇〇、条件Bが△△、条件Cが□□」というように実行条件を指定しているだけで結果は明確になっていません。強いて結果を挙げるとすれば「正しく動く」でしょうか。しかし、何が正しいかははっきりしません。そのため、結果を見てもそれが正しいのか間違っているのか分からないことがあります。
また、確認する狙いが複数であるため、不具合が起きたときにどこにバグがあるのか推測することが難しくなります。つまり《バグを取る》ためのテストには向かないのです。反面、《バグがないことを確認する》ためのテストには有効かも知れません。出荷前の最終確認やアジャイル開発での自動テストなど、バグがないことの確認が目的で、出来る限り効率化したいテストにおいては、活用を検討する価値があるかも知れません。
さらに、異常系のテスト（異常な条件下でエラーになるかの確認）には使えません。なぜなら、HAYST法は「複数の条件下で正しく動く」ことを確認する手法だからです。
以上、HAYST法はとても難しい手法ですが、使いようによっては劇的な効果をもたらします。気になる方は、勉強されてみてはいかがでしょうか。かなり難しいですが。
コメント