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

The QA Engineer will build and maintain automated and manual coverage for a hospital platform, helping teams assess release readiness across patient, billing, inventory, clinical, and integration workflows. The role combines end-to-end, API, database, performance, and acceptance testing with release and go-live support.

Role at a glance

Skills mentioned

What you will likely work on

• Build and maintain end-to-end journeys, automated checks, fixtures, test data builders, and failure traces.
• Create module-level test plans with business analysts and module owners, and maintain a release regression pack.
• Test service APIs and database behavior, continuous integration, environment reproducibility, and peak-load performance.
• Validate critical billing, inventory, clinical safety, access-control, and external-system integration paths, including failure cases.
• Run beta and acceptance testing on migrated data; support parallel runs, cutover, and hypercare at hospital sites.
• Prepare realistic, safe, reproducible test data and ensure defects are documented so others can reproduce them.
• Track escaped defects and test outcomes, contribute to retrospectives, and pair with engineers on automated checks.

Good fit signals

• Has at least three years in software quality, including hands-on ownership of test automation.
• Has used Playwright, Cypress, or Selenium in production on a system users relied on.
• Can write test helpers and fixtures, and work directly with APIs and SQL-backed data.
• Can assess release risk, explain why a release should not proceed, and document defects and test plans clearly.
• Healthcare or other consequence-sensitive domain experience, and parallel-run or cutover experience, are helpful rather than required.