Test Conditions

Test Conditions

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email
Share on reddit
Share on tumblr

How would you like to have all the software testing knowledge you need in one comprehensive eBook to transform your career?

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.

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.

Follow & Subscribe

Get updates and learn from the best

A Test Manager's Guide

Whether you want to be a better test manager, or gain useful knowledge of the software testing as a whole, A Test Manager's Guide is the software testing book for you.

A Test Managers Guide

How would you like to have all the software testing knowledge you need in one comprehensive book?