Skip to main content

Testing profiles: the rulebook for each product category

MC Testing never tests a product against generic expectations. Each category has a profile — data, not code — that defines the modules the product must expose, the journeys its users must be able to complete, the business invariants its numbers must obey, the evidence a run must produce, and the gates that decide its readiness label. Two profiles exist today, at honestly different stages.

Implemented

POS / Retail

Category: POS / Retail SaaS · Version: 1.0

29 required modules · 4 critical journeys · 5 proposed business invariants · 4 cross-cutting packs

Implemented and validated on a live product (Dukaan AI).

Packs: saas-billing (attached), bilingual-rtl (attached), import-export (attached), pakistan-payments (needs review)

Read the full POS / Retail profile definition

Definition ready — not yet validated

Madrasah / Masjid / Maktab

Category: Madrasah / Masjid / Maktab management · Version: 1.0

17 required modules · 5 critical journeys · 5 proposed business invariants · 4 cross-cutting packs

Definition ready — not yet validated on a live product. No product in this category is registered in the platform yet, so no test cases exist for it; case skeletons are created when the profile is first applied to a real product.

Packs: bilingual-rtl (attached), import-export (attached), pakistan-payments (attached (proposed)), saas-billing (needs review)

Read the full Madrasah / Masjid / Maktab profile definition

How profiles are used

When a product is registered, its profile drives everything that follows. Discovery maps the product's real features against the profile's required modules and records gaps for review — under the platform's Section 22 rule a missing module is a gap to review (it may be behind login, nested, plan-gated or simply not enabled), never automatically a defect. Test cases are generated from the profile's journeys and invariants, land as proposals, and only execute after approval. The profile's readiness thresholds — category weights and release gates — then decide how executed evidence becomes a score and a label.

Business invariants inside a profile are platform proposals until the product owner approves them: they are seeded from standard practice for the category, carry a source note saying exactly that, and are never presented as the product's own documented rules. The same honesty applies to profile status — the Madrasah profile below is a complete definition that has not yet been validated on a live product, and its page says so plainly.

Looking for the checklists that attach across categories? See the cross-cutting test packs, or the glossary for how terms like coverage and readiness score are implemented.

Testing Profiles for Web Products | MC Testing