How to migrate test cases into a QA tool without a CSV import

Two definitions of “migrate a test case”

When testomat.io, QA Touch, TestRail, or qTest talk about migrating test cases, they mean moving records between test management systems. You generate a CSV, XLS, or XML export, upload it, and map your fields to theirs. The destination tools require certain columns: in QA Touch, Module name and Test case title are mandatory during mapping, and imports over 500 rows run through a background queue. The cases arrive as rows. A human still reads each one and clicks through the app to execute it, exactly as before. The migration changed where the document lives, not whether a machine can run it.

Assrt treats a migrated test case as something that should execute. The target is not a row in a database; it is a runnable scenario plus the Playwright code that scenario compiles to. That single difference changes every step of the move, so the rest of this guide walks one real case across and shows what you actually do.

Step 1 — Reshape one case, no column mapping

Take a single case out of your current tool. Here is a typical TestRail-style export on the left and the same case as an Assrt #Case block on the right. Notice what disappears: the ID, the Section column, the Priority and Type metadata, the split Steps/Expected tables. None of it is required to run the test. The data column (the coupon code) does not vanish, it becomes a {{COUPON}} variable.

# TestRail export (CSV row, abridged)
ID:        C2041
Section:   Checkout
Title:     Apply a valid coupon at checkout
Priority:  High
Type:      Functional
Preconditions: User has one item in cart
Steps:
  1. Open the cart
  2. Click "Have a code?"
  3. Enter coupon SAVE10
  4. Click Apply
Expected:
  1. Coupon panel expands
  2. Order total drops by 10%
  3. "SAVE10 applied" badge is shown

The #Case N: name format and the rule that each case stay self-contained in 3 to 5 steps are specified in assrt-mcp/src/mcp/server.ts; the parser that turns the heading into a named case lives in src/core/agent.ts.

Step 2 — The case lands in a file you own

This is the part the closed tools cannot offer. Whatever you migrate from, the destination is plain text on your machine. When a scenario loads, Assrt writes the plan to /tmp/assrt/scenario.md and watches it for edits (see assrt-mcp/src/core/scenario-files.ts), and a whole suite is just a tests.txt in your repo. The same case can come from a spreadsheet, Zephyr, a manual doc, or hand-written Selenium, and they all converge on the same owned format on the way to real Playwright output.

Step 3 — Batch the suite and run it

Stack your migrated cases in one file. There is no separate import job, no 500-row queue, no field-mapping screen. The file is the migration. Note how the data-driven cases reuse one {{COUPON}} variable instead of a row per dataset, and how a case that used to be a negative-test spreadsheet row (the expired coupon) becomes three sentences.

# tests.txt — one file, the whole migrated suite

#Case 1: Apply a valid coupon at checkout
Open the cart with one item. Click "Have a code?",
enter {{COUPON}}, click Apply. Verify the total drops 10%
and a "{{COUPON}} applied" badge shows.

#Case 2: Reject an expired coupon
Open the cart with one item. Enter the code EXPIRED2024
and click Apply. Verify an error reads "This code has expired"
and the order total does not change.

#Case 3: Checkout completes after a valid coupon
Apply {{COUPON}}, continue to payment, fill the test card,
and place the order. Verify the confirmation page shows an
order number and the discounted total.

Then run the whole file. The --plan-file flag reads your cases, --extension reuses your logged-in Chrome session so auth-gated cases just work, and --json gives you a CI-friendly result file.

# Run the whole migrated suite, parameterized, with video
npx @assrt-ai/assrt run \
  --url https://staging.your-app.com \
  --plan-file tests.txt \
  --extension \
  --video \
  --json > results.json

The whole migration, in four moves

When a closed test-management migration is the right call

This approach is not free of trade-offs and it is worth being honest about them. If your organization needs an audit trail of who edited which manual case, a formal test-run sign-off workflow, or a compliance-grade vendor with a support contract, a dedicated test-management system is genuinely the better home, and you should migrate your cases there. Assrt does not replace that governance layer; it replaces the part where a human re-runs the same browser steps by hand every release.

The reason to migrate cases into Assrt instead is narrower and specific: you want the cases to execute, you want the output to be code you can read and commit, and you do not want to be locked to a closed engine to keep your own coverage running. If that is the goal, a plain-text #Case beats a mapped CSV row every time.