【連載】HAYST法のこれまでとこれから：「HAYST法」の発展、進化（最終回）

前回は、HAYST法を発表した2003年以降、支援先の企業から「組み合わせたときに生ずる不具合を解決するめどが立った」と喜ばれたという話を書きました。

それは、とてもうれしいことでした。しかし、一方で「ソフトウェアテストではHAYST法だけを実施すればよい」という誤解が生まれたのは残念でした。しかもごく一部ですが、「誤解」というよりも「信仰」に近い感覚でHAYST法を導入しようとする人が現れました。

そのような人は、「因子・水準の選択」や「組合せテストが対象としている欠陥」のことはお構いなしで、テストチームのメンバーに「HAYST法のツールを買ったから、画面にある全ての入力項目をこのツールに登録して、表を生成してテストしなさい。そうすればバグはゼロになるから」と言っていました。15年以上前の話ですし、以下のような記事の見出しを見たら、そう信じ込んでしまうのも無理はないのかもしれません。

見出しに書かれていることは事実ですが、HAYST法をソフトウェア工学で言うところの「銀の弾丸」（それを導入しさえすれば、ソフトウェア開発の品質と生産性を劇的に向上する特定の手法）と思われた人がいらっしゃったということです。HAYST法の最初の本（2007年）に「銀の弾丸は存在しない」と1ページを使って書いてあるのですが。

HAYST法は組合せテストのテストケース数の爆発を抑えて必要十分なテストを実施する方法です。従って、複雑なロジックがある場合にはデシジョンテーブルを使用する必要がありますし、そもそもHAYST法で因子と水準を見つけるためには、同値分割法などの基礎的なテスト技法が必要です。

これらの認識が自分だけのものなのかを確認するために、組合せテストの論文を読んでみたところ、「①クラシフィケーションツリー技法（※）で因子と水準を整理する」、「②ペアワイズツールで①で見つけた因子と水準から組合せ表をつくる」という2段階で組合せテストを実施していることが分かりました。

（※）クラシフィケーションツリー技法については、JaSST 2024東北のチュートリアル資料が分かりやすいのでお勧めです。簡単に言えば、テスト対象を分解して因子と水準を明らかにし、更に複数の因子の水準の組合せを明らかにする図を描いてテスト分析をする技法です。

「銀の弾丸」という誤解を解くために、HAYST法を含め、ソフトウェアテスト技法の全体像の理解とさまざまなテスト技法の使用方法をマスターすることを目的とした『ソフトウェアテスト技法ドリル』という本を書いて、2010年（改訂版は2022年）に出版しました。

テスト技法の書籍は本連載の第2回で紹介した、『はじめて学ぶソフトウェアのテスト技法』（リー・コープランド著）という良著があるものの、原因結果グラフは載っていませんし、日本で誕生した松尾谷徹氏が考案した「CFD法（Case Flow Diagram）」や、日立製作所で検査工程に入ってよいかをサンプリングテストによって統計的に確認する「探針」という手法の記載もありませんでした。せっかく書くなら「銀の弾丸」の誤解を解くだけではなく、日本のソフトウェアテストの現場で使用されているテスト技法を含めて体系的にまとめた解説書を書きたいと考えました。

書名に『ドリル』と付けたのは、例題をたくさん用意して、それを解きながらテスト技法を理解する本を作りたいという思いからでした。残念ながら、紙幅の関係でテスト技法を解説していたら例題は必要最小限しか掲載できませんでした。このときの無念さは、後にJaSST東北実行委員による『ソフトウェアテスト技法練習帳』により解消されました。

これらの書籍やJSTQB（ソフトウェアテスト技術者の資格認定試験）が広がり、今日では「HAYST法は銀の弾丸ではない」ことは浸透しているように思います。

HAYST法を発展させる試みは、私自身も行いました。まずは、組合せテストで見つかったバグからどの組合せが原因なのか、また、どの因子間の品質が悪いのかといったテスト結果を統計的に分析する方法を確立しました。統計的に分析できるのは、直交表を使用することで生じる組合せの数が同数という性質によります。

また、大きなところでは、HAYST法を状態遷移テストへ拡張しました。それは、状態遷移テストと組合せテストを同時に行うことで、外からの入力の組合せだけではなく、内部変数に対する組合せまでテストする手法で、「PathCombo」法と名付けました。

