Importing Test Cases
Filling in a Test Case Import file
Importing test cases via an Excel file allows you to mass create or mass modify a portfolio of tests. You can import test cases and their attributes, settings, and datasets, as well as their links to requirements.
This feature is very useful:
- during a migration from a third-party tool;
- to retrieve a portfolio of tests from a document;
- to mass modify test cases already in Squash.
You can import test cases from .xls, .xlsx, .xlsm, and .zip files.
Info
The import feature is only available for Admin and Project Leader profiles.
You can download an import template for Excel and .zip files from the import pop-up in the Test cases workspace.
Focus
You cannot import BDD or exploratory test cases.
You cannot modify a test case format (Classic/Gherkin/BDD/Exploratory) through importing.
Excel Import File Structure
The import file is composed of five tabs:
- The TEST_CASES tab contains information related to the test cases to import such as location, description, importance, etc.;
- The STEPS tab contains information related to a classic test case's test steps.;
- The PARAMETERS tab contains information related to a test case's parameters;
- The DATASETS tab contains information related to datasets;
- The LINK_REQ_TC tab contains information to link test cases to requirements that already are in Squash.
Structure of the file
The import file must follow these rules:
- The name of the five tabs must not be changed.
- The headings of columns must not be changed.
- The blank rows are ignored.
- The cells must not be merged.
- The order of the rows does not matter.
- If you use any "Classify and protect" method for your data, check that the file is public so Squash can read it.
- The import is done row by row.
Data in HTML
Some columns must contain text in HTML format.
If this format is not respected (for example, if special HTML characters are not encoded), the import will be incorrect or rejected.
Moreover, to avoid security vulnerabilities, only certain HTML elements and attributes are allowed. Their list can be found here.
TEST_CASES Tab
| Column name | Description | Expected value |
|---|---|---|
| ACTION | Value that indicates the action you want to perform. | Required FieldC: to create (Create)U: to update (Update) |
| TC_PATH | Test case path. It starts with /project name and ends with the test case. It includes the name of the project because the import is cross-projects. |
Mandatory Field For example: - /project/folder/testcase |
| TC_NUM | Test case position in its folder. - CREATE Mode: if not entered, considered as the last item of the folder. If entered, the case test is created at that position; - UPDATE Mode: if not entered, information is ignored. If you enter a position number that is different from the current order, the test case is moved to that different position. |
|
| TC_UUID | Test case Universal Unique Identifier - CREATE Mode: if entered, the test case is created under this UUID. If not entered, the test case is created with an auto-generated UUID; - UPDATE Mode: the value of the TC_UUID is not considered. You cannot modify a test case's UUID when it is already in the database. |
In most cases, this column should be left empty in order to auto-generate an UUID. If entered, the value of the TC_UUID column must match the regular expression: [0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}For example: 2ed2DFd9-8169-986f-4E2a-00b93C7ed77E |
| TC_REFERENCE | Test case reference | |
| TC_NAME | Test case name. - CREATE Mode: the field is ignored; - UPDATE Mode: allows you to rename a test case. |
|
| TC_MILESTONE | Name of the milestone(s) related to the test case. If an object is linked to several milestones, each of the milestone must be entered in the matching column, separated with a |.UPDATE Mode: if the column is blank, the existing links will be deleted. |
For example, if a test case is related to two milestones:Milestone1|Milestone 2 |
| TC_WEIGHT_AUTO | If, during the import, the value is at 1, Squash deduces the weight of the test case according to its related requirements, including the requirements related to called test casesIf the column or the value is not entered, the default value taken into account is "0". |
- 1: If the weight calculation is automatic- 0: If the weight value is manually entered. |
| TC_WEIGHT | Test case weight code. If TC_WEIGHT_AUTO = 1, the indicated value for TC_WEIGHT is ignored. |
- VERY_HIGH- HIGH- MEDIUM- LOW [Default value] |
| TC_NATURE | Test case nature code | - NAT_ATDD- NAT_BUSINESS_TESTING- NAT_FUNCTIONAL_TESTING- NAT_NON_FUNCTIONAL_TESTING- NAT_PERFORMANCE_TESTING- NAT_SECURITY_TESTING- NAT_UNDEFINED [Default value]- NAT_USER_TESTING |
| TC_TYPE | Test case type code | - TYP_COMPLIANCE_TESTING- TYP_CORRECTION_TESTING- TYP_END_TO_END_TESTING- TYP_EVOLUTION_TESTING- TYP_PARTNER_TESTING- TYP_REGRESSION_TESTING- TYP_UNDEFINED [Default value] |
| TC_STATUS | Test case status code | - APPROVED- OBSOLETE- TO_BE_UPDATED- UNDER_REVIEW- WORK_IN_PROGRESS [Default value] |
| TC_DESCRIPTION | Test case description | HTML text, see this paragraph for the constraints on this one. |
| TC_PRE_REQUISITE | Test case prerequisite | HTML text, see this paragraph for the constraints on this one. |
| TC_CREATED_ON | Test case creation date. Dates are exported in date cells or cells in ISO 8601 format. | Format: YYYY-MM-DDIf the date is not entered, the current date is used. |
| TC_CREATED_BY | Creator login. | If not entered, the login of the user who did the import is used. |
| DRAFTED_BY_AI | Indicates whether or not the test case has been generated by artificial intelligence. In the case of an UPDATE, this column is ignored and the test case keeps its initial value. | - 0: false [Default value] - 1: true |
| TC_KIND | Test case format code If not entered, the test case is imported as a classic test case. |
Format: - STANDARD- GHERKIN- KEYWORD (BDD) |
| TC_SCRIPT | Test case Gherkin script | |
| TC_AUTOMATABLE | Eligibility to automation of the test case | - M: To instruct [Default value]- Y: Eligible- N: Not eligible |
TC_CUF_<cuf's code> |
One column by custom field. In the heading, replace <cuf's code> by the custom field's code. |
Value linked to the custom field, see below. |
STEPS Tab
| Column name | Description | Expected value |
|---|---|---|
| ACTION | Value which indicates the action to perform. | Mandatory fieldC: to create (Create)U: to update (Update) |
| TC_OWNER_PATH | Path to the test case that owns the test step. | Mandatory field For example: - /project/folder/testcase |
| TC_STEP_NUM | Position number of the test step (starts at 1) For the import, the numbers do not have to be consecutive: the relative order between the different TC_STEP_NUM is used. If two test steps have the same position number or if there is no value, the order of apparition in the file is used. |
|
| TC_STEP_IS_CALL_STEP | To indicate whether this test step is an action or a called test case. | - 0 if the step is a test step [Default value]- 1 if the step is a called test case |
| TC_STEP_CALL_DATASET | This column is only taken into account if TC_STEP_IS_CALL_STEP = 1. |
- INHERIT if the chosen option is to not choose a dataset, the calling test case inherits the settings of the called test case- <NAME>: name of the chosen dataset |
| TC_STEP_ACTION | - Step action - Or path towards the called test case |
- HTML text, see this paragraph for the constraints on this one. - In the case of a test case call: CALL /project/folder/called_TC_name |
| TC_STEP_EXPECTED_RESULT | - Step expected result - If STEP_IS_CALL_STEP = 1, this column is ignored |
HTML text, see this paragraph for the constraints on this one. |
TC_STEP_CUF<cuf's code> |
One column per custom field. In the heading, replace <cuf's code> by the test step's custom field code. |
Value linked to the custom field, see below. |
PARAMETERS Tab
| Column name | Description | Expected value |
|---|---|---|
| ACTION | Value that indicates the action to perform. | Mandatory fieldC: to create (Create)U: to update (Update) |
| TC_OWNER_PATH | Path towards the test case that owns the parameter | Mandatory field For example: - /project/folder/testcase |
| TC_PARAM_NAME | Parameter name, must only contain the following characters: [0-9], [a-z], [A-Z] and [-,_]. |
Mandatory field |
| TC_PARAM_DESCRIPTION | Parameter description | HTML text, see this paragraph for the constraints on this one. |
DATASETS Tab
| Column name | Description | Expected value |
|---|---|---|
| ACTION | Value that indicates the action to perform. | Mandatory fieldC: to create (Create)U: to update (Update) |
| TC_OWNER_PATH | Path to the test case that owns the dataset. | Mandatory field For example: - /project/folder/testcase |
| TC_DATASET_NAME | Dataset name | Mandatory field |
| TC_PARAM_OWNER_PATH | Path to the test case that owns the parameter. This column is needed for parameters from test cases called by the dataset owner test case. | |
| TC_DATASET_PARAM_NAME | Name of the parameter for which the value is entered. It must only contain the following characters: [0-9], [a-z], [A-Z] and [-,_]. During the import, if there is no matching parameter, the value is ignored. |
Mandatory field |
| TC_DATASET_PARAM_VALUE | Corresponding value for the specified pair {dataset | parameter}. |
LINK_REQ_TC Tab
To link test cases to requirements already in the repository, the three fields are mandatory.
| Column name | Description | Expected value |
|---|---|---|
| REQ_PATH | Requirement path from the project name to the requirement name (current version) NB: Current version name can differ from version to link name | Mandatory field For example: - /project/folder/requirement- /project/PARENTrequirement/CHILDrequirement |
| REQ_VERSION_NUM | Requirement to link number | Mandatory field |
| TC_PATH | Test case path from project name to test case name | Mandatory field For example: /project/folder/testcase |
You can only add associations by importing test cases. Removing already existing lines of the LINK_REQ_TC tab will not delete the associations in Squash.
Info
With an Excel import, you can format all rich text fields such as the description or test steps by using HTML tags.
Structure of the Zip Import File
The .zip file contains the folders, subfolders, and the entirety of the test cases to import.
For each test case to import, you must create an Excel file. Each file must contain a tab with the test case's information. The tab name must match the test case to import name.
These files must be in their corresponding folders so that test cases are imported at the right location in the library of the Test cases workspace.
For example:
- To import ten test cases, you need ten Excel files;
- To import a test case in a folder titled
Folder1: you must create a folder titledFolder1and in that folder, put the Excel file which contains the information of the test case to import. Zip the folder for import.
Focus
A .zip import does not allow you to import Gherkin and BDD test cases;
With a .zip import, you can only import one project at a time;
With a .zip import, you can create only new test cases;
A .zip import does not allow you to import parameters, datasets, and test case links.
A test case's Excel file tab must contain the following tags in this order:
| Tag | First value | Second value | Comment |
|---|---|---|---|
| Description | Enter the test case description. | This data will be in the test case's Description field | |
| Importance | Enter the importance of the test case by choosing one of the following normed values: - VERY_HIGH- HIGH- MEDIUM- LOW. |
This data will be in the test case's Importance field | |
| Created_by | Enter the creator's login | This data will be in the test case's Created by field. | |
| Created_on | You can either enter the date (including the hour) in a date cell or in a text cell in the DD/MM/YYYY format. |
This data will be in the test case's Created by XXX on field | |
| Action_step | Enter the action to perform. | Enter the expected result. | Each time this tag is present, a new test step is created. Test steps are created in the file's order (from top to bottom). |
| Prerequisite | Indicate the information to add in the test case's Prerequisite. | If several ranks of the Excel file are filled in with this tag, the different values are concatenated in the Prerequisite field. |
For example:
The test case information is in the first tab. This tab's name is the same as the test case's Test case 1.
Test Cases Imports case studies
Squash allows you to import a tree of test cases from a .xls or .zip file.
To perform this import, you must fill in an Excel file and follow these recommendations Excel import file structure then import it by using the Import option in the Test Cases workspace. You can simulate the import to verify the coherence of the import file before importing it.
Learn more
For more details on the steps to follow to perform an import, please visit this page: Import an object.
Importing allows you to create test cases with all the features available in the Test Cases workspace.
Creating a tree of Test Cases
The tree is very important because it allows you to organize the tests repository. Importing allows you to create a precise tree of the folders and test cases to import in several projects at once.
If the folders are not in Squash during the import, they are created by the import.
For example:
For the path: /Project1/Folder1/Subfolder1/Testcase1
Testcase1 is added to Project1, in Subfolder1, located in Folder1.
Importing test cases with a custom list
If a custom list is set up for the nature and/or the type of test cases in the project, in the import file, you must enter the desired option code in the columns TC_NATURE and/or TC_TYPE.
For example:
- To have a custom list with several options, including
Nature2linked to the codeN2EN;
- In the Excel file, enter the value of the option code in the column TC_NATURE: in this case
N2; - When the file is imported, the test case is created and the Nature field is filled in with
Nature2.
Importing Test Cases with Custom Fields
If custom fields (CUF) are set up for the project's test cases, in the import file, you can fill in the column TC_CUF_<cuf code>. There must be one column by custom field. The column's heading must contain the custom field's code, which is available on its consultation page.
TC_CUF_<cuf code> Column Content:
| Custom field type | Expected value |
|---|---|
| Tag | Tag1|Tag2 |
| Checkbox | true or false |
| Drop-down menu | Option tag |
| Numerical | For example: 50, 12,8 |
| Numerical digit | YYYY-MM-DD |
| Simple text | Unformatted text with 255 characters maximum |
| Rich text | HTML text, see this paragraph for the constraints on this one. |
Importing Test Cases with Links to Requirements
The LINK_REQ_TC tab of the import file must be filled in with the requirement path, the version number, and the path of the test case to link. For the association to work, the requirement must already be in the repository.
The information is visible after the import in the test case's anchor Requirements verified by this test case.
Importing test steps
The STEPS tab allows you to import test steps for a Classic test case. The step's number, action, and expected result are entered in the file.
Import using parameters and datasets
The tabs PARAMETERS and DATASETS enable you to import parameters and datasets to a test case. You can also add the parameter directly to the test step using the STEPS tab.
For example:
For a test case on the connection to an app, you can import the two parameters Login and Password, as well as the three datasets corresponding to the connection of three different profiles: Admin, Project Leader, and Guest.
Learn more
To learn more about parameters and datasets, please visit the page: Variabilising classic test case.
Importing a test case calling another test case
Enter the calling test case in the TEST_CASES tab. Then, in the STEPS tab, fill in the following columns:
- In the TC_STEP_IS_CALL_STEP column, enter the value
1to indicate that this test step is a test case call; - In the TC_STEP_ACTION column, enter the following information:
CALL <called test case path>. (For example:CALL /project/folder/called-tc); - You do not have to fill in the TC_STEP_EXPECTED_RESULT column.
Info
If the called test case is not in the test repository, it must be in the TEST_CASES tab in the import file.
Learn more
To learn more about test cases calls, please visit the page: Modularising: Call a third-party test case.
Importing a Gherkin Test Case with a Script
To import a Gherkin test case and its script, you must fill in specific columns in the TEST_CASES tab:
- TC_KIND Column:
GHERKIN; - TC_SCRIPTING_LANGUAGE Column: The test case Gherkin script.
Focus
You cannot import BDD test cases.