Create and organize Test Cases assets

Create a Test Case

You can create a test case in the Test Cases workspace.

You can create a test case at the root of a project or a folder. For this, you must mention the test case's format (Classic, Gherkin or BDD) and enter at least one value in the Name field. If mandatory custom fields are linked to the test case object, they also appear in the pop-up for you to complete them.

We recommend that you still add a reference and a description to your test case even if these fields are optional.

Info

Once you have created the test case, you cannot modify its Format anymore, but you can modify the Name, Reference, and Description fields.

Create Test Cases from Requirements

To save time and maximize the test coverage, you can create test cases from requirements.

For this, you must:

• Select the requirement(s) in the Requirements workspace. You can select one or multiple requirements folders;
• Click on the [Copy] button ;
• In the Test Cases workspace, select the test cases destination location, then click on the [Import/Export] button ;
• Select the option Add test cases from selected requirements and choose the format of the test cases you are creating;
• A tree of test cases identical to the tree of the selected requirements is created in the chosen format.

The test case created from a requirement includes:

• the requirement's name;
• its reference;
• its description;
• its weight, set on 'auto' based on its criticality.

The test case is automatically associated with this requirement. Its default status is "Work in progress".

Info

The test case creation from requirements takes into account the parent/children relation between requirements. Thus, two objects are created: the test case and its folder. The test case is created identically to the parent requirement. The folder includes the parent requirement's name and reference. It contains the test cases from the children requirements.

Test Case Attributes

A test case is characterized by different attributes. You can access them through the Information block:

Info

We recommend that you fill in the attributes in a homogeneous manner to identify the tests to include in execution plans more easily and to optimize the priorization of executions.

Reference

The test case reference is optional. However, it allows you to organize your repository. Naming rules must be established to organize and identify test cases.

Status

The Status field allows you to assign a status to the test case. The default status is "Work in progress". In the test cases library, each status is represented by a colored dot preceding the reference or, if there is no reference, the test case's tag. You can modify the status thanks to the drop-down list with the following values:

• 

• 

• 

• 

• 

Info

• Once approved, the test case's status can be marked as "Approved". The test case is then ready to be integrated in an iteration to be executed;
• A test case's status can be marked as "Obsolete" once it is not in accordance with the tested system anymore. This status enables you to archive the test case in the repository without deleting it;
• The "To be updated" status is ideal to identify test cases that need to be modified following an evolution of the tested system.

Weight

The Weight field enables you to assign a level of importance to the test case ("Low" being the default value). You can modify the value thanks to the drop-down list with the following values:

• 

• 

• 

• 

Focus

The Auto checkbox enables you to automatically determine the weight of the test case from the criticality of the requirements it meets. The following rules apply:

• If the test case is linked to at least one non-obsolete requirement with a 'Critical' criticality, the weight is 'High';
• If the test case is linked to at least one non-obsolete requirement with a 'Major' criticality, the weight is 'Medium';
• If none of these criteria are met, the weight is 'Low'.

The 'Very high' weight can only be set manually.

The weight of the test case can be used to organize and prioritize executions but also to analyze their results (success/failure rate depending on the weight of the tests, weight of tests that were never executed).

Nature

The Nature field allows you to define the nature of the test case ("Undefined" being the default value). You can modify it using the drop-down list.

This field enables you to identify test cases according to their nature within the test assets.

You can customize this field's values in the Squash settings.

Type

The Type field enables you to define the type of test case ("Undefined" being the default value). You can modify it using the drop-down list.

The Type field can be used to identify a certain type of test you want to add to a campaign, such as regression tests.
You can customize the values of this field in the Squash settings.

Learn more

To learn more about information lists, please visit the page Information Lists.

Description

The Description field enables you to describe the test case's objective. The description includes the items of the requirement linked to the test case which are verified by the test case.
The description can begin as such: The test case verifies that [action].

Custom Fields

Custom fields can take multiple forms (text, checkbox, date, tag…). You can use them for a test case folder, a test case, or a test step. They appear in the different blocks only if they are added in the project's settings.

Learn more

For more information on custom fields, please visit the page Project custom fields.

Organizing the Tests Repository

Squash offers you multiple visual and methodological ways to organize the repository and easily identify tests and their attributes.

References

A reference is an ID that must be unique. It facilitates test case identification:

• In the library: test cases are first sorted by the alphanumerical order of the reference, then by the name of the test case;
• In the execution plan: if there are several tests that have an identical name, you can identify each one of them thanks to their reference.

For the repository to be organized in a coherent manner, it is important to establish naming rules for both references and test cases.

Info

Creating folders and subfolders is also an excellent way to organize the tests repository within a same project. Folders can also be sorted by adding a reference in the Name field.

Example: Use of references for folders and test cases:

Icons and dots

In the library, icons and dots enable you to have an overview of the tests repository.

In the library the test cases appear in a white pill shape in which are the following items:

• 1st position: A colored tab shows the weight of the test case;
• 2nd position: An icon shows the nature of the test case;
• 3rd position: An icon shows the status of the test case, the presence of test steps, and the linking to a requirement:
  • The dot's color represents the status of the test case;
  • An empty dot means that there is no test step in the test case. On the contrary, a full dot means that the test case contains at least one test step;
  • A check appears in the dot when the test case is linked to at least one requirement.

When hovering, a tooltip details each item.

Example:

• Test case "CT002 - Functional" has a "Low" weight, "Functional" as its nature, "Approved" as its status, contains test steps, and is linked to a requirement;
• Test case "CT005-Non functional" has a "High" weight, "Non-functional" as its nature, "Work in progress" as its status, contains test steps but is not linked to a requirement;
• Test case "CT007-Security" has a "High" weight, "Security" as its nature, "Work in progress" as a status and does not contain any test step.

Info

For Gherkin test cases, the status dot is always full because these test case's script is pre-filled with a language tag and the title of the feature.

Colors

In the Test Case library, each test case format is represented by a specific font color, thus enabling you to quickly identify them:

• black for Classic test cases;
• blue for Gherkin test cases;
• green for BDD test cases.

Pill Shapes

Pill shapes are located on a test case's consultation page, under its reference. They show:

• the test case's status;
• its weight;
• the status of the last execution.

You can modify them from there.