About the role
- Own whether the platform is safe to release — the automated suite, the manual passes automation cannot replace, and the judgement about what a failing test actually means
- Build and keep the end-to-end suite in Playwright across the journeys that matter — a patient booked, registered, seen, billed, dispensed to and reported on — and keep it fast and trustworthy enough that nobody is tempted to ignore a red build
- Write the test plan for each module from what the hospital does rather than from what the screen shows, with the Business Analyst and the module owner in the room
- Own the regression pack that runs before every release, and grow it every time something escapes
- Run beta: put each release in front of the hospital's own people on migrated data, log what they find so it can be reproduced, and close it before the next release starts
- Be the person who says a release is not ready, and be right often enough that it carries weight
- Money — every path that produces a bill, a discount, a refund or a day-end total, including the ones that fail halfway through
- Stock — batch, expiry, issue and return, and the concurrent case where two counters sell the last strip
- Clinical safety — allergy and interaction checks, dose limits by age and weight, critical values, and every alert that must reach a human
- Access — that one hospital cannot see another's data, and that a role cannot do what it should not
- Integrations — a laboratory result from a real analyser, an image from a real modality, an ABHA created against the real sandbox; a mock proves the code, not the hospital
- Test the failure paths as seriously as the happy ones; the happy path is the one everybody already tried
- Turn the acceptance scripts into something the hospital's own staff can run and sign, on their own migrated data, in the beta environment
- Design the parallel run: what is entered in both systems, what is reconciled daily, and what "the numbers match" means for registrations, bills, collections, dispensing and reports
- Be on the floor through cutover and hypercare, where the real testing happens, and bring what you see back into the suite
- Own test data: realistic, safe, and reproducible, including the awkward records that break things — the duplicate patient, the expired batch, the refund after a partial payment
- Sit in on specification work early, because the cheapest defect is the one caught while the specification is still a paragraph
- Keep every defect described so that someone who was not there can reproduce it — steps, data, environment, what was expected, what happened
- Track what escaped and why, and bring it to the retrospective rather than to an individual
- Pair with engineers on the automated checks that live beside the code, so testing is not a gate at the end but a habit along the way
- End-to-end testing — Playwright with TypeScript, against the real web application: journeys, fixtures, test data builders, and traces that say why a run failed
- API and service testing — pytest and pytest-asyncio against FastAPI services; the OpenAPI schema is the contract, and tests are written to it
- Database verification — PostgreSQL and SQL good enough to prove in the database what the screen claims, and to spot the migration that silently rounded a rupee
- Continuous integration — GitHub Actions; the suite runs on every pull request, and a red build blocks a merge
- Environments — Docker-based environments for development, beta and UAT, each with its own reproducible data set
- Performance — load testing at peak outpatient volume with k6 or Locust, and the judgement to know which number matters
- Integration test beds — HL7 v2 messages from analysers over MLLP, DICOM modality worklist and PACS, and the ABDM sandbox for ABHA creation and consent
- Defect and test management — a shared tracker visible to the hospital, with a published severity and response standard
- Playwright, Cypress or Selenium on a system people depended on — writing maintainable tests, not recording brittle ones
- A programming language, enough to write helpers, fixtures and data builders; TypeScript or Python, and the other within the first month
- API testing at the service layer, and the sense to know which layer a case belongs at
- SQL to verify data directly, not only through the screen
- A CI pipeline your tests ran in, where a failure meant something to the team
- Healthcare, banking, insurance, or another domain where a wrong number is a real consequence
- Testing integrations with devices or external systems — an analyser, a payment gateway, a government API
- Test design beyond the checklist: boundaries, equivalence classes, state transitions, concurrency
- Accessibility and usability testing on screens used by people who did not choose the software
- Running a user acceptance test with non-technical staff, and getting it signed
- Security testing basics — role-based access, injection, the OWASP top ten — and reading a VAPT report
- Three or more years in software quality with real ownership of automation, not only manual execution
- Have been the person who said a release was not ready, and can describe what you saw and what happened next
- Enough programming to be useful in a codebase: helpers, fixtures, test data, and the occasional fix to the thing you found
- Comfortable at the service layer and in the database, not only at the screen
- Can write a defect report that a developer reproduces first time, and a test plan that a module owner recognises as their own work
- Methodical about the awkward cases — the refund after a partial payment, the expired batch, the patient registered twice — because those are where a hospital gets hurt
- Willing to sit at a billing counter or beside a nurse for a shift and come back with the cases the specification missed
- Preferred: healthcare or another domain where correctness is auditable after the fact, and experience with a parallel run or a system cutover