Test Conditions

Test Conditions is a term that has multiple definitions. For the sake of this blog, we are going to define them as the equivalent of (Low Level) Test Objectives and state that they are One-Line statements of what is going to be tested. (High level Test Objectives may relate to more system level objectives and some of them may be derived from the Project Charter or plan.)

For example, the Test Conditions may read as follows:

1. Test that the system calculates interest correctly.
2. Verify that the design allows for 100 simultaneous connections.
3. Validate that the user interface is accessible according to the corporate standards.

The question that frequently arises is why bother to write these Test Conditions? It seems like an extra step with minimal return. Why not just go directly to the Test Cases?

We use them for a number of reasons.

1. They allow the tester to consider the entire system rather than getting into detailed test cases at the first step.
2. They allow other stakeholders to review the test coverage without having to read through full test cases.
3. They can identify coverage and omissions in coverage with limited effort.
4. They allow for estimation of the number of test cases that will be needed before the testcases are written.
5. They allow for estimation of the test effort early in the project.
6. They can help identify the components of the test environment earlier allowing it to be specified and built before it is needed.
7. They determine the required test data and allow it to be gathered and made ready before testing starts.

We have found that the effort in building test conditions is more than paid back in early information and helpful triggers for what needs to be done.

Discussion Questions

1. Do you write Test Conditions or Test Objectives?
2. Were they beneficial to the project?
3. What would you have done differently based on what you know now?

Next Week: Process Improvement – Deal with Results