Reader Art Salwin asks a good questions about an interesting distinction:

There seems to be quite a bit of contradiction in the literature between test conditions and test cases. Some places say the conditions have expected results (IEEE 829, for example). Other places say the cases have the expected results (some of the ITSQB study guides). There’s also disagreement about how high level a condition is. Some put it at pretty high level (test electronic payment, for example), others get down to if good credt card, accept; if bad credit card, reject.

Well, Art, there certainly is a lot of variation in the usage of certain terms in testing.  A number of terms, such as “test case,” “test condition,” “test plan,” “test strategy,” etc., are in very common use, but almost everyone seems to mean something a little different by them.  In addition, we have people using different terms to describe things that are the same; e.g., “test procedure” and “test script” and “test case.”  So, we get a lot of miscommunication in our profession.

To clarify communication, one thing I suggest, when talking to someone about testing, is to make sure that you’re speaking the same language.  If someone uses one of these common test terms, asking them what they mean by that term, and what specific contents he or she is referring to. Variation exists even within organizations, so a quick check to make sure you’re talk to each other, not past each other, is always a good idea.

Within an organization, it’s a good idea to adopt a single glossary for testing terms.  The ISTQB glossary isn’t perfect, but it is being constantly perfected and it’s certainly the most comprehensive testing glossary out there.  So, that’s probably a good place to start. 

It’s also important to adopt templates for common work products, because a definition by itself will not suffice.  For example, you and I could both agree on the ISTQB definition of the phrase “test strategy” and yet write different documents.  It’s important to remember that templates should be useful outlines that help people remember important topics to include in work products; templates are not straightjackets or substitutes for thinking.

So, going back to your original question.  If we take the ISTQB terminology and templates, then the test conditions are the higher level statements of what is to be tested.  In risk based testing, the risk items identified during a quality risk analysis are the test conditions (for more on how that works, see the video series on risk based testing on the Digital Library).  Examples of risk based test conditions would be “system responds too slowly to user input” and “system calculates incorrect report totals.”  In requirements based testing, test conditions are identified by an analysis of the requirements.  Examples of requirements based test conditions would be “check input field validation” and “check tax calculations.”  As you can see, these are at a high level.

The test cases are then developed to cover the test conditions.  One or more test cases should be associated with each test condition.  In risk based testing, the number of test cases for each test condition is determined by the level of risk associated with the risk item.  In requirements based testing, well, determining how many tests to have for a test condition is one of the problems with a purely requirements based testing strategy.  If you use a blended risk based and requirements based testing strategy, you can associate levels of risk with requirements to determine how much to test.

The test cases themselves can be a various levels of detail.  If you check Managing the Testing Process, 3e, you’ll find a discussion in there about the level of detail in test cases.  If enough people are interested, I can post some of that information on the blog.