Parameters

This topic explains Tosca Cloud's parameter types and levels. Use parameters to control how tests run and reuse values across test cases, playlists, workspaces, and your entire tenant.

Parameter types

Tosca Cloud supports two parameter types, each set at different levels. Here's what each type does:

  • Special task parameters control how a test case runs. You set them and Tosca Cloud acts on them in the background. For example, define the default browser, set a wait time, or configure the decimal character format. You don't need to reference them in test steps. For a full list of special task parameters and their values, check out Supported parameters.

  • Custom parameters let you define a value once and reuse it in multiple steps in your test case. For example, if you need to enter the same 20-digit code in several places, create one parameter and reference it everywhere. Check out Parameter values.

Parameter levels

Set parameters at four levels. Each level inherits the values from the level above and can override them. Set your defaults at the tenant level. Override only what needs to be different for a specific workspace, playlist, or test case.

Level

Set by

Applies to

Overrides

Tenant

Administrators

All workspaces, playlists, and test cases in this tenant.

None.

Workspace

Administrators and contributors

All playlists and test cases in this workspace.

Tenant values.

Test case

Administrators and contributors

This test case only.

Tenant and workspace values.

Playlist

Administrators and contributors

All test cases in this playlist.

Tenant, workspace, and test case values.

Choose the right level

Choose the level that matches the scope of the value you want to set:

  • Tenant: Use tenant parameters for values that should be the same across your entire organization. For example, the default browser, base URL, or number format. Every team gets a consistent starting point without extra configuration.

  • Workspace: Use workspace parameters when a team or project needs different values from the tenant defaults. For example, one team tests a localized version of the application with a different URL or decimal format. Workspace parameters override tenant values for that workspace only and don't affect other teams.

  • Test case: Use test case parameters for values that are specific to a single test case.

  • Playlist: Use playlist parameters to override values for one specific playlist. For example, if you want to run the same test cases against a staging environment instead of production, set the URL as a playlist parameter for that playlist. Playlist parameters have the highest override priority.

Let's say your organization builds a travel booking application. You have three teams, each with their own workspace: the Web team, the Mobile team, and the API team.

The administrator sets the following tenant parameters:

  • Browser: All teams now use Chrome as the default browser for test cases. The data type is set to String.

  • BaseUrl: All teams now use https://booking.travelapp.example.com as the base URL for all test cases. The data type is set to String.

The Mobile team tests on a different platform, so the administrator sets the following workspace parameters for the Mobile team's workspace:

  • Browser: The Mobile team uses Firefox as the default browser for test cases. The data type is set to String.

  • BaseUrl: The Mobile team uses https://mobile.travelapp.example.com as the base URL for all test cases. The data type is set to String.

The Web team wants to run one playlist against a staging environment. A contributor sets the following playlist parameter:

  • BaseUrl: The Web team uses https://staging.travelapp.example.com as the base URL for this playlist only. The data type is set to String.

One test case in the API team's workspace checks a specific flight booking. A contributor sets the following test case parameter:

  • FlightNumber: The test case uses TRV-2024-789 as the flight number. The data type is set to String.

When you run a test case, Tosca Cloud applies the parameters as follows:

For the Web team's playlist:

  • BaseUrl: The Web team uses https://staging.travelapp.example.com because the playlist parameter overrides the tenant parameter value.

  • Browser: The Web team uses Chrome because no playlist parameter is set at this level, so it inherits the tenant parameter value.

For the Mobile team:

  • Browser: The Mobile team uses Firefox because the workspace parameter overrides the tenant parameter value.

  • BaseUrl: The Mobile team uses https://mobile.travelapp.example.com because the workspace parameter overrides the tenant parameter value.

For the API team's test case:

  • FlightNumber: The test case uses TRV-2024-789 because of the test case parameter.

  • Browser and BaseUrl: The API team uses Chrome and https://booking.travelapp.example.com with no workspace or test case parameters set, inheriting the tenant parameter values.

What's next

Set up parameters at the right level for your use case: