Test Cases in Squash TM
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 TM, 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 TM, three test case formats are available: Classic, BDD, and Gherkin.
In the "Test Cases" workspace, you can easily 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, and blue for the Gherkin 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.
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 TM translates this script. There is no impact on the writing of the 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.
Test Case Consultation Pages
When you select a test case in the test case library, its consultation page appears.
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 case test'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 on the top right of the page.
On the left, the anchor bar enables you to access the corresponding block by clicking on it:
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
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
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
This block only appears for Classic 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
This block only appears 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.
This block only appears 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.
This block only appears 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.
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.
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.