テスト設計する前に、テスト対象を適切に分割し、分析した方がよい例
1. 結論
- テスト設計するときは、テスト対象を適切に分割してから分析した方がいい場合がある
- カッチリ固めるタイプのモデルを書く際に、ある側面を記述しているということを忘れない。
- 目的・どの側面からの見方に注目しているのか、事前に厳密で的確なラベル付けをする
- ラベルからのズレを感じたら、ラベルまたはズレを修正する
- 処理手順の視点が抜けていると、ピンぼけなテストをしがちなので、外部・内部設計、実装に関与したい気持ちしかない
2. 背景・課題提起
WACATEの同値分割のワークで以下の問題が出題された。
同値分割になりそうなものを、早速挙げていった観点がこちら
上記の観点図だと、以下の課題を含むことになる。
1. テスト対象や目的を考えていないので、入力値の組合せパターンをどう扱うか悩んだ。
2. 入力値の分析をするための図のはずが、組合せテストの分析にも踏み込んでいる。
以下の章で、それぞれの問題に対する方策を記載する。
3. 方策
1.テスト対象や目的の確認
テスト対象や目的の確認 として、テスト対象を、テストレベル、処理手順などに小さく分割する
インテグレーション・コンポーネントレベル
処理手順を分割して観点を洗い出すとスッキリしそうですね。
仮に以下の処理手順だったとして、処理手順ごとに観点を出す。
処理手順
1.入力欄に入力する
2.検索ボタンを押下する
3.受け取った文字列を、スペースを区切り文字として、分割する（パース)。データベースに投げる
4.データベースから検索結果が返ってくる
5.返ってきた検索結果を一つに纏める (データベース側でやる可能性もありそうだけど)
6.検索結果を画面に表示する
各処理手順に対する、観点と同値分割適用の例
1.入力文字数の制限(入力文字数)、検索履歴のサジェスト
2.検索ボタンを押下可否(入力文字数)
3.文字列の分割の有無（スペースとそれ以外)
4.検索ヒット(名前・電話番号、文字コード・文字幅・文字種、前方・後方・部分・完全一致)
5.ヒットの重複の排除(同じIDのデータのヒットの有無)、ソート
6.検索結果のページング処理(検索ヒットしたデータ数)
システムテストレベル
上記の処理とは別にユーザーの想定するデータ入力パターンとして、名前×名前のケースなどが考えられる。
入力値の組合せの因子も電話・名前・スペースあたりに収まって、シンプルになる。
2.入力値の分析をしていたはずが、組合せテストの分析にも踏み込んでいる問題
入力値の観点を洗い出していたのにも関わらず、途中で入力値の組合せを同じ表で扱おうとしていた。
マインドマップでは因子の側面に絞って抽出し、有則・禁則・無則は別の見やすいモデル（マトリクスなど）を利用するのが適切だった。
というのを、ブロッコリーさんのツイートを見て気づいた次第。
つまり、1次ノードの「入力パターン」洗い出しは不適切である。
