はじめに
こんにちは！だいみょーです！
探索的テストという比較的耳馴染みが良い言葉のせいか、アドホックなテストが探索的テストと呼ばれているケースが散見されます（自分調べ）
弊チームでも探索的テストという名目で取り組んでいますが、持ち回りにしていることもあり、担当によってはアドホックになっていたり、テストの質があまり高くないという課題感があったりしました。
そこでやり方を改めて考えて、運用の見直しを図ったのでメモを残しておきます。
そもそも探索的テストとは
JaSSTのセッションのとても良い資料から拝借しましたが、 エリザベス・ヘンドリクソンさんの定義だと
直近の実験から得た”気づき”を次の実験へ活用し、テスト設計と実行を同時に行い、システムについて学習していくこと
とされています。
また、同じ資料に記載されている探索的テストに必要な3要素として、製品知識、テスト技術、バグの知識が必要とされています。 そりゃなんとなくやったところで質は上がらず、きちんと戦略立ててやる必要があるなという感じです。
引用： https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf
やったこと：チャーターに広がりを持たせるセッションベースドテスト
今日はこれが気になるからやってみて探索していこうというスタイルでも良いのですが、 結構ハードルが高かったりしたので、チャーターに深みが出るように工夫（後述）して行う方針でやることにしました。
また、ふりかえりの場を設けるという意味でも区切りを設けるセッションベースドの方がやりやすいのでそうしています。 では実際の流れについて説明していきます。
全体の流れ
- チャーターを考える
- セッション①開始
- フィードバックタイム
- チャーターの見直し
- セッション②
- フィードバックタイム
- バグレポートの起票
チャーターについて
探索的テストでチャーターを作成するケースはあるんじゃないかと思いますが、 「さあ作ってみましょう」だとどうしても観点が偏ったり、結局闇雲に網を振っているだけになるので、 作り方を少し工夫することにしました。
チャーターの作り方その①：ペルソナの帽子をかぶって考えてみる
プロダクトの利用者によって求められる品質が異なることもあるので、 成り切ってそのユーザーだったらこんな風に使うかもしれないという前提でチャーターを作成することにしました。
チャーターの作り方その②：品質特性を念頭に置いて考えてみる
弊プロダクトでは、機能性と信頼性が重視されるので、例えば品質特性のこの副特性だったらこんなことを気にした方がいいなとか、品質特性を念頭に置いたチャーター作りをすることにしました。
チャーターの作り方その③：今回のスプリントで発見されたバグを中心に考えてみる
これはわかりやすいですね。バグからこんなこともあり得るかもなという形でそこから仮説を立ててチャーターを作ってみるパターンです。
やってみてどうだったか
1時間弱くらいの時間でやっているので、1セッション1人1チャーターくらいの感覚でやっていますが、 チャーターを修正するというタイミングを作っていることもあり、経験のサイクルがちゃんと回っていい感じになりました。 また、きちんと探索することで、新しいドメイン知識を獲得できたり、学習の観点でも効果があってとても良かったです。
その他
先ほどのJaSSTの資料にもありましたが、QAEの勘所というか、境界値だったりCRUDに注目したりとか、ポイント的なところを羅列しておいても良いかなとか。今のチームはSWEがテストしているので、手助けする何かがあると効率的だなあと。
