> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/migrate-to-contextqa/tricentis-tosca-to-contextqa.md).

# Migrate from Tricentis Tosca

Inventory Tosca requirements, TestCases, Modules, TestCase-Design, data, and ExecutionLists; rebuild a verified pilot in ContextQA without claiming a direct importer.

## Quick answer

Use a staged, intent-led conversion for Tricentis Tosca. This documentation does not verify a direct ContextQA importer for Tosca subset files, Modules, TestCase-Design objects, or ExecutionLists. Inventory the Tosca object graph, export or document a representative package for review, extract business behaviors and assertions, rebuild a small pilot in ContextQA, and run both systems against the same build. Migrate by accepted behavior—not by object count—and keep Tosca runnable until coverage, evidence, data, and rollback gates pass.

## Why Tosca needs a different path

Tosca suites can distribute behavior across:

* Requirements and requirement links;
* TestCase-Design TestSheets, classes, instances, and templates;
* TestCases and reusable TestStepBlocks;
* scanned Modules and ModuleAttributes;
* business parameters, buffers, and test configuration parameters;
* recovery and cleanup scenarios;
* ExecutionLists, configurations, and distributed execution; and
* workspace/project settings, file references, and external services.

A mechanical “step export” may omit the relationships that make a test valid. The migration must reconstruct the behavior and its ownership.

