クリスマススペシャル『テストチャーターの作り方』
この記事はソフトウェアテスト Advent Calendar 2024の24日目の記事です。
今回は探索的テストの時に使うテストチャーターの作り方のお話です。
フリースタイルの探索的テストはマネジメントも実行も難しい
何かバグを見つけたいから全体的に探索的テストする、ということはテストを行っている皆さんは経験があるかと思います。
作者もよく実施します。
この探索的テスト実施によって「あ、そんな問題があったんだ！」ということが色々と見つかります。
ですが、マンガに描いたように何に対して探索的テストの目が通っているか、何に対して探索的テストの目が通っていないかなど、実施範囲の把握が難しくなってきます。
また、メンバーにお任せスタイルだと探索的テストの実施個所に偏りも発生します。メインの機能は深掘りされているけど、少しマイナーな機能は影響範囲にもかかわらずほとんど探索的テストの目が通っていないなどです。
不慣れなメンバーですと「全体的に何か探して」と言われてもどうしていいかわからずに動けなくなってしまいます。
テストチャーターを作る
「全体的に見て何かを探したい」を深掘りして分解するともう少しマネジメントしやすい形になります。
この「全体的に……」の理由は「なんか不安だから」がほとんどかと思います。
その不安をもう少し考えていくとこんなことが見えてきます。
「～とかなったらイヤだな」
「こういうことがあったらどうしよう」
これがあなたが想定するリスクです。リスクの識別です。
これができたなら、その列挙したリスクをひとつずつ狙って確認していきましょう。
そのリスクを狙うためのドキュメントがテストチャーターです。
テストチャーターのテンプレート
マンガにも書きましたがこんなテンプレートがあります。
Explore <Target>
Using <Tools>
To discover <Risk/Information>
by "Explore It!"
<リスク/情報>を発見するために、<ツール>を使って、<ターゲット>を探索する
テストチャーターによって、何を発見するためにどこを探索するかがハッキリします。その探索的テストで何をすればいいか、何がゴールかがわかるわけですね。
ちなみに「ツールを使って」になっていますが、これは別に外部ツールを必ず使えという意味ではありません。
何かしらのデータセットを使って、とか、意地悪漢字を使って、など何かしら用いるものを指定します。
マンガでも本当は「情報を使って……」と書きたかったのですが、発見する情報と被ってしまうので「データ/ツールを使って」という形で描いています。
他にも以下のようなチャーターがあります。（作者的には一番最後が好み）
My mission is to test <Risk> for <Coverage>
by Tips for Writing Better Charters for Exploratory Testing Sessions - EuroSTAR - Michael D.Kelly
私のミッションは<対象>で<リスク>をテストすることだ
※この方の話の内容的にCoverageは僕たちが思い描くカバレッジではなく、対象や範囲の意味を指していそうです。
Look at <Target>
To test for <Test Idea>
by Web API テスト技法
<テストアイディア>をテストするために、<ターゲット>に着目する。
とはいえ「想定していない何かを発見したい」もある
こういったことを書くと
「リスクが思い浮かばないからチャーターを使った探索的テストができない！」
となる人もいるかと思います。
蛇足かとも思いましたがマンガの4ページ目にその辺を描きました。
「機能Aに着目して何かしら探す！」といった、ひとまず何か対象に着目して漁ろう、といった形です。
もちろん対象は機能だけではなく、シナリオでも良いです。
フォーカスするターゲットを決めるだけでも、「全体的に何か探す！」よりも実施したカバレッジもわかりますしマネジメントしやすくなります。
セッションベースドテストマネジメント
セッションベースドの探索的テストの作者がイメージする流れは以下です。
探索的テストのサイクルが、1回のセッションの中と、セッション間でのサイクルの二重のサイクルになっているイメージです。
まずはテストチャーターを用意します。
(例：入力エラーをテストするために、入力ボックスに着目する。時間:15分）
そして時間を区切って（作者は40分とすることが多め）、テストチャーターに沿って探索的テストを実施します。
探索的テストの実施が終わると、様々見えてくることがあります。
（例：入力エラーは問題ないけど表示崩れがいっぱいあるぞ！）
それをデブリーフィングで共有、分析と学習を行い、次のテストチャーターに活かします。
(例：表示崩れをテストするために、出力表示箇所に着目する。時間:30分）
この時、新しいテストチャーターを用意するのか、「テストチャーターのリストを作ってるから次のチャーターをやろう」のように事前に用意したチャーターを実行するかはその時々です。
