QA Tester

Experience: 3.00 + years

Salary: Confidential (based on experience)

Expected Notice Period: 15 Days

Shift: (GMT+05:30) Asia/Kolkata (IST)

Opportunity Type: Hybrid ()

Placement Type: Full Time Permanent position(Payroll and Compliance to be managed by: Pet Health and Wellness Company)

(*Note: This is a requirement for one of Uplers client - Pet Health and Wellness Company)

What do you need for this opportunity

Must have skills required:

LLM, WCAG, AI testing, Cypress, Playwright, QA, Selenium

Pet Health and Wellness Company is Looking for:

QA Tester

Years of Experience : 3-5 years in software QA

Location : Nashik, Maharashtra

Reports to : Operations Manager

Manages : A pod of 2 QA juniors, hired by you in sequence over your first two quarters

We ship a multi-tenant AI-native SaaS and an internal operating system at speed, with an Engineering Manager and a bench of junior developers. Speed without a gate produces a codebase that looks finished and behaves badly. You are that gate — and nothing reaches a client or the wider team without passing a standard you own and can defend in writing.

About The Role

The title says tester. The job is a release gate with a veto.

You own the definition of done — the written, versioned statement of what finished means, which you author and the Engineering Manager consumes. You own the release criteria, the defect taxonomy and triage process, the usability standard, accessibility conformance, the evaluation harness for AI and agent features, and your pod of QA juniors.

Three things make this role harder than conventional QA, and they are the reason it sits in the senior pack:

Much of what we ship is non-deterministic. An AI agent given the same input twice may produce two different outputs, both defensible, one wrong. Pass/fail equality assertions do not work on systems like that. Most organisations learn this by hearing about failures from clients. You are hired so that does not happen here.

Testing alone cannot get you to a high quality bar. Inspection and static analysis remove roughly twice the proportion of defects that any form of testing does. So inspection and static analysis are the primary removal mechanism here and testing is the backstop — which means part of your job is arguing for review discipline when someone proposes skipping it to just test it harder.

Anything with an interface needs a defensible usability standard rather than the taste of whoever built it last. That standard is yours.

What you do not own: the build — architecture, implementation, stack, refactors the roadmap or sprint planning (you gate what is built, you do not choose it) infrastructure and environments and the junior developers themselves. You gate their output you do not manage or direct them. The commonest failure mode for a first-time QA lead is drifting into unofficial project management because they are the person who notices everything. Notice everything own only your list.

What You'll Do

• Author and version the definition of done, and ratify it with the Engineering Manager — ratified means they have read it, disagreed where they disagree, and the disagreements are resolved or escalated. A gate the build owner has not agreed to is theatre
• Run the release gate as a checklist, not a judgement call — anyone should be able to run it and reach your answer
• Own defect severity. Severity is technical impact and is assigned by QA it is not negotiable by the person who wrote the code. Priority is agreed in triage, because it depends on context you do not solely own
• Run defect triage with the Engineering Manager three times weekly, twenty minutes, every defect getting a severity, a priority and an owner
• Get static analysis into the pipeline and formal code inspection onto the calendar, with findings treated as gate items rather than advisory noise
• Establish a trailing Defect Removal Efficiency baseline — defects found before release over defects found before plus after, measured at release + 90 days, with the window quoted every single time
• Run heuristic evaluation on every major surface quarterly, with 3-5 independent evaluators who do not see each other's findings until their own pass is complete
• Own WCAG 2.2 Level AA conformance: automated scan in the pipeline, manual keyboard traversal of changed flows, and a screen-reader pass
• Build and maintain the AI evaluation harness — eval sets, graders, baselines, case-level regression diffs on every prompt change
• Run browser automation through agents, not just scripts — drive regression and cross-browser coverage with agentic tooling that turns written intent into executed browser runs, and own the question of whether a failed run found a defect or just drifted
• Hire, onboard and develop two QA juniors, and publish a quarterly quality report the rest of the business can act on
  
  

Agentic AI in Your Day-to-Day


This role is unusual in the pack: agents are both a tool you run and the thing you are testing. Both halves matter, and the second half is the one almost nobody has done before.

Your Roles And Responsibilities

