Testing a healthcare platform like every request is someone's enrollment
How we hold DIAREV's Cloud Run backend, Firestore database and messaging integrations to a production standard before anything ships.
- Client
- DIAREV
- Industry
- Healthcare
- Services
- QA & Testing, Cloud Infrastructure
- Stack
- Cloud Run, Firestore, k6
Healthcare software doesn't get a "we'll patch it later."
DIAREV is a camp-based healthcare platform. Its backend handles live patient enrollment and support-plan data, runs on Cloud Run instances that scale to zero when idle, and sends messages through WhatsApp Business. In software like this, a failed request isn't a poor user experience. It's someone's enrollment that didn't go through. So we test the scenarios that actually break production, not just the happy path.
- Live enrollment data
- Scale-to-zero compute
- Strict template approval
Six checks before anything ships
None of these are hypothetical edge cases. Each one maps to a real failure mode we've caught and fixed in production.
Cold start & concurrency
Concurrent load is fired at a Cloud Run instance that has scaled to zero, the way a real enrollment rush would hit it.
Pass: no dropped connections
Composite index coverage
Every production query pattern is checked against Firestore composite indexes, with parity confirmed across environments.
Pass: zero FAILED_PRECONDITION errors
WhatsApp Business templates
Templates are screened before submission for emoji, marketing language and unrealistic sample values.
Pass: approved on first submission
Key provisioning
Concurrent key-provisioning requests are fired for the same user at the same moment.
Pass: exactly one key per user, no duplicates, no leaks
Load at peak concurrency
Scripted k6 runs hit production-equivalent traffic patterns at peak concurrency.
Pass: latency and error rate within threshold
Standing pre-deploy checklist
Every check above is folded into one repeatable checklist that gates each release.
Pass: run on every deploy
A cold-start crash isn't a log entry. It's a caregiver's enrollment failing at the exact moment they try to sign up. Testing a scaled-to-zero instance under concurrent load is how we make sure that moment works.
What changed for DIAREV
Cold-start failures eliminated
Through min-instance and concurrency tuning.
Index gaps closed
No more 500s on enrollment and admin endpoints.
First-pass template approval
WhatsApp Business templates cleared on the first try.
One checklist, every release
A repeatable pre-deploy QA process.
Every check maps to a real screen a patient uses
Every test case, step by step
DIAREV is a camp-based healthcare platform: real patients, real enrollment flows, real infrastructure running around the clock. When you're building for healthcare, "it works on my machine" isn't good enough. Every deploy has to survive concurrent traffic, cold starts, third-party API quirks, and the occasional silently-broken environment variable.
Below are a set of real test cases we run against DIAREV's stack (Next.js frontend, Cloud Run backend, Firestore, plus integrations like WhatsApp Business and OpenRouter). We're sharing them as a look into our QA process: the kind of rigor we bring to every client project.
Infrastructure & Deployment
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-01 | Cold-start stability under concurrent load | Trigger multiple admin dashboard API calls simultaneously against a scaled-to-zero Cloud Run instance | Requests queue and resolve cleanly without container crashes or dropped connections |
| TC-02 | IAM binding integrity post-deploy | After a deploy or service account change, call every backend endpoint that depends on a bound role | No permission-denied errors; all bindings resolve as expected |
| TC-03 | Min-instance scaling behavior | Drop traffic to zero, then send a burst of requests | With min-instances=1 configured, first request responds without a cold-start penalty |
| TC-04 | CPU throttling under sustained load | Run a sustained request stream at expected peak concurrency (concurrency=80) | Response latency stays within SLA; no throttling-induced timeouts |
Database (Firestore)
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-05 | Composite index coverage | Run every production query pattern (support plan enrollment, admin endpoints) against a fresh index set | No FAILED_PRECONDITION: index required errors; all queries return 200 |
| TC-06 | Index parity across environments | Diff the test project's indexes against production's firestore.indexes.json |
Zero drift: every index in prod exists in test and vice versa |
Frontend
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-07 | Environment variable resolution | Deploy frontend build and confirm every NEXT_PUBLIC_* variable resolves to a live, reachable domain |
No requests fail against unresolvable or stale hosting domains |
| TC-08 | Visual regression after framework upgrade | Compare key pages before/after a Tailwind major-version migration (e.g. v3 → v4) | Spacing, color tokens, and responsive breakpoints match pre-migration design exactly |
Third-Party Integrations
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-09 | WhatsApp template compliance | Submit a booking confirmation template for approval; check for disallowed emoji, marketing language, or unrealistic sample values | Template is approved on submission without rejection cycles |
| TC-10 | Concurrent key provisioning | Fire simultaneous provisioning requests for the same user against the Lambda + DynamoDB key-issuance flow | Exactly one key is generated per user: no duplicates, no leaked keys on refresh |
Performance
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-11 | Load test against production endpoints | Run a scripted load test (e.g. via k6) ramping to expected peak concurrent users | Error rate stays under threshold; p95 latency stays within target |
Migration & Cutover
| ID | Test Case | Steps | Expected Result |
|---|---|---|---|
| TC-12 | DNS cutover verification | After repointing a domain's A/CNAME records to a new host, check propagation and SSL issuance | Domain resolves to the new host globally within expected TTL; certificate is valid, no mixed-content warnings |
Why this matters
None of these are hypothetical. Each one maps to a real class of issue we've caught and fixed on DIAREV: a cold-start race condition, a missing composite index, a WhatsApp template that got rejected for using an emoji. Healthcare platforms don't get a grace period for "we'll patch it later." Building the test case before the bug ships is what keeps enrollment flows and patient-facing features reliable.
This is the standard we hold every client build to at Rise Digital India.
Want a QA process built around your platform's actual failure modes, not a generic checklist? Get in touch with Rise Digital India.
More Case Studies
- Anatomy of a Production Outage: Debugging DIAREV's Multi-Cause Incident
- QA Test Cases: Auditing a Sourcing Platform's Website Before Launch
- Haat: Building a Multi-Vendor Marketplace Shoppers Can Trust
- Angeethi: A Restaurant Operating System from Table QR to GST Bill
- NestPG: One Platform for Finding a PG and Running One
- See all case studies