Familiarize

Importing data

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 format

    Testlab has a common import interface for pushing CSV formatted data. This interface is used in some automated integrations where up-to-date master data is pushed to Testlab from a third party system and similarly, this interface can be used via Testlab’s user interface to import and update assets via
    manually created CSV files.

    When importing, the following principles will be followed:

    • Importing is always done in a set project – when importing via the user interface the targeted project is the current project you are logged on to.
    • All records in the file should be identifiable with an identifier that is used to check if the asset already exists in the project or not. The identifier varies depending on the type of the imported asset.
    • All imported files must start with a header record to indicate which attribute to map the column to.
    • Existing assets are updated, and if no corresponding asset is found a new one will be created. Importing never removes any assets from the project. Keep in mind though, that for updated assets the current content is overwritten.
    • When updating assets only fields present in the CSV file will be touched. When a field in the file indicates a blank value, the mapped attribute in the asset is set to a default value (if any) or left blank. When creating new assets missing fields from the file will be set to default values or left blank.
    • Importing does not create any change-history for the assets.
    • Importing does not create new versions for ready-accepted assets – data in the import file will overwrite the current version of the asset in the project.
    • Importing does not fire any events in Testlab – for example, users won’t get real-time event notifications for newly imported assets. However, the imports will be added to the timeline.
    • All fields with configurable option values are represented by the key value of the current option value set. The tables in this document list the default values provided by Testlab out of the box. If you customize the options for these fields, the customized values and their corresponding key values must be taken into account. The values can be imported by importing the title of the option, the title key of the option (if any) or the key value itself. For example, to set the type of a requirement as Functional, you can import the value as “Functional”, “type.functional” or “1”.

  • Typical import process

    A typical scenario for importing your data to Testlab consist of:

    1. Prepare a CSV formatted file (or files) with assets and information you would like to import to Testlab.
    2. Log in to the project you would like to import the data to.
    3. Select Testlab > Import > [Asset] menu option to launch the import tool. Note that you must have proper permissions (import.*) to be able to run the import.
    4. Configure the import parameters to match your CSV file.
    5. Enable “Dry run” -option to run the import without actually importing the data to the database. Check the output log of the import process so that it does not have any unexpected errors.
    6. Disable the “Dry run” -option and re-run the import to actually import the data to your project.

  • Supported CSV file format

    A CSV file consists of any number of records, separated by line breaks; each record consists of fields, separated by a separator character, most commonly a literal comma (,) or tab. All records have an identical sequence of fields. If some column should contain any special characters in the content (such as the separator character itself) the content should be quoted with a quote character, most commonly a double quote (“).

    Each file must start with a header record which identifies for which attributes of the imported asset the data in each column should be mapped to.

    Some common requirements for Testlab-supported CSV file are:

    • The file should be encoded in UTF-8, ISO-8859-9, ISO-8859-1 or Windows-1252 encoding.
    • The file should use a comma (,), a semicolon (;), a colon (:), a vertical bar (|), a tab or a space character as a field separator.
    • The file should use a double quote (“) or a single quote (‘) character as a quote character.
    • Separator characters should not be omitted meaning, that even if one particular row should not have any values in remaining columns the field separators must be set so that columns indicate ’empty’ data. For example,

    This is not valid:

    id,name,status,description,risk
REQ-1,Name of first requirement,Description of first requirement,low
REQ-2,Name of second requirement

    This is valid:

    id,name,status,description,risk
REQ-1,Name of first requirement,Description of first requirement,low
REQ-2,Name of second requirement,,
    • All column content with any special characters impeding with the CSV file format should be quoted with quote character and quote characters in the content must be doubled. For example, from
    id,name,description
