Skip to main content
Version: TMT v5 (latest)

Administration Guide

This guide will empower administrators to maintain their tenants, projects and users.

Q12-TMT has three different admin roles, which the user can be assigned to.

User roles

A system role is assigned to every user. It determines if a user is allowed to change the configuration.

System role order from lowest to highest privileges:

  • Guest: Basic access for assigned Projects.
  • Tenant Administrator: Full administrative control within a single tenant.
  • User Administrator: Manage user accounts and assign them roles.

Every new user is assigned the system-wide role “Guest” by default. The roles “Guest” and “Tenant Administrator” can be combined with the “User Administrator” role to obtain access to user management.

Only the “Tenant Administrator” automatically has access to all Projects. All other system-wide roles require a project-specific role to open and work in Projects. It is possible to assign a user different roles for different Projects (and Subprojects). The project assignment is displayed in the user’s profile.

The following cross-project rules apply

  • A project-level role applies to the Project and to all its Subprojects (including future Subprojects) when no role is defined at the Subproject level.
  • A role assigned to a Subproject applies exclusively within that Subproject. For the parent Project, the user automatically receives the project role “Guest,” unless a specific role has been assigned there

(Sub)Project specific roles:

  • Tester: Project members who create, maintain, and manage Test Suites and Test Cases, execute Test Runs, document results, and generate reports.
  • Test Manager: Responsible for planning and controlling testing activities, managing testing resources, and evaluating the test object.
  • Project Administrator: Administrative rights for the assigned project.
  • Guest: Stakeholders who want to review the Test Case base, documentation, and execution status (e.g., participants from other Projects or management).

A detailed list of permissions for the project-specific roles can be found in the “Permission” chapter.

Tenant administrator

The tenant administrator can edit the general configuration in the “tenant setting” menu. The language of created PDF files can also be specified here.

The use of AI features can be enabled or disabled by the tenant administrator via the API for individual Projects or Subprojects. They are not a direct project member but have the same rights as a project administrator for all (Sub)Projects. After logging into Q12 TMT, the project list with all (Sub)Projects appears immediately, not the dashboard.

User administrator

The user administrator has no project specific rights and is not assigned to any Project. Depending on the directory service in use, different functions are available to the user administrator in user management.

Use of Q12-TMT’s internal user management:

  • Create
  • Edit
  • Delete
  • Set active/inactive
  • Role assignment
  • Changing password

Use of a directory service (e.g., AD, LDAP) or single sign on (SSO)

  • Edit
  • Set active/inactive
  • Role assignment

User management

In this overview a list of all users is displayed. The user administrators can create, edit, or remove user accounts.

Clicking a user's row opens edit mode.

Toolbar:

  • + Users: Create a new user account.
  • Search: Searches the list for the entered character string (min. 3 characters).
  • Filter: Access the filter mask to filter the list.

Context menu:

  • Delete: Delete the user.

Only users that are not or were not assigned to a Q12-TMT business object, e.g., a Test Case in a closed Test Run, can be deleted.

info

If the Q12-TMT user management is used, the function to create and delete a user are available. If the login is done via a user directory (e.g., AD, LDAP) or via single sign-on (SSO), these two functions are not available.

Create & edit

Active status
A user’s status can be set manually to “yes” (for active) or “no” (for inactive). Access for an inactive user is blocked.

Roles
Each user can be assigned to one or more (Sub)Projects with different roles.

Expiration date
It is possible to set an expiration date for the account. Q12-TMT automatically sets users to “Inactive” as soon as the specified date has been reached. The field is not visible tenant administrator or user administrator.

Create a new user – user directory or SSO

After a user sign in to Q12-TMT for the first time via SSO, an account is created automatically. A user administrator can then assign system and project roles to the user and optionally set an account expiration date.

Create a new user directly in Q12-TMT

Clicking on the “+ User” button in the toolbar to create a new user.

Mandatory information:

  • User name
  • Email
  • Given name
  • Family name
  • Password
  • System role

Delete a user

Only users that are not or were not assigned to a Q12-TMT business object, e.g., a Test Case in a closed Test Run, can be deleted.
The following workflows can be used to deny a user access nonetheless.

When the user is leaving a Project:

  • In Project and Subproject roles, delete every project assignment:
    • This action has no impact on history and metadata.
    • The username is still visible in Q12-TMT, but the user will no longer be in the “Tester” or the “Assignee” list.

When the user is leaving the company:

  • Set active status to no to immediately block sign-in.
  • In Project and Subproject roles, delete every project assignment (not necessary).

Project settings

note

This “risk-based testing” feature is not available for all license options.

The “My Projects” button opens the project structure, a list of all Projects and Subprojects assigned to the user. In this overview, the project settings can be opened via the context menu.

The project setting is separated into three sections:

  • Test Suite
  • Test Run
  • Risk-based testing

For Subprojects, only the “Risk-based testing” section is displayed.

In the “Test Suite” and “Test Run” sections, the displayed columns of the respective tables can be configured.

The “Risk-based testing” section contains the keywords that are used to determine the impact value. The keywords can either be maintained manually or derived automatically from specification documents using the AI function.