その結果は、2013年7月のソフトウェア・シンポジウムで「N-Switch カバレッジテストの問題点と解決策」というタイトルで発表し最優秀論文賞を頂きました。

既に紹介したように、HAYST法は、プリンタードライバーのプリント指定（部数、原稿サイズ、出力用紙サイズ、原稿の向き、拡大縮小、まとめて1枚、両面、製本、カラーモード、閉じしろ位置、余白……等々）の組合せを網羅的にテストすることで、組合せバグを検出する目的で生まれたテスト技法です。

その後、約60社にコンサルティングをする中で、「なるほどこういうときに役立つのか！」と思った事例についてご紹介します。

保険の組み替え

生命保険や損害保険業界では新しい保険商品が続々と誕生します。保険に入っている人なら、保険会社から「新しい保険ができました。これまでと同額の保険料で保障（補償）内容がより充実しています。契約を見直しませんか？」と提案されたことがあると思います。

保険を申し込むときに特約を付けるなど、さまざまな条件を保険申込書に記入します。1つの保険申し込みだけでも大変な組合せ（既往症の登録と加入可能な疾病保険の組合せ等）が発生します。しかも、別の保険に切り替えるときには、現契約と新契約の間の条件の組合せ、すなわち、各契約に閉じていない組合せも考慮したテストをしなければなりません。場合によっては昔の保険に存在した条件がなくなっていたり、もっと厄介なのは、同じ名前の条件で微妙に内容に変更が加わっていたりすることがあります。

しかも、保険の切り替え時には、新契約の方は1種類ですが、現契約の方は、これまで販売した全ての保険商品ですから莫大な組合せとなります。このようなケースにおいて、HAYST法を用いて2因子間（現保険の条件と新保険の条件）の組合せを機械的に作成してテストをすることが非常に有効でした。

輸出入の法規制

輸出入では、ある国で輸出した商品が別の国で輸入されるわけですから、2つの国の輸出入に関する法律（ルール）の組合せが発生します。自国の輸出入の法律を作るときに、主要な取引先の国の法律はある程度参照して作りますが、そうでない国についての組合せの見落としは発生するものです。こちらも、HAYST法で組合せテストを実施することが有効でした。

音響機器の輸出先でのコンポーネント接続

とある音響機器に対してHAYST法でテストしたときのこと。テストが無事に終わり、テスト中に発見したバグも修正されました。商品の販売が始まり2カ月がたったころ、その会社の別の商品のテストのコンサルティングに来た私を見つけて、その時のリーダーが笑顔で近づいてきてこう言いました。

「秋山さん、先日はありがとうございました。おかげさまでリリース後、これまでとは違い、ほとんどバグは出ていません」

「えっ？」と私は驚きます。

「あの、『ほとんどバグは出ていません』ということは、何件か出たということでしょうか？」

「はい。2件ほど。でも、これまでと比べたらすごいことです」

「すみません。その2件の内容について教えていただくことは可能でしょうか」

多因子間の組合せがあったということか……。

そんなに複雑なソフトウェアには見えなかったのだけれど。

ドキドキしながら言葉を待ちました。

「バグの内容のご説明はもちろん可能です。製品サポートのウェブサイトにも掲載済みの情報ですし。実はイギリスに商品を輸出したところ、現地のビデオカメラとの接続したときの問題が2つ出ました」

「輸出されたのですか」

「はい。そういえばお伝えしていませんでしたね」

【輸出先のビデオカメラ】はテストの考慮に入っていませんでした。いわゆる「因子漏れ」です。因子が漏れていればテストされませんのでバグの見逃しが生じます。この件以降、「どうやって因子の漏れをなくすのか」の検討を実施しました。それには数年かかったのですが、FV表とラルフチャートという2つの手法がHAYST法に追加されました。

HAYST法についての話題の最後として、「網羅率80%の謎」について書きたいと思います。

すでに書いたとおり、HAYST法と似た組合せ技法にペアワイズ（オールペア法ともいう）があります。

物理実験や化学実験で使用されていた実験計画法が、ソフトウェアテストに応用されたのは1980年代中ごろの日本でのことです。その後、「直交表でなくても2因子間の全水準の組合せ表を作ってテストすればよい」とし、直交表を使用せずにコンピュータで都度組合せ表を作るペアワイズ（Pairwise）という方法が1990年代の中ごろにアメリカで生まれました。

