Madrasah / Masjid / Maktab testing profile

Critical journeys (5)

A journey is the smallest unit a product owner feels end to end. These are the journeys this profile treats as critical; each is linked to test cases, or states plainly why it cannot execute yet.

• Admission → student record created and searchable — No madrasa product is registered in the platform, so no cases exist yet. Journey case skeletons are created when this profile is first applied to a real product (Section 5: one category at a time, each validated on a real product).
• Daily attendance → class summary → notice to guardians — No madrasa product is registered in the platform, so no cases exist yet. Journey case skeletons are created when this profile is first applied to a real product (Section 5: one category at a time, each validated on a real product).
• Fee invoice → payment → printed receipt (Urdu PDF) — No madrasa product is registered in the platform, so no cases exist yet. Journey case skeletons are created when this profile is first applied to a real product (Section 5: one category at a time, each validated on a real product).
• Exam marks entry → result card generated (PDF) — No madrasa product is registered in the platform, so no cases exist yet. Journey case skeletons are created when this profile is first applied to a real product (Section 5: one category at a time, each validated on a real product).
• Offline entry (attendance/fees) → reconnect → two-way sync without duplicates — No madrasa product is registered in the platform, so no cases exist yet. Journey case skeletons are created when this profile is first applied to a real product (Section 5: one category at a time, each validated on a real product).

Proposed business invariants (5)

Invariants are the arithmetic rules a product in this category must never break. In MC Testing they are platform proposals (status PROPOSED) seeded from standard practice for the category, each carrying a source note; they bind a product only after its owner approves them, and they are never presented as the product's own documented rules.

• Σ fee receipts issued = Σ payments recorded for the same period.
  Platform proposal from standard madrasa administration practice — not confirmed against any specific product's documented rules (Section 17: PROPOSED until owner-approved).
• Attendance % = days present ÷ days held, per student per period.
  Platform proposal from standard madrasa administration practice — not confirmed against any specific product's documented rules (Section 17: PROPOSED until owner-approved).
• Result-card total = Σ subject marks; division/grade follows the institution's declared scale.
  Platform proposal from standard madrasa administration practice — not confirmed against any specific product's documented rules (Section 17: PROPOSED until owner-approved).
• Net pay = gross pay − deductions (loans/advances/absence), per staff member per month.
  Platform proposal from standard madrasa administration practice — not confirmed against any specific product's documented rules (Section 17: PROPOSED until owner-approved).
• After offline sync, every offline record exists exactly once on the server and once on the device — no duplicates, no silent loss.
  Platform proposal from standard madrasa administration practice — not confirmed against any specific product's documented rules (Section 17: PROPOSED until owner-approved).

Readiness gates

Category weights (proposed, stored with every score snapshot): Functional correctness 25% · Business logic & data integrity 20% · Security 20% · Integration & reliability 10% · UI/UX & accessibility 10% · Performance 10% · Deployment & operational 5%.

• No open P0 finding (including any confirmed public data exposure).
• Fee-to-receipt journey PASS on test data.
• Offline-to-sync journey PASS with zero duplicates (where offline is supported).

Platform proposal seeded from the Section 25 defaults — owner approval pending; not validated on any registered product yet.

Release blockers

• Any confirmed public exposure of student data (P0, Section 18.1).
• Any open critical security finding.
• Fee reconciliation invariant violated on test data (after owner approval of the invariant).
• Sync creating duplicate student or fee records in the offline-to-sync journey.

Security requirements

• Student personal data (names, guardian phones) must never be publicly reachable — the Section 18.1 leak sweep explicitly probes data exports under /uploads/ (the MC-MMS incident class).
• Role boundaries: teacher accounts see only their classes; finance functions are restricted by role.
• No confirmed public data exposure — a confirmed exposure is a P0 release blocker.

Required evidence

• Per-case step results with screenshots on failure.
• Urdu PDF samples opened and visually verified for shaping.
• Sync journey logs from both directions (device → server, server → device).
• Leak-sweep probe table (JSON) per security run.

Cross-cutting packs on this profile