手順通りに実施して期待値が確認できるか？
- 期待値を確認するために、手順が十分か。
- 期待値を確認するために、今の操作が期待値を確認できない画面にしてあったりする。
期待値に手順が入っていないか？
- これも結構ある。期待値は期待される値なので、手順は入れないほうが良い
- これは別に事前準備・テストと分けておくべき
このテストを実施する人が、そのテストで何を確認したいかを理解できるか？
- テストで確認したいことを理解できれば、仮に手順が間違っても修正できる
- 逆に確認したいことが理解できないと、何も修正できない闇になる
- テストの保守性を考えると、観点が明確になっている必要がある
このテストを後日実施した時に、差を検知することができるか？
- テストの手順と期待値を明確にしておけば、バージョン間で動作が変わった時に検知しやすい
- 逆に以下のようなテストケースは差が発生していても検知できないおそれがある
- 任意の文書を開いて、アクセス権限に従ってツールバー上のボタンの有効・無効が反映されていること
- 正常に動作していること
- 適切な値が表示されていること
- 仕様通りに動作していること(これは最悪仕様が全部書いてあれば何とかなるけど・・・
自分以外の人（仕様を知らない人とか製品に詳しくない人）がテストケースを見ればテストを実施できるか？
- このテストを誰が実施するかを想定しているか。省略した結果、テスト実施者が実行できないようなことになっていないか。逆に、テスト経験者向けにくどい説明をしていないかリグレッションテストケースに含めるべき内容
網羅性 VS 効率性
- すべてのテストケースを含めることはできない(リグレッションテストは膨大に存在するから、ほかのテストを行うための工数も考える必要がある)
- なので、テストケースに優先順位を追加する、もしくは必要ないテストケースを省く
必要のあるテストケースの優先順位をつけているか
- すべてのリグレッションテストを行うことは、難しい
- テストケースに優先順位をつけておく必要がある
- 優先順位の基準①人が使うときに、困ることがないか
・その機能は、多くのユーザーに利用されているか
・その機能は、頻繁に利用されるか
・その機能は、壊れたら致命的なエラーが起こるか
- 優先順位を考えるには、ユーザーのユースケースを考える必要がある
※ ただし自動テストに関しては、ある程度冗長でも構わない
テストケースの評価ポイント
- どんなテスト実施者が行っても、なるべく同じ手順になる(再現性)
- テスト実施者がなるべく早くテストを終えることが手間どらずテストを行うことができる(簡潔性)
- 事前準備の操作も、手順にだけではなく、なぜその手順が行われるのかを理解しやすくする必要がある(保守性)
- そのテストによって、より多くの回帰バグを見つけることができる(バグ検出力)
