Pat of software testing basics, you will have the test conditions. These represent an item or event of a component or system that could be verified by one or more test cases (ex: function, transaction, feature, etc.). A test condition may or may not specify values or variables. It all depends on the context at that test level. Some might be generic like “Test Payment” and others may be specific like “Test Payment with VISA for 3 items and a cost over 100$”.
Advantages of detailed test conditions
- More flexibility in relating other test work products
- Better and more detailed monitoring and control
- Contributes to defect prevention by occurring early
- Relates testing work products to stakeholders in terms that they can understand
- Influences and directs other testing activities, but also other development activities
- Enables test design, implementation and execution to be optimized by more efficient coverage
- Basis for clearer horizontal trace ability within a test level
Disadvantages of detailed test conditions
- Potentially time-consuming
- Maintainability can become difficult
- Level of formality needs to be defined and implemented across the team
GO detailed when
- Lightweight test design documentation methods
- Little or no formal requirements or other development work products
- The project is large-scale, complex or high risk
GO generic when
- Component (Unit) level testing
- Less complex projects where simple hierarchical relationships exist
- Acceptance testing where use cases can be utilized to help define tests
This article is based on the ISTQB Advanced Syllabus version 2012 and it also references the ISTQB Foundation Syllabus version 2018. It uses terminology definitions from the ISTQB Glossary version 3.2.
In late 2019 we have launched A Test Manager’s Guide eBook that stands as the base for this article. You can check out more useful test management lessons by enrolling for free to view Chapter 1 – Back to the basics.