REQ-1,First requirement,"Description, with a ""comma"" character"

    the description column will be interpreted and inserted as

    Description, with a "comma" character
    • Each file should start with a single header row which indicates which attribute to map each column to.
    • If time values are imported, standard ISO8601 time of day with time zone should be used as a format: yyyy-MM-dd’T’HH:mm:ssZZ which translates for example to 2010-03-28T20:24:35+02:00 for 28th of March 2010 at 20:24:35 in UTC + 2 hours time zone.
    • For custom fields with the type set as “date” format yyyy-MM-dd is supported, for example, 2010-03-28 translates to 28th of March 2010.

     

    Including custom fields

    To import values to custom fields of the supporting assets (requirements, test cases, and issues) the columns are automatically mapped to configured custom field title in a case-insensitive manner. For example, if you have configured a custom field with a title “Effort” for your requirements in the project, you could import requirements data as

    id,name,effort,risk
REQ-1,First requirement,Minimal,low
REQ-2,Second requirement,,low

    .. and the REQ-1 would get “Minimal” inserted to the Effort field and for REQ-2 the Effort field would be left blank.

     

    Including comments

    To import comments for requirements, test cases or issues the comments should be encapsulated to a single “comment” column. Each comment must contain a timestamp, the name of the author and the actual text of the comment separated with a separator character. For example, for

    id,name,comment
REQ-1,First,
REQ-2,Second,"2010-03-28T20:24:35+02:00,Agent Smith,Some comment"
REQ-3,Third,"2010-03-29T19:24:35+02:00,Agent Brown,Another comment,2010-03-30T11:24:35+02:00,Agent Jones,Third comment"

    REQ-1 would be inserted without comments, REQ-2 would be inserted with one comment by Agent Smith as “Some comment” as content and REQ-3 would be inserted with two comments, one from Agent Brown and another from Agent Jones. Note that the example probably soft-wraps to multiple lines on your display, each record should be on one line in the file.

    Note: Comments are never updated or removed in import. A comment in import is added for the asset if no matching comment for the asset can be found by comparing against the timestamp, author, and content.

     

    Including attachments

    You can import attached files to your assets by including the files as URL references to your file. Keep in mind, that for the import to work your files must be available for downloading over the internet at the time of the import.

    To import attachments, include URL addresses pointing to the files to “attachment” column. For multiple attachments separate the URL addresses with a separator character. For example, for

    id,name,attachment
REQ-1,First,"http://www.company.com/file.txt"
REQ-2,Second,"http://www.company.com/excel.xls,http://www.company.com/pic.jpg"

    .. requirement REQ-1 would be attached with file file.txt and REQ-2 attachment would be attached with excel.xls and pic.jpg files.

    Note: Attachments are never updated or removed in import. If a file with a matching name is already attached to the asset the file is not fetched.

     

    Option field values

    All fields with configurable option values are represented by the key value of the current option value set. The tables in this document list the default values provided by Testlab out of the box. If you customize the options for these fields, the customized values and their corresponding key values must be taken into account.

    The values can be imported by importing the title of the option, the title key of the option (if any) or the key value itself. For example, to set the type of a requirement as Functional, you can import the value as “Functional”, “type.functional” or “1”.

  • Importing requirements

    When importing requirements to Testlab the requirements are identified with a mandatory requirement identifier (id attribute). If a requirement with the same identifier already exists it is updated, if it doesn’t exist, it is created to the project. To import a requirement hierarchy each row may include a parent field pointing to the parent requirement. Please note that when importing a tree structure the file must be ordered in parent-child order (meaning, all parent requirements of children must be included before the child rows).

    Attribute mappings

    Please refer to the following table for supported standard attribute mappings. Note: The identifier of the requirement is mandatory – all other fields are optional and should be included when applicable.

    Field Format Description Default value*
    id Text Requirement identifier [mandatory].
    parent Parent requirement id For sub-requirements, this field should point to the identifier of the parent requirement. Note, that the file must be ordered in the parent-child order. Leave this field as blank for requirements placed at the root of the project. project root
    name Text Name of the requirement.
    generate id automatically true or false Should the requirement’s identifier be set to be generated automatically? true
    class Text Class of the requirement (Requirement, Folder, Test requirement or User story). Requirement
    status Text Workflow status of the requirement. Automatically mapped to a status in requirement workflow configured for the project.

    If you are using default workflows of Testlab please use the English variants of statuses: In design, Ready for review, Rejected, Ready or Deprecated.

    		 “In design” or initial (first) status in the workflow if using a workflow without In design-status.
    type Text Type of the requirement (Functional, Look and feel, Performance, Usability, Environmental, Maintainability, Security, Business or Legal). not set
    source Text Source of the requirement. not set
    risk Text Risk value for the requirement (Low, Medium, High or Critical). not set
    importance Text Importance of the requirement (Low, Normal, High or Critical). Normal
    description HTML text HTML formatted description for the requirement. “”
    assigned to User ID User ID of the user who the requirement 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
    covered true or false Should the requirement be marked as covered or not. false
    created yyyy-MM-dd’T’HH:mm:ssZZ The created timestamp for the requirement. Time of import
    created by Text Name of the person who created the requirement. “Import”
    created by user User ID User ID of the user who created this requirement. not set
    updated yyyy-MM-dd’T’HH:mm:ssZZ The updated timestamp for the requirement. not set
    updated by Text Name of the person who updated the requirement for last time. not set
    updated by user User ID User ID of the user who updated the requirement for last time. not set
    comment Comments (see above) A list of comments to be added to the requirement. –
    attachment Attachments (see above) A list of URL addresses pointing to the files to be attached to the requirement. –
    tags Tags A comma-separated list of tags for the requirement. –
    traces from A comma-separated list of requirement IDs A list of requirement IDs the requirement traces from. –

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

    Requirement import examples
    Basic minimal import
    id,parent,name
