Create and Organize Test Cases Assets
Create a Test Case
You can create a test case in the Test Case 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.
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 gain 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 case 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 "In progress".
The test case creation from requirements takes into account the parent/children relation between requirements. Thus, two things 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:
We recommend that you fill in the attributes in a homogeneous manner to identify the tests to include in the execution plans more easily and to optimize the priorization of executions.
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.
The 'Status' field allows you to assign a status to the test case. The default status is "In progress". In the test cases library, each status is represented by a color that you can easily identify thanks to the 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:
- 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.
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:
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, weitgh of tests that were never executed).
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 TM settings.
The value of the "Type" field's 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 easily 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 TM settings.
En savoir plus
To learn more about information lists, please visit the page Information Lists.
The "Description" field enables you to describe the test case's objective. The description includes the items to be verified of the requirement linked to the test case.
The description can begin as such: "The test case verifies that [action]".
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.
En savoir plus
For more information on custom fields, please visit the page Project custom fields.
Organizing the Tests Repository
Squash TM offers you multiple visual and methodological ways to organize the repository and easily identify tests and their attributes.
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.
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, an infotip details each item.
- Test case "CT002 - Functional" has a "Medium" 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, "In progress" as its status, contains test steps but is not linked to a requirement.
- Test case "CT007-Security" has a "Medium" weight, "Security" as its nature, 'In progress' as a status and does not contain any test step.
For Gherkin test cases, the status dot is always full because these test cases' script is pre-filled with a language tag and the title of the feature.
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 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.