オープニングと境界値分析の導入
皆さん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
ちょっとオープニングは趣味の話というか、自分は結構スポーツ観戦とかをしたりするんですけれども、
一昔前とかだと野球観戦とかあって、サッカー観戦とかあったかもしれないですけれども、最近バスケの観戦とかにも行ったりしています。
特に今までスポーツ観戦とかしてこなかったっていう方は、ぜひバスケの観戦がおすすめです。
野球とかサッカーとかは結構展開が少ないというか、初めて行く人とかにとってはあんまり得点が入らなかったりしますけれども、バスケの観戦ですとしょっちゅう得点は行ったり来たり入ったりしますし、
かつコートまで近いんですよね。距離が近いので、すごい迫力のあるものが見れるかなと思っています。
今ちょうどBリーグも活況ですので、気になる方はぜひバスケ観戦おすすめです。
ということで、今日は窒素設計技法の続きですね。
今日は境界値分析について話していきたいと思います。
ということで、今回もbtesting.fmスタートです。
今日はですね、境界値分析について語っていきます。
タイトルにもつけたとおり、意外と奥が深いということで、きちんと考えてみると、境界値分析ってこういう考え方があるんだっていうのを知ってもらえるかなと思っています。
境界値分析とは何か？
まず最初にですね、一つ例としてテストケースはいくつということで、パスワードの例題のやつから持ってきた感じですけれども、
パスワードが例えば8文字以上45文字以下であるようにしてくださいみたいに言われたらどうするかっていうのを考えましょうと。
このとき、じゃあ1文字入れたら、2文字入れたら、3文字、4文字、5文字、6文字っていうふうに、一つずつ100文字ぐらいまでやっていきますかね。
それでテストして大丈夫だったってなったら、次どうなると思います。100文字まで大丈夫だったと。
おそらく101文字でエラーとかになったらどうしようって不安になるわけですよね。膨大な数のテストケースになります。
テストの7原則の2つ目にですね、全数テストは不可能という言葉があります。
現実的に全てをテストするっていうのは不可能だと言っているんですね。
今回の場合みたいなときによく使われるのが境界値分析になります。
改めて境界値分析とは何かということについて話していきます。
これはJSTQBのアドバンスドレベルのテストアナリストのシラバスから引用してきました。
境界値分析というのは、順序付けられた同時パーティションの境界上に存在する値を適切に処理していることをテストするために使用する。
と書かれています。ここでのポイントは3つです。
順序付け、そして同時パーティション、そして境界上の3つになります。
まずポイントの1つ目が同時パーティションという言葉です。
つまり境界値分析をやるためには、まず前提として同時パーティションがある。
つまり同時分割をするというところが大事になります。
同時分割に関しては以前のエピソードで紹介したので、そちらも参考にしてください。
2つ目が順序付けられたというところです。
つまり同時分割の場合は別に順序付けとか必要ないんですけれども、
境界値分析においては何らかのルールに基づいて順序付けられていることが前提となります。
そして3つ目が境界上という話になります。
先ほどのお題ですね、8文字以上45文字以下のパスワードは設定できるというお題に対して、
どういうふうに境界値分析をやっていくかということを考えていきます。
境界値分析の実践ステップと不等号のミス
まず1つは数直線で表現するというのがあります。
今回の場合、8文字以上45文字以下という、ある意味何文字という文字数でいくと数直線で表現できる。
数直線で1から100とかまで順序付けられて並ぶことができます。
なのでまずは数直線で表現します。
続いて2つ目、同時分割を行います。
今回の場合ですと、設定できない文字数というのが8文字より小さいところにあって、
あとは8文字以上45文字以下のパスワードは設定できるので設定できる文字数、
そして45文字より大きいところで設定できない文字数という、
3つに同時パーティションがまずは分割されるかなと思っています。
そしたら続いて、仕様に言及がない境界の値を記載していきます。
今回の場合ですと、仕様は8文字以上45文字以下のパスワードは設定できると言っています。
つまり設定できる文字数の8文字と境界になる設定できない文字数ということを考えます。
そうするとそれは7文字がそうですよね。
同様に設定できる文字数の上限の45文字があるんだとしたら、
それより上の設定できない文字数の境界の部分というのは46文字です。
だからこの7文字、8文字、45文字、46文字というのが導き出すことができるんですね。
じゃあなんでこの境界、7文字、8文字、45文字、46文字という境界を考える必要があるのか
ということについてもう少し深掘りしていきます。
じゃあなんでパスワードが8文字以上といった場合に、
さっき境界値として出てきた7と8というもの、これをテストでやるわけですけれども、
なんでこれをテストするのかというのを考えていきます。
そうすると一つプログラムを書いてきました。
if x小なり7のときにリターンで入力したパスワードが短いですというようなプログラムがあったとします。
これよく見てください。今回の場合、パスワードが8文字以上といった場合のこのプログラムってどうでしょう。
正しいでしょうか。
というと、これは一箇所正しくないところがあるんですね。
何かというと、このx小なり7って書いてあるところですね。
これって今回8文字以上だったらOKだし、8文字より小さい、
7文字以下だったら入力したパスワードが短いですというふうに出したかったわけですよね。
けど、ここよく見るとx小なり7って書いているので、
7文字のときっていうのが入力したパスワードが短いですとならないわけですね。
つまりここって正しくはx小なり8とか、もしくはx小なりイコール7っていうふうに書いたほうがいいわけですよね。
こういうふうに不統合のミスによる不具合っていうのを発見できるのは、
これ7をテストしたときだけなんですよね。
こういうのを見つけたいがために強化位置分析っていうのを行います。
カバレッジ100%の罠と仕様の読み取り
これは何で重要かっていうと、単純にテストコードっていうことだけ考えると、
よく言われるのがコードカバリッジ100%になるようにテストすればいいんでしょっていうふうに言ったりする人がいるかもしれませんが、
コードカバリッジが100%であってもバグを見逃してしまうっていうのがあります。
例えば先ほどのやったお題、8文字以上45文字以下だったらパスワードを設定できるっていうお題に対して、
こういうふうなプログラムを書いたとしますと、
ジャッジする関数があって、if xが小なり7のときはreturn falseで、
else ifでxが46より大きければreturn falseで、それ以外はreturn trueっていうプログラムがあったとしますと。
一方でそこに対してテストとして、5文字の場合、60文字の場合、15文字の場合っていうふうに3つあったとします。
そうすると、まずxに5を入れたときっていうのはfalseになるべきだっていうのに対して、
実際にちゃんとコードのほう通ったら、うん、確かにfalseになったと。
続いて60を入れたときもfalseになる、うん、ちゃんと通ったと。
最後15のとき、7よりも小さいわけではないし、46よりも大きいわけではないからちゃんとtrueになったと。
うん、よし、ちゃんと3つのテスト通ったし、これコードカバリッジを見ると全部のところ通ったから100%だっていうふうになるわけですよね。
しかし、ここの先ほど示したような7文字とか46文字のとき、バグが残っちゃってるわけですよね、ここの部分ですね。
なので、これって結局コードカバリッジが100%になっているけれども、バグを見逃しちゃっている例になります。
これは何でかっていうと、そもそも使用を読み間違えているとか、そういう話になるので、
そもそもどういうテストを作るのかっていうところをちゃんと考えてないとこうなってしまうわけですね。
なので、今回の場合だったら境界値分析を使ってやってみましょうとかっていうのが大事になるっていうことですね。
システム上の境界値と精度の問題
これだけではなくて、実はそれだけじゃなくて、システム上の境界値も合わせて考えたほうがいいと思います。
実は先ほど7文字、8文字、45文字、46文字をやればいいですよという話をしたんですけれども、
実は仕様に書かれてないけれども、システム上の境界値っていうのもあるはず。
何かというと、まず0文字までは設定ができないけれども、そもそもマイナス1文字とかは入力できないですよねと。
いや、これ現実的に無理でしょっていうとそうかもしれませんが、
先ほどのプログラムのコード上だったらXにマイナス1を代入すること、入れることはできるので、
そこも一応確かめてもいいかもしれませんし、あとはもう一つ、限りなくすごい多い文字数とかっていうのもできるかもしれません。
例えば実際にパスワードの入力欄に100文字とか200文字とかは入力ができてるけど設定できないっていうのがあるかもしれませんが、
ある文字数以上はそもそも入力すらできないっていうところがあるはずで、
例えばパスワードを入力しますと、それで登録しようとしたときに、
その入力した文字列を元に一回プログラムに変数として入れたときに、
そもそも桁あふれとかになってException入っちゃうみたいなこともあり得るかもしれないんですね。
なのでこういうふうなシステム上の境界値っていうのも合わせて考えたほうがいいかなと思っています。
あともう一つですね。
単純に境界値って、要はそこのドッジパーティションでやったところの境界を見ればいいんでしょっていう話だと、
そんな単純なところだけじゃないっていう例を一つ紹介します。
例えばアトラクションとかで195センチ以下の人は乗れますよみたいなものがあったときに、
195センチ以下の人だったらいいですよっていう部分の境界値っていくつになるでしょうと。
196センチの人は乗れませんよねと。
195センチ以下だったらOKって言って、196センチだったら乗れませんよね。
これは確かにそうだと。
じゃあ195.1センチの人は乗れるんですかねと。
195センチ台ではあるから乗れてもいいんじゃないかって考えられる人もいるかもしれません。
195.1センチはダメですよっていう人に関しては、じゃあ195.01センチはいいんですかねと。
実際に計測とかしたときは普通にざっくり健康診断とかで計測した場合は195センチとして判断されるけれども、
厳密に言うと195.01センチです。
じゃあその人はダメなんですかねと。
っていう風に境界値はどこまで有効数字的な話ですね。
どこまで見て境界値として定めるのかっていうのは意外と奥が深かったりします。
ということで今回は境界値分析について話していきました。
質問コーナー：開発者とQAのテストの使い分け
最初は境界値分析でしょやったことあるよって思っていたかもしれませんが、
こういう風に話してみると意外と奥が深いなっていうことを理解してもらえたかなと思っています。
それではここからはお便りというか質問のコーナーですね。
以前いただいた質問を紹介していきます。
まず今回は紹介するのはこういう質問ですね。
エンジニアによるテストでどんなことをやっているのか。
QAエンジニアによるテストの使い分けが気になりますということで。
ありがとうございます。
これは組織によって異なったりするかなと思うんですけれども、
今日お話しした境界値分析みたいな話は、
開発者の中でも結構知られていてやっているところとかも多いかもしれませんね。
それ以外の例えば今後紹介していくディシジョンテーブルを使ったらとか、
状態遷移テストでやったらとかっていうのは、
なかなか最初は開発者も知らなかったりとかがあったりするかもしれないので、
そこは最初はQAエンジニアがやったりするかもしれません。
ただそれでも毎回QAエンジニアがやるかというとそうではなくて、
だんだん開発者にもこういうふうな考え方でやるといいですよっていうのを啓蒙していくことによって、
開発者自身がやれるようになっていくっていうのが一つの理想型かなと思っています。
そうするとQAとしてはもっとニッチな部分を攻めていこうとかになったりとか、
もっと開発者がどんどん増えていって開発とQAの比率がすごい開発が人数が多くなったときも、
自分たち自身でできるようになっていくっていうことを目指しています。
その上でけどちょっとここ仕様とかやろうとしていることが複雑すぎるので、
ちょっとQAエンジニアの人に助けてほしいみたいな感じで、
そのときにQAエンジニアが入るみたいなそういう使い分けになっていくかなと思っています。
ということで質問ありがとうございました。
エンディングと次回予告
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなどをどんなことでも構いません。
投稿本部は番組概要欄にあります。
またエピソードの感想は、
ハッシュタグBテスティングでXのポストをお願いいたします。
今日のお話でいえばですね、境界地面積知ってるよって思っていたけれども、
こういうとこって確かにそうなんだとか、
意外と知らなかったところとかそういうのも教えてもらえると嬉しいですね。
もしもこれからも聞きたいという方は、
お手持ちのPodcastアプリで番組のフローもお忘れなく
最新回が上がったときにすぐに気づけます。
実はこの境界地面積、続きものにしようと思っていて、
次回も境界地面積のもっと奥が深い部分、
しゃべっていこうかなと思いますので、
それが上がったときにすぐに気づけるようにぜひフォローをお願いします。
ということで今回はここまでです。
それではまた次回。バイバイ。
