秋山さんが語るHAYST法

２０１８年６月１３日（水）１９時に開催しましたJaSST'18 Tohoku復習会で使用した原稿をリライトしたものです。

JaSST'18 Tohokuの基調講演「HAYST法によるテスト設計の考え方」の秋山さんの講演内容をベースに書いています。ただし、僕というフィルターを通して書いていますので、言葉の選び方とか語尾の処理とかは異なっています。

また、秋山さんはツイッターで質問を受け付け、それに対する回答をされています。その内容も一部取り込んでいます。

目次

１．組み合わせテストとは何か？
２．有則のテストと無則のテスト
３．組み合わせテストを支える技術
４．HAYST法が取り扱うもの、取り扱わないもの
５．経営者のテストへの期待
６．悪魔のサイクルとHAYST法
７．HAYST法のプロセス
８．ワークをやる前に

まつさん（@mty_mno）提供の写真

■１．組み合わせテストとは何か？

組み合わせテストは３つの流れでやります。

１．組み合わせる条件を決定する
２．組み合わせ表を作成して、テストを実施する
３．テスト結果を分析する

１．組み合わせる条件を決定する
　何を組み合わせるかを決めます。たとえばブラウザですが、IE、Chrome をやると決めます。OSは、WindowsとiOSをやると決めます。

２．組み合わせ表を作成して、テストを実施する
　それぞれの条件を組み合わせて表を作り、その表の行にある組み合わせをテストします。ブラウザはIE、OSはWindows、端末はデスクトップPC・・・のような条件をテストします。

３．テスト結果を分析する
　組み合わせテストをやっている組織で、このテスト結果の分析をやっていないところもありますが、実は、テスト結果の分析が必要なんです。

テスト結果の分析が分かりにくいようなので、説明をします。

５番目のテストでfailしたとします。IE、iOS、タブレット、テスト対象のアプリのバージョンが2.0の組み合わせが失敗したとします。どこが原因なのか。何が原因でテストがfailするのか。今までpassしたテストを考慮にいれると、次のどれかが原因であることが分かりました。

IE × タブレット
iOS × タブレット
タブレット × 2.0
のどれかが原因です。

この例では、因子が少ないですから、総当りで原因を探れます。因子が増えますと、分析が大変になります。ですから、何らかの手法が必要になります。

■２．有則のテストと無則のテスト

組み合わせテストには２つあります。有則の組み合わせテストと無則の組み合わせテストです。

有則の組み合わせテスト

一つは仕様書に書いてあるものを組み合わせるものです。例えば、宿泊キャンセル料金のテストです。宿泊キャンセルの料金は、当日キャンセルの場合は宿泊料金１００％、前日キャンセルの場合は５０％とか決められています。このような仕様書に書かれている条件を組み合わせるテストがあります。

これは有則のテストといわれています。有則という言葉は、松尾谷さんが使い始めて、今では一般的になってきました。有則のテストは、機能のテストなので重要なテストです。

無則の組み合わせテスト

本日のテーマは、有則のテストではなく、仕様書に書いていない組み合わせのテスト、無則のテストです。

例えば、仕様書に用紙サイズと用紙の厚さの組み合わせについて書かれていません。
Ａ３で薄紙のテストをやったとき時間がかかりました。
Ａ３で普通紙だと、１０秒ででてくる。
Ａ３で薄紙のときだけ、１０分かかる。

このような具体的に何を組み合わせるかまでは、仕様書に書かれていません。いろいろな紙が使えるとは書いてありますが、組み合わせは書いていません。開発者に問い合わせたら『想定外です』と言います。けど、お客様は怒っていらっしゃる。テストでなんとかしたい。

このように仕様書に書かれていない組み合わせをテストするのが、無則のテストになります。

無則の組み合わせテストの前提条件

無則の組み合わせテストをするときには３つの前提条件があります。

１．仕様書がある
２．単機能のテスト、有則の組み合わせテストをやっておく
３．組み合わせテストの工数は単機能テストと同じ程度を用意する

１．仕様書がある

この条件は結構ハードルが高いです。仕様書が無い会社はあります。しかし、仕様書がなければ、期待結果が分かりませんから、何を合格としてよいのか分かりません。

