The posting
QA Engineer
Key Responsibilities
- 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
Where Testing Is Mandatory
- 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
Beta, Parallel Run and Go-Live
- 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
Working With the Team
- 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
Tech Stack
Playwright · TypeScript · pytest · Python · FastAPI · PostgreSQL · SQL · REST · OpenAPI · GitHub Actions · Docker · HL7 v2 · FHIR · ABDM
We build in Python on FastAPI with React in front of it, on Amazon Web Services, and we test it with Playwright and pytest. That is what this role writes, runs and reads every day, and we would rather say it plainly at the top than have you find out in week one.
What you will work in every day
- 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
What we need you to have used in production
- 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
Good to have as well
- 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
What You'll Bring
- 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
