Skip to main content

Test packs: cross-cutting checks that attach to profiles

Some risks are not specific to one product category: SaaS billing lifecycles, local payment collection, bilingual Urdu behaviour and data import/export cut across products. MC Testing packages those checks as packs (Master Prompt Sections 23.1–23.4) that attach to a profile where the category needs them — with a recorded status and reason for every attachment, including “needs review” where applicability is genuinely unknown.

Section 23.1

SaaS Billing, Trial & Quota

Signup, trials, plan gating, quotas, upgrades and suspension — the commercial lifecycle of a SaaS product, tested on a dedicated TEST-QA account.

6 defined checks. On POS / Retail: Attached. On Madrasah / Masjid / Maktab: Needs review.

Read the SaaS Billing, Trial & Quota pack in full

Section 23.2

Pakistan Payments (JazzCash / EasyPaisa)

Local payment collection for Pakistani products — fee and subscription collection via JazzCash and EasyPaisa, exercised in sandbox / test mode only.

4 defined checks. On POS / Retail: Needs review. On Madrasah / Masjid / Maktab: Attached (proposed).

Read the Pakistan Payments (JazzCash / EasyPaisa) pack in full

Section 23.3

Bilingual / Urdu-RTL

Default language, language switching, RTL direction and Nastaliq shaping — treated as functional behaviour, not cosmetics.

4 defined checks. On POS / Retail: Attached. On Madrasah / Masjid / Maktab: Attached.

Read the Bilingual / Urdu-RTL pack in full

Section 23.4

Import / Export

CSV and Excel data movement: valid imports land completely, malformed files fail loudly, exports match the screen and never leak another tenant's rows.

6 defined checks. On POS / Retail: Attached. On Madrasah / Masjid / Maktab: Attached.

Read the Import / Export pack in full

How pack attachment works

A pack attaches to a profile with one of three statuses. Attached means the category demonstrably needs the pack and its cases exist. Attached (proposed) means the pack is expected to apply — for example JazzCash/EasyPaisa fee collection on the Madrasah profile — but no product has validated it yet, so its cases are created when the profile is first applied. Needs review is the honest third state: applicability is unknown from every source available to the platform, so the pack is neither assumed present nor assumed absent until product documentation or an authenticated inspection settles it.

Pack cases follow the same discipline as everything else in MC Testing: they execute only on TEST-QA accounts, payment-related cases run in sandbox or test mode only (never real money), undocumented expected behaviour is marked NEEDS REVIEW instead of being invented, and blocked cases are reported as blocked. Packs complement the category rulebooks in the testing profiles; the vocabulary used here is defined in the glossary.