そもそも仕様書を作らない会社の場合、組み合わせテストの前に済ませておかなければならない、単機能テストに問題があって、組み合わせテストに入れない、ということがあります。

２．単機能のテスト、有則の組み合わせテストをやっておく

無則の組み合わせテストでは、単機能のテストは一通り終わらせておくことが前提条件です。
単機能テストを十分にやっていない組織に対しては、「HAYST法の前にやってください」とお願いします。
HAYST法を教えるのが仕事なのですが、HAYST法はまだ早い、やっちゃダメって言うこともあります。
単機能のテストができていないのに、HAYST法をやってもね。開発者が単機能の品質に自信がないところで、組み合わせテストをやってもダメですよね。

３．組み合わせテストの工数は単機能テストと同じ程度を用意する

単機能テスト＆有則の組み合わせテストの工数を１週間とっているのであれば、無則の組み合わせテストも１週間とります。工数をイコールにします。

■３．組み合わせテストを支える技術

技術的には３つあって、年代ごとに研究者の興味が変わっていきました。

９０年代：組み合わせ表を作成する技術
９０年代頃は表を作ることに研究者はやっきになっていました。直交表やオールペアなどいろいろな表を作るロジックの研究が進んでいきました。

００年代：組み合わせ条件を見つける技術
２０００年代になって因子は何かという研究が進みました。本日は、この因子を見つける技術をマスターします。

１０年代：テストした結果を分析する技術
２０１０年代になってテスト結果を分析する技術の研究が行われています。テストをするとバグがでますが、どこが問題なのか分からない。無則の組み合わせテストでは、そういうことが起こり得ます。

因子が２０個なら１９０個の組み合わせパターンになります。とてもじゃないけれども、バグの原因がどこか分からない。どの因子が悪さをしているのか、テストを Pass した情報を使いながら探っていきます。私（秋山さん）は統計解析を使って分析をしています。

ログとかが残っていればいいんです。しかし、クラッシュをしたり、ハングアップしたりする。こうなると、どこが原因か分からなくなります。ですので、絞込みの技術が必要になります。

■４．HAYST法が取り扱うもの、取り扱わないもの

《取り扱うもの》
1.アジャイル
　　ユーザーストーリーごとに組合せテスト
　　ナラティブフローでユーザーストーリーを組み合わせたテスト
2.仕様書
　　仕様書が無ければテストしている場合ではない
　　➔　テスト設計時に考慮する範囲を限定（定義）できる
　　➔　仕様書が常に最新情報に更新されていて信用できる
　　➔　現行の仕様について、その是非（要求を果たすこと）を説明できる
3.ユニットテスト
　　プログラマがプログラミング中にテストを行う
　　➔　一番大切で数も多い
4.運用と保守
　　売った後のことを考える
　　➔　ライフエンド時でも目的を果たすことをテスト
5.非機能要件
　　機能を目的単位で取り扱うことで非機能のテストを同時に行う
　　➔　FV表

《取り扱わないもの》
1.商品企画
　　ビジネスの分析は取り扱わない
　　➔　企画品質はコンジョイント分析で評価
2.要求
　　ビジネス要求と業務要求は取り扱わない
　　➔　システム要求は【仕様書】と同じもの
　　➔　（曖昧か、具体的か、の違いのみ）
　　➔　「みんな持ってる」、「みんなって誰よ」←要求はあてにならない
3.ペルソナ
　　利用者を高々十数名想定しても、広大な市場条件はカバーできない
4.内部構造（設計）
　　効率化のため6W2Hでアーキテクチャ、FL表で境界値はコードで確認するが、それ以外はプログラマの自由裁量
　　（いつ変えても対応できるテストとする）
5.受け入れテスト
　　「業務に使えるか」を確認する作業であり業務シナリオテストを行う

取り扱うもの

１．アジャイル

皆さん、不思議に思われるかもしれませんが、HAYST法は普通にアジャイルを扱っています。アジャイルは普通にやっています。最近は、ユーザーストーリーマッピングを扱っています。

日本ではアジャイルをやるか、やらないかを、未だに議論しています。やってみて、失敗したところを改善すれば良いのにそこまで行き着いている組織が少ない。失敗の経験がないところがあります。

２．仕様書