REQ-1,,First requirement
REQ-1.1,REQ-1,Sub requirement of REQ-1
REQ-3,,Second requirement at root

    Importing this file creates requirements as:

    • REQ-1 – First requirement
      • REQ-1.1 – Sub-requirement of REQ-1
    • REQ-3 – Second requirement at the root

    Requirements will be created in “In design” status.

    Import with additional details

    Note: Lines starting with space indicate that the content should be on the same line in the file.

    id,parent,name,generate id automatically,class,status,type,source,
 risk,importance,description,assigned to,milestone,
 covered,created,created by,
 updated,updated by,
 comment,
 attachment
US,,User stories,true,folder,ready,functional,Workshop 1,
 medium,normal,"<p>User stories for the system</p>",,
 false,2010-03-28T20:24:35+02:00,Agent Jones,
 ,,
 "2010-03-28T20:25:35+02:00,Agent Jones,""Please, create user stories here.""",
US1,US,Some story,true,folder,ready,functional,Workshop 1,
 medium,normal,"<p>As an user, I do what I do</p>",Agent Brown,Release 1.0 [R1.0],
 true,2010-03-28T21:24:35+02:00,Agent Brown,
 ,,
 ,
 "https://www.melioratestlab.com/wp-content/themes/meliora/img/melioralogoshaded.png"
