Managing Test Cases in Excel: When It Works, and What Breaks

Managing test cases in Excel works, up to a point. A spreadsheet is free, everyone can already use it, it needs no rollout, and for a small team writing a few hundred cases it does the job without complaint. Most QA teams start there and it is not a mistake.

What breaks isn’t the writing. It’s the running — the moment you need to record that these cases were executed on this build by this person, and answer questions about that months later.

And the reason it breaks isn’t size. A spreadsheet is a very good list, and it stays a very good list at ten thousand rows. What changes is that somewhere along the way you stopped maintaining a list and started operating a system.

What spreadsheets are genuinely good at

Worth being fair, because the honest version of this argument is more useful than the sales version.

• Zero friction to start. No procurement, no admin, no schema decisions before you’ve written test one.
• Total structural freedom. Add a column, invent a convention, restructure on a Tuesday. No tool lets you reshape your model that fast.
• Everyone can read it. A product manager can open a spreadsheet. Getting them into a QA tool is a project.
• Bulk editing is unbeatable. Find-and-replace across 400 rows, fill-down, sort, paste a column — decades of refinement on exactly this, and a hard standard for anything that replaces it.

If you have one tester, a few hundred cases and a release every quarter, a spreadsheet is a rational choice. The problems below are problems of scale and time, not of taste.

Which is worth drawing, because it locates the problem somewhere other than where most people look for it.

Everything below that line is a relationship — between a case and the times it ran, between a requirement and what covers it, between two people editing at once. A grid stores values in cells. It has no way to store a relationship except by convention, and convention is the thing that decays.

The four things that break

1. There’s no place to put a result

This is the fundamental one and everything else follows from it.

A test case is a plan. An execution is an event — this case, this build, this tester, this date, this outcome. A spreadsheet has one row per case, so the moment you want to record a result you have to choose between two bad options: overwrite the previous result, or add a column per cycle.

Overwriting loses history. Columns-per-cycle means Result_Sprint_12, Result_Sprint_13, Result_Sprint_14, and a file that gets wider forever. Neither survives a year.

2. Concurrent editing quietly loses work

Cloud spreadsheets handle two people editing different cells fine. What they don’t handle is two people executing at once — one sorts the sheet to find their tests, and everyone else’s rows move underneath them. Add filtered views, and someone deletes a row that was hidden from them.

The failures are silent. Nobody gets an error; a result just isn’t there any more.

3. Nothing connects to anything

Coverage questions are the ones that get asked when something goes wrong, and a spreadsheet answers them by convention rather than by structure. “Which tests cover the payments requirement?” is answered by a text column that says REQ-14 — which works exactly as long as everyone types it identically, forever.

That means no reliable answer to “what’s untested”, “which requirement did this defect come from”, or “was this area covered before we shipped”. Those questions need a chain that actually holds — requirement to test to execution to defect, and a text column isn’t one.

4. Nobody trusts it after a year

The end state of an unmaintained sheet is familiar: cases for features that were removed, results from a build nobody can identify, three tabs that disagree, and a column called Notes2. It isn’t wrong, exactly — it’s just no longer something anyone will act on.

Deciding it’s time to move

Not everyone should migrate. Some reasonable triggers:

If none of those are true, staying is a legitimate decision. Migrating a spreadsheet that’s working costs weeks and buys you nothing yet.

What actually survives a migration

This is the part most migration guides skip, and it’s the part that determines whether the move is a week or a quarter.

Spreadsheet columns map cleanly onto the fields a test management tool has, and have nowhere to go otherwise. Realistically:

Usually survives — title, description, priority, severity, test type, folder or suite structure, preconditions, steps and expected results, and requirement references if they match identifiers the target already knows.

Usually doesn’t — attachments referenced as file paths or shared-drive links, custom columns your team invented, historical results, anything encoded in cell formatting (colour-coded severity is invisible to an importer), and formulas.

Import in slices, not all at once

Import one folder or one area first, look at what arrived, and fix the mapping before doing the rest. A full import of 3,000 rows with a subtly wrong column mapping is much more expensive to undo than to redo.

How this works in Hawzu

Import runs as a four-step wizard — source, mapping, review, result — and there are four sources, not one: a generic Excel/CSV import with manual column mapping, plus dedicated importers for TestRail, Zephyr and QASE exports. (If you’re coming from something else, there’s a request form; there is no Jira, Azure DevOps or Xray importer today.)

For the generic path, a Download template button gives you the exact grid the importer expects — 14 columns covering title, priority, severity, description, test type, parent folder, requirements, automation status, preconditions, the step fields, and a Gherkin flag. Two conventions are worth knowing before you reshape your own sheet: folder nesting is expressed in one cell as Parent > Child > Grandchild, and a multi-step case is a row with a title followed by rows with the title left blank, each adding a step.

Mapping is auto-guessed from your header names and overridable. Title, priority and severity must be mapped; the rest are optional. The review step shows what will be created before anything is written — rows ready, rows with issues, folders that will be created, and a sample preview.

Two behaviours are worth calling out because they’re the sort of thing you find out about afterwards:

• Requirement references resolve or are dropped. A REQ-101 that matches a real requirement becomes a link; one that matches nothing is discarded rather than stored as text. The reasoning is in the code itself — a value that resolves to nothing isn’t a link, it’s a wrong number in your coverage figures.
• Unmapped columns are silently ignored. Because mapping works Hawzu-field-first, any column you don’t assign is simply never read. Nothing warns you. This is exactly why you import a slice first.

Coming the other way, export offers Excel, CSV and JSON, and the round-trip is deliberate: the xlsx and csv output is written against the same template the importer reads, with values written as display labels precisely so they re-import. Hawzu’s own export is valid input to Hawzu’s own wizard — which also means it’s a clean way to get your data back out. JSON is the lossless one, carrying shared-step boundaries, labels and custom fields, but it isn’t a wizard input.

After importing, bulk editing covers priority, severity, test type, automation status, and moving cases between folders. It does not cover labels, requirements, custom fields or step content — so get those right in the sheet where find-and-replace is still available to you.