仕様書は必要です。仕様書を書きなさいというと、最初から全部書かなくてはいけないと思ってしまいますが、そうではありません。
仕様書には、気になるところだけ書いてあればよいのです。それをベースに毎回少しずつ手を加える程度でもよいから書いてください。

仕様書が無いと何が正しいかわかりません。「仕様書」と言っても、最初から完璧なものを求めなくて良いです。
最初から完璧でなくてもいいから、書きたいものから書けば良いです。必要なところだけ書きます。仕様書を書いたほうが品質はよくなります。騙されたと思ってやってほしい。

３．ユニットテスト

皆さんは、実装の横に単機能テストというV字モデルをみたことがありませんか。私も昔の講演で、そのようなスライドを使っていました。ごめんなさい。あれは間違いです。

コーディングとユニットテストは一緒のフェーズになっています。同時に書いてもらうことで、品質が良くなったという経験があります。単機能のテストは開発者がすべきことです。

プログラマがテストを行います。テストケースを書きます。プログラマが自分で確認します。大切なのは覚えているうちにテストを書くということです。コーディングとユニットテストのテストケースは同時に書きます。TDDのように、テストを先に書かなくても良いです。

テストピラミッドというのがあります。ユニットテストが一番多い。まずはユニットテストをやります。自動テストができていることが前提です。

TestPyramid, Martin Fowler　より引用

４．運用と保守

この運用と保守に関しては、実行委員が作成した未来スライダーというアニメーションスライドをみてください。

５．非機能要件

非機能要件は、HAYST法で取り扱っています。機能の中に作りこめというのが、うちの会社の文化です。目的ごとに非機能が決まってきます。うまく分ければ、その単位で非機能を扱えるようになります。

取り扱わないもの

１．商品企画

商品企画ではHAYST法を使いません。みんなのやる気を起こさせるものが企画。これが実現したら、こんな良い世界があるなら、こういうもので意識を統一します。多人数の意思統一をはかるために企画を作ります。

うちの会社では、企画品質についてコンジョイント分析をやって、評価しています。HAYST法ではできないのか？　とよく聞かれますが、できませんと答えています。

２．要求

要求は相手にしません。要求は、ビジネスに対する要求、業務に対する要求。作るための要求があります。
作るための要求は、仕様だから扱います。

要求は過去にあがってきたものを扱います。「みんなが持ってる！」と言われても、みんなって誰？ってことになります。要求はあまり当てにならないものです。

３．ペルソナ

午後の演習で６Ｗ２Ｈを使ったワークをやりますが、このワークをやるとペルソナを書きたがる人がいます。
しかし、HAYST法では、ペルソナを扱いません。ペルソナをいくつ作るかというと、３つとか４つで。それでどれだけカバーできるのか。

ペルソナで十分な商品はあります。（ペルソナで十分な商品の説明）でも、複合機は誰が使うのか分かりません。そういう商品を扱っています。

４．内部構造

内部構造はラルフチャートで書きますが、扱いたくない。内部構造はいつでも変えていいという考えだからです。
よいアイデアがでたら、変更して良いといいたい。良くしていく、そういう気持ちは大切にしたい。だから、内部構造は取り扱いません。外部仕様に対する自動テストがあって、それがパスすることが必要です。

５．受入テスト

受入テストの業務が通るどうかはシナリオを用いたテストでよくて、わざわざ組み合わせテストでは無いだろうと思っています。

５．経営者のテストへの期待

縦軸が品質・信頼性、横軸が評価コスト、お金をどれだけかけたかになります。

赤い線は普通の現場の姿です。S字曲線になっていて、最初のうちはコストをかけても品質は上がらず、中ぐらいから品質が上がり始め、後半は品質が上がらない。お金をかけても品質があがらないようになっていく。

昔の携帯のように、５００名体制から１０００名体制にしたからといって、上がる品質は期待通りではありません。

青い線にしたい。コストをかけたらその分だけ品質が上がるようにしたい。そのためには技術力を向上するしかありません。今日のHAYST法もそうかもしれません。

６．悪魔のサイクルとHAYST法

ソフトウェア開発には５つの悪があります。これは因果ループ図を描いています。

①大規模・複雑化するから、②変化を予測できない、③ソースコードを読まなくなる　ということがあって、④テスト戦略とかテストアーキテクチャとかを考えなくなる、そうすると⑤個人や組織のノウハウが残らなくなってしまいます。負のループが強化されます。

