事前条件とテスト観点について整理する

テスト

テスト観点について何気なく調べていたところ、こちらで議論されているのを見つけました。
テスト観点と実装実施時要検討事項 - Togetter
丁度自分が悩んでいたことに少し関係があり、自分なりに整理します。
また、引用先の議論で自分の今の力量では今回理解できそうでできなかったところも多々あるので、今時点で自分が腑に落ちたところだけ書きます。


事前条件とテスト観点について

経験上、そして今回議論されているようにテスト手順書の「事前条件」に書くもの（書いてしまうもの）の意図は、大きく分けると以下の2つがあります。
引用先の議論で使われている言葉を用いて、下のように表現します。

・テスト観点（テストケースの意図を満たすもの）
・実装実施時要検討事項 ※1
　-テストケースの実施に必要な事前準備（テストケースの意図を満たすものではない）

もしその事前条件がテストケースの意図を満たすために必要なら、それは事前条件ではなくテストケースそのものに含まれるべきで、それはテスト観点（やテスト値）のはずです。ただ他のテスト観点と違うのは、何らかのトリガによって事前に実行されている可能性が高いということです。

逆に、その事前条件がテストケースの意図を満たすために必要無ければ、それは単なる事前条件であり、テスト観点ではありません。
参照：
テスト観点と実装実施時要検討事項 - Togetter

棲み分けないことで起こったこと

タイムリーな話として、自分がテスト設計していないテスト手順書を実施した時、頭でこの区別がはっきりできていない事による弊害を感じました。
具体的には、あるケースの中に明確に特定の環境や値が記載されておらず、実施者によって任意で選択されるものがある場合、任意の一つの値を選択するだけでなく「別の値だとどうなるだろう？漏れがないだろうか。」と深読みしすぎて考えを広げてしまいました。参照先でも似たようなことが記載されています。

しかし一般的なテストでは、テスト観点と実装実施時要検討事項を厳密に峻別しません。それによってテスト観点の漏れを防ぐ側面もあるからです。そのため、実装実施時要検討事項なのに境界値を選んだり網羅しようとしたりします。したがって混同してしまいます。

参照：
テスト観点と実装実施時要検討事項 - Togetter

まさに「漏れがあるかも」というモチベーションで考えを広げましたが、振り返るとケースに書かれていない観点やその期待値にばかり気を取られていたと思います。

とはいえ、設計者のテスト観点漏れを拾える場面でもあるので一概に悪い行為ではなさそうです。

 

棲み分けないために起きること

以下で引用した図は実装時実施時要検討事項の棲み分けの議論で出た図です。
こちらに続くスレッドに書かれているように、もし棲み分けされていれば、「保証しないことが明確になる」のはテストとして確かにメリットだと思いました。

 

これから実施したいこと

テスト実装や実施時に、テストケースの記述を書いたり見た時に「実施時要検討事項（C）」のように見えるものが本当に（C）なのか、テスト設計で漏れていた観点（B）の可能性がないかを検討したい。