When a team moves its stored test-case definitions from one commercial case-management product to another, what survives the export and import intact, and what usually does not?
answer
- two buckets, not one library
- definitions move, context does not
- flat fields import cleanly
- typed fields land as strings
- row counts prove parsing only
basics
~20 sDefinitions travel; the context the old product wrapped around them mostly does not. Titles, step text, folder placement and plain fields import cleanly. Execution history, attachments, typed custom-field meaning and shared-step relationships arrive degraded or missing.
solid answer
~50 sSort the library into two buckets before planning the move. **Flat, self-contained data travels**: case title, description, precondition, the ordered step text and expected results, the folder path, and any custom field that is plain text, a number or a date. **Everything relational or product-owned degrades**: recorded executions, attachments, references pointing outside the repository, typed custom fields whose allowed values are objects in the source product, and shared step blocks, which most exporters inline as copies. The cause is structural — an export serialises one product's model and the importer has to land it in a different one, so whatever has no counterpart is dropped, stringified or flattened, usually with no error. Plan around that: verify by sampling real cases after import rather than comparing row counts, and decide deliberately what to do with each thing that did not travel.
go deeper
Be able to say which parts of a case are just text and which are relationships the product owns. Titles and step text move; runs, files and links are the risky half.
Explain why the loss happens: an export serialises one product's model and the importer lands it in another, so anything without a counterpart is dropped, stringified or flattened without raising an error.
Show how you would verify rather than trust — sampling by shape, comparing rendered cases, hunting for collapsed fields and duplicated step sequences — and how you preserve the source key before the old instance goes away.
Own the framing: decide up front which losses are acceptable, make that an explicit written trade rather than a discovery, and set what evidence the team must see before the source instance can be switched off.
## The distinction that governs the whole move A case repository stores two very different kinds of thing under one roof. The first is the **definition**: a case's title, its precondition, its ordered steps and expected results, its placement in the library tree, its tags and its custom fields. The second is **everything the product accumulated around that definition**: who ran it, when, in which cycle, with what outcome, with which screenshot attached, against which build. An export moves the first kind well and the second kind badly, and that is structural rather than a defect in any one tool. An export file is a serialisation of *one* product's model. The importer on the far side must land those bytes in a *different* model. Anything with an obvious counterpart lands; anything without one is dropped, stringified or flattened — silently, because the absence of a counterpart is not an error condition anyone coded for. ## What travels intact - **Title, description and precondition text** — plain strings with an obvious home on the other side. - **The ordered step list**, step text paired with expected result, as long as both products model steps as an ordered list of text pairs, which most do. - **The folder path**, usually re-created by name rather than by identity, so it arrives as nested names that happen to match. - **Flat custom fields**: free text, a plain number, a date, a checkbox. - **Tags**, where the target has a free-form tag concept — though they may arrive as an unmanaged flat list rather than a governed vocabulary. ## What degrades, and how | What | What actually arrives | |---|---| | Recorded executions | Usually nothing. Most importers accept definitions only; where past runs can be loaded at all, the outcome, the original runner and the original timestamp rarely survive together. | | Attachments | Either bundled bytes, or references back into the source instance that stop resolving once it is retired or the credential behind them expires. | | Typed custom fields | The field lands, its **semantics** do not: a constrained list becomes free text, a person-picker becomes a display name, a derived value arrives frozen as whatever it was at export. | | Shared step blocks | Commonly inlined — every referencing case gets its own copy, and the single-point-of-edit property disappears. | | References out of the repository | Land as text if at all; nothing on the far side re-establishes what they pointed at. | | Identifiers | The target mints its own. The old human-readable key survives only if you deliberately park it somewhere. | ## Why identity is the quiet problem The source key is the one field nobody lists as important and everybody depends on. It is quoted in tickets, in spreadsheets people maintain by hand, in saved filters, in test plans written in a document, and in the shorthand a team speaks in. After a move, the target has assigned its own identifiers and every one of those references now points at nothing. The fix is cheap only if you do it during the move: carry the source key into a plain text field on every imported case, and keep a two-column map from old key to new identifier under version control. Retrofitting that map after the source instance is switched off is not possible. ## How to verify an import rather than believe it 1. **Count, then stop trusting counts.** Matching totals prove the rows parsed. They prove nothing about meaning, and a stringified field or a flattened block still counts as one row. 2. **Sample by shape, not at random.** Deliberately pick the longest case, one with many steps, one with every custom field populated, one carrying attachments, one that referenced a shared block, and one buried in the deepest folder. Those six find nearly everything. 3. **Compare rendered cases, not records.** Open the case in both products side by side and read them. A collapse from a constrained list to free text is obvious on screen and invisible in a row count. 4. **Search for the tell-tale collapse.** Look for identical step sequences repeated across many cases (a flattened shared block), for fields whose values are now arbitrary strings, and for attachment areas that are empty on cases you know had evidence. ## What to do about what did not travel - **Execution history**: decide explicitly whether to carry it, keep the source readable for a defined window, or export it to neutral files — and say so in the plan rather than discovering the gap afterwards. - **Attachments**: confirm the export contains bytes, not links, before scheduling the source shutdown. - **Typed fields**: re-create the constrained field in the target *first*, then import, so values land against a real vocabulary instead of arriving as free text you must clean later. - **Shared blocks**: re-create them in the target before the load, or accept the flatten knowingly and budget for the maintenance it creates. The migration is finished not when the importer stops printing rows, but when someone has opened real cases in the new product and agreed that the parts which did not survive were the parts you chose to leave behind.
- The importer loaded every exported row and reported no errors. What would still make you refuse to sign the migration off?No errors means the rows parsed and were accepted, which is a much weaker claim than fidelity. I would refuse until someone has opened sampled cases in the target and confirmed that constrained fields still constrain, attachments actually download, step lists match, and the source key is recorded somewhere. Silent degradation produces zero errors by definition.
- Old case identifiers are quoted in tickets, saved filters and spreadsheets. What do you do about them?Carry the source key into a plain text field on every imported case during the load, and keep a map from old key to new identifier in version control. Then every stale reference is still resolvable by search, and anything you have to rebuild later has a lookup table. Doing this after the source is retired is impossible.
It is like moving house: the furniture goes on the van and can be counted off it, but the wiring in the walls, the shelves screwed into them and everyone's memory of your address do not travel with the boxes.
saying these in an interview costs you the question
- Assumes the vendor importer carries execution history across
- Treats a matching row count as a verified migration
- Believes attachment links in an export stay resolvable
- Expects constrained custom fields to keep their vocabulary
- Forgets that the target mints entirely new identifiers