HAYST法は５つの悪を一つひとつに対して対応しています。

①大規模だからテストできない。
→　6W2Hで全体を把握し、FV表で小さくしてしまう。

②変化を予測しない、想定できない
→　3Wで保証範囲のキワを狙っていく。

③ソースコードを読まない
→　ラルフチャートでソースコードの肝を抜き出す。
必要なものだけを抜き出して、別の図にする。

④テスト戦略
→　テスト戦略はD-Caseを使って、合意を取る。

⑤個人の属人性
→　FL 表でノウハウを残す。

７．HAYST法のプロセス

HAYST法のプロセスは次のとおりです。

１．テスト戦略
２．テスト要求分析
３．テスト設計
４．テスト実装
５．テスト実施
６．テスト結果分析

プロセスを作る目的は「未来の抽象的な目的」（十分な品質を提供するなど）を「現在の具体的な目標と行動」に変換していくために「目的を分解・具体化」し、「ステップをイメージ」し、『外部へ組織の成果をもって貢献する』意識を常に持って活動するためです。

上に示しているように、テストというのは、最終的には人類平和のため、世界平和のために行っています。しかし、今日やる活動がどのようにするか結びつきません。今、何をしたらよいのか、何に集中したらよいのかをプロセスは作っています。

ウォーターフォールのように見えますが、行きつ戻りつはＯＫです。テスト戦略はマネージャが決めること。テスト要求分析とテスト設計はアナリストがやります。

今日のワークは、黄色の6W2H、FV表、ラルフチャート、FL表をワークの対象とします。

８．ワークをやる前に

6W2H
目的
・テスト対象の理解
・テストに対する要求の理解

《方法》
　　視座
　　　　・開発者
　　　　・ユーザー
　　　　・お客様のお客様

　　視野
　　　　・開発者　　　　：Why、What、How To
　　　　・ユーザー　　　：When、Where、Who
　　　　・お客様のお客様：Whom、How Much

　　樹形図、木構造で分解する

《どこまでやるか》
・因子レベル（気にしない）
・最長で半日
・レビューは必須

（投影されたスライドを見ながら）実物の6W2Hをお見せします。インターネットにある時計のマニュアルから作りました。

《Whom》
Whom はお客様のお客様。価値を決めるものです。誰のためのものか。講演台の上に時計を置いていますけど、これは時間を守るためです。では時間を守るのは誰のためでしょうか。受講生や実行委員のためかもしれません。利益を得る人のことを考えましょう。

《How Much》
売上から品質コストが導き出せ、評価コストを求めることができます。売る販売数と価格が分かれば売上高が分かります。
4%をかけると品質コストが分かります。どのくらい品質にコストをかければよいのかが分かるので、テストにどのくらいかえればよいのかも分かります。

例えば、5万円の商品が1万個売れるとなりますと、売り上げは5億円になります。品質コストを4%としますと、2千万円になり、その半分がテストで使えるとなると、評価コストは1千万円になります。

何もやってない企業は20%ぐらい、やっている企業は4%と言っていたりします。4%という数字はクロスビーに書いてあった数字です。

ただし、この割合に従うのではなく、自分の組織に合わせて割合を決めて欲しい。各社で決めてもらえばよい数字です。どの値が適切かよりも、品質コストを計測し徐々に良くしていくことが大切です。

《What》
Whatは一番大きい枝になります。何を作るのかを分解します。仕様書の書き写しで構いません。なぜ書き写すのか、後でこんな機能があったのかという事態にならないようにです。

昔、プリンタのテストをやっていた頃の話ですが、UNIXからプリントできないというクレームをもらったんです。私はUNIXからのプリント出力はテストしていませんでした。そういうことが無いように書きます。

時計の話に戻しますと、ソーラー充電の仕様をいろいろ書いてありますが、パワーセーブのところをみてください。
電波受信停止というのがあります。時計の場合、正確さも大切ですが、何より動くことが大切です。数秒遅れることよりも、秒針が止まるほうが大変です。そのため、電波を受信しなくなるという機能があるんですね。

《How To》
How Toはグレーボックステストために使います。内部の作りを知っていますとテストを減らすことができます。

3W

