組み合わせ爆発

これまでに、2024 アドベントカレンダーの中で、エンティティや
テストコンディションなど、組み合わせテストを作るのに必要な基本をご紹介しました。
https://qiita.com/advent-calendar/2024/hanamaruqa

こうした、テンプレート化しやすい資料ができたところで、よくあるのは、
「これで組み合わせテストを正直に作ったら、大変なことになる」
という課題です。

削減するには

テストケースのボリュームを減らすのは、増やすよりはるかに難易度が高いです。
テストを減らすということは、不具合が流出してしまうリスクが上がるからです。

かといって、無限にテストを続けるわけにはいきません。
ですので、リスクベーステストなどの手法が考案されています。

テストケースを削減する場合、どのテストを割愛するかの線引きが必要です。
テストの作り方で、これをコントロールすることが、一定可能ですが、
リリースクライテリア（リリース時の品質基準）については、
経営方針、顧客、リソースなどが指標になります。
これらの指標を見つけるには、普段からの、カスタマーサクセスや、
ビジネスサイドの情報が必要になります。

削減手法

削減手法にはいくつかありますが、ここでは組み合わせテストを紹介します。

直交表

直交表は、あらかじめ、組み合わせの出現が保証されたテンプレートを使って
多因子・他水準の組み合わせでの品質を保証する手法です。
一度テンプレートを作ってしまえば、適用は意外と簡単です。
このときの、因子水準の選び方が、一つの削減ポイントと言えるでしょう。

AllPair

オールペア法（ペアワイズ）とは、２因子間の値の組み合わせを
着実に網羅するテストを効率的に作成する手法です。
テスト作成には、便利なツールが出ています。

抽象化

抽象化は、先に基本となるテストをしっかり行ったうえで、優先度付けを行い、
因子を代表する水準を選ぶことです。

またテストパスをしっかり網羅するという意味で、水準をずらしながら
テストを組む方法もあります。直交表ではしっかりとした組み合わせが保証されますが、
これは、コントロールした範囲でテストパスの網羅性を高めるやり方になり、
削減の効果は高いですが、もちろん網羅性は下がるので、必要に応じた見極めが
ポイントになるでしょう。

Web製品のテストでは、組み合わせの複雑なところから不具合が出やすい傾向があるので、
抽象化と探索的テスト、不具合分析を絡めた手法で、効率よくバグを見つける
努力をすることがあります。

リスクの探し方

リスクの定義には、前提に、経営方針やビジネス事由などがあるのは前述しましたが、
ヒト・モノ・カネ・時間など、製品の要件にしたがって変わりますので、
自分たちに必要な品質の定義を行い、運用していきます。

不具合分析から

普段の不具合をBTSから抽出し、傾向を調べることで、バグの出がちな
条件や操作を見つけることができるでしょう。
そうした要素はテストから外さないようにするなどして、効率化を図ります。
また、パレート分析を行って、これを数値化する手法もあります。

リスクベーステスト

リスクベーステスト（一度、JSTQBのなかでも読み方が変わっていますね）
についても、テスト工数削減のテクニックの一つと言えます。
リスクのある個所を重点的に行う進め方になります。

人・カネ・物・時間、など、製品を使うステークホルダー
（ユーザー・ビジネスユーザー・運営など）にとって、リスクになることを
関係者に共有し、そこを担保することを優先して保証するやり方です。
また、風評被害などについても考慮します。

ユースケースから

実際のユーザーが行う操作の主要なものから保証を行うやり方もあります。
この場合、エッジケースが間引かれる恐れがあるので、そこを組み合わせテスト他、
各種テスト技法を使って、どうやって保証していくかの戦略が必要になります。

テストパスで間引く

いわゆる、C0、C1のような、コードレベルでのテストカバレッジもありますが、
単純にそれだけだとビジネスに必要な個所が網羅されているかの保証が
判断できない側面もあります。

ここでいうテストパスというのは、一定保証された基本テストで必要な操作を抽象化して、
そこのバリデーションを網羅保証していく組み方になります。

例えば、ログインの機能は十分保証されたので、ここは正常系を使って、
そのあとの操作をテストする、といった具合です（抽象化を行っている）。

あるいは、ログイン不正が一度起こった場合に、その後どうなるか、という組み方を
することもあります（ログイン不正という抽象化を行っている）。

こうして、テストパスを操作単位で、部分網羅→抽象化→操作組み合わせ、として、
必要な網羅性を高めつつ、保証の範囲を広げていきます。

テスト戦略の中で網羅性を高めるには

こちらはリグレッションを流す手法ですが、設定条件の組み合わせリストを
あらかじめ用意しておき、リグレッションで少しずつ消化して、テストの網羅性を
担保し続ける、網羅範囲を固定にしない手法です。
このテスト条件の組み合わせには、直交表を使うなどして、
テストパス・テストコンディションを一度に保証することを意識します。

最後に

ざっと表面的な内容を記述してみましたが、それぞれのテスト技法や、
テスト戦略について、深い知識をもって組み立てる必要があるので、
テストの醍醐味のような、面白さがある部分でもあるかと思います。

まだまだ紹介しきれていない方法もあるので、興味があれば、ぜひ調べてみてください。

用語解説

BTS

バグ・トラッキング・システムの略で、Jira や Redmine などがそれにあたります。

パレート分析

QC七つ道具の一つである、パレート図を使って、不具合の傾向を調べる指標です。
分類を作るのには、一定の経験が必要になるでしょう。
傾向を数値化するのに便利です。
https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E5%88%86%E6%9E%90