ビジネス

【連載】HAYST法のこれまでとこれから:「HAYST法」誕生前夜(第1回)

【連載】HAYST法のこれまでとこれから:「HAYST法」誕生前夜(第1回)

皆さん、こんにちは。秋山浩一です。

これまでQA(Quality Assurance)・テスト業界にあまり縁がなかった方は、どうも初めまして。逆にこの業界に長らく籍を置く方であれば、私のことをご存じかもしれません。「HAYST法」というテスト技法の生みの親と言われています。

まずは簡単に経歴を紹介しましょう。1985年に大手事務機メーカーに就職し、SEのバックヤードやソフトウェア開発を担当。1996年にはソフトウェアテストの部署へと異動しました。その会社で36年間働いた後、現在は150人程度の中堅SIerでCMMI(Capability Maturity Model Integration:能力成熟度モデル統合)のSEPG(Software Engineering Process Group)の一員としてプロセス改善の仕事をしています。

社外活動としては、NPO法人「ASTER」が運営しているJaSSTやJSTQBの立ち上げ、一般財団法人 日本科学技術連盟による運営のSQiP研究会にてテスト分科会の主査などをしてきました。また、「ソフトウェアテスト技法ドリル」(日科技連出版社)という本を書いています。

さて、この連載では、2000年辺りにまとめた「HAYST法」の話をします。といっても、直交表の仕組みや禁則回避方法の詳しい説明といった技術的な内容は書籍等(※1)に譲り、ここでは、HAYST法が生まれた背景や、その時にどんな課題に直面し、何を考え、実行に移したのかといったエピソードを中心に書きたいと思います。ぴったりとシチュエーションが重なる人はいないかもしれませんが、そういうプロジェクトの実例のほうが読者の参考になるのではと考えました。もしも、何か別の記事を読みたいという場合は「HQW!」編集部に連絡いただければ、前向きにご要望にお応えします(笑)。

では、ストーリーを始めましょう。

(※1)HAYST法に関する書籍は、『ソフトウェアテストHAYST法入門』(日科技連出版社、2007)と『事例とツールで学ぶHAYST法』(日科技連出版社、2014)があります。ウェブでは、JaSST'18 Tohokuの資料が詳しく分かりやすいです。

プリンターテストの自動化に挑むが……

1996年11月のこと。新しくできたソフトウェアテストの専門部署(第三者検証組織)に異動した私は、上長から「製品テスト業務に加えてソフトウェアテストのやり方を根本から見直してください」と言われました。34歳になったばかりの私は、5人くらいのチームのリーダーを任されました。

この会社はプリンターを販売していたので、さまざまなアプリケーションから正しくプリントできるかどうかを確認することがソフトウェアテスト部門のミッションでした。簡単に言えば、たくさんの文書をプリントしてプリンターのバグを見つける仕事です。

多くのテスターさんが朝から晩までずっとプリントしてはプリント結果をチェックしています。同じ文書をWindowsとMacintoshのそれぞれで確認します。会社独自のプリンタードライバーとAdobe社のPostScriptプリンタードライバーでも確認します。大変な労力でテストしていました。いわゆる人海戦術というやつです。

「プリントする操作を自動化して、プリント結果をスキャナーで読み込み、PCに表示している画面と自動的に比較したらよいのでは?」

そう思った私は、初めに、市販の自動化ツール(WinRunner)を使って印刷操作を自動化する「Auto Printing Tool(APT)」を開発しました。

次に、印刷直前のイメージをプリンターから取り出し、フェイクの超高解像度を持つ画面用のドライバーを作り、PC上に表示されているイメージと自動比較する「Auto Checking Tool(ACT)」を開発しました。ACTを開発するときには、全てのドットがぴったり合うとは思っていなかったので、ファジーに一致するかどうかを判定する機能を入れました。

割と自信を持っていた、これらのツールは大失敗に終わりました。

印刷の操作を自動化するといっても、アプリケーションを開いてからの作業が文書ごとに違っていました。また、画像の比較については、例えば「きれいなグラデーションになるか」といったプリンターの特性に合わせたイメージの官能評価(グラデーションが滑らかではなく段々が見えるとか、モアレが見えるといった、見る人が見れば一瞬で分かる不具合)に一切役立ちませんでした。官能評価のためには、ソフトウェアが作成したデジタルな画像データを実際のプリンターや用紙が持つハードウェアの物理的な特性に合わせ込んだ結果を評価する必要があるためです。

しかも、当時はオフショアが流行っていたため、ツールによる自動化の競合は「より優秀な自動化技術」ではなく、「安価なオフショアによる労働力」に変わりました。 結局、「やっぱり人間を教育して、人間が判断したほうが良いテストになるよね」という意見には、自動テストを推進していた私も首肯しました。

自動化に関しては、市販製品の問題点を克服したツールを自作しました(結果は「JaSST 2003」で発表)。その後、何年も使われ続けたので失敗のまま終わらずに良かったのですが、画像比較のほうは、プリンタードライバーのリグレッションテストでしか役に立ちませんでした。つまり、新旧のドライバーからプリント指示した画像をプリンターから抜き出して新旧比較する、いわゆる”現新比較テスト”でしか役立ちませんでした。