今回のワークでは、6W2H のうち、When、Where、Who の 3W を作ってもらいます。3W がないとFV表が作れないから。3W を作る目的は、テスト対象を分割して、FV表を作るためです。

ユーザーのコンテキストを When × Where × Who で作ります。3W の価値は、どのようなユーザーがどのような使い方をするのかが分かることです。いつ、どこで、だれが、が分かります。勝手に考えたコンテキストでは、市場環境は複雑ですから、いくらやってもダメです。

昔ATTでは、23の部屋というのがあったそうです。この部屋を全部通らないと出しちゃだめというもの。1ヶ月もたたないうちにいくつもクレームがきたと。田口先生がこんなのはダメだと仰っていました。

標準を一つ、異常を二つ書きます。異常は予測される保証範囲のキワを狙います。極端な条件でうまくいけば、ゆるい条件なら当然うまくいくからです。

保証範囲のキワの例を示します。私の持っている時計は、生活防水がついています。土砂降りで大丈夫なら小雨も大丈夫でしょう。それなら土砂降りでテストすればよいですね。でも、生活防水ですから水泳は保証範囲外になります。保証しているぎりぎりのところをテストします。水泳のテストはしないけど、土砂降りのテストはやります。

なんのためにある機能かとことん考えます。それが大切。パワーセーブは何のためにあるのか。電波受信を止めるのは何のためなのか。時刻表示を止めないためです。

今の複合機は深夜に使われることはあまりありません。使う場合もオフィスが中心です。使う人は主に会社員です。主婦は使っていません。

これからの複合機はクラウドに接続しますし、世界中の人が使います。誰もが使います。時間はいつでも、場所は地球上のどこでも、人は様々になります。そうなりますと、今までの因子水準とは変わるわけです。

直交表を活用してコンテキストを作っています。

標準は、昼間、オフィス、会社員ですが、キワとして深夜、外出先、主婦というのもあるでしょう。このように因子水準で、一般のものと、キワのものを書いておきます。

3W で昼間、外出先、主婦というコンテキストがあったとき、ユーザーストーリーはどうなるかと言いますと、「主婦の役割として、会社の重要書類を夫に届けることを達成したい、家に置き忘れて出社したからだ」になります。

ユーザーストーリーを書いてあげると、どんなテストをしたらよいのかが考えられます。

スライドに映していますこの図にある赤い丸ですが、これは単機能のテストで確認されているところを表しています。大きいな四角は、使われ方を表しています。この使われ方、直交表で決まったものが四角の大きさになります。
（赤丸は開発環境、四角形は市場環境の保証範囲）

6W2H には開発の視座と顧客の視座があります。開発の視座には、要求、仕様、設計が、顧客の視座には、何時、何処、ユーザがあります。

Whom と How Much は誰が喜ぶのかを明らかにします。
3W は保証するコンテキストになります。

ユーザーストーリー

ユーザーストーリーを作成するヒント

《When》
周期（年・季節（四半期）・月・週・日・時・分・秒）
順番（インストール直後、操作順番）
タイミング（充電切れ、動き始め、ネット切断＆再接続）

《Where》
天候環境（雨、風、気温、気圧）
国（日本、米国、中国、航海中、国際線の中、宇宙）
抽象的な場所（移動中、狭い、広い、劣悪環境、屋内、屋外）

《Who》
性別・年齢、知見の有無（男、女、子供、大人、老人、初心者、熟練者）
身体障害の有無（色覚、聴覚、手足、脳）
コンピュータ（AI、遠方からのVR，他のシステム、同時使用）

FV表

大きいテストは作れないので小さくするためにFV表を使います。FV表の＜F＞でゴールを規定します。規定したゴールをどのような条件でテストするのかを考えます。V列で考えます。V列を書きながら、6W2H の What のノードを消し混みます。What の枝にあるすべてのノードが消し込めたら完了になります。

FV表の作成方法は次の通りです。

1.仕様書をアプリケーションを目的機能で分割し、Fr列に目的機能を文章で記述する
2.No.列には該当機能が記載されている箇所を着さする←仕様書の網羅を担保するため
3.目的機能を果たす条件（因子）をV列に記載する（因子はゴールを満たす条件）
※因子はラルフチャートで出し尽くすのでここでは重要なもののみでよい
4.V列に記載した条件を確認する方法（テスト技法、テストタイプなど）をT列に記載する。確認方法＝テストによるエビデンスの取得方法

