-

Importing data - super user features

For importing your existing data to Testlab you can use a comma-separated value (CSV) file. CSV files are simple text files supported by many applications dealing with tabular formatted data such as Microsoft Excel, other office tools, and database software.

  • Importing test sets

    When you import test sets to Testlab you are practically importing test set categories, test sets in them, and relations to the test cases of the test sets. Testlab supports a CSV file format that includes all this information in one compact file.

    As test sets have no single attribute which uniquely identifies them test sets are identified with a compound identifier consisting of test set category path and the title of the test sets. For example, in

    • Acceptance tests
      • Customer
        • Login tests (a test set)

    the “Login tests” test set would be identified with a category path set as “Acceptance tests/Customer” and title as “Login tests“. Please note that when importing a tree structure the file must be ordered in parent-child order (meaning, all parent categories of children must be included before the child rows).

    When importing the test set is looked up from the project with the category path + test set title pair. If it is found the test set is updated. If it is not found it is created.

    Note: When updating existing test sets the import will replace the test cases of the existing test sets.

    Attribute mappings

    Please refer to the following table for supported standard attribute mappings. Note: Category path and the title of the test set are mandatory for rows representing test set data – all other fields are optional and should be included when applicable.

    Field Format Description Default value*
    category path Text Test set category path [mandatory] with categories separated by a / character. Note, that the file must be ordered in the parent-child order and all rows with test case data must have this value. 
    title Text Title of the test set [mandatory].
    description HTML text HTML formatted description for the test set. “”
    milestone Text Title and optionally the identifier of the target milestone in “Title [Identifier]” format, for example, “Release 1.0 [R1.0]”. not set
    assigned to User ID User ID of the user who the test set should be assigned to. not set
    created yyyy-MM-dd’T’HH:mm:ssZZ Created timestamp for the test set. Time of import
    created by Text Name of the person who created the test set. “Import”
    tags Tags A comma-separated list of tags for the test set. –
    Repeated on own row for each test case in the set:
    test case Category path and the name of the test case bound to the test set. This field can be repeated on multiple rows to bind test cases to the test set. The value must contain a full category path and the name of the test case. For example “Functional tests/Customer/User logs in” value would be mapped to a test case “User logs in” in a test category Functional Tests / Customer. –

    * Default value: Value to be inserted for created test sets (or related data) if missing or set as blank (“”) in CSV file – default value will be also set for updated test sets if the field is set as blank (“”) in CSV file.

     

    Binding test cases to test sets

    The test cases of the test set can be included in the file as separate rows after the actual row with test set data. Please note, that the attributes of the test set must not be repeated on each row. As the file is parsed the parser remembers the last test set row it detected and binds the subsequent test cases on rows to this test set. For example, importing

    category path,title,test case
