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.

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 for the source version you use.

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.

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 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.
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.

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

Can ContextQA import a Tosca subset file directly?

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.

Should every Tosca Module become a ContextQA object?

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

Can a browser pilot justify retiring SAP, desktop, or other specialist Tosca coverage?

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

Related documentation

• Migration overview
• Migration planning checklist
• Requirements management
• Test data management
• Test results

Planning a Tosca migration? Book a migration architecture review → — Bring one requirement, its TestCase-Design source, reusable Modules, and a persistent ExecutionList result.