FV表を作成してから、因子を見つけます。なぜFV表が因子の発見に効果的なのかは、「ゴールを果たす」は曖昧なので、「これこれの条件（因子）で目的を達成する動きをする」に言い換えているからです。

また、ユーザー要求を超えて、システムが果たすべき目的にまで考えが及ぶことでブレイクスルーができます。（要求と仕様は曖昧化具体的かが違うだけで、同じもの。どちらも過去を起点とする）

目的機能とユーザーストーリー

・仕様書の「機能」で整理することの問題点
　　・「正しく動作」しているかの確認しかできない
　　　　・仕様書には「機能」の働きしか書いていない
　　　　・コンテキスト（使用の文脈）の理解が重要
　　　　・仕様書に暗黙の仕様（前バージョン仕様、開発者の常識）は書かれない。
　　　　・本来は「正しい動作」をしているかの確認がテストの目的

　　・要素還元的な見方しかできない
　　　　・分解した小さな機能がすべて動けば全体が問題なく動くと思ってしまう。

・「機能」から導き出した「目的機能」で整理する意義
　　・必ずユーザの使用目的や市場条件を考えることになる（動的）
　　　　・＜利用者の役割＞として、＜ゴール＞を達成したい。＜理由＞のためだ

　　・非機能要件のテストが楽になる
　　　　・目的機能単位に非機能要件のメトリクスを計測する
　　　　・性能、信頼性、セキュリティ要件は目的ごとに異なる

　「正しく動作する」　　＝　検証（verification）
　「正しい動作をする」　＝　妥当性確認（validation）

ユーザーに直接接点を持つ目的機能はユーザーストーリーで表現できます。
ログや保守の機能などはユーザーストーリーでは表しにくい
（そのような場合は、直接、目的機能を書く）

ラルフチャート

複雑な目的機能から因子を探すために、ラルフチャートを持ちます。ラルフチャートを使うことで、因子が見つかります。
・信号因子：入力
・誤差因子：ノイズ
・状態因子：状態変数

IE11の例にとると
・信号因子：画面上のメニューなどのアイテム
・誤差因子：負荷やクラッキング
・状態因子：DBのレコード

入力はユーザーの意思です。そのときに入れるものを挙げます。事前に設定するものではありません。事前に設定する場合は状態に入れます。サーバーに入っているものは状態になります。ある結果を得たいときに入力するものが入力です。

出力は求める結果とエラーの結果になります。

ノイズは意地悪条件。

アクティブノイズは、データを盗み取ろうなどの人の犯罪行為のことです。悪意ある行為です。

ラルフチャートを描けば、FV表のT欄（テスト技法）を埋めていけます。書けます。ラルフチャートを描けば、一応テスト技法は出てきます。ちゃんと描かないと出てこないですが。

ラルフチャートとテスト技法

入力がないところは入力が「－」になっています

FL表

FL表を作成する作業は、因子水準の確定作業になります。一番左をデフォルトにします。

それぞれの水準に対して、意図を残します。意図を残さないと、どんどんテストが増えていきます。OS が増えていくと、それに合わせて水準が増えます。本当にそれでよいのか、という話です。

やったテストを減らせないという組織があります。「削ったテストのところで本番障害が発生したら、僕の首が飛びます」という話を聞きました。

なぜ削れないのでしょうか。これはテストの意図が残っていないからです。例えば、OS のバリエーションをテストするとして、VISTA、Windows 7、Windows10とテストしていて、新しいOSが出たら追加するのか、という話です。

まあ、Windows10は常に最新で新しいOSは出ませんので、この例は適切でないのかもしれませんが、言いたいことは伝わると思います。ここで、次のような意図が書かれていたらどうでしょうか。

・Windows10 が最新
・VISTAは癖が多い
・Windows７は一番使われているもの

このように意図が書かれていれば、将来OSが増えたときも、別に増やさなくてもよくなります。何でその水準を選んだかが書いてあるからです。

FV表にて、HAYST法などの組み合わせテスト技法を使用すると決めた項目について、入力にあたる因子・水準を整理します。水準１はデフォルト値として異常値は入れません。

メモはここまで。
━━━━━━━━━━━━━━━━━━━━