Custom Fields
Custom fields allow you to customize Testmo for your projects and your workflow. You can add new fields to test cases, test results and sessions (for test automation results you can also submit additional fields separately).
Not only can you configure new fields, you can also group them into templates so testers can choose different field templates for different tests. For example, some test cases can have detailed test steps that uses the Steps field, while other test cases might work better with a single rich-text field. Likewise, an exploratory test session can have different fields than a usability test session etc.
Additionally, fields and templates can be assigned to all or just some projects. When fields are assigned to projects, it's possible to specify different project options. This way you can easily define different dropdown options or field defaults for different projects. See below for a description of the different entities and concepts of Testmo's custom fields.
Cannot see a new field you've added?
If you cannot see a new field you have added, you have likely not assigned the field to your project(s) and/or template(s). See our FAQ below on how to resolve this.
Custom fields and templates
Custom fields can be configured for test cases, test results and sessions. When adding new custom fields, you select the type and enter a system name for the field. Both the system name and field type cannot be changed after a field was added. The system name is used for imports, exports or future API methods. Currently Testmo supports the following field types:
- Checkbox
- Date
- Dropdown
- Float
- Integer
- Link
- Multi-select
- Steps (cases only)
- String
- Text
When you add or edit custom fields, you need to assign them to your projects. In the Add/Edit field dialog, make sure to add your projects to the Projects & options section. If you do not assign a field to your projects, the field will not be visible in the project. You can choose to either add a field to all your projects, or you can select specific projects the field should be active for.
When you assign your fields to your projects, you also specify various field options. This includes options such as default values, dropdown options, max/min values, whether the field is required etc.
The advantage of having these options as part of the project assignment is that you can specify different options for different projects if you like. For example, a field could be required in one project and can be optional in other projects. Likewise, e.g. for a dropdown field you can specify different dropdown values for different projects etc.
When you assign fields to projects, you can select whether a field is a required or optional field. For required fields, users have to enter or select a value when adding a test case, test result or session.
Please note that when users add new test cases via the inline add feature from the repository page, Testmo always uses the default value of a field regardless of whether a field is required. Likewise, if a user does not have the permission to enter a value for restricted fields (see below), then the default value is used for required fields.
When adding to the result log in a test run without a status (i.e. comments and assignments), Testmo also automatically uses the default value of fields that are required.
It is also possible to restrict custom fields to certain users and groups, so only users with restricted field permissions can update these fields. For example, if you add a Review dropdown field to select if a test case needs a review or has been reviewed, you might want to restrict this field to test leads or managers. This way most users cannot change this field unless they have the permission to do so.
You can configure field restrictions when you assign fields to projects. So you can also adjust the restrictions for different projects. You can learn more about field restrictions in our permissions article.
Custom fields are linked to templates. Templates allow users to select a different set of fields for different test cases or sessions. For example, you could create two separate templates for sessions, e.g. Exploratory test and Usability test and enable different fields for these templates. When a user then creates a new session, the user can select one of these templates for the session to only use the relevant fields for this session.
You can add and edit templates for the test case repository (for test cases & results) and for sessions from Admin > Fields. Make sure to add new fields to one or more of your templates. If you do not enable a field for your templates, the field will not be visible when you add/edit test cases, results or sessions. You can also see the list of templates for a field by editing the field and reviewing the template list on the right side of the field add/edit dialog.
We are covering some frequent questions about adding and configuring custom fields below.
In order to add a new field and to ensure that it is visible when adding test cases, results or sessions, follow these steps:
- When editing the field, in the Projects & Options section of the Add/Edit field dialog, ensure that the field is assigned to your project(s). If the field is not assigned to your project(s), the field will not be visible.
Adding field project mappings
- You also need to enable the field for your templates. For example, when adding a new test case field, also ensure that the field is added to your template(s) by editing your template(s) under Admin > Fields. If the field is not selected for your template(s), the field will not be visible.
Adding fields to templates
- Last but not least, when adding/editing a test case or session, select one of the templates you've enabled the field for in the above step.
If you are still unsure about the field configuration, please include screenshots of the following dialogs and pages when contacting us:
- The field configuration
- The field's project options
- The relevant template
- The case/session edit dialog
Last modified 8mo ago