Skip to content

Test Cases in Squash

What is a Test Case?

A test case is "A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement." (ISTBQ) 1.

Each test case's minimum objective is to verify a requirement's specified result.

In Squash, a test case is an object of the Test Cases workspace. It is defined by an objective, initial prerequisites, datasets to be constituted, actions to be performed, and expected results. Executing a test case must enable you to verify the compliance of a tested system's expected behavior step by step and thus identify potential issues.


For the test coverage to be optimal, it is important that you give an exact description to the test case by clarifying its objective: The test case verifies that [action]. Sometimes, a requirement can be verified in multiple ways, so there must be as many tests as there are identified scenarios.

Test Case Formats

In Squash, four test case formats are available: Classic, BDD, Gherkin and Exploratory.

Test case formats

In the Test Cases workspace, you can identify each format thanks to its color. In the test cases tree, tags appear in black for the Classic format, green for the BDD format, blue for the Gherkin format and purple for the Exploratory format.

Classic Test Cases

A classic test case enables you to describe the actions to perform and their expected results via test steps. Its Prerequisites block contains the test case's preconditions. You can set variables for this test case with datasets and factorize it via test case calls. This test case is suited to manual tests but it can also be automated.

Classic test case

BDD Test Cases

A BDD test case enables you to describe a scenario in Gherkin language. Its interface is simple and intuitive, and it has an autocompletion feature 2. Each test step is composed of a keyword (Given-When-Then) and an action sentence that can be reused in other BDD test cases. This format is particularly suited to automation. It enables you to export its associated script to a format suited to Cucumber or Robot Framework. Squash translates this script. There is no impact on the writing of the test case.

BDD test case

Gherkin Test Case

A Gherkin Test Case enables you to design one or multiple Gherkin scenarios in a dedicated text editor. This editor's features include syntaxic highlighting and syntax verification, but no autocompletion. This format is suited to automation. The Gherkin script is exported to Cucumber format as designed by the user.

Gherkin test case

Exploratory Test Case

Unlike other test case formats, the exploratory test case does not include a predefined scenario or test steps. Instead, it features a test charter designed to provide a framework for users during execution. Exploratory test cases complement other test case formats.

Lean more

For more information, please visit Manage exploratory testing

Test Case Consultation Pages

When you select a test case in the test case library, its consultation page appears.

Test case consultation page

On a test case's consultation page, you can see:

  • the test case's name and reference;
  • pill tags showing its status, importance, and last execution status;
  • the test case's attributes, links, and content in specific blocks.


During the creation of the test case, you can name your test case and assign a reference to it (optional). We highly recommend that you use a reference for your test case as it will be better for the organization of your repository. You can also modify the name and reference of the test case on its consultation page.

You can add an attachment via the button Add attachment on the top right of the page.

On the left, the anchor bar enables you to access the corresponding block by clicking on it:

Information Information

The Information block displays the test case's attributes: Status, Importance, Type, Nature, and Format. It also displays its description and custom fields.

Requirements Verified by the Test Case Requirements Verified by the test case

The block Requirements verified by the test case enables you to associate the requirement(s) covered by the test case. The related requirements' information is displayed in a table.

Parameters and Datasets Parameters and Datasets


This bloc only exists for Classic and BDD test cases.

The Parameters and datasets block enables you to variabilize the test cases by valorizing their parameters with datasets. For a Classic test case, the parameters can be defined in the fields Prequisite, Action, and Expected result. For a BDD test case, they can be defined in the test steps actions. Datasets enable you to define a set of values for these parameters. The parameters entered in the test steps and prerequisites are automatically transfered to the Parameters and the dataset table.

Test case called by Test case called by


This bloc only exists for Classic and BDD test cases.

The block Test case called by lists all the tests that are calling the current test cases. This test call mechanism is what enables the building of test cases modular libraries. During the execution, the called test case steps are seen as test case steps in the calling test case. A table dislays the "calling" test cases information.


This mechanism can also be used for end to end testing using the tests portfolio of different projects.

Prerequisites and test steps Prerequisites and test steps


This bloc only exists for Classic test cases.

The block Prerequisites and test steps is composed of two parts:

  • Prerequisites: receives the test case's preconditions;

  • Test step: is composed of a series of actions to perform in order to reach the test's objective and the corresponding expected results.

Prerequisites and test steps Test steps


This bloc only exists for BDD test cases.

This anchor enables you to add test steps based on Gherkin syntax. For this, choose a keyword in the drop-down list and write an action.

Prerequisites and test steps Script


This bloc only exists for Gherkin test cases.

By clicking on this anchor, you can edit the Script block and write Gherkin scenarios using snippets. A writing assistance tool for Gherkin test cases is available by clicking on the [Help] button.

Test charter Test charter


This bloc only exists for Exploratory test cases.

The Test Charter block consists of two elements:

  • Test Session Duration: indicates the duration (hours and minutes) of an exploratory test session;
  • Charter: defines, among other things, the objective and scope of the test or any other useful information to provide a framework for users during execution.

Executions Executions/Sessions

The Executions block lists all the test case's executions and their attributes (status, ID of the tester who executed the test case, date of execution, number of issues reported). The table updates itself automatically in real time and cannot be modified.

For exploratory test cases, this block is named Sessions and lists exploratory sessions based on this test case.

Known issues Known Issues

The Known issues table 3 lists all the issues reported during the test case executions. It updates itself automatically and in real time thanks to the bugtracker. It cannot be modified. Two clickable links enable you to access:

  • the issue's consultation page in the bugtracker;
  • the consultation page of the execution during which the issue was reported.

  1. ISTBQ stands for "International Software Testing Qualifications Board".

  2. Available via the Actions Library plugin.

  3. This anchor appears only when a bugtracker is linked to the test case's project.