How to move test cases out of Excel
Most services teams start with test cases in a spreadsheet, and most outgrow it around the third client project. Here is how to move them without a lost week or a lost history.
Signs it's time to move
- Two people edited the same sheet and one lost their changes.
- Nobody can say which test cases cover a given story.
- Each release, someone copies the sheet to record a new run, and old runs are scattered across files.
- A client asked what was tested, and the answer took an afternoon.
If two of these sound familiar, the sheet is costing you more than a tool would.
Step 1: clean the sheet before you import
An import is only as good as the sheet. Spend an hour here and save a day later.
- One row per test case, or one row per step with the case title repeated. Pick one shape and use it everywhere.
- Clear columns: ID, title, preconditions, steps, expected result, priority, and module or suite.
- A story key column, such as
PAY-112, so each case can link to the story it covers. - Remove duplicates and dead cases. If a feature no longer exists, its cases shouldn't come over.
- Number steps consistently, either one per row or "1. … 2. …" inside one cell.
Step 2: decide what to do with history
Past run results rarely import cleanly, and you seldom need them in the new tool. A practical rule:
- Bring over the test cases: titles, steps, expected results, suites and links.
- Keep the old sheet read-only as the record of past runs, and note the date you switched.
- Record every new run in the new tool from day one.
Step 3: start with one module
Import one module or one client project first. Check that the steps, suites and story links look right, run one test cycle in the new tool, and fix the column mapping if anything is off. Then import the rest in one go.
Step 4: run the next release in the new tool
- Create a test run for the release from the relevant suites.
- Record a result for every case: passed, failed, blocked or skipped.
- File bugs from failures, linked to the case and the story.
- Share the results with the client instead of a copied sheet.
After one release, stop updating the old sheet. Two sources of truth is worse than either one.
Common mistakes
| Mistake | Better |
|---|---|
| Importing everything at once, untested | Pilot one module, then import the rest |
| Rewriting every case during the move | Move them as they are and improve them over the next sprints |
| Keeping the sheet "just in case" and updating both | Freeze the sheet on the day you switch |
| Losing the link to stories | Add a story key column before the import |
How NaatOps handles the import
NaatOps imports Excel (.xlsx) and CSV files, including exports from TestRail, Zephyr and Xray. It shows how each column maps before anything is created. Steps can be one per row or numbered in one cell, suites come from a section, module or folder column, and cases link to stories by issue key. Past run results stay in your sheet, and new runs are recorded in NaatOps.
Stories, tests and API checks in one place
Free for up to 10 users. Team and Delivery start with a free trial, no card needed.