ソフトウェアテスト設計の品質を検算する方法（その②）
問題の在り処
その①の稿で示したのと同様、プログラマが間違えそうなところと、テスト設計者が見落としそうなところは重なっている可能性が高いことを問題であると考えています。
ソフトウェアテスト設計の品質を合理的な範囲で検算可能な場合があるので、本稿でもその方法の一つを示します。
前稿とは異なり、ここで示すものはソフトウェアテスト設計の範囲の中で、異なる二つの設計技法で設計されたものの間での検算になります。
こう説明すると、「結局設計にわざわざ２度手間をかけるということですね？」と思われてしまうかもしれませんが、そうではありません。
ここに示す二つのテスト設計技法は、目的が異なるものなので、検算のために２通りやるわけではなく、そもそも最初からそれぞれが必要があって設計されるべきものです。
ただ、どちらも「組み合わせのテスト数を減らしてくれる技法」であることは知っているが、どう使い分ければ良いのか知らないという人も多いです。
本稿は、テスト設計技法の目的の違いを理解する一助にもなると思います。
原因結果グラフ法によるテスト設計とHAYST法によるテスト設計との間の検算
下図に示しますように、ここでは有則組み合わせテストCEG-TとHAYST無則組み合わせテストHayst-Tを相互に比較することを考えます。
ここで有則組み合わせテストCEG-Tと呼んでいるものは、一般にディシジョンテーブルを活用して設計されるようなテストのことであると思って頂ければ良いです。
「有則」という言葉は聞き慣れない方が多いと思います。デシジョンテーブルにおけるような規則がある部分を指す表現だと思ってください。後で、規則がないと思われる部分を対象とする話が出てくるので、互いに対比するために有則、無則という表現を使用しています。
しかし、その同じ有則組み合わせ領域に対して、デシジョンテーブルではなく原因結果グラフ法を用いると、有則のそれぞれがロジックとして実装されるのか、アーキテクチャとして実装されるのか、区別すべきことに気付きます。テストも区別して設計する必要が出てきます。そのことは別稿に示しました。
ついでにですが、図に「有則(表と裏)のテスト」という表現が入っています。「表とか裏とか何だ？」と疑問を持たれたかもしれません。これもオーソライズされているような用語ではありません。
有則の中でロジックとして実装される部分のテストを表のテスト、アーキテクチャとして実装される部分のテストを裏のテストと呼んだ方がいまして、取り急ぎどちらかを指すのに便利な表現なので、ここで借用させて頂いております。
さて、もう片方の比較対象HAYST無則組み合わせテストHayst-Tは、HAYST法の考え方により設計された組み合わせテストとします。
HAYST法を無則の領域に対してテスト設計するものと理解されている方が時々いらっしゃるのですが、それは間違いです。HAYST法は有則か無則かを特に区別せずに組み合わせていくテスト設計技法です。（有則領域にこそ主な機能が存在するのが普通ですから、そこを排除してしまうなど、あり得ません。）
「無則組み合わせテストと自ら呼んでいるではないか！」と言われるかもしれませんが、そこで「無則」と言っているのは、組み合わせる際に、基本的姿勢として、そこにある規則に依存しないで組み合わせることを強調するためです。
有則領域と無則領域の境界線を正しく把握できていると確信できない、あるいは少し別の言い方をすれば、有則領域を間違いなく切り取れる自信が持てないので、有則か無則かを特に区別せずに組み合わせていきます。
よく、改変時に「影響範囲が確定できない」等と悩んでいる現場は多いですが、これも同じで、有則を完全に把握し切れていないということなので、やはり有則か無則かを特に区別せずに組み合わせていくことが一つの有効なやり方です。
無則組み合わせテスト技法は、大きく二通りの考え方があるようです。
・無則領域で組み合わせ設計しようとするもの
・HAYST法のように有則か無則かを特に区別せずに組み合わせていくもの
簡単な見分け方ですが、「組み合わせる因子の数は、せいぜい数十ぐらい」等と想定されていたり表現されていたりしたら、前者でしょう。
後者の場合、因子の数は100を超え、数百になることも普通ですので。
さて、目的の異なるテストですから、それぞれの設計が出てくるところまでは当然なのですが、この二つの設計情報を直接比較しようという話にすると、それはそれで手間がかかって大変です。
それに、目的が違うからと言って、有則(表と裏)のテスト設計と、HAYST法による無則組み合わせテスト設計を、完全に独立に行うのも非効率で現実的ではありません。
というのも、有則(表と裏)のテスト設計が済んでいれば、その情報をそのまま使ってHAYST法による無則組み合わせテスト設計は機械的にできてしまうからです。
というわけで、ここでは無理にそれぞれ別々に設計することを推奨したりはしません。
有則組み合わせテストCEG-Tの情報をそのまま流用してHAYST無則組み合わせテストHayst-Tを設計するのが合理的ですから、それを推奨します。
つまり、検算CEG-TtoHayst-Tは実際には行わないどころか、CEG-Tを一旦完全に信用してそのまま持ってくることを推奨している、ということになります。
検算Hayst-TtoCEG-Tも、期待値確認中やテスト実施で問題が発覚したものについてのみ行うという程度が現実的限界と判断しているということです。
有則テスト設計の品質を無則のテスト実施状況で検算できる
有則組み合わせテストCEG-Tは、左下図のグレーと紫で表した部分に対して設計することになります。境界線の空白部分の隙間(ヌケモレ)が無いのが理想です。
微に入り細を穿つようなテストが理想的なはずなのですが、四角な座敷を丸く掃くようなテストを設計しても、このテストだけやっている限りはそれが発覚し難いです。境界線に近付かない方が事故(仕様の誤認等の発覚)が起き難く、無難に見えて通り過ぎてしまい易いところが困ったところです。
下図では有則部分を一つずつのグレーと紫の丸で表しましたが、実際のテスト対象は有則部が複数あったり、その間に少し重なりがあったり、もっと複雑なことになっているのが普通です。
実際、デシジョンテーブル1枚では済まずに、複数枚作成しなければならないことがほとんどだと思います。
境界線の空白部分の隙間(ヌケモレ)はあちこちに広がっていることになってしまいます。
そこで今度はHAYST無則組み合わせテストHayst-Tを設計します。基本的に規則の有無を気にせずに組み合わせるので、右下図のように境界線のところに隙間ができるようなことはありません。
ただし、テスト対象から規則が無くなるわけではありませんから、規則とも整合するように、そして微に入り細を穿つ範囲で調整をします。(ここに様々なアルゴリズムが開発されたりしているのですが、本稿では主題から外れるのでそこは説明しません。)
規則と整合させるためには、その情報が必要ですが、それには有則テスト設計CEG-Tの情報を持ってくるのが良い、と推奨しました。CEG-Tの情報を持ってきてそのまま忠実にHAYST法的な考え方の無則テストHayst-Tを設計すれば、左上図に示したような白い境界線に対応する境界線が、右上図の方にも出てくることになります。
さて、ここでいよいよ無則テストHayst-Tの期待値を確認したり、現実にテストを実施すると、その過程で右上図の黄色い境界線のような結果が得られることがあり、テスト設計とズレていることが、つまりは欠陥があることが発覚することになります。
筆者はこれをもって、「有則組み合わせテストCEG-TとHAYST無則組み合わせテストHayst-Tを相互に検算した」と見做して良いのではないかと思うわけです。
無則テストで発見された禁則は有則テスト設計のバグである
上に示した表は、HAYST法の考案者の一人である秋山浩一氏が示した資料です。（左の吹き出しは筆者が追記したものです。）
無則組み合わせテストが成り立つようにするために、禁則を回避しなければならないことを説明しています。この資料自体は、その説明のためにわざわざ有則の情報を入れずにテストケースを生成したものです。
もし、ヌケモレなく正しい有則テストが設計され、それを持ってきて誤りなく入力できていれば禁則はモレなく回避されるはずです。
無則組み合わせ生成後に禁則が見つかれば、それは無則テスト設計のバグということだけではなく、有則のテスト設計としてもバグあったということになります。
もう少し詳しく、テスト設計と実際のズレの理由を見ていくと、以下の図のようなことが考えられます。
開発設計側と同様、テスト設計側にも境界線を巡る誤解、勘違い、思い込み、情報不足、スキル不足等の問題はあるはずです。バグも作り込んでいるはずですが、テスト設計の検証は行われないので、発覚して騒ぎになるような形にはならないで済んでいるということでしょう。
有則テストだけをしていると、これらのテスト設計の問題は、何れも見過ごされてしまう可能性が高いと言えるでしょう。
HAYST法が境界線をくっきりさせるわけ
ここで少しだけ、HAYST法の関係する部分について説明しておきます。HAYST法でいう組合せ網羅率とは、任意の2因子間の組合せの網羅率のことです。下に示した式で表されます。
HAYST法では組合せ網羅率８０％以上を目指します。（必ずしも１００％を目指しません。）
下図の、どの領域に入っている因子であっても、平等に、全因子の中から任意の２因子を取り出して、その双方の水準を組み合わせ、網羅率を上げていこうということです。（テスト対象が排除してしまっている組み合わせは除くしかありません。それを禁則組み合わせと呼びます。）
2因子間の網羅率を上げるに従って、上図の画像解像度が上がっていくかのように、境界線がくっきりしてくるイメージが湧いたでしょうか。
「網羅率８０％以上」というと、「なぜ、100％を目指さないのか？」との質問を受けることが良くあります。
もともと気にかけて見ていなかった境界線を見るようになり、それなりの解像度で見れば、見えなかったもの(未発見のバグ)が見えてきます。でも、そこそこ解像度が良くなったら、それ以上に解像度をどんどん上げても、あまりバグは見当たらなくなります。そういうことです。
それに、示しているのは網羅率であって、テスト数ではないことに注意してください。
網羅率とテスト数は比例関係にはありません。
「あと20％でしょう！」は網羅率のことで、そのためにテスト数は何倍にも膨れ上がるかもしれません。
もちろん、網羅率１００％が合理的なテスト数に収まるのであれば、それは望ましいことです。
形式手法、その適用範囲との境界線の検証法
ところで、さらに上の品質を目指したいので、「やはり形式手法しかない」と考えるケースもあるでしょう。
しかし、経済合理性やリスク管理の観点から、システム丸ごと形式手法の適用範囲とする、ということにはまずならないと思います。
そうすると、形式手法を適用するにしても、その範囲についてはどこかに境界を引き、クリティカルな部分を切り出すことになります。そして境界線をどこに引くのかの判断には、どこか恣意性が含まれてしまうことが避け難いと思います。
また、設計上の境界、実装上の境界、テスト設計上の境界、それらすべてに問題がなく、互いの整合がとれていると説明できるならば問題はないですが、これも現実には難しいでしょう。
そうすると、境界情報を前提としないHAYST法の無則組み合わせテストで境界線の確認を含めた検証をすることは、十分に合理的なのではないかと思います。
HAYST法による無則組み合わせテストの適正数は、通常必ず行われているであろう単機能テストの数とほとんど変わらないように設計できるはずです。
まとめ
(原因結果グラフ法による)有則組み合わせテストCEG-TとHAYST無則組み合わせテストHayst-Tとの間で、経済合理性のある範囲での(疑似)検算方法を示しました。
これにより、四角な座敷を丸く掃くようなテスト設計の問題を浮き彫りにすることができます。
問題が発覚するのはHAYST無則組み合わせテストHayst-Tのタイミングになるわけですが、そこで「やっぱり、HAYST法のテスト設計は難しいですね。」などと感想を述べるのではなく、検算で問題があることが明らかになった元の有則テストからやり直しを検討すべきである、と指摘しました。
HAYST法のバグ検出率が高い理由は、いくつかの説明の仕方が可能ですが、ここでは(有則テストの範囲に含めたり、形式手法を適用したりして特に品質を高めようとした部分とそうではない部分との間の)境界線との関係から説明しました。
この記事が気に入ったらサポートをしてみませんか？