In the ISTQB Foundation Level syllabus, test analysis and design are grouped into one topic. However, the ISTQB Test Manager syllabus treats them as separate activities that can be implemented together, in parallel, or as iterative tasks to produce the desired work products in the test design phase.

Test analysis describes “what” should be tested, in terms of test conditions. In simple terms, test condition is something that can be tested by us.

These conditions are recognized by analyzing these three factors:

1. Test objectives
2. Test basis
3. Product risks

These factors are the detailed targets and measures for success. Anyone must be able to trace the test analysis back to these three factors as well as other success criteria specified by the stakeholders.

By contrast, anyone should be able to trace the test conditions forward to test designs and other test work products as soon as they are created.

Test analysis of a specified testing level can be done only after the test conditions for the level have been defined.

Some of the techniques used to identify the test conditions include:

• Formal testing
• Risk based strategy
• Requirement based strategy

Both risk-based and requirement-based test strategies are analytical in nature. Depending on testing level, the test conditions may or may not specify these:

• Variable values
• Information that forms basis of defining conditions
• Degree of documentation granularity or depth

Factors that determine the level of detail of Test Condition

When determining the level of detailing required for test conditions, a number of factors need to be considered:

• Testing levels
• Detailing level and quality of test conditions
• System or software difficulty level
• Product risk and Project risk
• Correlation between test condition, what is being tested and method of testing
• Software development lifecycle being used
• Test management tool in use
• Detailing level of test design and other test work products like test documentation
• Understanding level and abilities of the test analysts
• Experience level of the organization as well as the test process(detailing level is directly proportional to the experience)
• Accessibility of other stakeholders for discussion in case of difficulties

If test conditions are described in great depth, huge number of test conditions will be created. Let us take the example of testing the checkout process of an e-commerce application.

In a general test condition, this will be specified as a single condition – “Test checkout”.

However, in a detailed test condition documentation, this will be broken down into multiple test conditions for example, each payment option, currency or country etc.

Advantages of describing test conditions in a detailed manner

• Greater flexibility in correlating other test work products like test cases to test conditions and objectives. This in turn enables better and in-depth control and observation for the Test Manager.
• Helps in avoiding faults, as explained in Foundation Level, because the condition happens quite early in a project, immediately after the test condition is defined and sometimes before detailed designs and system architecture are available.
• Explains testing work products in terms that are easily understood by the stakeholders. They may not comprehend the test cases, test basis or the basic figures like number of times a test case has been executed.
• Impacts other testing as well as development activities.
• Optimizes test design, test implementation, test execution and test work products by covering specified measures and targets in detail.
• Enables transparent horizontal traceability in the test level

Disadvantages of describing test conditions in a detailed manner

• Detailing is time consuming
• Sticking to plan is difficult in case of dynamic environment
• Defining and implementing test levels across the team is challenging

When to describe test conditions in great detail?

• Simple ways of documenting test design are being used like checklists, due to different constraints like time, cost, or typical development lifecycle
• Unavailability of formal requirements document or development work products that can be used as basis for defining test conditions
• Project is so complex that required level of control cannot be achieved just by specifying test cases

When to describe test conditions in less detail?

A low level of detail of test condition is used when the basis of test can be easily communicated to test design work products.

These are some of the situations where this may be the case:

• Testing at component level
• Simple projects having hierarchical relations between test conditions and test cases
• Acceptance testing, where tests can be defined with the help of use cases

In the next topic we will learn what is test design and when to create test design.

Other popular articles:

• What is Test analysis / Test Basis? or How to identify the test conditions?
• What is Test Monitoring and Test Control?
• What is Test Design? When to create Test Design?
• How Do Software Development Lifecycle Activities & Work Products Affect Testing?
• What is Test Planning? What are Work Products in Testing?