オープニングとAIテストの現状
皆さん、こんにちは。B-Testingのブロッコリー です。このB-Testing.fmは、QAエンジニア
である私、ブロッコリーがテスト や品選に対する私なりの考えを
約10分間で語っていくポッドキャスト 番組です。先日、Just Tokyoに参加
してきました。Just Tokyoというのは ソフトウェアテストシンポジウム
というジャストがあるんですけれども その中で東京で開催されている
ものが毎年3月あたりにありまして それをこの間といっても、この
放送からすると結構前になると思 うんですけれども、参加してきました。
結構セッションの数が多かったんです けれども AIを用いていることが
前提のセッションとか AIを用いて どうするのかみたいな、そういう
話のセッションがほとんどだった なと思っています。ただ、実際
内容を聞くと、それってAI関係なく 昔から大切にしていることだよ
ねみたいな、そういう話が意外と 多かったなと思っています。この
B-Testing.fm、今日の話とかは別に AI関係なくというか、もう昔から
あるテスト設計技法の一つのディシジョン テーブルについて、今日は話して
いきたいと思います。ということで 今日もB-Testing.fmスタートです。
デシジョンテーブル（決定表）の基本と例題
ということで、今日はディシジョン テーブルの紹介になりますかね。
ディシジョンテーブルを機械的に 作るという話をしていきたいと思います。
そもそも、今日扱うディシジョンテーブル というテスト設計技法が何かっていう
話を最初にします。ディシジョンテーブル 日本語に訳すと決定表と呼ばれたり
します。これは何かっていうと、 問題の記述において起こり得る
すべての条件とそれに対して実行 すべき動作とを組み合わせた表
のことです。つまり、こういう条件 とこういう条件とみたいな条件
が組み合わさって、いろいろ考え なくちゃいけないっていうテスト
があると思うんですけども、そういう 時に役に立つ技法になります。
これをディシジョンテーブルこういう 問題をっていう話をしても、なかなか
分かりづらいかなと思うので、一 つ例題を用いて話していきます。
今日最初にちょっとお断りしない といけないなと思うんですけれども、
やっぱりテスト設計技法を説明して いくにあたって、どうしてもやっぱり
スライドで見て知ってもらうっていう ところが多くなってしまうので、
極力音声でも話していこうかな とは思うんですけれども、やっぱり
できるだけここら辺に関しては スライドを見てもらえると嬉しいです。
今日扱う例題はこのポイントバック に関しての例題ですと、以下のツール
についてどのようなテストを作成 するかということで、支払い時に
連携があって、それによってポイント バックされる金額が変わりますと、
どういうふうにポイントバック の金額が変わるかというと、アプリ
登録をしていると15パーセント 付与しますと、さらにメールアドレス
連携もしていると10パーセント 付与されますよと、当店のカード
連携をしていると5パーセント付与 しますみたいな、こういう仕様が
あったとしますと、これに対して どんなテストをしますかという話です。
デシジョンテーブルの誤った作成手順と正しい方針
そのときにデシジョンテーブル というテーブル、徹底表を作る
のが役に立つんですけれども、こういう テーブルになるよっていう結果
だけを見せるんじゃなくて、作る 過程を説明していきたいと思います。
まず最初に作成する手順として は、原因の部分と動作の部分。原因
と動作っていうのを単語として わかりづらいと思うので、自分なり
の言葉にすると、条件とあとは 結果ですね。それの値を書き出します
と。今回の場合だと、原因の部分 条件って何かっていうと、アプリ
登録をしているかしていないか。 あとはメールアドレスを連携している
かしていないか。そしてカード連携 をしているかしていないかっていう
ふうになると思います。フィールド ポイントは何パーセントとかっていう
のがいろいろ出てくると思うん ですけれども、今回はここは最初
スキップしますと。次がまず最初に 重要なところなんですけれども、
このアプリ登録メールアドレス カード連携しているかしていない
かっていうのを思いつくままに やるみたいなところ。まずはアプリ
登録してカード連携はしてなかったら みたいなところで丸が打てます
と。アプリ登録のところ登録済み。 メールアドレスも連携済みでいい
かなカード連携は未連携かなっていう ので丸をつける。次はカード連携
だけした場合はみたいにアプリ 登録は未登録でメールアドレス
も未連携でカード連携は連携済み だみたいに思いつきで書いていく
みたいなこういうのはよくある デシジョンテーブルの作り方やっている
方が多いかなと思うんですけれども そういうことじゃないんだっていう
のを今日強く訴えたいなと思っています デシジョンテーブルの作成する
ときの方針ですね。今言ったような こういうふうなものがあるんじゃないか
っていう思いついた組み合わせ で列を足していくっていうこの
足し算の考え方は基本的に行わない ほうがいいです。何でかっていう
と今たまたま思いついただけで 思いつかなかった組み合わせが漏れて
しまうというリスクがあります。 なので正しい作成方針としては
全ての条件の組み合わせをまずは 掛け算で用意をしてあげてその
後その条件を割り算で割り当てます。 最後というわけではないですが
その後にテストできないものを 引き算で削るみたいなことを考えて
いきます。具体的に先ほどの例を 使って話していきます。まず最初
機械的なデシジョンテーブル作成の実践
全パターン数を掛け算で計算します。 今回の場合はアプリ登録するしない
の2パターンとメールアドレス 連携するしないの2パターンとカード
連携をするしないの2パターン なので2×2×2で8パターンになります
よと。つまり先ほどのレシジオン テーブル表の右側の列っていう
のは全部で8つまずは掛けるんだよ っていうまず全体感を知ることが
できます。その次に割り算を使って 割り当てるということをやって
きます。これを機械的に作成して いきます。そうするとまず最初一番上
の部分ですね条件アプリ登録登録 済みか未登録かというのはこれは
登録済み未登録っていう2パターン がありますねと。全体が8パターン
で2パターンあるので8割る2を下 で。そうすると4点出てくるので
最初の登録済みのところを1から 4まで4つ丸を付けてその後アプリ
登録未登録のほうに5から8まで 4つ付けてあげる。こういうふう
に4つずつ付けます。続いて2つ目 今度はメールアドレスのほうに
降りていきます。メールアドレス は連携済み未連携のやっぱり2
パターンありますと。先ほどアプリ 登録の割り算で出した4っていう
ところからさらに割る2をしていきます。 そうすると2パターンずつになる
ので丸が2個ずつ付きます。メール アドレス連携済みに1番2番に丸
を付けて未連携のほうに3番4番 に丸を付けてやります。この5678
はどうなっていくかっていうと 今作ったこの1から4の塊をその
まんまコピーして持っていく。 これを最後まで繰り返すっていうこと
をやっていきます。最後 カード連携 のところも同様です。カード連携
連携済みと未連携の2パターン ありますと。先ほどメールアドレス
のときに出した4割る2で2だった のでその2から割る2連携済みか
未連携かの2をする。2割る2をする と1になるので1パターンずつ丸
を付けます。カード連携連携済み に丸を付けてカード連携未連携
に丸を付けるみたいにしていきます。 そうすると1番と2番がそうやって
丸で埋められました。じゃあ345678 はどうするかっていうと先ほど
のメールアドレスのときと同じ でこの1 2のこのパターンをコピー
して横に繰り返して貼っていく みたいにするといいです。こう
することによってこのアプリ登録 を登録済み未登録メールアドレス
連携連携済み未連携カード連携 連携済み未連携すべてのパターン
をこういうふうに洗い出すことが できました。こういうふうにディシジョン
期待結果の記入と禁則・仕様の曖昧さの発見
テーブルを作っていきます。そしたら 次です。今は主に行を見てやって
いきましたが今度は列を見ていきます。 各パターン列に対してどんな期待
結果どんな動作になると想定される かっていうのを埋めていきます。
今回の仕様は何かっていうとアプリ 登録をしていると15パーセント
付与でさらにメールアドレス連携 をしていると10パーセント付与
でカード連携をしていると5パーセント 付与って書いています。例えば
この中の2番目のところを見てみます。 アプリ登録登録済みメールアドレス
連携連携済みカード連携が未連携 ってなっています。そうすると
アプリ登録をしていると15パーセント 付与していてメールアドレスを
連携しているとさらに10パーセント 付与って言っているので15たす
10で付与ポイントは25パーセント になるだろうっていうふうに分かれ
ます。こういうふうに列一つ一つ に対して埋めていきます。そうする
とすぐ簡単に埋められるのは4番 7番8番のところかなと思います。
4番はアプリ登録は登録済みだけど メールアドレスとカード連携は
未連携なのでそうすると15パーセント になりますね。7番がアプリ登録
とメールアドレスは未登録未連携 だけれどもカード連携は連携済み
だからそうすると5パーセント 付与だし8番は何も未登録未連携
なので0パーセントの付与ポイント になるっていうのが簡単に埋め
られます。そうすると残りの部分 考えていきましょう。まず5番と6番
アプリ登録は未登録なんだけれども メールアドレスは連携済みっていう
ものですね。これおそらくアプリ 登録する際にメールアドレス連携
をしているのかなって自分はこの 仕様から読み取ったのでアプリ
登録は未登録なんだけれども メールアドレスが連携済みっていう
のはあり得ないんじゃないかっていう ふうに今回の場合は考えました。
こういうふうにあり得ないパターン 表記の仕方はいろいろあるんです
けれどもNAって記入することが 多いかなと思います。適用できない
のとアプリカブルですかね。すみません 自分は英語はそんな得意ではないん
ですがそれの略でNAっていうふう に記入をしたりします。こういう
ふうにあり得ないパターンのことを 禁則 禁止されているルールっていう
意味で禁則っていうふうに呼んだり します。あと残っているのが2箇所
ありますね。ここでちょっと期待 結果が若干この仕様だと不明な
ように見えます。例えば3番のところ ですね。アプリは登録済みでメール
アドレスは未連携なんだけどカード は連携済みのとき。アプリ登録している
と15パーセント付与でカード連携 していると5パーセント付与なんだけど
これって合算されるんですかね。 合算されて20パーとかになるのか
それとも15パーだけなのか5パーセント だけなのかちょっとここが曖昧です
と。同じく1番のところですね。全部 登録とか連携している場合って
15パーと10パー足して25パーの さらに5パー足して30パーとかになるん
ですかね。それとも5パーの付与 はなくなるんですかね。っていう
のがすごい曖昧っていうのが分かり ます。これは関係者に確認をしましょう
と。ここってどうしますかみたいな 話をいろいろと議論をするっていう
のができます。そうすると例えば アプリ登録とメールアドレスの連携
は合算ができて15たす10で25とか になるけれども カード連携の5パー
付与はさらに加えるっていうこと はしませんよと。どっちか付与
ポイントが多いほう取りますよ みたいな。そういうものだとしたら
じゃあこれアプリもメールアドレス もカード連携もしてた場合は15
たす10で25パーとカード連携5パー の多いほうだからじゃあ25パーですね
みたいにそういうふうに埋めて いくことができます。この関係者
に確認して期待結果を埋めるという 行為そのものが これ自身はテスト
設計ではあるんですけれども 仕様 の曖昧なところがこういうふう
に潰すことができるっていうのが 大きなメリットかなと思っています
質問コーナー：境界値分析とモデル化
ということでここまでがデシジョン テーブルを機械的に作るという
話をしてきました。途中でも話した かけ算を考えて そこから割り算
で割り当てていく その後 金属 っていうところで引き算になる
っていうようなところ。あとは 仕様が曖昧なところがテスト設計
をする。実際にテストは実行してない でしましてはプログラムとか一文字
も見ていない状態だけれども テスト のことを考えていって 仕様の曖昧な
ところを潰すっていうことができる っていうのを今回学んでいきました
はい それではお便りというか質問 のコーナーです これは自分が以前
質問としてもらったものでして その中で結構一般的な質問 よくある
疑問かなと思ったので このPodcast で紹介していきたいなと思います
前回ですかね 前々回ですかね 境界値分析の話をしました その
境界値分析に関する質問ですと 境界値を考えるとき ケースバイ
ケースなので前提の考慮漏れが怖い ですと どのようにすればそもそも
前提の考慮漏れを防げるか知り たいですっていう質問をもらいました
これに関しては結構認識を合わせ ましょう 先ほどのデシジョンテーブル
もそうですが 認識合わせをしましょう っていうのは大事だと思います
し それだけじゃなくて やっぱり モデル化っていうところが大事
かなと思います 結構 文章のまま 処理しちゃうと 曖昧なところに
気づきづらいので ちゃんとモデル化 先ほどのデシジョンテーブルでいう
表形式にしたりとか 境界値分析 でいう垂直線にしたりとか そういう
何か図示できる形 モデル化をして 関係者の方々が同じ認識を持っている
かっていうのを議論することが 大事かなと思います これを一人
で 特にこの仕様とか設計をした 人自身が考慮漏れに気づくっていう
のは結構稀だと思うので 議論 できる形に持っていく そのための
モデル化っていうことを大事に していくといいかなと思います
例えば これは境界値分析のとき の題材を持ってきました 東海道
新幹線の望み号は名古屋駅を出る と新横浜駅まで停車しませんっていう
ときの停車しない区間はっていう 話を この文章だけで読み取る
のはなかなか難しかったりする と思うんですけど これをモデル
化をしますと 今回の場合だと これ 路線図っていうんですかね 停車
駅一覧っていうのをこういうふう に表現する これもある意味モデル
化なんですよね 数直線みたいな 形で 何か境界値分析の肝となる
順調づけられたものっていうの をちゃんと順番に並べて表現する
ことによって じゃあ望みの止まってない 部分 停車しない部分はここですね
っていうふうに一目見て分かる わけですよね こういうふうにモデル
化をして議論する そうすると 例えば いや 望み 静岡には止まるんじゃない
とか そういう議論とかもできる と思うんですね なので モデル
化して議論するっていうことを 大事にしていくかなと思っています
エンディングと次回予告
ではエンディングです btesting.fm では リスナーさんからのお便り
を募集しています エピソードの 感想や 私に聞いてみたい質問や
テストのお悩みなど どんなこと でも構いません 投稿フォームは
番組概要欄にあります また エピソード の感想は ハッシュタグ
btesting banscotestingでXのポストを お願いいたします 今回の話でいえば
デシジョンテーブルの作り方について 話していきました 今まで何となく
作ってたとか 足し算の考え方で 実はやってたんだとか なるほど
こうやって作ればいいんだねみたいな そういう感想 何でも構いません
ぜひXのポストをお願いします もしもこれからも聞きたいという
方は お手持ちのPodcastアプリで 番組のフォローもお願いします
最新回が上がったときにすぐに 気づけます この後 多分次回になる
とは思うんですけれども デシジョンテーブル 今回だけでは終わりではなくて
次回は簡単化という話をしていきます 今回からの続きの回になります
ので ぜひ それが上がったときに すぐ気づけるようにフォローも
お願いします ということで 今回はここまでです
それでは また次回
バイバイ