• Test-case generation — Agent drafts cases from acceptance criteria and the spec. You decide which of them are real tests and which are merely present
• Static analysis triage — Agent clusters pipeline findings by root cause and separates gate-blocking items from noise before you open the report
• Browser automation — Agent drives the browser from written test intent rather than hand-maintained selectors: it walks the flow, adapts when the DOM moves under it, and reports what it saw. This is the biggest single lever you have on regression and cross-browser coverage, and the one we most want you building out
• Regression suite maintenance — Agent flags cases that have drifted out of sync with the code they test, which is how external test-case tools quietly die within two sprints
• Defect report drafting — Agent turns a reproduction into a structured report — steps, expected vs actual, environment, tags — for you to assign severity to
• Accessibility scanning — Agent runs the automated layer on every change and maintains the per-surface conformance statement and remediation backlog
• Transcript triage for AI features — Agent surfaces the transcripts worth your human hour from the thousands you cannot read
• Exploratory charter prep — Agent assembles the recent-change surface area so your time-boxed exploratory sessions start where the risk actually moved
• Quality reporting — Agent assembles the defect distribution, gate outcomes and eval pass rates. You write what they mean
  
  

What Stays With You, Always


Agents find candidates. They do not hold a line:

• Severity. The number that decides whether a release ships is yours, and an agent's suggested severity is an input to it, never a substitute.
• The veto. It did not pass is a sentence you say in public with evidence attached. No agent says that for you.
• Telling a flaky agent from a broken product. An agent driving a browser is itself non-deterministic, so a red run is ambiguous in a way a scripted run is not. Separating the agent lost the thread from the build is broken is yours, and an automation suite nobody trusts is worse than no suite at all.
• Judging whether a test is real. An agent will happily generate a suite with excellent coverage statistics that asserts nothing meaningful. Catching that is the job.
• Grader alignment. An unaligned LLM judge is a random number generator with good manners. Before you trust one, you label a sample by hand, run the judge against it, and measure precision and recall — not raw accuracy, which an always-pass judge games trivially.
• Reading transcripts by hand. Regularly, including passing ones. Scores tell you whether the graders fired only transcripts tell you whether they measure the thing that matters. Budget an hour a week and defend it — it is the first thing dropped when a team gets busy.
• Measurement integrity. A benchmark without a disclosed sample size, date range and metric definition is not a benchmark it is a number someone typed. When we lack data, you say we do not have enough data yet. That buys more credibility here than any invented figure.
  
  

How You Run Agents As a System


You are not a user of AI tools. You are the person who decides whether the AI we ship is actually working, and can show the method behind the answer.

• Eval sets are curated, not imagined. Start at 20-50 cases drawn from real observed failures, covering four classes deliberately: happy path, edge cases, adversarial inputs, and off-topic requests the agent should decline cleanly rather
• than hallucinate through. Every production failure becomes a new case the week it is found — that loop is the entire mechanism by which the set gets good.
• Prompts are source code. Versioned in the repository, never edited in a production console, and every prompt change triggers a full eval run before merge, diffed case by case against the recorded baseline. A change that lifts the aggregate while breaking three previously-passing cases is a regression, and the aggregate will hide it.
• Run each case k times. pass@k answers can it do this at all and pass^k answers can I rely on this They diverge sharply as k grows. For anything client-facing, pass^k is the number that matters — and pass@k is the number a vendor will quote at you.
• Grade outcome and trajectory, without over-specifying the trajectory. Agents routinely find valid paths nobody anticipated, and grading each step rigidly produces brittle tests that fail on correct behaviour and train the team to ignore red.
• Record every baseline with its date, model version and set version. A provider updating their model underneath us moves our numbers with no change on our side — which is why the set runs on a schedule, not only on commit.
• A browser agent is held to the same bar as any other agent. Named owner, written purpose, versioned prompt, and a measured flake rate. An agent-driven suite that goes red at random trains the team to ignore red, which costs more than the coverage was worth.
• Offline and online. Offline evals gate deployment online evaluation watches live traffic for failure classes nobody anticipated. Online is where next quarter's cases come from.
  
  

What We're Looking For (Must-Have)

• 3-5 years in software QA on a product, with real ownership of release readiness rather than test execution handed to you
• You have personally blocked or delayed a release, and can tell us what happened next — the pushback, how it resolved, whether there was a written waiver. A candidate who has never blocked anything has watched a gate rather than run one
• A working method, not a vibe: you can name the checklist you ran and the evidence you required
• Holds severity and priority apart instinctively, and knows which of the two belongs to QA
• Functional, regression, smoke and exploratory testing on web, with API testing (Postman or equivalent) and SQL for data verification
• Browser automation, and an appetite for driving it with agents. Hands-on with Playwright, Cypress, Selenium or equivalent, with cases versioned alongside the code they test. You need not have run an agentic browser suite before — we will build that here — but you must want to, and you must be able to say why a self-healing agent run is harder to trust than a scripted one
• Static analysis and code-review discipline treated as first-class quality mechanisms, not as somebody else's process
• Has had a defect escape to users and can describe the systemic fix that followed — not I'll be more careful. A candidate who has never had an escape has either not shipped or is not telling us the truth
• Writing that other people act on without asking a follow-up question. The entire job is producing artefacts other people act on
• Calibrated about AI testing: you need not have built an eval harness, but you must recognise that one passing run proves almost nothing and one failing run proves almost nothing either, and your instinct must be toward repeated trials
  
  

