探索的テストにおける期待値（基準）の作り方
スクラムフェス新潟2022で話した内容です。
探索的テストは基本的には期待値を自分の中に作ってテストを実施していきます。（もちろん仕様書を見ながらのときもありますが）
その期待値はどうやって作るんだろう？という質問が多かったので本や自分の経験からまとめみました。
簡単な説明
探索的テストではバグだけではなく「違和感」にも気を付ける。 通常の状態と違うときに「違和感」を覚える。 通常の状態を形成する基準*1となるモノは以下の6つ。
- 以前のソフトウェア（変更前）はどう動いたか？
- 同じソフトウェア内の類似の機能はどう動くか？
- 社内の別のソフトウェアはどう動くか？
- 社外のソフトウェア（競合他社やデファクトスタ ンダード）はどう動くか？
- 現在のトレンドはどうか？
- 法令やスタンダードに沿っているか？
もちろん上の6つ以外にも会社独自のガイドラインなども入ってくるかもしれません。 また今回は敢えて仕様書というのは抜いています。 仕様書が神という方がいますが、最終的にはユーザーがソフトウェアの価値を評価をするため、バグみたいな仕様でも仕様書に書かれていればバグじゃなくなる訳ではないです。仕様書は紙、ユーザーが神。（個人の意見）
このうちのいくつかはExplore It！の「第5章 Evaluate Results 結果を評価する」にもう少し詳しく書かれています。 特にNever and Alwaysという概念は探索の中で必須になってくると思います。
*1:基準という言葉が気になる人は「標準」とか「法則（ルール）」という言葉でも良いと思います。
