オープニングと前回の振り返り
皆さん、こんにちは。B-Testingのブロッコリーです。このB-Testing.fmは、QA
エンジニアである私、ブロッコリー がテストや品質に対する私なりの
考えを約10分間で語っていくポッドキャスト 番組です。今日は前回に引き続き
Just Tokyoのお話をしたいなと思うん ですけれども、前回も話したとおり
Just Tokyo ソシアテストシンポジウム の東京で3月にありましたが、そこ
ではAIのセッションが多かったという お話を前回したと思います。そんな
中、私が所属しているコミュニティ の若手が登壇、主催をしたワークショップ
セッションっていうのをJust Tokyo で開催しまして、そこではもう
AIがどうこうとかあんまり関係 ないというか、AIが関係ないクラシフィケーション
ツリー技法のワークっていうの を開催していきましたと。AIでクラシフィケーション
ツリーを書かせるっていうことは 今後あるかもしれませんが、そもそも
知識として知ってもらいたいな と思ってワークを開催した感じ
です。このクラシフィケーション ツリーの技法に関しての説明は
数回後のエピソードの中でも説明 する予定なので、お楽しみにして
いてください。今日は前回のディシジョン テーブルの話の続きしていきたい
なと思います。ということで今回も btesting.fmスタートです。今日は
デシジョンテーブルのパターンを機械的に削る方法
ディシジョンテーブルの話の続き ですね。ディシジョンテーブルの
パターンを機械的に削るという 話をしていきます。ディシジョンテーブル
のパターンを機械的に削るという 方法は2つ。均速という前回も話した
内容もあるんですけれども、それ だけじゃなくてもう一つ簡単化
というものがあります。この簡単化 っていうのは何かというと、条件
を整理することでディシジョンテーブル のパターン数を減らすものになります。
「簡略化」によるパターン削減の考え方と手順
これどうやってやっていくのか っていうのも手順を踏まえてやって
いこうかな、説明していこうかな と思います。今回使う題材も前回
と同じくこの同じ題材ポイント バックですね。支払い時の連携によって
ポイントバックされる金額が変わります とアプリ登録をしていると15パーセント
付与。さらにメールアドレス連携 をしていると10パーセント付与。
当店のカード連携をしていると5パーセント 付与という仕様があったとします。
これに対して前回作成したディシジョンテーブル は今画面に示したようなものになっています
と。全部で8パターンあってアプリ 登録を登録しているかしていない
か、メールアドレス連携をしている かしていないか、カード連携をしている
かしていないかの条件が2かける 2かける2で8パターンあって、それぞれの
パターンに対して対応する付与 ポイントっていうのを考えていきました。
仕様として曖昧な部分もあったん だけれども、それは関係者と話して
ここに示したようなものになった としますと。例えばアプリ登録
で15パーセント、メールアドレス 連携で10パーセント足して15足す
10で25パーセント、カード連携は 5パーセント付与なんだけれども
25パーセントと5パーセントでより 大きな値ということで25パーセント
になるよっていうのが1列目のテスト 結果というか付与ポイント25パー
セントのところにチェックが付いてる っていうのはそういうことになります。
今これって全部で8パターンあります と、5番目6番目は実際にテストができない
ので実質6パターンになるわけです けれども、じゃあこっからさらに
係数を削れないかって考えるっていう のが今回やりたいことです。一見
すると6パターンとか8パターン 全部やればいいじゃんって思う
かもしれませんが、実際の現実的な 業務の中で作ったディシジョン
テーブルはもっと数が多いもの になることが多いかなと思います。
そのときにどうやって削るかっていう のを機械的に削る方法を簡単化
というものをぜひ今日知っておいて もらいたいなと思います。
じゃあまず最初ですね、このパターン 1とパターン2の部分に注目します。
これは何かっていうとアプリ登録 が登録済みですっていうのは1番も
2番も同じです。メールアドレス 連携が連携済みっていうのはこれも
1番と2番で一緒ですと。カード連携 は連携済みの場合と未連携の場合
がありますと。ただこれどちらに おいても付与ポイントは25パーセント
ですよっていうふうに変わりません と。つまりこれってカード連携済み
かどうかっていうのは結果動作 の付与ポイントの数としては関係
してこないっていうのが分かります。 なのでこれは1番と2番をそれぞれ
別々にやる必要ないんじゃない 共通にしてやっていいんじゃない
っていうことで簡単化を行うことが できます。簡単化を行った結果
こういうふうになります。アプリ 登録が登録済み。メールアドレス
連携が連携済みのところに丸が 付いている。カード連携は連携済み
でも未連携でもどっちの値を使って もいいよっていうことで今回の
場合はハイフンで表現しました。 このうちの実際にテストするときは
どっちかの値を使えばいいよっていう 表現になります。同様に今度は3
パターンの3つ目と4つ目も考えて みます。アプリ登録は両方とも
登録済み。メールアドレス連携 は両方とも未連携。カード連携は
連携済み未連携それぞれのパターン どちらにしても付与ポイントは
15パーセントで変わらないよっていう ふうになっていると。ってことは
これもやっぱりさっきの1番2番 と同様にカード連携済みかどうか
は結果に関係しないので簡単化 ができます。簡単化するとこういう
形でカード連携のところがハイフン で表現されるみたいなことができます。
じゃあ同じように他のところも できるんじゃないっていうことで
今度は7番と8番を考えてみます。 両方ともアプリ登録は未登録メール
アドレスは未連携です。カード連携 は連携済みと未連携それぞれの
パターンがあります。ただこれは さっきほどまでとちょっと違う
のはカード連携が連携済みだった 7番の場合は付与ポイントが5パーセント
になっていてカード連携が未連携 である8番の場合は付与ポイント
が0パーセントになっています。という ふうに動作付与ポイントの期待結果
がそれぞれ異なる。こういう場合 は列を圧縮簡単化することはできません。
なので先ほどの1番と2番の簡単化 3番と4番の簡単化みたいにケース
を一つに作り直す書き直すっていうこと はできないのでこのまんまにして
おく必要があります。というのが 簡単化の説明でした。
「禁則」による不要なパターンの削除
あともう一つそもそもディシジョン テーブルの列の削除っていうのが
できます。これは前回も話した とおり5番と6番っていうのはアプリ
登録が未登録なんだけれどもメール アドレスの連携が連携できるっていう
のは現実的には今回のプロダクト の場合はあり得ないっていうこと
が分かった場合ですとそもそも テストが不可能なのでNAと書いて
あるんですがそもそも列を削除 できますと。これを前回も話した
とおり禁則と呼びます。禁則の 部分はもう列ごと削除しちゃい
ましょうっていうので消すことが できます。こういうふうに禁則
で削除していったり簡単化をする ことで最初は8パターンあったテスト
が8パターンから4パターンに今 言ったようにロジカルに削減が
できましたと。こういうふうになん となくここにしようではなくて
削減前のテーブルを残す重要性と戦略的判断
ロジカルに削減できるっていう のがすごいいいところかなと思います。
ただここで注意点というか自分の ちょっとしたTips的な話でいうと
ぜひ削除前のディシジョンテーブル も一緒に残しておいたほうがいい
です。削除した後のディシジョンテーブル しか残してないと4パターンになりました
っていったときにロジカルに削って 4パターンになったのかそれとも
4パターンしか考えられなくて実は パターンが漏れていたのか区別
をつけることができませんと。なので まずは全パターン簡単化とか近
測による列を削除する前の状態 っていうのをまずはちゃんと用意
をしておいて8パターン全部であり ました。そん中からロジカルに
削って4パターンになったので テストをやるときはこの4パターン
でテストをしますっていうふうに 説明できるようになったほうが
いいと思います。ちなみに先ほど 8パターンから4パターンに削った
っていう話をしたんですけれども 必ずしも極限まで削りなさいという
つもりはないです。あえてパターン を圧縮しない簡単化しないという
判断実際あり得るかなと思っています。 例えば今回のパターン1の場合登録
済みかつ連携済みメールアドレス 連携済みでカード連携も連携済み
のとき15たす10で25パーセントに プラスカード連携の5パーセント
がされて30パーセントとかになってない よねっていうのを確認したいとき
っていうのはあえて1番と2番を 簡単化してどっちか1つやればいい
やではなくて両方残しておくっていう 判断もありだと思います。そうすると
8パターンだったのが一番簡単化 を極限までやったら4パターンになる
けれどもそこはあえて残しておいて 5パターンにするみたいなことは
全然ありかなと思います。今さっき 言ったとおりパターン1が本当に
25パーセントになるか30パーセント にならないか確認したいであった
りとかあとはカード連携のイフ 分がプログラムの最後にある前提
なんですよねこの簡単化の話で 言うと。なのでもしもイフ分が
プログラムの最初に存在していた 場合っていうのはそれぞれで別
のプログラムコードを通ったり するのでそれは両方とも確認す
べきだよねっていう判断になる かもしれません。これは結局実際
プロダクトがどういう状況になっている かプロダクトコードがどういう
状況になっているかっていう話 なのでケースバイケースになる
とは思います。なので本当に削除 していいのかっていう判断はできる
だけ関係者同士で話し合ってじゃあ ここまで細かく見る必要ないよね
とかっていうのを議論するっていう のが何よりも大事かなと思っています。
デシジョンテーブルの様々な表記方法
あとはディシジョンテーブルの最後 ちょっとした話なんですがディシジョンテーブル
はさまざまな表記方法があります。 左に示したものですね。今回の条件
に当てはまるもの先ほどは丸で 表現してましたがYとNで表現する
イエスノーで表現してあとは不要 ポイントのところXで表現する
みたいな。これは結構実企画に則 った表記方法だとこういうふう
になるかなと思います。ですがお 勧めのというか個人的にはこの
画面の右側の方法ですね。条件に 該当するところだけに丸をつける
っていうのが個人的にはお勧めかな と思います。っていうのもY Nで全部
埋めちゃうと結局これどこの条件 を使おうとしてるんだっけっていう
のが結構パッと見た目で分かり づらいっていうところがあるので
自分が実際の業務でやるときは 丸と空欄みたいなそういうふう
にやることが多いかなと思っています。 ということでいろいろしゃべって
質問コーナー：テストケース100件超への対処法
きましたけれどもディシジョンテーブル のパターンっていうのを機械的
に削る近速の話と簡単化の話を 今日は話していきました。
ここからは質問コーナーです。これは 以前にこのディシジョンテーブル
の話をいろいろなところで話した ときに実際にいただいた質問から
ピックアップして持ってきました。 実際の業務の中での話だと思うん
ですけれどもテストケースが100件 ぐらいあって簡単化して削減する
方法で進める場合に除いていいか どうかを検討することにも時間を
要すると思うのですが一定の基準 で素早くできる方法があれば知り
たいですと。先ほど簡単化をする ときには関係者に議論しようっていう
話をしたんですけれどもさっき は全部で8パターンっていう分かり
やすいことだったけれども100件 ぐらいあったら削減どこっていう
のを説明するのもみんなで理解 するのも大変じゃないっていう
そういう質問ですね。そもそもの 話になっちゃうんですけれども
そもそもデシジョンテーブルの削減 前のケースが100件とかになった
場合っていうのは簡単化でどれを 削ろうかっていう話よりも前に
これ本当に出した条件全部掛け 合わせてテストすべきなのかっていう
のを検討したほうがいいかなと思 っています。要は結構掛け合わせ
ようとしてる条件がすごい多かった りとかこの条件とこの条件とこの
条件4つ5つを全部掛け合わせて 見てとかそこでの条件がイエス
ノーの2パターンだけじゃなくて 3パターン4パターン5パターン
ぐらいあるからそうすると掛け算 で100件とかになるっていうので
あれば本当にそれって条件の掛け 合わせが必要なんだっけっていう
ところを疑うほうがいいかなと思います なので除いていいかどうかっていう
のを検討するのに時間がかかって いたらそもそもこれそんなに複雑
に100件とかパターンが多いの自 体がどうなんじゃないかみたいな
そもそも仕様が複雑になっていない かとか もしくは仕様自体は実は
そこまで難しくないシンプルなんだ けれどもそれを難しく捉えてこれも
これもこれも掛け合わせようみたいな 感じで複雑な実証テーブルを作成
してしようとしてませんかねと なので簡単化とかで除く削減する
とかっていう検討の前に まずは どこが複雑になっているか もしくは
どこを複雑と考えているかっていう 部分を明らかにして解きほぐす
ことが先かなと思っています ということで 今日も一つ質問に答えて
エンディングとリスナーへの呼びかけ
いきました ではエンディングです btesting.fm
ではリスナーさんからのお便り を募集しています エピソードの
感想や私に聞いてみたい質問や テストのお悩みなど どんなこと
でも構いません 投稿フォームは 番組概要欄にあります また エピソード
の感想はハッシュタグ btesting banscotestingでxのポストをお願いいたします
今日の話で言えば簡単化という ディションテーブルを慣れてない
と もしかしたら ちゃんとこういう ふうにロジカルに削減するという
のをやったことがない方とかも いたかもしれません なるほど こういう
ふうにやればいいんだとか あとは 話聞いてみたけど ちょっとまだ
よく分かんなかったなみたいな そういう どんな感想でも構いません
ので ぜひxのポストをお願いします もしもこれからも聞きたいという
方は お手持ちのPodcastアプリで 番組のフォローもお願いします
最新回が上がったときにすぐに 気づくことができるかなと思います
今回のディシションテーブルは 前回と続きものみたいな形になって
いたので そういうときにすぐに 気づけていたりとか あとはたまに
毎週月曜を基本に考えています けれども 木曜にもたまに配信を
したりとかもするので そのときに すぐに気づけるかなと思っています
ので ぜひフォローもお願いします ということで 今回はここまでです
それでは また次回
バイバイ
