The first of five (5) subjects within Test Components & Preparation looks at "what" to test.
Deriving Test Conditions
Preparation for all Test Types begins by identifying and deriving the relevant Test Conditions.  The Test Conditions for a Solution represent the types of valid (and invalid) values that will be used to determine whether a given Test passes or fails.
Overview
Test Conditions define "what" should be tested.  Test Conditions are derived from a number of sources, including Acceptance Criteria, Acceptance Tests, future- state Business Process Definition(s), Features and Stories. In simple terms, a Test Condition is something that can be tested.
Test Conditions grow in complexity as the levels of testing increase. At the Unit Test level, most Test Conditions verify a single value. For example, that a date field can't accept text, or that a lookup field only accepts values from a list. Functional Tests will have conditions which combine values, such as a Customer Address Zip Code must match their State, or a Retail customer is prevented from selecting a Commercial Sales Type. Integration Tests will have conditions where outputs from some upstream function become inputs to some downstream function. Test Conditions are goals for each Test Case. What may be a goal of a lower-level Test Case can become a input to, or portion of, a higher-level Test Case.
Test Conditions should state the types of values used determine whether a given test passes or fails, not the values themselves. The values are provided by Test Data.
NOTE: Understand the distinction between Test Conditions and test values. A Test Condition represents a type of value (e.g., Sales Model or Product Type); a value is one or more variations for a given Test Condition (e.g., 'Direct Sale' vs 'Recurring Revenue' as values for the 'Selling Model' condition).
Each Test Condition should have a corresponding, manually created, high-level, Test Data Set which is a set of valid and invalid values as well as expected results for each. The values in the Test Data Set should be cross-referenced back to the design, specification, Feature or Story from which it was derived to allow traceability and to help keep the values focused and to a minimum. As Test Conditions are reused, so to are their Test Data Sets. It's huge waste of time to keep reinventing a list of values when they can more easily be updated and reused.
Test Conditions should also identify and include Boundary Conditions. Boundary Conditions are specific values that are too large or too small, negatives, nulls, chars vs. numbers, etc. These are values which may not even be valid for the given condition.  Delivery Team members and Solution Owners will validate the conditions and values to be tested.
Purpose
A Test Condition represents a constraint to be validated when testing the Solution.
Timing
Identification of Test Conditions and corresponding valid / invalid values should occur as part of Feature Analysis & Design and Story Analysis & Design.
In other words, during Feature & Story refinement; when creating functional and technical specifications for RICE objects, or specifying configuration of delivered objects. Doing so helps to ensure that the design or configuration specification is at a sufficient level of detail.
Opportunities for Reuse
- Any Test Condition can be applied to multiple Test Cases.
Derivation Example
Each time Acceptance Criteria is given in testable form - that is when a 'Given / When / Then' format is used - that criteria maps directly to a Test Condition.
Using this template structure whenever possible simplifies and standardizes requirements definition and corresponding test creation:
- Given: <some context or condition exitsts>
- When: <some action is carried out>
- Then: <an observable - and testable - result occurs>
Sample Test Conditions
- Given an authorized User wants to access the System
- When they enter both a valid <User Name> and a valid <User Password>
- Then they are granted access to System.
- Given my account has a credit balance
- When I attempt to withdraw an amount less than my balance
- Then the withdrawal should complete with no errors or warnings.
Next, see how Test Conditions can be applied to Test Scripts.