「2.4 テスト分析と設計」では、テスト条件の特定と、テストケースの作成について解説しています*1。
わたしのように忘れている方のために書いておくと、テスト条件（test condition）は、
コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。たとえば、機能、トランザクション、品質特性、構造要素など (JSTQBシラバス)
とあります。テストをする際の事前条件（管理者権限でログインした状態で・・・とか）ではありません。混乱しやすい箇所ですね。
2.4.1 テスト条件の特定
テストの目的とテストベースから、テスト条件を特定します。
テストベース（test basis）とは、
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。 (JSTQB)
とあります。テスト設計をするための元ネタってことですね。
例を考えてみましょう。
ユーザからの検索リクエストに応えて、検索結果一覧を画面に表示する、という機能。これがテストアイテム。この機能について、「表示される結果は正しいか」「検索リクエストが1秒間に100件来ても耐えられるか」「表示された画面は、見やすいか」といった、確認したい切り口・性質が、テスト条件。
つまりテスト条件の特定とは、「テストする対象は何か」「その対象のどんな性質をテストするのか」を知ることですね。
さて、P.32から節の最後までは、第2章で最も難解と言っていいでしょう・・・。原文と訳文は以下。
The decision to determine the level and structuring of the test conditions can be based upon the functional and non-functional features of the test items using the following
テストアイテムの機能的フィーチャおよび非機能的フィーチャを基にして決定したテスト条件のレベルや構成は、以下のことに使える。
・・・・・・。自分なりに訳してみたのが、以下です。
テストアイテムの機能的/非機能的特性を元に、テスト条件のレベルと構成を決めることができる。それは、以下のこと利用する。
あんまり変わらないですね。
で、「以下のもの」とは、
- テストベースの粒度（granularity）
上位レベルの要件からは、最初は上位レベルのテスト条件しか出てこないかもしれない。たとえば「画面Xが動作することを確認する」。で、そこから下位レベルのテスト条件を導く。「画面Xは、正規の桁に1桁足りない口座番号を拒否することを確認する」。- プロダクトのリスク
例：下位レベルのテスト条件から具体的になったリスクの高い特性を、（テストの）対象として定める- マネジメントへの報告と情報のトレーサビリティに関する要求
- テストケースは作成せず、テスト条件だけでテストを行うかどうかの判断。
難解というか・・・うーん。
2.4.2 テストケースの作成
テスト技法を用いてテスト条件を詳細化・明確化することで、テストケースを設計していきます。キーワードは、「繰り返し可能」「検証可能」「要件トレース可能」。
テストケース（test case）の定義を確認しておきましょう。
入力値、実行事前条件、期待結果、そして、実行事後条件の組み合わせで、特定のプログラムパスを用いることや指定された要件の遵守を検証することのような、特定の目的またはテスト条件のために開発されたもの。 (JSTQB)
「テスト項目」と呼んでもいいでしょうね。
ここでいう「期待結果」は、たとえば画面の表示結果だけでなく、内部のデータや環境がどのように変化したか、ということも合わせて考える必要があります。
理論的には、テストベースさえ完璧ならテストケース作成も簡単なはず。でも実際には、仕様は曖昧だったり矛盾があったりします。また、たとえ完璧であっても、複雑な仕様であれば期待結果も複雑になりがち。
なので、専門的な知識に基づいて、「結果はこうあるべし」と判断することができる神からのお告げ・「テストオラクル（test oracle）」が必要です。
なお、IEEE829には、テスト設計の間に作成されるドキュメントの標準が用意されています。どんなドキュメントを作成するかは、採用する基準やライフサイクル次第。たとえば、アジャイルならドキュメントは最小限に、ということになりますね。
*1:（2011/8/14）2.4.1の日本語訳を修正しました。