"Imported sets",My test set,"Functional tests/Test case x"
,,"Security tests/Other test case"
,,"Security tests/And a third test case"

    would add an “Imported sets” test set category, create a “My test set” named test set under it, and add three test cases to this set:

    • Test case x in test category Functional tests,
    • Other test case in test category Security tests and
    • And a third test case in the test category Security tests.
    Running the import for test sets

    To import test sets prepare a file with applicable fields included from the above table according to the rules explained in this document. Log on to the project preferred, select Testlab > Import > Test sets from Testlab’s menu and configure the following:

    • CSV file: Select the file you want to import the data from
    • Charset: Select the character encoding your file is encoded with [defaults to UTF-8]
    • Separator: Select the separator character your file is encoded with to separate the columns [defaults to comma (,)]
    • Quote char: Select the quote character used in your file to quote the data in individual columns [defaults to double quote (“)]
    • Dry run: Select this option to not to import the actual data to your project database. Using this option is handy for validating that the options and the format of the import file are correct.

    Click the Import-button. After the import is run (or a dry run is run) the Import process output can be looked through for a server-side log of the import process.

  • Importing test runs (including testing results)

    When you import test runs to Testlab you are practically importing test runs, relations to test cases executed (or to be executed) in them, and the results for the steps of these test cases. Testlab supports a CSV file format that includes all this information in one compact file.

    As test runs have no single attribute which uniquely identifies them test runs are identified with their title. When importing the test run is looked up from the project with the title provided and if it is found the test run is updated. If it is not found it is created.

    Note: When updating existing test runs the import will replace all the test cases and their results of the existing test runs.

    Attribute mappings

    Please refer to the following table for supported standard attribute mappings. 

    Field Format Description Default value*
    title Text Title of the test run [mandatory].
    comment Text Comment or description for the test run. “”
    assignees A comma-separated list of User IDs List of users who the test run should be assigned to not set
    milestone Text Title and optionally the identifier of the target milestone in “Title [Identifier]” format, for example, “Release 1.0 [R1.0]”. not set
    version Text Test run’s version – if a matching version is not found in the project a new version will be created. not set
    environment Text Test run’s testing environment – if a matching environment is not found in the project a new environment will be created. not set
    start yyyy-MM-dd Starting date for the test run (= when the test run is planned to be started) not set
    deadline yyyy-MM-dd The deadline date for the test run (= when the test run should be finished at the latest) not set
    tags

     

    		 Tags A comma-separated list of tags for the test set. –
    test set The category path and the title of the test set this run relates to. The value must contain a full category path and the title of the test run. For example “Our Sets/Acceptance tests” value would be mapped to a test set “Acceptance tests” in a test set category Our Sets. not set
    created yyyy-MM-dd’T’HH:mm:ssZZ Created timestamp for the test run. Time of import
    created by Text Name of the person who created the test run. “Import”
    status not started, started, aborted or finished The status of the test run not started
    started yyyy-MM-dd’T’HH:mm:ssZZ Timestamp when this run was started Depends on status: If started / aborted / finished is missing status implies a value, timestamps will default to current time.
    aborted yyyy-MM-dd’T’HH:mm:ssZZ Timestamp when this run was aborted
    finished yyyy-MM-dd’T’HH:mm:ssZZ Timestamp when this run was finished
    Repeated on own row for each test case in the run:
    test case Category path and the name of the test case bound to the run. This field can be repeated on multiple rows to bind test cases to the test run. The value must contain a full category path and the name of the test case. For example “Functional tests/Customer/User logs in” value would be mapped to a test case “User logs in” in a test category Functional Tests / Customer. [mandatory if test cases are present] –
    result not run, pass, fail, skip, block Testing result for the test case. not run
    run by Text User ID of the user who executed this test case. not set
    test started yyyy-MM-dd’T’HH:mm:ssZZ Timestamp when the execution of this test case was started. Current time
    run yyyy-MM-dd’T’HH:mm:ssZZ Timestamp when the execution of this test case was completed. Current time + 3 minutes.
    Repeated on own row for each step of the test case **:
    step Number A number of the step in the test case. [mandatory if steps are present]
    step result not run, pass, fail, skip, block Testing result for the step. Result of the test case
    step comment Text Execution comment for the step. “”
    step run by Text User ID of the user who executed this test case step. not set

    * Default value: Value to be inserted for created test runs (or related data) if missing or set as blank (“”) in CSV file – default value will be also set for updated test sets if the field is set as blank (“”) in CSV file.

    ** If steps of test cases are left out, the process will import test case results to the runs without any steps. When inspected the UI, the result for a test case will then show no steps at all.

    Setting results for test runs’ test cases and steps

    The results for run test cases can be included in the file as separate rows after the actual row with test run details. In a similar fashion, results for individual steps of test cases can be included.

    Please note, that the attributes of the test run must not be repeated on each row. As the file is parsed the parser remembers the last test run and test case rows it detects and binds the subsequent test cases and steps on rows to relevant assets. For example, importing

    title,test case,result,step,step result
My test run,"Functional tests/Test case x",fail,1,pass
,,,2,fail
,,,3,fail
,"Security tests/Other test case",pass,1,pass
,,,2,pass

    would create a “My test run” titled test run and add results of two test cases to this run as:

    • Test case x as failed with steps as
      • step 1 as passed
      • step 2 as failed
      • step 3 as failed
    • Other test case as passed with steps as
      • step 1 as passed
      • step 2 as passed
    Running the import for test runs

    To import test runs prepare a file with applicable fields included from the above table according to the rules explained in this document. Log on to the project preferred, select Testlab > Import > Test runs from Testlab’s menu and configure the following:

    • CSV file: Select the file you want to import the data from
    • Charset: Select the character encoding your file is encoded with [defaults to UTF-8]
    • Separator: Select the separator character your file is encoded with to separate the columns [defaults to comma (,)]
    • Quote char: Select the quote character used in your file to quote the data in individual columns [defaults to double quote (“)]
    • Dry run: Select this option to not to import the actual data to your project database. Using this option is handy for validating that the options and the format of the import file are correct.

    Click the Import-button. After the import is run (or a dry run is run) the Import process output can be looked through for a server-side log of the import process.

  • Importing projects

    To efficiently create a set of projects for a company, a CSV import can be used.

    When importing the project is looked up from the database with the project key (for example, TLABDEMO in case of the Demo project). If it is found the project details are updated. If it is not found it is created.

    Note: When importing projects only the basic details of the project are imported. To import further assets such as test cases, separate import with test cases containing CSV should be done.

     

    Attribute mappings

    Please refer to the following table for supported standard attribute mappings. Note: The project key is always mandatory and name, time zone, and workflow fields are mandatory for rows representing new project data – all other fields are optional and should be included when applicable.

    Field Format Description Default value*
    key Text Project key [mandatory]. 
    name Text Name of the project [mandatory for new projects].
    status Text Status of the project: active or deactivated active
    description Text Description for the project. “”
    time zone The canonical ID of the time zone The canonical ID of the time zone for the project [mandatory for new projects]. Must be one of the standard supported IDs (for example, Europe/Helsinki). For a list, please see here. simple
    www Text, URL The URL address for the project. Informational – shown in the bottom bar of the UI when the user is logged in. –
    workflow Text, name of the workflow Name of the workflow to be set for the project [mandatory for new projects]. The default workflows of Testlab are: simple and with review.
    notice scheme Text, name of the notice scheme Name of the notice scheme to be set for the project. not set
    copy from Text, project key Key of the project from which the content is copied to the new project. If set, ALL content is copied. Applicable only for projects which do not exist yet. If not set, projects are created as blank.

    Note: If set, the workflow field must match the workflow set for the copied project. Importing projects with “copy from” value does not support migrating the copied content from workflow to another.

    		 –

    * Default value: Value to be inserted for created projects – if missing or set as blank (“”) in CSV file – default value will be also set for updated projects if the field is set as blank (“”) in CSV file.

    Project import example

    The following example imports two projects to the company the user is logged in. Importing the file

    key,name,status,description,time zone,www,workflow,notice scheme,copy from