連載の第1回目で述べたとおり、HAYST法が生まれたのは1999年です。もしも、私が海外のテスト事情に詳しければペアワイズで満足していたと思うのですが、1998年に米国に学習へ行ったときに親会社ではペアワイズを使用していなかったのでキャッチアップできませんでした。

ペアワイズは上記の通り、組合せ表を作るだけであり、因子・水準の見つけ方やテスト後の不具合解析には対応していないためHAYST法との直接比較はできません。ですが、ここではペアワイズが「2因子間の全水準の組合せを100%網羅する」ことに焦点が当たっていることだけ知っていれば構いません。

「ペア網羅率100%」は魅力的です。クラシフィケーションツリー技法などを用いて抽出した因子と水準に対して、2つの組合せの問題をテストで見つけ尽くしたと断言できるからです。「市場導入後、これらの因子・水準に対して2つまでの組合せで不具合が生じることはないと保証できる」ことは安全だと示す時に特に有効です。

例えば、「2つの部品が同時に故障しても安全に路肩に駐車できることはテストで確認済みです」と言われたら、ずいぶん安心できると思います。

ところが、HAYST法は「ペア網羅率80%」を目指します。前回「HAYST法を使用して直交表に機能を割り付ければ、組合せテストは、どんなに因子が多くても64件のテストケースに抑えられ、それは実施可能なテスト数なのでテストされます」と書きました。これは、ペア網羅率100%を目指すのであれば実現不可能です。例えば、10水準の因子が2つあれば、少なくとも100件テストしなければ「ペア網羅率100%」とならないからです。

私は、一部の多水準を持つ因子やペア網羅率100%にこだわることで、何倍も組合せテストをしなければならなくなることは合理的でないと考えました。HAYST法では、100%にならない、つまり、表に出現しないテストされない組合せについて、テストの必要性を開発者とひざを突き合わせて議論します。それは開発のアルゴリズムの改善にまで踏み込みます。

組合せテストで解決すべき課題は「ペア網羅率100%」ではなく「たかだか2つの組合せでバグが発生しないこと」なのですから。

HAYST法については、2014年に『事例とツールで学ぶHAYST法』という書籍にこれまで書いてきた状態遷移テストへの応用を含め書いたことで自分の中では一区切りが付いています。

現在は、CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）というプロセス改善のモデルを組織に定着するための活動をしています。2024年2月にレベル5を達成しました。日本では、2003年に日本電気（NEC）が達成してから20社目に当たります。

従って、現在の関心ごとはソフトウェアテストを含む開発全体のプロセス改善に移っています。

CMMIでは、「見積もり」、「計画」、「監視と制御」、「リスクと機会の管理」、「原因分析と解決」、「決定分析と解決」、「構成管理」、「実績と測定の管理」、「要件と解決の管理」、「技術ソリューション」、「成果物統合」、「サービス提供管理」、「インシデントの解決と予防」、「供給者選定」、「供給者合意管理」、「検証と妥当性確認」、「ピアレビュー」といったさまざまな活動（プロセス）に対して、最も良いやり方を探し、それをみんながまねできるように「標準化」をします。そして、その標準化がうまくいっていることを「統計」を使って確認します。どこかの標準を持ってくるだけではうまくいきません。開発者、テスト担当者、部門長、お客様……全てを納得させ、品質を向上させるという同じ方向に向かわせる必要があります。

たまに、テスターやQAのキャリアアップのご相談を受けることがあるのですが、自分の技術力の幅を広げるためにCMMIのSEPG（Software Engineering Process Group）のメンバーになるというのはありじゃないかと思います。

以上、3回にわたりお届けした連載「HAYST法のこれまでとこれから」を終わります。お読みいただいて分かるとおり、私が何かを成し遂げたというよりも、ただただ周りの要求に対して取り組み続けただけに過ぎません。分からなければこの仕事をやめたいと言い、エキスパートを付けてもらったことは象徴的なエピソードです。

ですから、かっこいいことは一つもないけれど、だからこそどんな人にも進む勇気を与えられるといいなと、そんなふうに思っています。

困っていたら、「私は今、困っている」と言うといいですよ。