MC Testing discovers what a web product actually exposes, tests it in a real browser against the rules of its category, and turns the evidence into a readiness score and a bilingual report. It is the testing platform behind CodeHubb & MindCrafts AI product launches — built for POS and retail SaaS, school and madrasa systems, and the web products that follow.
Operator loginExplore testing profiles
Honest by design: testing here is deterministic rule-based programming, not AI opinion. Scores come only from executed tests, blocked checks are reported as blocked, and a gap is never dressed up as a pass.
Nine verified capabilities, each running against real products today or defined as openly-labelled blocked skeletons until a test account exists. Nothing on this page is aspirational marketing — if a capability is limited, the limit is stated where the capability is described.
MC Testing crawls a product's public surface read-only and inventories its pages, routes and features, then maps what it finds against the modules its testing profile requires — gaps are recorded for review, never assumed to be defects.
Approved test cases execute in a real Chromium browser through the platform's Test Runner: page loads, forms, navigation and critical user journeys, with step-by-step results and screenshots on failure.
Where a product's signup allows it, the platform provisions its own TEST-QA account. Where verification, a CAPTCHA or a card blocks signup, it stops and takes owner credentials through a secret store instead — see Provisioning in the glossary.
Public pages are scanned with axe-core for critical and serious violations, alongside layout checks at a 390px mobile viewport: horizontal overflow, missing alt text and tap targets under 40×40px.
A safe, read-only sweep probes for publicly reachable .env files, .git data, backups, database dumps and data exports under /uploads/. Suspected data files are judged on HEAD metadata only — their contents are never read.
Public pages are checked for the headers that protect users in production — HSTS, a content security policy, clickjacking protection and MIME-sniffing protection — as part of the deployment readiness evidence.
Every score is computed from executed tests by a documented formula and gated by fixed rules: an open critical finding or a confirmed exposure means Not Ready, whatever the number says. Coverage is always reported next to the score.
Reports are generated in English and Urdu: the readiness score and its inputs, coverage, findings with reproduction steps and evidence, and any waivers or accepted risks — ready to share with clients.
After release, scheduled lightweight checks keep watching availability, sensitive-file exposure and security headers, and raise in-platform alerts when something changes. Monitoring detects; it never modifies the product.
From a product URL to a release decision in five stages.
Add the web application, its environment URLs and the testing profile that fits its category.
The platform crawls the public surface and maps discovered features against the profile's required modules.
Generated and profile cases land as proposals. Only approved cases execute — blocked ones say exactly why.
The Test Runner executes approved cases in a real browser and records results, findings and evidence.
A readiness score, coverage and a bilingual report show what passed, what failed and what is still unknown.
A profile is the rulebook for a product category: the modules it must expose, the journeys a user must be able to complete, the business invariants its numbers must obey, and the gates that decide readiness. Profiles are data, not code — read the full definitions.
POS / Retail SaaS · 29 required modules · 4 critical journeys · 5 proposed business invariants
Implemented and validated on a live product (Dukaan AI).
Madrasah / Masjid / Maktab management · 17 required modules · 5 critical journeys · 5 proposed business invariants
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 are reusable check sets that attach to profiles where the category needs them — SaaS billing, Pakistan payments, bilingual Urdu-RTL behaviour, and import/export safety.
Signup, trials, plan gating, quotas, upgrades and suspension — the commercial lifecycle of a SaaS product, tested on a dedicated TEST-QA account.
POS / Retail: Attached · Madrasah / Masjid / Maktab: Needs review
Local payment collection for Pakistani products — fee and subscription collection via JazzCash and EasyPaisa, exercised in sandbox / test mode only.
POS / Retail: Needs review · Madrasah / Masjid / Maktab: Attached (proposed)
Default language, language switching, RTL direction and Nastaliq shaping — treated as functional behaviour, not cosmetics.
POS / Retail: Attached · Madrasah / Masjid / Maktab: Attached
CSV and Excel data movement: valid imports land completely, malformed files fail loudly, exports match the screen and never leak another tenant's rows.
POS / Retail: Attached · Madrasah / Masjid / Maktab: Attached
QA vocabulary is full of terms that mean whatever the vendor wants. Our glossary defines each term by this platform's actual rules and formulas.
A 0–100 score computed only from executed tests by a fixed, auditable formula — plus a rule-based label that a high score can never override.
How much of what was planned was actually executed — always reported separately from the pass rate, so a high score on thin evidence cannot hide.
A test whose result flips between pass and fail across runs without the product changing — measured from result history, never guessed, and never silently deleted.
A recorded, owner-owned decision to accept a known risk — visible in every report, time-boxed by a review date, and never a way to make a critical blocker disappear.
A safe, read-only sweep that checks whether sensitive files — .env, .git, backups, data exports — are publicly reachable on a product's web surface.
The clickable size of an interactive element on a phone. MC Testing flags anything under 40×40 CSS pixels on a 390px mobile viewport.
How MC Testing gets its own TEST-QA account: it signs itself up where signup allows, and stops for owner credentials — via a secret store only — where verification blocks it.
What “Provisioning (Test-Account Self-Provisioning)” means in MC Testing
No. MC Testing is deterministic, rule-based testing software. Every check is a programmed rule — a page must load, a total must equal the sum of its lines, a leaked file must not be reachable — and every score is computed from executed test results by a documented formula. The readiness label (Ready, Conditionally Ready, Not Ready, Insufficient Evidence) is decided by fixed gates, never by an AI's opinion, and the exact inputs behind any score are stored so the number can be re-derived by hand.
Web applications — products that run in a browser, such as SaaS dashboards, POS and shop systems, and school or madrasa management systems. It does not test native mobile apps. Testing is organised by product profiles (for example POS / Retail, or Madrasah / Masjid / Maktab) that define the modules, critical journeys and business rules a product in that category is checked against.
Client reports are produced in English and Urdu. The report covers the readiness score and what produced it, coverage, findings with reproduction steps and evidence, and any waivers or accepted risks — in both languages, so a product owner and their clients can each read it in the language they work in.
No. MC Testing tests and reports; it never changes the tested product's code. For a finding it can prepare a fix brief — what is wrong, where, the evidence and the acceptance test — and after you deploy a fix it re-runs the original failing case to verify it. A finding is only marked verified-fixed when that original case passes.
Yes, by construction. MC Testing works only on dedicated TEST-QA accounts and TEST-QA-marked data — never on real customer accounts. It never makes real payments: payment flows are exercised in sandbox or test mode only. Where a product's signup allows it, the platform creates its own test account; where verification blocks that, your test credentials are stored only in a server-side secret store — never in the database, in evidence, or in any report.
You get a readiness score with the coverage behind it, a findings list with severity, reproduction steps and evidence (including screenshots on failure), and a bilingual report you can share with clients. After release, scheduled monitoring keeps checking availability, sensitive-file exposure and security headers, and alerts inside the platform when something changes.
MC Testing is operated by CodeHubb & MindCrafts AI for the products it builds and audits. Operators sign in to the console; everyone else can explore the profiles, packs and glossary above to see exactly how a product will be judged before it is tested.