The following rules apply to the keywords:

  • Minimum number of characters: 1
  • Maximum number of characters: 30
  • Maximum number of keywords: 50
  • No duplicates

Calculation of the impact

The calculation and analysis are only conducted for Test Cases where the impact slider is set to “Auto”.

The analysis begins by searching for the stored keywords (starting with the most severe) in the title of the Test Case, followed by the folders and subfolders of the Test Case. When a keyword is found, the search for the affected Test Case can be stopped and map the keyword corresponding impact score to the Test Case. If none of the keywords can be found in the fields searched, the impact remains empty.

The impact level is then weighted with the Test Case prioritization.

  • Mandatory test: Impact Score * 1
  • Optional test: Impact Score * 0,5
  • No test: Impact Score * 0

If no prioritization is specified, the impact score is unchanged.

Based on the calculated impact score, the impact is categorized as follows:

“n” is the impact scoreImpact
8 ≤ nSerious
6 ≤ n < 8Major
4 ≤ n < 6Moderate
2 ≤ n < 4Minor
0 ≤ n < 2Insignificant

The calculation is executed each time there is a change to content that is included in the calculation, e.g., changes to prioritization or changes for the folder of the Test Case.

Calculation of the likelihood

The calculation and analysis are only conducted for Test Cases where the likelihood slider is set to “Auto” and is based on Test Cases that are included in the same Version of the Project or Subproject.

From a business perspective, a complex feature would lead to complex Test Cases with a lot of information in the precondition and many test steps.

For the calculation, the median number of test steps and the median number of words in the preconditions are first determined for all Test Cases in one Version of the (Sub)Project. For each individual Test Case, the number of test steps as well as the number of words in the preconditions are compared with the corresponding median, and a value is assigned as a complexity factor:

“f” is the corresponding complexity factor of a Test CaseComplexity level
2 * Median < f5
1,2 * Median < f ≤ 2 * Median4
0,8 * Median < f ≤ 1,2 * Median3
0,5 * Median < f ≤ 0,8 * Median2
0 ≤ f ≤ 0,8 * Median1

The complexity “C” of a Test Case is then determined as the average of the previously calculated complexity values, from which the likelihood is derived.

“C” is the average complexityLikelihood
4 < CAlmost certain
3 < C ≤ 4Likely
2 < C ≤ 3Possible
1 < C ≤ 2Unlikely
0 < C ≤ 1Rare
No valueNo value

AI keyword generation

info

The system administration or support can enable or disable the use of this AI feature for each (Sub)Project individually.

This function is only available for project admins and system admins.

To generate keywords, a file (PDF or DOCX) must be uploaded in the “Risk-based testing” section.

Go to: My projects → Context menu (Sub)Project → Settings → “Risk-based testing” section → Edit → Generate keyword → File upload

There are several limits to the file:

  • Type: PDF & DOCX
  • Number of files: 1
  • Max. file size: 15 MB

After the file has been successfully uploaded, the process can be started by clicking the “Process” button. If the generation was successful, a results table with the impact score and keywords is displayed in the details view. The identified industry, business context, and language are also displayed. Clicking on the “Replace current keywords” button closes the details view and the existing impact score table will be replaced by the new values.

If the generation is faulty, a corresponding message is displayed.

The uploaded file will not be saved, it will be deleted after one day at the latest.

Active users

The user administrator sees a list of all active users in this menu. This list can be exported as a CSV file.

Permission

User rolesPermission
TesterRead-only access to the Project and Project Version pages.
Create and edit Test Suites.
Create, edit and delete Test Cases and folders.
Print Test Cases as PDF.
Create, edit and close Test Runs.
Add, edit and remove Test Suites in Run and Test Cases in Run.
Execute Test Cases in Run, document and edit test results.
Create Test Run Report (PDF).
Search for business objects.
Print the search result list for Test Cases as PDF and transfer it to a Test Run.
Pin and unpin business objects.
Assignment as Assignee and Tester to a Test Case.
Overview of assigned tasks.
Test managerSee tester, additionally:
Edit Projects.
Create, edit and close Versions.
Delete Test Suite and empty Test Runs.
Project administratorSee test manager, additionally:
Create Subprojects.
Change project settings.
GuestRead-only access to the Project, Project Version, Test Suite, Test Case and Test Run pages.
Print Test Cases as PDF.
Create Test Run Report (PDF).
Search for business objects.
Print the search result list for Test Cases as PDF.
Pin and unpin business objects.
“My Task” page is not available.

Q12-TMT Data Export

This feature and detailed documentation are available only to on-premise customers.

Customers using the cloud version can implement an export feature themselves with the usage of the TMT-API as described in https://q12-tmt.com/docs/api/intro. Alternatively, exports can be requested from support as part of the (paid) support services.

The export operation collects all required project business objects into a portable package.

The process generates a set of CSV files, which are stored in a predefined folder in the file system. Test Cases, Test Suites, Test Runs, attachments, and historical data are exported for each Project Version. The export file also includes information about the hierarchical structure of the Test Cases.