"FP","First project","active","Europe/Helsinki","www.melioratestlab.com","simple",,
"SP","Second project","active,"Pacific/Tahiti",,"with review",,"TLABDEMO"

    would import data as:

    • The project named “First project” with identifying key as FP, it would be active and be located in Helsinki, has WWW URL set as www.melioratestlab.com, and uses the “Simple” workflow. The project would be added as blank with no other content.
    • The project named “Second project” with identifying key as SP – it would be active and be located in Tahiti, has no WWW URL, and uses the “With review” workflow. The project would be set up by copying all content from the Demo project “TLABDEMO”.
    Running the import for projects

    To import projects prepare a file with applicable fields included from the above table according to the rules explained in this document. Log on to some project in the Testlab you would like to create the projects to, and select Testlab > Import > Projects from Testlab’s menu and configure the following:

    • CSV file: Select the file you want to import the data from
    • Charset: Select the character encoding your file is encoded with [defaults to UTF-8]
    • Separator: Select the separator character your file is encoded with to separate the columns [defaults to comma (,)]
    • Quote char: Select the quote character used in your file to quote the data in individual columns [defaults to double quote (“)]
    • Dry run: Select this option to not to import the actual data to your project database. Using this option is handy for validating that the options and the format of the import file are correct.

    Click the Import-button. After the import is run (or a dry run is run) the Import process output can be looked through for a server-side log of the import process.

  • Importing users

    To efficiently create a set of users to a company, a CSV import can be used.

    When importing existing users are looked up from the database with the user ID (the ID the user logs on to Testlab). If it is found the user’s details are updated. If it is not found a new user is created.

    Note: When importing users the file contains the password credentials of users. When a file is used for creating users, extra care must be taken in handling the import files.

     

    Attribute mappings

    Please refer to the following table for supported standard attribute mappings. Note: User ID is always mandatory, and name, email, and password fields are mandatory for rows representing new user data – all other fields are optional and should be included when applicable.

    Field Format Description Default value*
    userid Text User ID [mandatory]. 
    status Text Status of the user account: active, locked, or removed. active
    name Text Name of the user [mandatory for new users].
    email Text
    E-mail address for the user [mandatory for new users].
    disable notices true, false If true, e-mail notices are disabled for this user. false
    password Text, min 8 chars, max 64 chars. Password for the user. Minimum of 8 characters. [mandatory for new users]
    administrator true, false If true, the company is set as a company administrator. false
    roles Text A compound set of project roles to grant for the user in format:

    <project key>:<role>[,<role>,…][,<another project key>:<role>[,<role>,…]]. See the examples below.

    		 none

    * Default value: Value to be inserted for created users – if missing or set as blank (“”) in CSV file – default value will be also set for updated projects if the field is set as blank (“”) in CSV file.

    User import example

    The following example imports two users to the company the user is logged in. Importing the file

    userid,status,name,email,disable notices,password,administrator,roles
"agentbrown","active","Agent Brown","agent.brown@zion.com","false","catcatcat",false,"TLABDEMO:TESTER,ISSUEMANAGER,ATM:TESTMANAGER"
"morpheus","active","Mr Morpheus","morpheus@zion.com","false","dogdogdog","true",

    would import data as:

    • Regular active user with ID “agentbrown” named “Agent Brown” with an e-mail address as “agent.brown@zion.com”, password set as catcatcat and roles in projects as
      • In project TLABDEMO: TESTER and ISSUEMANAGER roles
      • In project ATM: TESTMANAGER role
    • Company administrator user with ID “morpheus” named “Mr Morpheus” with an e-mail address as “morpheus@zion.com”, password set as dogdogdog with no specific project roles (as the user is administrator, no roles are needed).
    Running the import for users

    To import users prepare a file with applicable fields included from the above table according to the rules explained in this document. Log on to some project in the Testlab you would like to create the users to, and select Testlab > Import > Users from Testlab’s menu and configure the following:

    • CSV file: Select the file you want to import the data from
    • Charset: Select the character encoding your file is encoded with [defaults to UTF-8]
    • Separator: Select the separator character your file is encoded with to separate the columns [defaults to comma (,)]
    • Quote char: Select the quote character used in your file to quote the data in individual columns [defaults to double quote (“)]
    • Dry run: Select this option to not to import the actual data to your project database. Using this option is handy for validating that the options and the format of the import file are correct.

    Click the Import-button. After the import is run (or a dry run is run) the Import process output can be looked through for a server-side log of the import process.