テストケースを効率的に削減するために「Pair-wise(オールペア法)」や「直交表」をなんとなく使っていませんか?実は、条件の組み合わせ方によっては、絶対に削ってはいけない重要なケースを漏らしてしまう危険があります。
今回は、クラシフィケーションツリー法の続編として、テスト設計において極めて重要な概念である「無則(むそく)」と「有則(ゆうそく)」の違いを解説します。コーヒーショップの割引条件を例に、なぜその技法を選んだのか、その根拠をロジカルに説明できるようになるための知識をお届けします。
📌 今回のエピソードのポイント
- 「無則」と「有則」の定義と、テスト設計に与える影響
- Pair-wise法で「期待結果のバグ」を見逃してしまうメカニズム
- 条件が独立している場合と、掛け合わせで結果が変わる場合の技法の適正
- ベテランでも陥りがちな「テスト削減」の盲点
- 質問コーナー:小規模案件でもテスト技法を検討すべき理由
🕒 チャプター
- () オープニング
- () コーヒーショップの例題:複雑な割引条件を整理する
- () Pair-wise法でテストを剪定してみる
- () 期待結果の検証:削減によって失われた「450円」のケース
- () 「無則」な関係:各条件に影響がない場合の削減手法
- () 「有則」な関係:組み合わせが重要な場合の削減手法
- () 無則・有則と各手法の適性まとめ
- () 質問コーナー:テスト技法を使うかどうかの判断に迷うときは?
- () エンディング
📢 あなたのご意見をお聞かせください
皆さんはテストケースを削減した結果、大事な組み合わせを漏らしてしまった経験はありますか?また、「ここは技法を使うまでもない」と判断する基準は何でしょうか?ぜひ感想を聞かせてください。
X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。
フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
感想
まだ感想はありません。最初の1件を書きましょう!
サマリー
今回のエピソードでは、テストケース削減手法であるPair-wise法や直交表を用いる際の注意点として、「無則」と「有則」の概念を解説します。「無則」は条件間に影響がない場合で、Pair-wise法などが有効ですが、「有則」は条件の組み合わせによって結果が変わるため、これらの手法では重要なケースを漏らす危険性があります。有則の場合は、ディシジョンテーブルの簡略化などが推奨されます。ベテランでも陥りやすいこの落とし穴を避け、適切なテスト技法を選択するための知識を提供します。
オープニングとテストケース削減の重要性
皆さん、こんにちは。B-Testingのブロッコリー です。このB-Testing.fmは、QAエンジニア
である私、ブロッコリーは、テスト や品質に対する私なりの考えを
約10分間で語っていくPodcast番組 です。今回は、無則とか有則っていう
話をするんですけれども、前回の 網羅基準の続きにあたるんですが、
無則・有則とかを知らないと、テストケース を削減するっていうときに、本当は
削っちゃいけないのに削ってしまう っていうことが結構発生しうるん
ですね。これを意識していないがために やっちゃいけないことをやっちゃ
っているみたいなのを、新人エンジニア としてはやっちゃいけないことを
経験が少ない人だけではなくて、 結構ベテランの方でも意外と簡単に
はまっちゃうところだと思いますし、 それだけじゃなくて、最近のでいう
とAIとかでも、もしかしたらうまく いかないんじゃないかなっていう
ようなことが結構あります。ということで 今回もB-Testing.fmスタートです。
コーヒーショップの割引条件とClassification Tree
ということで、今日は無則・有則 とテストケース削減の方法について
しゃべっていきます。1つ、今回も Classification Treeの続きということで、
前回まで使っていたのとはちょっと 違うお題。同じコーヒーショップ
でちょっとややこしいんですけれども、 コーヒーショップのここに書いてある
ような仕様をClassification Treeで 考えとくっていうところを元ネタ
としてテストケースの削減ということ を考えていきます。今回のお題は、
とあるコーヒーショップではコーヒー が500円で売られていますと。本日
2回目以降のコーヒー購入で、かつ 一緒にクロワッサンを購入すると
会員の場合はコーヒーが50円引き になりますと。このときにコーヒー
の価格に関するテストをしたいって いったときにどうすればいいか。
これをClassification Treeでまず書いて 解いていきます。そうするとどう
なるかっていうと、コーヒーを何回 目の購入かっていう話と、クロワッサン
を一緒に購入するかという話と、 会員かどうかっていう話が3つ要素
として出てくると思います。そうすると このスライドで示したように、
コーヒーの価格はっていうのに対して 購入回数、クロワッサン購入会員
かどうかっていうClassification 3つ 書いて、購入回数であれば1回目
なのか2回目以降なのかっていう クラス要素が出てきて、クロワッサン
購入はありなし、会員かどうかは 会員もしくは非会員っていうような
クラスが出てくるかなと思います。 これを前々回話したやり方で
Classification 3テストとしてテストケース を書いて解いていくと、こういう
ふうになるかなと思います。まず 最初1つ目はコーヒーの価格は購入
回数のところいって1回目になって、 今度はクロワッサン購入であり
のほうをたどって、今の2つの線は もうたどれないので、3つ目は今度は
会員かどうかっていう線にいって 会員っていうところで点を打つ
ことができます。そしたら一番 最後の会員のところ1つ上に戻って、
今度は非会員のほうにいったら 2つ目のケースができるみたいに
点を打っていきますと、全部で8つ、 8個のケースが出てくるわけですね。
Pair-wise法によるテストケース選定とその限界
そしたらこれをもとにテストを 選定しますと、前回やった網羅基準
を考えて、それでテストを選定 してみますと、じゃあ今回はPairwise
でやってみましょうと。認識感網羅 になるようにPairwiseでテストを
選定してみると、例えばこういう ふうになります。1から8のうち、
1番と4番と6番と7番を選ぶみたいな ことができるわけですね。そうすると
例えば、今回Pairwiseですので認識感網羅 なので、例えば今適当に購入回数が
2回目以降でクロワッサン購入を ありの場合っていうのは、1番は
合ってはまらない、4番も合って はまらない、6番で購入回数2回目
以降でクロワッサン購入を選んでる なっていうのが分かったりとか、
あとは別の例だと、例えば購入回数 1回目の会員が非会員だったら4番目
のケースですね。購入回数1回目に 点が打ってあって、会員が非会員
のところに点が打ってあるみたいに。 じゃあ一応もう一つやりましょうか。
例えばクロワッサン購入なしの 会員の場合っていうのは7番ですね。
クロワッサン購入なしの会員っていう ので、2つの因子から適当に選んだ
ときに、それもどっかしらのケース 1番、4番、6番、7番のどこかでテスト
ができるっていうのが、これがPairwise のいいところでした。
Pair-wise法の落とし穴:期待結果のバグを見逃す
じゃあこれでテストを削ってみました が、本当にこれでいいのかっていう
のを改めて考えてみます。これ 期待結果を見てみるとどうなるか
っていうと、通常はコーヒーの価格 は500円ですと。ただ2回目以降で
クロワッサン購入ありで会員だった 場合は50円引きですっていうのって
この450円になるのって5番のケース だけなんですよね。購入回数2回目
以降のクロワッサン購入ありの 会員かどうかが会員っていうのは
5番のケースだけ。何でかっていう と、これ3つの要素の組み合わせ
で見ていくので、Pairwise 認識 間の網羅だと漏れてしまう可能性
があるわけですね。っていうのがPairwise とか、ただ3人やればいいじゃん
って思ったときの落とし穴につながります。 ここで知っておいてもらいたいのが
「無則」な関係と削減手法
無則と有則という言葉が出てきます。 無則に関してなんですけれども、
これは各条件間に影響がないという 話です。前回まで元々のところで
使ってたお題ですね。コーヒーが ブラックコーヒーなのかカフェラテ
なのか、あとはトッピングがホイップクリーム もしくはチョコチップで、チョコチップ
シングルかダブルかみたいな。あの お題って実は、例えばホイップクリーム
だったらプラス何十円みたいな、 それぞれの条件だけで金額がプラス
料金とかって決まってたんですね。 他の条件に影響しないもの、こういう
ふうに条件の掛け合わせをしても 何の影響もないものを、これを無則
と言います。無則な関係に対して 削減したい場合は、先ほど示した
ようなPairwiseとか、もしくはまだ このPodcastの中では話じゃないですが
直公表とかっていうやり方があるん ですが、それが有効になります。もちろん
ディシジョンテーブルの簡単化とか 用いて削減してもよいんですが
Pairwiseとか直公表を用いることで 効率的に削減ができます。どうして
かっていうと、無則な場合は先ほど 言ったように、例えばブラックコーヒー
を選んだ時点で500円ですよと。じゃあ これの中で言うと3番のケースを
見てみましょうか。ブラックコーヒー を選んだ時点で500円ですよと。3番
はホイップクリームを選んでます。 ホイップクリームを選んだ時点で
プラス70円ですよと。チョコチップ のシングルも選んでますと。そうする
時点でプラス50円ですよと。っていう ふうに、ここのそれぞれの要素、
一つ一つでプラス料金っていうふう に考えることができるんですね。だから
3番の場合は500円と70円と50円、 それぞれ独立したその金額同士を
足し合わせて620円ですよっていう ふうに出せます。これが無則な場合
です。一方で有則っていうのは 条件の掛け合わせによって変わる
「有則」な関係と適切な削減手法
ものを言います。今回のエピソード で話したお題ですね。購入回数が
2回目以降でクロワッサンをセット で購入してて、会員だった場合は
50円引きみたいに言いましたけど、 この購入回数とセットで購入している
かどうか、会員かどうかを組み合わせ て掛け合わせることでコーヒー
の価格が変わるみたいな条件の 掛け合わせによって出力が変わる
ものを有則と言います。今回のこの 有則の場合に関してはPairwiseとか
を使ってしまうと先ほど示したように 450円のケースを漏らしてしまう
可能性があったりするので、ディシジョン テーブルの簡単化、以前このPotcast
でも紹介しましたディシジョン テーブルの簡単化などを用いて
ロジカルに削減すべきですと。この 有則の場合っていうのは先ほども
示しましたが、購入回数が2回目以降 でクロワッサン購入ありで会員
だった場合、3つ選んでこの3つが 選ばれたときに初めて安くなる
っていうふうになりました。先ほど 無則のときに示したようにこちら
ですね、ブラックコーヒーだったら 500円でホイップクリームだったら
70円でチョコチップのシングル だったら50円みたいにそれぞれの
点を打つ場所で金額が出ていって それを加算するっていうやり方
ではないんですよね。この有則の 今回の例だとそれぞれ2回目以降
だったら500円でクロワッサン購入 だったらマイナス50円でみたいな
そういう置き方じゃないですよ ね。3つ揃ったとき初めて安くなる
みたいな。これが有則な場合っていう ので、ちょっと使い分けが必要かな
と思います。この有則無則と各手法 の適正についてまとめたものが
無則・有則と各テスト手法の適性まとめ
こういう感じで、まず無則な関係 のときはPairwiseとか直行表とか
あとはツールでいうとPICTとか 呼ばれるものもあったりします。
そういうのは有効に使えますと。 デジタルテーブルの簡単化を使っても
別に間違いではないです。漏れが 発生するっていうのは少ないと思います。
一方で有則な関係の場合はデジタル テーブルの簡単化をお勧めします。
一方でPairwiseとか直行表とかPICT はお勧めしません。なんですが
これ本当に今日オープニングでも 話したとおり、ベテランの方でも
結構間違えていますし、具体的な 直接の言及は控えますけれども
とあるテストの書籍とかでも、この 有則な関係、これとこれの掛け合わせで
初めて金額が変わるとか何かしら 期待結果が変わるみたいな
そういう題材に対して、こういう 時はPairwiseを使って削減ができるんだよ
っていうふうに教えている書籍を 自分は見つけたりしています。
なのでっていうふうに書籍を書いている ような方でも結構勘違いされやすい
ところなので、とても注意が必要です。 なので自分が自分の組織のQAメンバーに
これ教えるときは、まず一旦Pairwise とか直行表とかは教えないようにしています。
まずはちゃんとディシジョンテーブルの 簡単化とか、あとは金則による削減とかでも
いいですけど、そこをきちんとできる ようになって、ちゃんと有則無則が
分かるようになってから初めてPairwise とか直行表を使うように伝えることが多いです。
なので皆さんもぜひ簡単にPairwise とか直行表を使えばいいよではなくて
今回の場合本当に当てはめられる かなっていうのを気をつけながら
質問コーナー:テスト技法を使うべきかの判断基準
ぜひ使ってください。ということで この無則、有則とそれに合わせた
テストケースの削減の方法について 今日は紹介していきました。
ここからは質問コーナーです。 これは以前に別の場所でいただいて
いた質問を今回一般的な皆さん にも伝えると良さそうな質問だったので
持ってきました。テスト技法を使う べきかどうかの判断に迷うことが
ありますと、小規模案件だったり 重要ではない検証項目の場合
洗い出すほどではないのかなという 疑念がついてもある気がしますが
どうすればいいですかと。それに対する 回答なんですけれども、実際にあります。
全てのテスト技法が使えるとは 限りません。わざわざディシジョン
テーブルで条件の組み合わせを 考えるみたいな、そういう必要がない
ものとかっていうのはあったり しますし、自分も実際の現場では
いや、これただ単純に確認すれば いいよねみたいなものはチェックリスト
みたいな形で過剰書きで書くっていう のもあったりします。
とはいえ、それは自分とかテスト 設計技法ある程度慣れてるからこそ
これは設計技法別に使わなくても いいよなっていう判断をしたりは
するんですけれども、慣れてない うちはまずはどんなテスト技法が
適応できるといいかなっていう ふうに考える癖をつけておくことが
大切かなと思います。テスト技法 とかやってなくてもテストは作れ
ちゃうんですよね。それが本当に 有効かどうか、効率よくできてる
かどうかっていうのを判断する っていうのが非常に難しいですし、
もしくはQAエンジニアではない 人がそれを判断するっていうのは
すごいテストについて精通してる 人ではないと難しくなったり
するんですよね。だからこそ自分 自身で常日頃テスト技法どう適応
できるかなって考える癖をつける っていうのは非常に大切だと思います。
特に今後AIとかが発展していって 何でもかんでもテストを結構
どんどん重要性が上がっていっている 昨今だと思っていて、そのときに
じゃあものができました。じゃあ これテストをやるべきなのか。そんなに
テストいっぱいあるからこれ削る とか、そういう話になったときに
ちゃんとそのときにスッとじゃあ 今回はClassificationツリーを使おう
とか、これだったらDecision Table 使って簡単化したほうがいいよね
とかっていうのを判断つけるためには やっぱり慣れることが大事で、
どんどん試すっていうのがすごい 重要かなと思っています。なので
ぜひどんどん使う必要ないかな と思っても、ぜひ使うことを
ためてみてください。ではエンディング です。btesting.fmではリスナーさん
エンディングとリスナーへの呼びかけ
からのお便りを募集しています。 エピソードの感想や私に聞いてみたい
質問やテストのお悩みなど、どんな ことでも構いません。投稿フォーム
は番組概要欄にあります。また エピソードの感想は、ハッシュタグ
btesting.beanscotestingでXのポスト をお願いいたします。
今日の話でいうと、Pairwiseの落とし穴 直行表の落とし穴みたいなものを
話していきましたけれども、皆さんも この落とし穴はまってないですかね。
そこちゃんと考えられてなくて、実は そこ漏れてたかも。確認すべき
テストすべき内容漏らしてたかも みたいなことを、もちろん話せる
範囲で構わないので、ぜひXのポスト とかしてもらえると大変うれしい
なと思っています。もしもこれからも 聞きたいという方は、お手持ちの
Podcastアプリの中から番組をフォロー をお願いします。最新回が上がった
ときにすぐに気づけるようになっている かなと思います。今回でClassification
ツリーの話は終わりにはなりますが、 次もまだどんどんいろいろ話して
いきたいなと思いますので、その 回が上がったときにすぐに気づける
ようになると思うので、ぜひ番組の フォローお願いします。ということで
今回はここまでです。それでは また次回。バイバイ。
17:01
コメント
スクロール