そんな頃、上長から「米国のテスト方法を学んできたら?」と言われました。そこでちょっと調べに行き、帰国後、真似っこして原因結果グラフからデシジョンテーブルを作るツールを作ったのですが、皆に「原因結果グラフ自体を作るのが難しくて無理」と言われ、効果は一部にとどまりました。

このときに得た知識は後にCEGTest(※2)を加瀬さんが作る際のアドバイスに役に立ったため、無駄にはなりませんでした。ただし、当時の社内では何の成果も生みませんでした。たとえ、優れたテスト技術であっても、多大なトレーニングが必要なものは現場には受け入れられにくいことを学びました。

(※2)CEGTestとは、原因結果グラフからテスト条件を作成するツールで、無料で利用できるウェブアプリのことです。

営業からの一本の電話

そんな失敗続きの中のこと。1998年の暮れも押し迫ってきた12月27日の朝、営業から一本の電話がかかってきました。

「秋山さん、お客様が困っているので助けて」

話を聞くと、お客様がパワポ(MicrosoftのPowerPoint)で作った8ページのスライドをハガキ1枚にまとめてプリントしようとしたけど、プリントできない状況でカンカンだとか。営業は「これから謝罪に行くので同行してもらえませんか?」と言います。

興味があったので、お昼に待ち合わせて、ご飯を食べながら情報交換し、午後1時にお客様先に到着しました。ご迷惑をおかけしたことについて謝罪したところ、お客様も冷静になってくださいました。

状況を確認したところ、パワポで作ったA4サイズのスライドを8枚並べ(8面付けにして)、はがきサイズに縮小してプリントすると、エラーになることが分かりました。

ただ、ラッキーなことに、客先には「DocuWorks」というさまざまなアプリケーションのドキュメントを紙のように扱うことができるソフトウェアが入っていました。それを使ってDocuWorks上に、8面付けにしたA4サイズの1ページ物の文書を作って、それをA4からハガキに縮小印刷することで事なきを得ました。

プリントアウトされたハガキを見ると、それは年賀状でした。つまり、お客様は4コマ漫画を2本、パワポで1コマずつページを分けて作っていて、それを年賀状にプリントしたかったのでした。最初に怒っていたのは、27日中に出さないと元旦に間に合わないからでした。

「なるほど。確かに、そういう使い方あるよなあ。年が明けたら開発に相談しよう」と思い、お客様先を後にしました。

「そんな使い方は想定外です」

年が明けて開発者に事の顛末を話したところ、「A4サイズの用紙を8面付けして、それをさらにハガキに縮小するなんて、そんな使い方は【想定外】です」と言われました。実のところ、われわれテスト部門も、そのような使い方を想定できなかったので、テストをしていなかった負い目もありました。

さらに、その開発者は言葉を重ねて、「もしも、そういう想定外の組合わせのバグを見つけるために全組合わせテストをしたら、いったいどれほどのテストが必要だと思っているんです?」とも言われました。

確かに、原稿の用紙サイズは20種類あります。ということは、出力先の用紙サイズも20種類あります。さらに、用紙の方向は縦横2通り、面付は5種類と、これだけでも全組合わせは、20×20×2×5=4000通りです。このほかにも余白、カラーモード、画質……組合わせが可能なパラメータは50を超えています。「全組合わせをテストすることは(現実的には)不可能」という開発者の言葉は正しいものでした。

ところが、当時、他でも似たようなことがありました。「【想定外】の使い方です」と言われて根本的な問題に対する再発防止が取られていないケースが社内で散見されたのです。

実験計画法を学ぶ

私はそのようなバグを1年分集めて調べました。そして「組合わせに起因するバグが流出している。しかも増加傾向にある」という結論を得て、部門長に話しました。

Hセンター長は「ハードウェアの世界には『実験計画法』という組合わせ効果を効率よく調べる方法がある。これを使ってみたら?」と言いました。

「え? 実験計画法ってなんですか? 初耳なのですが」

「いや。実は俺も学生の頃に授業で習った程度で詳しくないんだ。まずは勉強してごらん」

本を何冊か買って読んではみたものの、「こんな小さな組合わせ表では使い物にならない」というのが私の結論でした。その結果を、今度はHセンター長の上司のT統括部長にぶつけてみました。

「ちょっと無理っぽいです」

「そうか。それなら、よっちゃんを紹介してやるから相談するといい」

よっちゃんとは、吉澤正孝氏のことで、社内のみならず、日本で有数の実験計画法、品質管理、品質工学の有識者だったのです。

その翌週のこと、吉澤さんがやってきました。一通りの経緯を説明すると、

「簡単ですよ」

と言います。

「米国のATTでL64直交表を使用して30個くらいの機能を組み合わせたソフトウェアのテストを指導したことがあるから、その方法を使えばうまくいく」というのです。

「それを教えてください」

「いいよ」

とこんな感じで、HAYST法は、誕生に向けて初めの一歩を踏み出しました。

次回は、実験計画法がHAYST法になるまでの苦労話をお伝えします。

SNSシェア

この記事は面白かったですか?

今後の改善の参考にさせていただきます!

Ranking

ランキング

もっと見る