この記事は ACCESS Advent Calendar 2019 6日目の記事です。
今日は忙しい人のためのテスト設計スキルトレーニング（初級）について書きます！
ざっくり言うと
「ながらダイエット」ならぬ「ながらテスト設計トレーニング」です。
- 試験票の要約はテストのリバースエンジニアリング ≒ テスト設計、テスト結果報告にも使えるので是非やろう
- テストケースからねらいとコアを抽出しよう
- 順番が大事
はじめに
- 試験票をレビューするのが大変 or いまいちよい指摘ができない
- テスト設計は大事だと思うが、業務プロセスに組み込めていない
- テスト技法を勉強したが、業務でうまく使えない
ということはないでしょうか。
これって言い換えると
- 本当はテスト設計をレビューしたいが、できていない
- テスト技法を使うための材料出し（観点出しやモデリングなど）に慣れていなくて使えない
ということではないですか？
この問題の解決法は色々あると思うんですが、その一つとして
「試験票レビュー前またはテスト結果報告時に試験票を要約する（してもらう）」
という方法はどうでしょう。
テスト設計の話なのになぜ試験票の要約なのか？
実は試験票の要約とは「テストのリバースエンジニアリング」で、出来上がったもの（要約）は簡素かもしれませんが「テスト設計書」になっているんです。
試験票要約でテスト設計スキルトレーニングを行うこの手法のメリットは以下です。
- テスト結果報告（or試験票レビュー）という既存のプロセスを変えなくてよい
- テスト設計プロセスがなくても（テスト実行後でも！）テスト設計・設計レビューできる
- 今まで通りの業務をしながら自然にテスト設計スキルを上げられる
- テスト設計書ができあがる
- テスト結果報告も要約がついて分かりやすくなる
- 「テスト設計」という言葉に拒否反応がある人がいてもこっそり導入できる
どうでしょう。やりたくなってきませんか？
「試験票の要約」というと簡単そうですが、「試験票の力を100%活かせる要約」を作るにはただ単語を拾い上げていてはダメで、試験票の裏に隠れている（ことが多い）「試験票の内面 = テスト作成者の考え」を抽出しなければいけません。
キーワードは「ねらい」「グルーピング」「コア」「順番」です。
テストのねらい（意図）を書け
あなたがテストケースを作るとき、必ず何か確認したいことがあるはずです。それを言葉にしてみましょう。
コツは「複数の（ただし全てではない）テストケースをまとめて説明できないか」考えてみることです。まとめようとすると抽象化しやすくなります。
ダメな例：ログ送信機能が正しく動いていること
→全てのテストケースが該当してしまう
よい例：送信されるログのフォーマットが仕様通りであること
→フォーマットに関するテストケースだけが該当する
テストケースではNGワードとされている「仕様通り」などの曖昧な記述が入ってしまっても「ねらい」ではあまり問題ありません。紐づくテストケースの方では「仕様通り」を具体的に説明できているはずだからです。
グループのねらいを説明する文を考える（文を修正する）
↓↑
ねらいに当てはまるテストケースをグルーピングする（グルーピングし直す）
のループを何度か行い、ねらいとグループを最適化します。
唯一解があるわけではないので、大体で大丈夫です。
どうにも他のテストケースと一緒にできないテストケースは、単一のねらいとテストケースのままでもOKです。
ねらいを階層化する
ねらいを階層化してもいいでしょう。
個人的には2階層あると「ふんわりした意図-具体的なポイント」というように分けられるのでやりやすいです。
階層化しすぎると上の方は抽象化され過ぎ、下の方は具体化され過ぎになってしまうので、2〜3階層に収めます。
例：
* ログが規定のフォーマットで送信されるか
* ログ送信先が指定通りか
* リクエストメソッドがPOSTか
* ログ本体のフォーマットが規定通りか
* ログ送信の条件が仕様通りか（正常系）
* 送信契機Aで送信されるか
* 送信契機Bで送信されるか
* ログ送信の条件が仕様通りか（準正常系）
* トークンがないとき送信しないか
* 画面滞在時間がN秒未満のときは送信しないか
* エラーが発生した場合はリトライするか
この例だと結構具体的なので次の章で触れるコアとほぼ1:1対応になるのでコアの抜き出し作業はあんまり要らなくなりますが...。
試験票を要約できればよく、ねらい/コアを厳密に区別したいわけではないので、「文ならねらい、単語ならコア」を一応の目安にしつつ、気楽にやります。
テストケースのコアを抜き出せ
次は、ねらいに紐付くテストケースからそれぞれを特徴づける要素 = コアを抜き出して分類します。
同じグループのテストケースAとテストケースBの違いを探すと特徴が見つかると思います。
そして特徴を並べてみるとその中でも似たものと違うものが出てくるのではないでしょうか。
（ただし、ねらいに紐づくテストケースが少ないときは同種しかないこともあります）
先程のログフォーマットの確認であれば、以下のようなものが出てきそうです。
- 日付時刻、ユーザID、区切り文字、ステータスコード、...
- うるう秒、xxデータ取得失敗時、マルチバイト文字、...
前者はログを分割して各部分を、後者はデータの内容がちょっと特殊な場合の動作を確認するテストケースです。
ねらいにコア分類をぶら下げてみます。
-
送信されるログのフォーマットが仕様通りであること
- ログの各部分（日付時刻、ユーザID、区切り文字、略）
- 特殊なデータ（うるう秒、データ取得失敗、マルチバイト文字、略）
これも具体的にユーザIDやマルチバイト文字に何を使ったのかはテストケースで決められているか実施結果備考などに書いてあるはずですので、ここで書かなくても大丈夫です。
もしデータ取得失敗にも色々な場合があったり、文字種をもっとたくさん確認しないといけないのであればリストを一段階深くしてもいいでしょう。
順番にこだわれ
順番は大切です。
出来上がったリストを「分かりやすく」並べ替えましょう。
並び替える目安は以下です。
* 重要なものは上に
* 似たものは近くに
* 基本的なものは上に / 発展的なもの、例外的なものは下に
* 大きい、多いものは上に / 小さいもの、少ないものは下に
* 抽象的なものは上に / 具体的なものは下に
* 単純なものは上に / 複雑なものは下に
例えば「正常系のテスト」と「異常系のテスト」では前者の方が重要かつ基本的です（正常系が動かないとまず使えません）ので、正常系のねらいやコアを先に並べます。
他にも「NGが出たものは上に（=プロジェクトにとって重要）」「機能系/非機能系でまとめる（=似たものは近くに）」「単機能系 > 組み合わせ系の順で書く（=単純なものは上に）」などが考えられます。
何が重要か、何は似ているのか、はプロダクトによるかもしれないので「このチームではどういう順番が分かりやすいのか」を話し合ってみるといいですね。
完成！
テストの概要を説明するリストができました！
これで試験票を読むよりも断然早く全体を把握できます。
もし「観点が足りなくない？」「具体的な値は？手順は？」と気になったら、試験票のその部分だけを見れば済みます。
また、自然な文で書かれた「ねらい」があることでテスト作成者がテスト対象をどう理解しているか、どのように（何に注意して）テストすれば良いかが分かるので、
- 作成者の理解に間違いや不足があった場合に気付きやすい
- 作成者と実行者が違っても認識違いが起きにくい
というメリットもあります。
他にも紐づくテストケースの量とねらいの重要度・抽象度の関係を見ながらレビューする、など色々な使い方ができるのではないかなぁと思ったりしています。
おわりに
いかがだったでしょうか。
「こんなんでいいのか」「やってみようかな」と思ってもらえれば幸いです。
気軽にテスト設計して 最強テスター を目指しましょう。
【余談】
普段身の回りで使っている試験票に対して「分かりにくいな」「使いにくいな」「大変だな」と感じることがあるんですが、それはにし先生が下記で解説されているような方法で解決できるんじゃないかと思っていて、なんとかこれを現場に取り入れていけないかということを来年は考えてみたいです。
テスト観点とテストケースとテスト手順を区別する by テスト設計コンテスト'20 チュートリアル
さて、明日は @SekiT が正規表現について書いてくれるようです。お楽しみに！