あさって12/17(木)の19:00から、「人類よ！これが探索的テストだ！テスト実況生中継で学びを深めよう！」というイベントがあります。
Intended Audience、人類ですからね。
今回は、QAエンジニア福田里奈さま（@_rina_ ）をゲストにお招きして「探索的テストのライブテスティング」を開催いたします。
アジャイル・DevOps時代のテストや品質保証として注目される「探索的テスト」。ただ、モンキーテストと誤解されてしまったり、そもそもやり方を説明できる人が少なかったりするのではないかと感じていました。
そこで、専門家に探索的テストを実況生中継（ライブテスティング）していただきながら、探索的テストがいったいどういうもので、なにができて、何ができないのかを参加者と一緒に考えていき、「探索的テスト完全に理解した」を目指したいと考えております。
われらがリナさん*1です。ハードルを最高まで上げての煽り、最高です。
さて近年、探索的テストについての「にし仮説」が発表されました。
にしの仮説「自分は探索的テストが上手いと思ってる人の9割は、単なるアドホックな典型シナリオテストしかできてない」
— Yasuharu NISHI (@YasuharuNishi) 2020年12月9日
わたし自身は探索的テストマスターではないどころか、自分でしっかりと取り組んだ経験にも乏しいので、探索的テストについて一家言もないです。
ただポエムとしては、先日の記事として以下のように詠じておきました。
個人的には、この3つ目が重要なのかなと思っています。
- テストの目的として、「バグを見つける」と「品質を把握する」がある。
- 「バグを見つける」目的は、怪しい箇所を素早く狙っていく探索的テストが有効に働きやすい。
- 「品質を把握する」目的に対して、探索的テストは特定のエリアのテスト観点の導出につなげることができる。
- スクリプトテストにおいても観点の導出は行うので、本質的に違いがあるわけではない。
前置きが長くなりましたが、人類の一員としてあさって探索的テストを学ぶにあたり、自分でも探索的テストをやってみようと思い当たりました。
対象は・・・ベリサーブさんが先月リリースしたテスト設計モデリングサービス・GIHOZです。
さすがに自分のものでもないプロダクションサービスを勝手にテストをしてブログに書くほど荒くれものではないのですが、中の人がいいと言ってくれたのでいいのです！ ふところひろし氏かよ・・・？
先に断っておくと、このトライでバグは見つけていませんし、そもそも模範的な探索的テストの流れを見せられるわけでもありません。
むしろどちらかといえば「幼稚な」思考過程をあからさまにすることになりそうですが、それは許してください。
準備
大方針
まず、大方針を以下としました。
- 1ポモドーロ・25分の中でやる。
- 「同値分割」を対象とする。
本当にバグを探ることが目的ではなく、勉強のためなので、時間を短く区切ります。
また同じ理由で、機能として一番シンプルに見える「同値分割」をテスト対象としました。
チャーター
GIHOZの同値分割では、パラメターの最小・最大を指定すると数直線が描かれて、その数直線上でのクリックで境界を指定するという直観的な操作ができます。
ちょっと面白いふるまいとして、たとえば「0」と「5」の間をクリックして境界に値「10」を指定するとエラーになるというものがあります。数直線上の位置を判断しているということですよね。
そういった振る舞いもあることから、このお絵かき部分を掘り下げてみることにしました。
『Explore it!』的フォーマットで書くと、
Explore the feature for drawing a number line with various data to discover how the feature behaves.
って感じでしょうか。適当英語です。
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing (English Edition)
- 作者:Hendrickson, Elisabeth
- 発売日: 2014/02/04
- メディア: Kindle版
実行
この節では以降、引用符部分はその時点で考えたことです。
まずは普通の数字を入れて、典型的な動作を確認しよう。
ということで、「普通の」数字を入れてみます。
特に問題なし。
オーソドックスに、変数の大小を逆転させてみる。
想定通りのエラーで、問題なし。
なお最大値＝最小値でも「逆転」となったけど、ヨシ。
大きな数字を試してみる。
最大桁はここまでのようです。
これでお絵かきすると、丸図形の中に数字が収まらなくなるけれど、マウスオーバーで値を表示してくれるので問題ありません。
では、最大幅を確認する。
入力OK。お絵かきも問題なし。
負の数としての最小じゃなくて、絶対値としての最小を後で、やろう。
先に増減幅の方が気になる。
まず、0.000...
これ0と見なされ、正しく怒られます。
絶対値の最小を、増減幅で試そう。
！？
0.0000001と入力した瞬間、指数表記になる。
これはどういう動きなのでしょう。気になります。
これはいったんおいておいて、定義域最大、増減幅最小でお絵かきしてみる。
境界もキワキワにおいてみよう。
これも通って正しくお絵かきできました。
ん？ このように増減幅ギリギリに境界を設定すると、パーティションの上限下限が同じ値になって、図上で表現できなくなるのでは？*2
だけどこれは別に小数じゃなくても整数でも確認できるので、あとで。
上限側もやっておく。
スクショはありませんが、これも正しく描画することができました。
この状態で、同値分割を出力してみよう。
とっくにチャーターから外れてはいますが・・・。
「値の範囲」を見て一瞬びくっとしましたけど、この「4」は、適当に付けたパラメター名でした。
この代表値はどうなってるんだ？ これまでの感じだと、パーティションの上限と下限の真ん中に設定されていたと思うけど・・・。
負の数が入ると何か動きが変わるのか？
気になるけど、先にさっきの指数表記を触ろう。
キャプチャはできませんが、「0.0000009」を「9e-7」にする（そして無効エラーが出る）だけでなく、「3e8」も「300000000」にされます。
途中まではこうなのですが、この次に「6」を入力すると急に受け入れてくれます。
これは明示的に作り込んだ「機能」なのかはわかりません。
実際にはプログラマーに質問して、意図しない挙動ならもう少し深掘りするのかなーと思いました。
次に行きます。
ついでに、増減域広すぎパターンを見ておきたい。
何を入れても境界外になりますね。やってはみたものの、パラメターの仕様として通常ありえないはずなので、深掘りするところでもないでしょう。
刻みを中途半端にしても正しく計算できるかも確認しておく。
これも正しく計算できています。
ちょっと戻って、さっきの代表値算出を、負の数でやってみよう。
特に問題なく、平均値になっている。
定義域がマイナス～プラスだとおかしくなったりする？
やっぱり平均値になっているっぽいなー。・・・あれ！？
よく見たら、最大値と最小値が一桁違うじゃん・・・。
そうなんです。正は、999,999,999。負は、-99,999,999。
そりゃ平均値もプラス側にずれますよね。
しかしやはり不思議な気もします。最大値と最小値の絶対値は、揃えるのが自然に思えるけど、何か意図があるのでしょうか。値そのものじゃなくて、マイナス記号含めて「文字列長」で値範囲が決まっているようにも見えます。
これもプログラマーに聞いてみるやつでしょうかね。
ここらでだいたい25分終了となりました。
やってみての感想
探索的テストは、テスト対象を学習しながらテスト設計・実行していくものとされています。
ですがこうやって過程を書き出してみると、（わたしの場合）思考が発散し、チャーターからも逸脱して、まったくシステマティックにならないことにあらためて気づきます。もちろん修練を積めばそんなことないのでしょうが。
ただ今回のように、気になった点を都度メモっておくと、それをテスト観点として、いわゆるスクリプトテスト向けのテスト設計につなげられるのかなとも思います。
今回でいうと、
- 数字の桁数のコントロールってどうなってるのか。
- 指数表記ってどういう期待動作になっているのか。
あたりは、実装している人と話しながら、次のテストにつなげていくのかなーと。
予習はこんな感じです。リナさんの探索を楽しみにしています！
"Maze Wallpaper Green" by Tiger Pixel is licensed under CC BY-NC-ND 2.0
