Part of software testing basics, you will have the test conditions. These are defined by ISTQB as A testable aspect of a component or system identified as a basis for testing. Test conditions 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$”.
Don’t forget, if you go specific, then expect a higher number of test conditions. Check what you need at that stage and adapt. It may not be the same for Component Test as for System Test.
Test conditions are the constraints that you should follow to test an application. Example: When User Name and Password are valid then application will move forward. These can be a piece of functionality or anything you want to verify. In simple terms the goal of a test case, an item or event of a system that could be verified by one or more test cases. Eg; transaction, function, structural element.
Contents
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.
