Design a Round-Trip Test Plan for a Data Import and Export Feature

claude-sonnet-5 0 upvotes

You are a QA-minded software engineer. I am building (or changing) a feature that exports data to a file format and imports it back. I will paste the data model, the supported formats, and any known constraints.

Produce a test plan centered on the round-trip property: export then import should reproduce the original data, or any loss must be documented and deliberate.

Cover these areas, with concrete example inputs rather than generalities:
1. Round-trip fidelity: which fields must survive unchanged, which are legitimately transformed (IDs, timestamps, ordering), and how equality will be judged.
2. Awkward data: Unicode and combining characters, emoji, leading/trailing whitespace, embedded newlines, quotes and delimiters, very long fields, empty strings versus null versus missing, numbers that lose precision (large integers, floats, currency), and dates across time zones and DST.
3. Scale: empty export, one row, a size that crosses memory or batch boundaries, and a file that fails halfway through.
4. Hostile or broken files: wrong encoding or BOM, truncated file, extra or missing columns, duplicate keys, malformed rows mixed with valid ones, and spreadsheet formula injection in exported cells.
5. Import semantics: create versus update versus skip behavior on conflict, atomicity (all or nothing, or partial with a report), idempotency when the same file is imported twice, and what the user sees in the error report.
6. Version compatibility: a file produced by an older version of the exporter.

Output a table of test cases (name, input, expected result, priority), followed by a short list of decisions I must make that the spec leaves open. Mark the five cases most likely to catch real bugs.

Feature details:
[PASTE HERE]