US2,US,Another story,true,folder,ready,functional,Workshop 1,
 medium,normal,"<p>As an user, I do something else</p>",Agent Brown,,
 true,2010-03-29T21:24:35+02:00,Agent Brown,
 ,,
 ,

    Importing this file creates requirements as:

    • US – User stories (Folder): “User stories for the system”
      • US1 – Some story (User story): “As a user, I do what I do”, targeted to milestone Release 1.0 [R1.0]
      • US2 – Another story (User story): “As a user, I do something else”

    All assets are of “Functional type” from “Workshop 1” (as a source), Folder is created by Agent Jones and stores are created by Agent Brown. US-folder has a comment by Agent Brown as “Please, create user stories here” and the US1 story has Meliora’s logo as an attached file.

    Running the import for requirements

    To import requirements 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 > Requirements 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 (“)]
    • Folder: Select the folder for which into you would like to import the requirements as sub-requirements
    • Import strategy: Select ‘Update’ or ‘Update with hierarchy’ import strategy
      • Update: Creates all requirements from the file which are not already found in the project by requirement identifier; Updates all requirements in your project found by requirement identifier but does not move the existing requirements to the parent specified in the import file.
      • Update with hierarchy: Creates all requirements from the file which are not found in the project by requirement identifier; Updates all requirements in your project found by requirement identifier and moves the requirements in requirement hierarchy to the parent specified in the import file.
    • 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.

    Import scenarios for requirements

    Testlab’s import process is flexible and can be used for various kinds of import scenarios. This chapter describes some common strategies for importing your requirements into your project.

    Import a subset of requirements via a folder

    You have a project in Testlab that includes all requirements of your project: functional requirements, security requirements, usability requirements and so on. Let’s say you a subset of load testing related requirements in an Excel file which you would like to easily import into your Testlab project. The requirements in your Excel file are just in a flat list hierarchy and you would like to import these requirements to your Testlab project.

    For this, a useful strategy is to

    1. Create an import “folder” to the root of your project in Testlab so that you can easily find the imported load testing related requirements from the hierarchy.
    2. Prepare and export your Excel as CSV formatted file according to the format in this document
    3. Import the file to Testlab with ‘Update’ import strategy and select the “Import” folder you created in step 1. as a target

    Now your requirements should be found in the Import folder in your Testlab project. You can now use cut ‘n’ paste features of Testlab to move the requirements to a proper location in your project.

    If for some reason you would like to run the import for these same requirements again later on (and update the data) you can re-run the import with ‘Update’ strategy to keep the requirements in the location you have moved them into.

    Note: If your import file should have a parent field set up and the values in this field point to existing requirements in your project these requirements would be directly imported as sub-requirements of the specified parent. Only requirements without an existing parent would be imported to the selected target folder.

    Testlab as a slave system, third party system as a requirement master

    You have a separate requirement management system which is the master for your requirement data. You’d prefer to use Testlab for testing. You would like to import the requirements and the hierarchy of requirements as it is from the requirement management system.

    For this, a useful strategy is to

    1. Export data from your requirements management system and prepare a CSV formatted file according to the format in this document.
    2. Import the file to Testlab with ‘Update with hierarchy’ import strategy.

    This way the requirements and the requirement hierarchy would be imported to Testlab as it is. Keep in mind, that if for some reason some requirement is moved around in Testlab’s requirement hierarchy the import (or re-import) of the data updates the parent-child relationship of the requirements and so doing forces the requirement hierarchy to match the requirement management system.

    Batch update for a requirement field

    You have a long list of requirements already present in Testlab. You would like to batch update 30 requirements so that the risk field should set to High and the source field should be set to “Week 5 workshop”.

    For this, a useful strategy is to

    1. Prepare a CSV formatted file as

    id,risk,source
