「ゆるWeb札幌 x TEF道 探索的テスト勉強会」に参加してきました
探索的テストの勉強会に参加してきました。
当日の様子はこちらのTogetterにまとめられています。
探索的テスト
探索は、「未知の事柄などをさぐり調べること」。
探索的テストは、テスト設計とテストの実行、システムについての学習を、対象を動かしながら並行して行うテスト手法。
- 頭の中で仮説をたて結果を予測し（テスト設計）
- テストを実行
- フィードバック（システムについての学習）
を行う方法で、テスト設計についてはあらかじめドキュメント化しておくことはしない。
お医者さんが患者さんに問診を繰り返しながら病気を見つけていくやりかたににている。
探索的テストとスクリプトテスト
探索的テストのメリット
- 軽快。テスト仕様書を書くコストを削減し必要なところだけピンポイントに確認する。短納期でバグを見つけたい時に良い。
- 柔軟性が高い。実物に合わせてテストの重み付けをその場で変えることができる。
- 暗黙知を活用しやすい。
探索的テストのデメリット
- 属人性が高い。実施する人のバックグラウンドやコンテキストにも影響される。
- 記録が残りにくい、再現させづらい。
探索的テストとスクリプトテストの併用
スクリプトテストと探索的テストは目的が違う。
スクリプトテストはバグがでないことを確認するのが目的だが、探索的テストはバグを出すのが目的。 なので、目的の違う2つのテストをうまく併用すると良い。
ワーク
テストチャーターを使う
簡単に言うと探索的テストの『道しるべ』となる。抽象度の高いテストケースや、機能リスト、リスクリストなど。テスト手順ではないということに注意。
お題：かんばんりすと
@volpe_hd28vさん作「かんばんりすと」を使って探索的テストを行ってみる。
テストには以下のチャーターを使用。
(対象) かんばんりすと を
(資源) マニュアル を用いて探索し
(情報) マニュアルとの不一致 を発見する
やってみた
自分は@volpe_hd28vさんを知っているので、最初に思ったのが「きっとClomeでしか動作確認してないだろうからブラウザを変えたらバグが出る気がする」ということでした。*1
あとポモドーロタイマーあたりが怪しいかなと。
このように、例えば実装者のクセとか、開発の経緯を知っている／知らないで予測すべきポイントが変わってくる。これが「バックグラウンドやコンテキストによる違い」というやつですな。
で、Safariで起動してテストを行っていたのでですが予想に反してブラウザ違いによる不具合は見つけられませんでした。
結局自分が見つけたのは2つだけ。
ディスプレイのサイズ（横幅）によってヘッダ部分の表示が崩れてしまう
BookのFilter機能が、特定の操作手順で正しくフィルタリングされないときがある
やってみてどうだったか
気を抜くとチャーターをガン無視していた
チャーターには「マニュアルとの違いを探す」と書かれていたのに、気がつけば自分の勘にたよってテストしてました。
スクリプトテストではテスト仕様書に書かれている通りに実施すればいいので、よく書かれたテスト仕様書であればあるほど考える能力を必要としません。
一方、探索的テストでは仮説と検証を繰り返す、すなわち想像するということが随所に求められるのですが、そういうやり方に慣れていないので気の赴くままに没頭しがちでした。。
時々モンキーテスト化していた
探索（仮説と検証）するということを意識しないと、手当り次第のただのモンキーテストになります。
考えることをやめると、人はサルになる…！
ピンポイントを攻めがちになった
「ポモドーロタイマーがあやしい」と思っていたのですが、実際にみんなで答え合わせしてみたら、バグが多かったところはもっと違うところでした。
「よく使うところのバグを潰す」「バグがでたら影響が大きい機能のバグを潰す」というのが効果の高いテストだと思うので、そうじゃない機能を局所的に攻めても、良いテストとはいえないですね。
まとめ
「探索的テストのほうが優れているから、みんなこれからは探索的テストの時代だよ！」というわけではなく、スクリプトテスト＋必要に応じて探索的テストを取り入れることによって、相乗効果が期待できる気がします。
ただ、説明でもありましたが属人性が高いと思うので、システムやテストの暗黙知部分を共有していくことが重要だなと思いました。*2
おまけ
余談ですが、かんばんりすとが昔使っていたときより進化していて、ちゃんとメンテナンスされ続けていることに感動しました。