{% hint style="warning" %}
Tosca subset export is designed to transfer Tosca objects between Tosca projects. Tricentis documents that project-root test configuration parameters and project definitions are not included in subset export. Do not treat a `.tsu` or `.tce` file as a complete, portable ContextQA input. See the official [Tosca subset documentation](https://documentation.tricentis.com/tosca/1520/en/content/tosca_commander/import_export_subsets.htm) for the source version you use.
{% endhint %}

## Choose the migration boundary

| Tosca scope                               | Recommended treatment                                                                     |
| ----------------------------------------- | ----------------------------------------------------------------------------------------- |
| Browser business workflows                | Reconstruct intent and assertions in ContextQA pilot cases                                |
| API setup or validation                   | Map to verified ContextQA API steps or retain the source control                          |
| TestCase-Design combinations              | Preserve equivalence classes and required combinations in a data/coverage ledger          |
| Reusable TestStepBlocks                   | Convert by behavior; use reviewed reusable setup/data patterns where available            |
| Modules/ModuleAttributes                  | Use as source evidence; do not copy locator implementation as business intent             |
| Recovery Scenarios                        | Separate environment recovery from assertion behavior and define explicit stop conditions |
| ExecutionLists                            | Map release purpose to ContextQA suites/plans, not folder structure alone                 |
| Desktop/SAP/mainframe/specialized engines | Retain until the exact ContextQA target capability is verified                            |
| Distributed execution                     | Evaluate browser/device, network, capacity, evidence, and ownership separately            |

## Phase 1: Freeze the Tosca source

Record:

```
Tosca version:
Repository/workspace:
Workspace revision or checkout baseline:
Project settings baseline:
Selected Requirements folders:
Selected TestCase/TestCase-Design folders:
Selected ExecutionLists:
Required Modules and reusable blocks:
Test configuration parameters:
Data sources/services:
Baseline execution result:
Migration owner:
Tosca owner:
```

Use a persistent ExecutionList result for baseline evidence rather than a ScratchBook-only run. Tricentis documents ScratchBook as a trial-run surface whose structure and results do not persist, while ExecutionLists preserve results. See [Tosca test execution overview](https://documentation.tricentis.com/tosca/1520/en/content/tosca_commander/execution_overview.htm).

## Phase 2: Inventory the Tosca object graph

### Requirement-to-execution map

| Behavior ID | Requirement | TestCase/Template | TestCase-Design source | Modules/reusable blocks | ExecutionList | Last result | Owner |
| ----------- | ----------- | ----------------- | ---------------------- | ----------------------- | ------------- | ----------- | ----- |
|             |             |                   |                        |                         |               |             |       |

### Configuration and data map

| Dependency                   | Scope               | Source location | Secret? | Setup/reset | ContextQA destination                       | Owner |
| ---------------------------- | ------------------- | --------------- | ------- | ----------- | ------------------------------------------- | ----- |
| Test configuration parameter | Project/folder/test |                 |         |             | Environment or data profile / review        |       |
| Buffer/dynamic value         | Run                 |                 |         |             | Runtime variable or API/UI handoff / review |       |
| Test data service/source     | Shared              |                 |         |             | Test data profile/API setup/retained        |       |
| File reference               | Workspace/external  |                 |         |             | Uploaded fixture/retained/review            |       |
| Credential                   | User/service        |                 | Yes     | Rotation    | Approved secret control                     |       |

Do not put secret values into the migration workbook, screenshots, or generated steps.

### Recovery behavior map

| Recovery/Cleanup scenario | Trigger | Intended recovery | Could hide a defect? | ContextQA treatment                           | Stop condition |
| ------------------------- | ------- | ----------------- | -------------------- | --------------------------------------------- | -------------- |
|                           |         |                   |                      | Environment recovery / explicit step / retain |                |

Recovery that dismisses a modal, refreshes a page, or repeats a step may make the next action possible, but it can also conceal a product change. Preserve the original failure and require a reviewer when recovery changes the behavior under test.

## Phase 3: Create a portable evidence package

Use your organization’s approved Tosca documentation/export methods to preserve:

* object names and stable IDs;
* requirement links;
* ordered TestSteps and ActionModes;
* TestCase-Design classes, instances, and coverage rationale;
* Module and reusable-block dependencies;
* configuration-parameter names without secret values;
* ExecutionList structure and the latest persistent results;
* screenshots, recordings, or logs needed to understand a failure; and
* source owner and revision.

If you use subset export, keep it as a Tosca backup/reference. Official Tosca documentation says exported individual objects include the referenced objects needed to recreate them in Tosca, but also identifies exclusions. Record the exact Tosca version and verify the exported subset by opening it in an approved disposable Tosca workspace before relying on it.

## Phase 4: Build behavior packets

Translate each selected business behavior:

```
Behavior ID:
Requirement and risk:
Source Tosca objects and revision:
Role/tenant:
Preconditions:
Data setup and cleanup:
Action sequence:
Positive assertions:
Negative assertions:
Persisted-state assertions:
Required environments/browsers/devices:
Recovery behavior that must not weaken the result:
Source execution evidence:
Known exclusions:
Reviewer:
```

### Translate ActionModes to outcomes

Do not mechanically preserve implementation syntax. Ask what the step means:

| Tosca intent              | ContextQA treatment                                                |
| ------------------------- | ------------------------------------------------------------------ |
| Input/select              | Natural-language interaction using controlled test data            |
| Verify                    | Explicit UI, API, data, or file assertion with the same outcome    |
| Buffer/save dynamic value | Named runtime handoff with scope and sensitivity review            |
| WaitOn/delay              | Observable readiness condition; fixed delays require justification |
| Constraint                | Precondition or selection rule in the behavior packet              |
| Recovery                  | Separate recovery policy with retained failure evidence            |

## Phase 5: Select a representative pilot

Include:

1. A linear browser workflow.
2. A requirement with positive and negative cases.
3. A TestCase-Design template with several meaningful instances.
4. A reusable block used across tests.
5. A buffer or dynamic data handoff.
6. A recovery scenario or historically unstable flow.
7. An API/data prerequisite if it is in scope.
8. A specialized-engine case to determine whether it must remain in Tosca.

The pilot should reveal the hard boundaries. It should not be sized to maximize the migration percentage.

## Phase 6: Rebuild the ContextQA pilot

For each behavior packet:

1. Create the required [environment](/execution/environments.md) and safe data references.
2. Create the ContextQA test case from the approved business steps or requirements.
3. Review every generated step and assertion in the [test steps editor](/web-testing/test-steps-editor.md).
4. Recreate negative and boundary cases rather than only the happy-path instance.
5. Map accepted cases to a purpose-based suite and saved test plan.
6. Record unsupported steps and the retained Tosca owner.

Do not upload a Tosca subset and assume ContextQA can interpret it. Use documented ContextQA input formats and workflows only.

## Phase 7: Verify TestCase-Design coverage

Tricentis describes TestCase-Design as a way to structure combinations and reduce redundancy. Preserve the decision logic, not necessarily every generated instance. See [Tosca TestCase-Design](https://documentation.tricentis.com/tosca/1520/en/content/testcase_design/testcase_design_intro.htm).

| Attribute/class | Relevant values | Pairwise/boundary rule | Source instances | ContextQA data/cases | Omitted combinations and reason |
| --------------- | --------------- | ---------------------- | ---------------: | -------------------- | ------------------------------- |
|                 |                 |                        |                  |                      |                                 |

Run at least one positive, negative, boundary, and invalid combination when the requirement calls for them.

## Phase 8: Run parallel acceptance

Execute Tosca and ContextQA against the same application build, role, data revision, and intended browser/device.

| Behavior | Tosca ExecutionList result | ContextQA run | Assertion parity | Data parity | Evidence parity | Difference owner |
| -------- | -------------------------- | ------------- | ---------------- | ----------- | --------------- | ---------------- |
|          |                            |               |                  |             |                 |                  |

Use persistent results from both systems. A screenshot without build, environment, and test identity is insufficient for a release-critical comparison.

## Phase 9: Seed controlled failures

For at least one critical behavior:

* change an asserted business outcome in a disposable build;
* verify the Tosca and ContextQA tests both fail for the expected reason;
* confirm recovery logic does not turn the failure into a pass;
* restore the build and rerun; and
* retain both attempts in the evidence packet.

Also test a missing data/configuration value and an unavailable dependency so the team can distinguish product failure from setup failure.

## Phase 10: Decide what remains in Tosca

| Source behavior | Decision                                         | Reason | Authoritative system | Owner | Re-evaluation trigger |
| --------------- | ------------------------------------------------ | ------ | -------------------- | ----- | --------------------- |
|                 | Migrate / Retain / Replace / Retire / Unresolved |        |                      |       |                       |

Keep specialized Tosca coverage until ContextQA has demonstrated the exact application, protocol, control, evidence, and operating requirement. Avoid a blanket platform-replacement claim from a web-only pilot.

## Tosca migration checklist

* [ ] Tosca version, workspace/repository, source revision, settings, and persistent baseline are recorded.
* [ ] Requirements, TestCases, TestCase-Design, Modules, reusable blocks, data, and ExecutionLists are mapped.
* [ ] Project-root parameters and other subset-export exclusions are inventoried separately.
* [ ] Secret values are excluded from migration artifacts.
* [ ] Recovery scenarios are reviewed for defect-masking behavior.
* [ ] Behavior packets preserve positive, negative, and persisted-state assertions.
* [ ] The pilot includes templates, reusable components, dynamic data, and a hard/specialist case.
* [ ] ContextQA inputs use documented formats and workflows; no direct Tosca importer is assumed.
* [ ] TestCase-Design coverage rules are reconciled.
* [ ] Same-build parallel and seeded-failure runs are complete.
* [ ] Retained Tosca scope and owners are explicit.
* [ ] Cutover, rollback, and evidence-retention decisions are approved.

## Common questions

<details>

<summary>Can ContextQA import a Tosca subset file directly?</summary>

No direct `.tsu` or `.tce` importer is documented in this guide. Treat the subset as a Tosca backup/reference and use an intent-led reconstruction unless ContextQA supplies and demonstrates a supported importer for your exact version.

</details>

<details>

<summary>Should every Tosca Module become a ContextQA object?</summary>

No. Modules are implementation assets. Reconstruct the business action and assertion, then use the simplest supported ContextQA configuration that preserves it.

</details>

<details>

<summary>Can a browser pilot justify retiring SAP, desktop, or other specialist Tosca coverage?</summary>

No. Evaluate each target and engine separately. Keep the Tosca control authoritative until the replacement demonstrates the required capability and evidence.

</details>

## Related documentation

* [Migration overview](/migrate-to-contextqa/migration.md)
* [Migration planning checklist](/migrate-to-contextqa/planning-checklist.md)
* [Requirements management](/web-testing/requirements-management.md)
* [Test data management](/web-testing/test-data-management.md)
* [Test results](/reporting/test-results.md)

{% hint style="info" %}
**Planning a Tosca migration?** [**Book a migration architecture review →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=tosca_migration) — Bring one requirement, its TestCase-Design source, reusable Modules, and a persistent ExecutionList result.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/migrate-to-contextqa/tricentis-tosca-to-contextqa.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.