ID1,High,Week 5 workshop
ID2,High,Week 5 workshop
...
ID30,High,Week 5 workshop

     2. Import the file to Testlab with the ‘Update’ import strategy.

    Import will update the fields set in your CSV file to specified requirements and leave all other fields in requirements untouched.

  • Importing manual test cases

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

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

    • Functional tests
      • Customer
        • Login

    the “Login” test case would be identified with a category path set as “Functional tests/Customer” and name as “Login“. 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 case is looked up from the project with the category path + test case name pair. If it is found the test case is updated. If it is not found it is created.

    Note: When updating existing test cases and the file contains steps the import will replace the execution steps of the existing test cases. If the existing test cases have already been executed and results are present, the results of the test cases will be lost.

     

    Attribute mappings

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

    Field Format Description Default value*
    category path Text Test 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. 
    name Text Name of the test case [mandatory].
    status Text Workflow status of the test case. Automatically mapped to a status in test case workflow configured for the project.

    If you are using default workflows of Testlab please use the English variants of statuses: In design, Ready for review, Rejected, Ready or Deprecated.

    		 “In design” or initial (first) status in the workflow if using a workflow without In design-status.
    priority Text The priority of the test case (Low, Normal, High or Critical). Normal
    assigned to User ID User ID of the user who the test case 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
    description HTML text HTML formatted description for the test case. “”
    created yyyy-MM-dd’T’HH:mm:ssZZ The created timestamp for the test case. Time of import
    created by Text Name of the person who created the test case. “Import”
    created by user User ID User ID of the user who created this test case. not set
    updated yyyy-MM-dd’T’HH:mm:ssZZ The updated timestamp for the test case. not set
    updated by Text Name of the person who updated the test case for last time. not set
    updated by user User ID User ID of the user who updated the test case for last time. not set
    comment Comments (see above) A list of comments to be added for the test case. –
    attachment Attachments (see above) A list of URL addresses pointing to the files to be attached to the test case. –
    tags Tags A comma-separated list of tags for the test case. –
    verifies A comma-separated list of requirements IDs A list of requirement IDs the test case verifies. –
    precondition Text Preconditions for the execution of the test case. “”
    postcondition Text The expected end result for the execution of the test case. “”
    step description Text Description of a step. “step description” and “step expected” fields can be used to import the steps of the test case by including multiple rows with these two fields set appropriately – see examples below. “”
    step expected Text The expected result of a step. See above. “”

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

    Including execution steps

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

    category path,name,step description,step expected
"Cat A",Some test case,"Do something","Expect something to happen"
,,"Do something else","Expect something else to happen"
,,"Do a third thing","Expect miracles"

    would add a “Cat A” test category, create a “Some test case” named test case under it and add three steps to the test case:

    1. Do something -> Expect something to happen
    2. Do something else -> Expect something else to happen
    3. Do a third thing -> Expect miracles

     

    Manual test case import examples
    Basic minimal import
    category path,name,step description, step expected
"Cat A",,,
"Cat A/Cat B",First test case,"Click","You hear a click"
,,"Click again","You hear a click again"
"Cat C",Second test case without steps,,

    Importing this file creates test categories and test cases as:

    • Cat A
      • Cat B
        • First test case
    • Cat C
      • Second test case without steps

    “First test case” has two steps as

    1. Click -> You hear a click
    2. Click again -> You hear a click again

    “Second test case without steps” is created without any steps.

    Test cases will be created in the “In design” status.

    Import with additional details

    Note: Lines starting with space indicate that the content should be on the same line in the file.

    category path,name,status,priority,
 description,assigned to,
 precondition,postcondition,
 step description,step expected,
 created,created by,
 updated,updated by,
 comment,
 attachment
"Functionality",,,,,,,,,,,,,,,
"Functionality/User","Login",in design,high,
 "<p>Test case for user login</p>",agentsmith,
 "Login page is open","User is logged in",
 "Enter 'admin' as user name","User name is accepted",
 2010-03-28T21:24:35+02:00,Agent Brown,
 ,,
 "2010-03-28T21:25:35+02:00,Agent Brown,""Are the credentials in the file correct ?""",
 "https://www.example.com/import/credentials.xls"
,,,,,,,,"Enter an invalid password and click Login","Access is denied",,,,,,
,,,,,,,,"Enter a valid password and click Login","Access is granted",,,,,,
"Functionality/Admin","Kill session",in design,high,
 "<p>Test case for invalidating sessions</p>",agentsmith,
 "Admin view is open","Session is invalidated.",
 "Select a live session from the list","Session is selected",
 2010-03-28T21:28:35+02:00,Agent Brown,
 ,,
 ,
