Black Box Testing Techniques: Use Case Testing

In previous articles we learned about Testing Techniques Overview and then Specification Based Testing Techniques or Black Box testing techniques overview.

In this article we will learn about "Use Case Testing" Type

Use Case Testing

“A black box test design technique in which test cases are designed to execute user scenarios.” [ISTQB glossary]

Previous techniques used to design test cases for parts of a system:

  • Input variables.
  • Business rules.
  • System behavior. 
This technique is used to design test cases that exercise a system's functionalities from start to finish by testing each of its individual transactions, that are documented in use cases. 

Use Case: A sequence of steps that describe the interactions between the actor and the system 

Actor: A user or other system seeking to use the system to accomplish something worthwhile within a particular context.

A use case consists of: 

  • Name: The name of the use case. 
  • Brief Description: The role and purpose of the use case. 
  • Pre-conditions: Condition that must be true before performing the use case. 
  • Basic Flow: Description of the successful scenario from start to finish.
    Alternative Flows: Description of the exceptions in the basic flow. 
  • Post-conditions: Condition that must be true after performing the use case. 

Use Case Terms:

  • Include: An include relationship defines that a use case contains the behavior defined in another use case. 
  • Extend: An extend relationship specifies how the behavior of the extension use case can be inserted into the behavior defined for the base use case.

Use cases can be used at two levels:

  • Abstract level: business use case, technology-free, business process level
  • System level: system use case on the system functionality level 

Use cases are good tool for:

  • Describing the system from user’s point of view.
  • Describing system behavior in business terms.
  • Actively involving users in requirements gathering and definition process.
  • Serves as the foundation for developing test cases at the system and acceptance levels.

When to use: 

  • Requirements written in the form of use cases. 
  • Suitable for system and user acceptance testing.

How to use: 

  • Create at least one test case for the basic flow. 
  • Create at least one test case for each alternative flow. 
  • Use equivalence partitioning and boundary value analysis techniques to specify the input data.
  • Use decision table for business rules within the use case.


  1. This comment has been removed by a blog administrator.