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

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