,,,,,,,,"Click Invalidate session","View reports session as invalidated",,,,,,
,,,,,,,,"With invalidated session, click a link on page","Access is denied",,,,,,

    Importing this file creates test categories and test cases as:

    • Functionality
      • User
        • Login
          • Enter ‘admin’ as username -> Username is accepted
          • Enter an invalid password and click Login -> Access is denied
          • Enter a valid password and click Login -> Access is granted
      • Admin
        • Kill session
          • Select a live session from the list -> Session is selected
          • Click Invalidate session -> View reports session as invalidated
          • With invalidated session, click a link on page -> Access is denied

    Highlighted text below Login and Kill session represent steps added to the test cases. The login test case will be attached with credentials.xls file and comment as “Are the credentials in the file correct ?” will be added to the test case.

     

    Running the import for manual test cases

    To import test cases 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 cases 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 (“)]
    • Folder: Select the category for which you would like to import the content of the file into. You can use this option to bulk import the categories and test cases to a specified import folder and hand-pick the content from the folder by cutting and pasting later on.
    • 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 automated test cases

    When you import automated test cases to Testlab you are actually importing test categories and test cases in them. Testlab supports a CSV file format that includes all this information in one compact file.

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

    • Automated tests
      • Customer
        • LoginChecks

    the “LoginChecks” test case would be identified with a category path set as “Automated tests/Customer” and name as “LoginChecks“. 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 case is looked up from the project with the category path + test case  + type (always automated) combination. If it is found the test case is updated. If it is not found it is created.

     

    Attribute mappings

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

    Field Format Description Default value*
    category path Text Test 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. 
    name Text Name of the test case [mandatory].
    automation Text Automation rule value for the automated test. “”
    priority Text The priority of the test case (Low, Normal, High or Critical). Normal
    assigned to User ID User ID of the user who the test case 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
    description HTML text HTML formatted description for the test case. “”
    created yyyy-MM-dd’T’HH:mm:ssZZ The created timestamp for the test case. Time of import
    created by Text Name of the person who created the test case. “Import”
    created by user User ID User ID of the user who created this test case. not set
    updated yyyy-MM-dd’T’HH:mm:ssZZ The updated timestamp for the test case. not set
    updated by Text Name of the person who updated the test case for last time. not set
    updated by user User ID User ID of the user who updated the test case for last time. not set
    comment Comments (see above) A list of comments to be added for the test case. –
    attachment Attachments (see above) A list of URL addresses pointing to the files to be attached to the test case. –
    tags Tags A comma-separated list of tags for the test case. –
    verifies A comma-separated list of requirements IDs A list of requirement IDs the test case verifies. –

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

     

    Automated test case import examples
    Basic minimal import
    category path,name,automation
