テストケースの”事後条件”って何のためにあるのか

JSTQBで定義されている「事後条件」について、私自身の解釈が違っていたのでメモを。

これまでの自分自身がテストをしてきた経験で、テスト実行したときには不具合が出ていなかったのに、テスト実行したその後の状態で不具合が発生することがままありました。
例えば、複合的なテストにおいて、ある機能（A）とある機能（B）をぶつけるテストをしたときに、ぶつけたときはちゃんと優先順位が考慮されていて問題なかったんだけど、その後、ぶつけられたAの機能を動作させようとするとうまく動作しなかった、ということがありました。

そういった経験をしてきていたので「事後条件」は、何かの処理の後にどうなっているかまで確認すべき内容として書かなければいけないと思っていました。

しかし、実際に事後条件をテストケースに作成しているとその解釈が誤っていることに気づきました。事後条件を書く意味は、テストケースセットを作り出すため、なんですね。
確かに前述の私の例だと単に期待結果の書き方が悪いだけで機能同士をぶつけた後もきちんとそれぞれの機能が働くことの確認を期待結果として表現すればいいだけなんですよね。

事後条件を書いておくことで、事後条件と別のテストケースの事前状態を合わせることで効率的なテストができます。簡単な例でいうと、事後条件が電源OFFで、別のテストケースの事前条件が電源ONだと、テストケースを終えた後、別のテストケースの事前状態を整えるために一度、電源ONにするという行為が発生します。しかし、事後条件と事前状態をそろえておくと、電源OFFにするテストケースを終えた段階で、別のテストケースの事前状態を既に作り出せている、ということになります。

今回の例だとさほど手間はかからないのですが、テストにおいては事前条件を整えるのに非常に手間がかかるものもあります。例えば、メモリを初期化する、だったり、バージョンアップのテストのためにバージョンを一度下げるためにソフトを書き換えたりする必要があります。そんな場合はうまく効率的にやらないといけないです。

よって、事後条件は、別のテストケースの事前状態を結び付けるためのもの、と定義できるので、事後条件に何を書くかは、事前状態として何を設定するのかに依存していると言えます。

自分にはなかなかなじみのなかった事後条件ですが、これでぼくの中ですっきりしたのでプロジェクトメンバーにもちゃんと説明して、理解してもらえそうです。