テスト条件と検証内容

JSTQBの定義ではテスト分析のアウトプットはテスト条件です。

>A testable aspect of a component or system identified as a basis for testing.

ISTQB Glossary

どんなテストをするか考えた結果出てくるものがテスト条件、と捉えるとよいと考えています。

また、HAYST法において類似した概念と言えば、FV表の中の検証内容が該当すると思われます。（ちなみに僕はHAYST法のプロではないので、疑念が生じたら原典に立ち戻っていただければと思います。）

＞FV表は、機能とその検証を行う条件を整理するために作られる一覧表である

＞検証内容：希望する商品が速やかに検索できること

（ソフトウェアテストHAYST法入門より）

テスト条件や検証内容を考える際に、どんなことに注意した方がよさそうか考える機会があったので、その内容をちょっと書いてみます。

テスト条件は抽象度がさまざまある

テスト条件の定義としては、"testable aspect"だけなので、抽象度についての議論はありません。なので、特定のコンポーネントやシステムの「テストしたいこと」が表現できていればそれはテスト条件になりうると言えます。ただ、テスト分析の次のプロセスはテスト設計です。テスト設計ではテスト設計技法を適用してテストケースを生成する必要があります。テスト設計技法を適用できるぐらい具体性を持ったテスト条件にしないと、先に進めないわけです。

よって、テスト条件はさまざまな抽象度で表現できるけれども、テスト設計に使うテスト条件は具体的でないと困る、と言えると思います。

テスト条件は主に二つの目的に使われる

一つ前のトピックで説明しましたが、テスト条件はテスト設計の入力として使われます。これが最も大きなテスト条件の役割です。僕は、もう一つテスト条件の役割があるのでは、と考えています。それは、テスト分析の出力としてのテスト条件です。…これだけでは何も言っていない感じがしますね。

言い換えると、テストをしたいことを誰かに説明するためのテスト条件、です。テスト条件が決まった段階で、ステークホルダーと合意を取ることはベストプラクティスだと思っています。JSTQB的なテストプロセスとはずれますが、テスト条件が識別できた段階で初めてテスト計画が完成するイメージです。

このステークホルダーとの合意のためには、テスト条件はある程度抽象度が高い必要があると考えます。上で示した検証内容の例ぐらいのレベルです。

テスト条件は行ったり来たりする

一つ前のトピックで語ったテスト設計のためのテスト条件と説明のためのテスト条件ですが、多くの場合は前者の方が具体的です。また、多くの場合は後者が先に導出され、そのあとそれを詳細化する形で前者が識別されます。ただ、単純にシーケンシャルに進むというよりは、詳細化したら元の抽象的なテスト条件があいまいだったことが明らかになり、それを修正する、というような流れがぐるぐる回るイメージです。

テスト条件はテスト開発のプロセスの中で一番大切と言ってもいい成果物であり、いろいろな目的につかわれ、いろいろな形を持つものだと思っています。

また、テスト条件という用語はソフトウェアテストの用語の中でも一二を争うConfusingな用語です。

ここを正しく理解して、よいテストの開発ができるようになりたいな、と思っています。