"Cat A",,
"Cat A/Cat B",UI tests,"fi.meliora.tests.ui"
"Cat C",Backend tests,"fi.meliora.tests.backend"

    Importing this file creates test categories and test cases as:

    • Cat A
      • Cat B
        • UI tests (automation rule value: fi.meliora.tests.ui)
    • Cat C
      • Backend tests (automation rule value: fi.meliora.tests.backend)

     

    Running the import for automated test cases

    Import for automated tests follows the same principles and logic as with the manual test cases. See “Running the import for manual test cases” above.

  • Importing issues

    You can import issues to your Testlab project. Issues are identified with an ID: If an issue with matching ID is found from the project the issue is updated. If the ID is left blank a new issue is added to the project and an issue ID is automatically assigned to it. All rows with issue IDs set and no matching issue from the project can be found are ignored.

     

    Attribute mappings

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

    Field Format Description Default value*
    id Text Issue identifier. If left blank a new issue will be created with automatically assigned issue identifier applied.
    title Text Title for the issue. “”
    status Text Workflow status of the issue. Automatically mapped to a status in issue workflow configured for the project.

    If you are using default workflows of Testlab please use the English variants of statuses: Open, Assigned, Resolved, Closed or Reopened.

    		 “Open” or initial (first) status in the workflow if using a workflow without Open-status.
    type Text Type of the issue (Defect, New feature, Enhancement or Other) Defect
    priority Text The priority of the issue (Trivial, Low, Normal, High or Critical). Normal
    severity Text The severity of the issue (Cosmetic, Low, Normal, High or Blocker) Normal
    resolution Text Resolution of the issue (Fixed, Won’t fix, Duplicate, More info needed or Cannot repeat) not set
    assigned to User ID User ID of the user who the issue should be assigned to. not set
    milestone Text Title and optionally the identifier of the milestone in “Title [Identifier]” format, for example, “Release 1.0 [R1.0]”. not set
    version Text Detected in version – if a matching version is not found in the project a new version will be created. not set
    resolved in version Text Resolved in version – if a matching version is not found in the project a new version will be created. not set
    environment Text Environment – if a matching environment is not found in the project a new environment will be created. not set
    description HTML text HTML formatted description for the issue. “”
    created yyyy-MM-dd’T’HH:mm:ssZZ The created timestamp for the issue. Time of import
    created by Text Name of the person who created the issue. “Import”
    created by user User ID User ID of the user who created the issue. not set
    updated yyyy-MM-dd’T’HH:mm:ssZZ The updated timestamp for the issue. not set
    updated by Text Name of the person who updated the issue for last time. not set
    updated by user User ID User ID of the user who updated the issue for last time. not set
    resolved yyyy-MM-dd’T’HH:mm:ssZZ The resolved timestamp for the issue. not set
    resolved by Text Name of the person who resolved the issue. not set
    resolved by user User ID User ID of the user who resolved the issue. not set
    closed yyyy-MM-dd’T’HH:mm:ssZZ The closed timestamp for the issue. not set
    closed by Text Name of the person who closed the issue. not set
    closed by user User ID User ID of the user who closed the issue. not set
    comment Comments (see above) A list of comments to be added to the issue. –
    attachment Attachments (see above) A list of URL addresses pointing to the files to be attached to the issue. –
    tags Tags A comma-separated list of tags for the issue. –

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

     

    Issue import examples
    Basic minimal import
    title,type,version,description
"Example defect",defect,beta 0.1,"<p>Something is rotten in beta 0.1</p>"
"Example new feature",new feature,,"<p>Color purple would be great!</p>"

    Importing this file would add two new issues:

    • “Example defect” as a defect and
    • “Example new feature” as a new feature

    and assign new issue IDs for them. “Example defect” would be set as detected in version “beta 0.1” and “beta 0.1” version would be added to the project if it does not already exist.

    Import with additional details

    Note: Lines starting with space indicate that the content should be on the same line in the file.

    id,title,
 description,
 priority,severity,resolution,
 status,type,assigned to,version,
 environment,resolved in version,
 created,created by,
 updated,updated by,
 comment,
 attachment
ATM-3,"Existing issue",
 "<p>Description of ATM-3</p>",
 high,blocker,fixed,
 closed,defect,,alpha 0.1,
 Production,alpha 0.2,
 2010-03-28T21:24:35+02:00,Agent Jones,
 2010-03-30T20:14:25+02:00,Agent Brown,
 "2010-03-30T20:14:35+02:00,Agent Brown,""Seems to work ok now.""",
,"New issue",
 "<p>Description of issue</p>",
 normal,normal,,
 open,defect,,alpha 0.2,
 Production,,
 2010-03-30T22:24:35+02:00,Agent Brown,
 ,,
 ,

    Importing this file would update the existing ATM-3 issue (if found) by closing it. adding a new comment to it and updating the attributes according to the fields set in the file. The import would also add a new issue titled “New issue” as opened by Agent Brown.

     

    Running the import for issues

    To import issues 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 > Issues 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 manual test runs (testing results)

    When you import test runs to Testlab you are practically importing manual test runs, relations to manual 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].
    description 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 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 The 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
    test comment Text Execution summary for the test case. “”
    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 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 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 manual 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.

  • Exporting data

    To export requirements, test cases or issues in CSV format explained above log on to your project and select Testlab > Export > [Asset]. Testlab exports the content to a UTF-8 encoded CSV file with a comma (,) as a separator and double quote (“) as a field separator.