A valid import lands completely
A small CSV of TEST-QA rows imports with every row present afterwards and totals matching the file. The product's accepted import format is pinned by a reviewer before approval where it is undocumented.
Section 23.4
Import / Export test pack
CSV and Excel data movement: valid imports land completely, malformed files fail loudly, exports match the screen and never leak another tenant's rows.
Import and export are where web products quietly lose or leak data. A CSV import that silently drops rows, double-counts stock on a second run, or corrupts Urdu names destroys records a shop or school depends on; an export that includes another tenant's rows is a privacy breach in a single download. The import/export pack tests these flows with small, TEST-QA-marked fixture files whose expected results are known in advance.
Every case in this pack lives behind authentication, so on the pilot product the cases are defined as approved-scope skeletons that execute only on the TEST-QA account. Imported fixture data is TEST-QA-marked and recorded for cleanup after the run — the pack never imports into real customer data.
The checks in this pack
A malformed import is rejected loudly
A CSV with a missing required column and a non-numeric quantity must be rejected with a clear error — no partial, silent import of the good rows.
Importing the same file twice follows the product's duplicate rules
The valid file is imported a second time. Duplicates must be handled per the product's rules — above all, stock must never silently double.
Urdu names survive import without corruption
A UTF-8 CSV with Urdu customer names imports and the names render identically afterwards — the import path is where Urdu text most often corrupts.
Exported totals match the on-screen totals exactly
A report is exported for the TEST-QA shop and the file's total cell is compared with the on-screen report total, digit for digit.
An export contains only the exporting tenant's data
The exported file must contain zero rows belonging to any other shop — the tenant-isolation check that turns an export feature from a convenience into a liability if it fails.
Status on each profile
| Profile | Status | Reason (from the profile definition) |
|---|---|---|
| POS / Retail | Attached | Inventory/customer import-export is core POS surface. All pack cases are authenticated, so they are defined as PROPOSED + requires_credentials and never executed in this phase. |
| Madrasah / Masjid / Maktab | Attached | Student/fee data moves by Excel/CSV in this category (including Urdu names); the pack's Urdu-content and tenant-isolation cases are directly relevant. |
Honest limits
Because these flows are authenticated, none of the pack's cases can run against a product until a TEST-QA account exists for it. The pack defines the checks, fixtures and expected results in advance so that the first authenticated run is a verification, not an exploration.
Pack checks run under the platform's standing safety rules: TEST-QA accounts and TEST-QA-marked data only, no real payments, credentials only through the secret store, and every result — pass, fail, blocked or needs-review — reported as it actually is. Read how the resulting evidence becomes a readiness score and coverage figure.