What We're Looking For (Preferred)

• Hands-on evaluation of LLM or agent features — eval sets, LLM-as-judge, prompt regression suites
• WCAG 2.x accessibility testing with manual keyboard and screen-reader passes, not scanner output alone
• Agentic browser tooling in anger — Playwright MCP, browser-use, computer-use agents or similar — including an honest account of where it wasted your time
• Multi-tenant SaaS, where a tenant-scoping defect is a security defect
• Heuristic evaluation or other structured usability method
• Has hired or onboarded a junior tester
  
  

Not required: a formal QA certification

• prior QA Lead title — we care about whether you owned the gate, not what the box said.
  
  

Who Excels In This Role

• Takes ownership — treats the role as their own operation ships the work end-to-end
• Proactive — sees the next move before being asked ships the fix and reports
• Domain expert — has real, hands-on depth in the discipline this role covers
• Out-of-the-box thinker — when the obvious move stops working, finds the non-obvious one quickly
• Performs under stress — triages and ships in real-time when things break
• Evidence-first under pushback — when a developer says your bug is not a bug, you reach for the reproduction and the log, never for the person, and you escalate rather than cave or fight
• Calibrated about AI — neither dismissive of it nor uncritically enthusiastic knows where it works and where it does not
  
  

What Success Looks Like


By month six, someone outside the team should be able to check each of these without taking your word for it:

• The defect-removal baseline is in place. You can show how many defects were caught before release and how many showed up after, measured the same way every time, with the method written down next to the number. The trend against your own earlier figures matters more than the figure itself.
• Code inspection and static analysis run on every change. Nobody asks to skip them when a deadline is close, because the case for them was settled early.
• The defect log is complete and people trust it. Severity is set by QA and is not argued down. Priority is agreed in triage, which is where that discussion belongs.
• Accessibility status is written down for every screen, with a dated list of what is still to be fixed.
• AI testing is set up properly. When someone asks is the agent working, you give a number and can explain how you arrived at it.
• The browser automation suite runs on its own and the team acts on the results instead of ignoring them.
• One QA junior is hired and running the release checklist unsupervised, and you can point to what they caught.
  
  

Two signs matter most. The gate has blocked at least one release and the team handled it without a fight — a gate

that has never stopped anything is paperwork, not a gate. And nobody is caught out by the gate: the team knows in advance what will pass and what will not, which means the standard is written clearly enough.

The job is not measured by how many bugs you find. It is measured by how few reach a client, and by whether people believe the number you give them.

Hiring Process

The process is the same for every senior role in this pack:

• Intro call (30 min) — mutual fit and role expectations. We give you the compensation band in this call.
• 24-hour take-home task — a real exercise from our day-to-day work
• Role deep-dive (60-90 min) — a walkthrough of real work you have done
• Team + culture conversation (45 min) — with the Operations Manager and the team you would work with
• Offer + onboarding plan
  
  

Benefits

• Direct report to the Operations Manager
• Growth path: the quality function scales under you — your pod, your standard, and ownership of the AI evaluation harness as the product surface grows
• Monthly KPI bonus structure (paid monthly, on outcomes) + promotion ladder
  
  

What we are watching for: we tested everything thoroughly with no named mechanism

• a smooth-launch story offered as evidence of sign-off authority
• treating an automated accessibility scan as conformance
• asserting exact-output assertions on AI output, or it worked when I tried it reasoning
• quoting an industry average instead of a trailing baseline
• drifting into project management because you are the person who notices everything.
  
  

How to apply for this opportunity

• Step 1: Click On Apply! And Register or Login on our portal.
• Step 2: Complete the Screening Form & Upload updated Resume
• Step 3: Increase your chances to get shortlisted & meet the client for the Interview!
  
  

About Uplers:


Our goal is to make hiring reliable, simple, and fast. Our role will be to help all our talents find and apply for relevant contractual onsite opportunities and progress in their career. We will support any grievances or challenges you may face during the engagement.

(Note: There are many more opportunities apart from this on the portal. Depending on the assessments you clear, you can apply for them as well).

So, if you are ready for a new challenge, a great work environment, and an opportunity to take your career to the next level, don't hesitate to apply today. We are waiting for you!