Hire QA Engineers in India
The hard part of hiring QA engineers in India is not finding candidates. It is working out which of three quite different jobs you are actually buying, because the manual tester, the SDET and the test architect all answer to the same title and only one of them will fix your problem.
Almost every unhappy QA hire we are asked to rescue started with a job description that said "QA Engineer, 4+ years, Selenium, Postman, JIRA" and ended with a person doing work nobody wanted. Sometimes an excellent exploratory tester was handed a broken CI pipeline and told to fix it. More often a competent automation engineer was asked to sit in refinement meetings and argue about acceptance criteria, which is a different skill entirely and not one they were hired for. This page is about telling those roles apart before you write the brief, and about what an offshore QA engagement out of India honestly looks like from wherever you are reading this.
One Job Title, Three Completely Different People
Backend and frontend at least sound different. QA does not. The title covers a spectrum that runs from someone who never opens a code editor to someone who spends their whole week inside one, and buying at the wrong end of that spectrum is the single most common way a QA hire fails. Before anything else, work out which of these you are short of.
The manual tester, who is not the junior version of anything
There is a persistent assumption that manual testing is what people do until they learn to automate. It is a separate discipline with its own senior tier, and the senior tier is rare. A strong manual tester takes a feature nobody has described properly, forms a theory about where it will break, and goes looking. They will find the bug that appears only when a user pastes a phone number with a non-breaking space in it, because they thought to try that. No script contains that test, and no script ever will, because the value is in the thinking that produces the test rather than in running it.
You want this person when your product has a lot of human-facing surface area, when requirements arrive as conversations rather than documents, or when your last three production incidents were all things nobody had considered. You do not want them when your problem is a two-hour build and a suite that fails randomly.
The SDET, who is a developer with a different objective
SDET stands for Software Development Engineer in Test, and the important word is Development. This person writes real code: page objects and API clients, fixture factories, seeding scripts, a harness that can spin a stack up and tear it down, and the CI configuration that runs all of it. They read stack traces for a living. They will care about how long the suite takes because they are the one waiting for it.
Hire an SDET when the bottleneck is mechanical rather than intellectual: a release process that needs three days of clicking, a suite that nobody trusts, a stack too awkward to stand up locally so nobody tests against it. Do not hire one and then ask them to spend most of their week doing exploratory passes. They will do it badly and leave within the year.
The test architect, who is mostly deciding what not to do
A test architect earns their keep across teams rather than inside one. Their output is decisions: which behaviours are verified at which level, where the contract boundaries sit between services, what the environment strategy is, which risks are accepted deliberately rather than by accident. They are the person who can look at a suite of nine hundred end-to-end tests and say that six hundred of them are testing something already covered by a unit test, and then get that argued through with three engineering managers who each own part of it.
This role only makes sense once you have several teams whose testing decisions collide. One product team with eight developers does not need a test architect; it needs a good senior QA engineer with opinions. Hiring an architect into a single team produces a lot of documents and very little change.
Working out which one you are short of
Ask what happened the last three times something reached your users broken. If the answer is that nobody thought to try that combination, you have a manual and exploratory gap. If the answer is that a test existed and had been failing for weeks so everyone ignored it, you have an SDET gap. If the answer is that two teams each assumed the other had covered the integration, you have an architecture gap. The failure history tells you the role. The job board tells you nothing.
A caveat worth stating: these categories blur at the top. Genuinely senior QA people usually do all three to some degree, and the best SDET we have worked with also happens to be the sharpest exploratory tester in the room. But you cannot hire for the blur. You hire for the primary skill and get the rest as a bonus.
What Does a QA Engineer Actually Do on a Tuesday?
Job adverts describe QA work as ensuring product quality, which describes nothing. Here is the shape of the actual week, because knowing it helps you judge whether the person you are interviewing has lived it.
Reading the ticket before the code exists
A good chunk of the value arrives before anything is built. The QA engineer reads the story, asks what happens when the field is empty, what happens when the same request arrives twice, what the behaviour is for a user whose subscription lapsed mid-session. Half of those questions change the implementation. This is the cheapest defect prevention available and the part most teams skip because it looks like meetings rather than work.
Exploratory sessions with a charter, not aimless clicking
Structured exploratory testing means picking a mission for a fixed block of time, say ninety minutes on the checkout flow with a focus on payment failures, and keeping notes as you go. It is not random. At the end there is a record of what was covered, what was found, and what could not be reached. When a candidate describes exploratory work as just playing with the app, they have never done it properly.
Keeping the automated suite honest
Suites rot. Selectors drift, fixtures go stale, a test that has been skipped since March never comes back. Part of the week goes on the maintenance nobody schedules: deleting tests that assert nothing, fixing the ones that fail for environmental reasons, and pushing back when someone wants to add the twelfth end-to-end test for a validation rule.
Triage, reproduction and the awkward conversations
When a report arrives from support, someone has to turn "it did not work" into a set of steps that fail reliably. That work is unglamorous and it is where a lot of QA value hides, because a bug that cannot be reproduced does not get fixed regardless of how real it is. The same person usually ends up saying that a release is not ready, which requires a spine and a track record of being right.
The bit that surprises people: reading logs
Modern QA work involves a lot of observability. Reading application logs to find the actual exception behind a generic error page, checking whether a request even reached the service, looking at a trace to see which downstream call timed out. A tester who reports only what the browser showed them is doing a fraction of the job. One who arrives with the request ID and the stack trace saves the developer an hour every single time.
How an SDET Differs From a Developer Who Writes Tests
This distinction gets waved away with "our developers write their own tests", and sometimes that is genuinely the right answer. It is worth being precise about where the two stop being interchangeable.
Different question, same keyboard
A developer writing tests is asking whether their code does what they intended. An SDET is asking what would have to be true for this to fail in front of a customer. Those questions produce different tests from the same feature. The developer covers the branches they wrote. The SDET covers the branches nobody wrote: the second click, the expired token, the response that arrives after the user navigated away, the request that succeeds but writes the wrong row.
There is a well-known blind spot here and it is not a criticism of developers. It is very hard to imagine failures in a mental model you built yourself. Fresh eyes matter for the same reason authors need copy editors.
Ownership of the machinery, not just the assertions
The tests are the visible part. Underneath sits the part an SDET actually owns: how a test environment is created and destroyed, how data is seeded so runs are independent, how the suite is sharded to fit a CI budget, how flakiness is detected and quarantined, how a failure produces enough evidence that nobody has to rerun it locally to understand it. Developers rarely build this because it is not their product, and without it a test suite decays within two quarters.
Where a developer who tests is genuinely enough
Small team, one deployable, a product with a narrow surface, developers who already write decent tests and actually run them. In that situation an SDET hire will be underemployed and will spend six months building infrastructure for a problem you do not have. The honest advice there is to spend the budget on a strong exploratory tester part-time, or on nothing at all until the shape of the problem changes.
The hybrid that usually works
One QA engineer embedded in a team of six to ten developers, doing the risk thinking and the exploratory work, writing the tests at the levels developers neglect (usually the integration and contract layer), and owning the health of the pipeline as a shared concern rather than a personal fiefdom. That is the arrangement we staff most often and the one that survives contact with a deadline.
How Do You Screen a QA Engineer Without Asking Which Tools They Know?
Tool questions are easy to prepare for and tell you almost nothing. Every question below is designed so that the shallow answer and the deep answer sound different within thirty seconds, and none of them can be revised for the night before.
Here is a feature. What would you test, and what would you not bother automating?
This is the one that does most of the work. Describe something real and slightly messy, say a discount code system where codes can be percentage or fixed amount, can stack in some combinations, expire at midnight in the customer's timezone, and are validated again at payment. Then let them talk.
Weak candidates list happy paths and then list every possible combination, which is the same as having no plan. Strong candidates start narrowing almost immediately: they will want to know the money impact of each failure, they will ask whether codes are created by staff or generated in bulk, they will notice the timezone in the expiry rule and pull on it. Then comes the half that matters. Ask what they would leave manual and listen for a genuine trade-off rather than a shrug. Good answers sound like this: the stacking rules go in unit tests because there are forty combinations and each is cheap there; one end-to-end test proves a code survives the full checkout; the admin screen for creating codes gets checked by hand each release because it changes twice a year and an automated test for it would cost more to maintain than to run manually. Depth shows in what they choose to leave alone. Anyone who says everything should be automated has never maintained a suite for two years.
Tell me about a flaky test you fixed
Not a flaky test you saw. One you fixed, root cause and all. The answers sort candidates into three groups fast. Group one added a wait and moved on. Group two added a retry, which hides the failure and occasionally hides a genuine race condition in the product. Group three found the actual cause, and the causes are always interesting: a test asserting on a list that arrives unordered, two tests sharing a user record, an animation completing at different speeds under CI load, a token expiring mid-suite, a clock that ticks past midnight during a long run.
Push once more and ask how they knew it was fixed rather than quiet. The good answer involves running it many times in a loop, or checking the failure rate over a fortnight of CI history. The weak answer is that it stopped failing.
How do you decide whether something is a unit, integration or end-to-end test?
The textbook answer is the pyramid, and everyone recites it. What you are listening for is a decision rule they apply under pressure. A usable one sounds like: push the test as low as it can go while still proving something a user would notice, and only go to end-to-end when the thing being verified is the wiring between components rather than any single component's behaviour.
The follow-up separates people further. Ask where they put a rule like "orders over a certain value need manager approval". If it lives in one service, that is a unit test, plus perhaps one integration test to prove the approval record is written. Candidates who reach for an end-to-end test for a business rule are telling you their suite is expensive and slow, and that they have not felt the cost of that yet.
Your suite takes forty minutes. What happens next?
A superficial answer goes straight to parallelisation, which is the right tool and the wrong first step. Better answers start by asking where the forty minutes actually goes, because in most suites a small number of tests eat most of the clock and half of them are waiting on fixed sleeps. Then come the real options, roughly in order of value: delete the tests that duplicate coverage at a lower level, replace hard waits with proper conditions, seed data through the API rather than driving the UI to create it, split the suite so pull requests run the fast subset and the full run happens on merge or nightly, and only then shard across parallel runners.
There is a judgement question hiding in this one. Ask what they would tell a team that wants to keep all forty minutes on every pull request. The right answer acknowledges that developers will start ignoring or bypassing a gate that slow, and that a suite people route around is worse than a smaller suite people respect.
How do you test something with no requirements document?
This is the normal case, not the edge case, and candidates who look uncomfortable here have only worked somewhere with a business analyst layer. Good answers involve building the specification by other means: reading the code or the API schema to see what the system claims to do, checking analytics for how the feature is actually used, talking to whoever handles support tickets about the same screen, and writing down the assumptions as testable statements to be confirmed or corrected by the person who asked for the feature.
The strongest version of this answer treats the missing document as an output rather than an obstacle. They test, they write down what the system does, and that becomes the first honest description of the behaviour anyone has had. We have seen that artefact change a roadmap.
Rewrite this bug report so it gets fixed
Hand over a genuinely bad report, the kind support forwards: "Payment page broken on mobile, customer complained." Ask what they would need and where they would get it. This exercise catches the difference between someone who files tickets and someone who investigates. Watch for whether they ask about the environment and build, whether they think to check logs for the timestamp, whether they consider the customer's actual device rather than guessing, and whether they attempt to reproduce before escalating.
The Tool List on the CV Is Usually a Warning
A QA CV listing Selenium, Cypress, Playwright, Appium, JMeter, k6, Postman, RestAssured, TestNG, JUnit, Cucumber, Pact, Jenkins, TestRail and Zephyr looks impressive for about four seconds. Then you notice that nobody has fifteen tools' worth of depth in six years, and that the list is describing exposure rather than skill.
What the long list usually means
It is most common on CVs from large services companies where people rotate between accounts every eight months. Each rotation adds a tool. What it does not add is the experience of maintaining anything through two years of product change, which is where all the hard lessons live. Someone who ran one Playwright suite for three years knows things that fifteen bullet points cannot contain: how selectors decay, which abstractions were a mistake, what the suite cost to keep alive.
The question that collapses the list
Pick one tool from the middle of the list and ask what they dislike about it. Real users have complaints, and the complaints are specific. Somebody who has genuinely lived with Cypress will mention the way its architecture makes multi-tab and multi-origin work awkward, or the trade-off in its automatic waiting. Somebody who has lived with Playwright might grumble about how easy it is to write over-broad locators, or about trace files eating CI storage. Somebody who has lived with Appium will have opinions about driver version compatibility that they will share at length. A candidate who says a tool is great and has no complaints has read the documentation.
Tools worth actually caring about, and what for
Browser automation sits mostly with Playwright and Cypress now, with Selenium still everywhere in older estates and not going anywhere given how much of the world runs on it. API-level work runs through Postman collections with newman in CI, RestAssured in Java shops, or plain pytest with requests, and the choice matters far less than whether the tests are independent. Contract testing means Pact in practice. Load work means k6, Gatling or JMeter. Accessibility scanning means axe. Mobile means Appium, or Espresso and XCUITest if you are willing to maintain two native suites for better stability. Reporting means Allure or the CI's own output, and test management means Xray or TestRail if you have compliance reasons to need it.
Notice how short that list is. Depth in three of these plus the judgement to pick between them beats familiarity with all fifteen. When we shortlist, tool overlap with your stack is a tiebreaker rather than a filter, because a competent automation engineer moves between Playwright and Cypress in a fortnight while the thinking transfers on day one.
Certifications
Testing certifications are common on Indian QA CVs and they are neither a positive nor a negative signal on their own. They demonstrate that someone learned a vocabulary. They say nothing about whether that person can find a bug in your checkout flow, which is why we assess with exercises rather than credentials and why we do not use certification as a shortlist criterion.
Test Strategy Is the Senior Skill, and It Is Mostly Subtraction
Junior QA people add tests. Senior QA people remove them and can explain why. If you interview for one thing beyond diligence, interview for this, because it is the difference between a suite that helps and a suite that becomes a tax on every change.
Risk is impact multiplied by the chance of getting it wrong
Every part of a product has a different cost of failure and a different likelihood of breaking. Payment capture is high impact and high churn, so it gets attention at every level. The marketing footer is low impact and rarely touched, so it gets a glance. A settings screen that has not changed in a year is low likelihood even if the impact is moderate. Ask a candidate to rank the areas of your product by risk and you will learn more in ten minutes than from an hour of methodology talk.
The dimension people forget is detectability. A bug that shows up loudly in the interface will be reported by a user within the hour. A bug that quietly writes the wrong tax rate to a database row will surface in an audit nine months later, and by then the data is wrong across thousands of records. Low detectability raises priority even when impact looks moderate at first glance, and candidates who bring this up unprompted are worth keeping.
Deciding what not to test
Nobody says this out loud in interviews because it sounds like negligence, so it is worth making explicit that you want to hear it. Things that genuinely do not deserve a test: framework behaviour, third-party library internals, getters and setters, cosmetic layout that a person looks at every day anyway, and any path where the cost of the bug is lower than the cost of the test's maintenance for a year.
The commonest waste we find is combinatorial expansion in end-to-end tests. Four user types multiplied by three subscription states multiplied by two currencies is twenty-four scenarios, each taking a minute of browser time, and twenty of them are re-proving logic that one parameterised unit test could cover in half a second. A senior person spots this pattern in a suite within an afternoon.
Knowing when to stop
Testing has no natural end. Somebody has to decide the release is good enough, and doing that well means having exit criteria agreed before the testing starts rather than argued about at 6pm on release day. Reasonable criteria are specific: the agreed risk areas have been covered, no open defects above a defined severity, the regression suite is green, known issues are documented with workarounds where they exist.
Ask a candidate about a time they signed off on a release that then broke. Everyone has one. The answer you want describes what they missed and what they changed afterwards. The answer that worries us is the one where it was somebody else's fault.
Coverage percentages, and why we do not chase them
Code coverage measures which lines executed during a test run. It does not measure whether anything was verified, which is why a test suite with no assertions at all can report high coverage. Chasing a coverage target reliably produces tests written to touch lines rather than to catch defects, and once a number becomes a target it stops being useful information.
Coverage is genuinely useful in one direction: as a search tool for surprises. A payment module sitting at very low coverage is a question worth asking. The number going from 71 to 74 percent is not an achievement. If a candidate's proudest accomplishment is a coverage percentage, probe for what it actually prevented.
Working With Developers, Not Standing at the End as a Gate
The old arrangement had developers finish a feature and throw it to a QA team who found problems days later. It produces slow feedback, defensive engineers and a QA function everyone resents. Most teams say they have moved past it. Fewer actually have, and it shows up in how the QA person spends their week.
Involvement before the code exists
The cheapest bug to fix is one that was never built, and the way to catch those is a conversation between the person who wanted the feature, the person building it and the person testing it, held while the story is still soft. Twenty minutes of that reliably surfaces the case nobody had considered. Ask a candidate what they contribute to refinement and listen for questions about edge conditions rather than a recital of ceremony names.
Testability as a design conversation
Some systems are almost impossible to test through no fault of the tester. State hidden in a way nothing can inspect, no way to trigger a scheduled job on demand, no test mode for a payment provider, timestamps taken from the system clock with no ability to inject one. A QA engineer who can raise these early, in the design review, is preventing months of pain. One who accepts an untestable design and then writes elaborate workarounds around it is storing up flakiness.
Reviewing pull requests without being a nuisance
QA people reading pull requests is one of the higher-value habits available and one of the easiest to do badly. The useful contribution is not style comments. It is noticing that a change touches the discount calculation and asking whether the negative-amount case was considered, or spotting that an error is now swallowed where it used to be logged. This requires enough code fluency to follow a diff, which is a fair thing to test in an interview even for a non-automation role.
The gate that still has to exist
None of this means nobody is allowed to say no. There has to be a point where someone with the full picture says the release is not ready, and that person should be able to hold the line under pressure from a delivery manager with a date. The difference from the old model is timing and tone: the objection arrives early and comes with evidence, rather than arriving on the last afternoon as a list of surprises.
Where our engineers fit into your process
The QA engineers we place work inside your team's rituals rather than beside them. Your board, your definition of done, your pull requests, your review rules. Where the engagement covers a specific discipline in depth, the specialist work is described in more detail on our automated testing services in India page and our API testing services in India page, which cover the engagement side of that work rather than the hire.
Bug Reports That Get Fixed, and Bug Reports That Get Closed as Cannot Reproduce
Every QA engineer writes bug reports. The gap between a report that a developer picks up and fixes in twenty minutes and one that sits in the backlog for a quarter before being closed unresolved is almost entirely craft, and it is easy to assess before you hire.
What survives triage
A report that gets fixed answers the developer's questions before they ask them. Exact build or commit, exact environment, the account or data state that mattered, steps that a stranger can follow, what happened, what should have happened, and evidence: a screenshot at minimum, a video for anything involving timing, the request ID or the log line for anything server-side. The frequency matters too, because "every time" and "roughly one attempt in eight" lead to completely different investigations.
The single highest-value habit is attempting to narrow before filing. Does it happen on a fresh account? Only in one browser? Only when the item was added from search rather than the category page? Five minutes of that turns a vague complaint into a report that points at a function.
The autopsy of a cannot-reproduce
Reports get closed unreproducible for a small number of recurring reasons, and every one of them is preventable. The state was different: the reporter's account had an old subscription record, and the steps do not mention it. The environment was different: staging had a config flag that production does not. The timing was different: the bug needs the request to arrive while a background job holds a lock, which manual steps rarely recreate. The build was different: it was fixed incidentally three commits later and nobody linked the change. Or the steps were simply incomplete, missing the one action that mattered.
Ask a candidate how they handle a bug they saw once and cannot reproduce. Filing it anyway with everything they have, clearly labelled as intermittent with the timestamp attached so someone can go and look at the logs, is a better answer than either dropping it or padding it with guesses. The worst answer is inventing steps that seem plausible.
Severity, priority, and the argument between them
Severity is technical impact. Priority is business urgency. They come apart constantly and conflating them wastes everybody's time. A crash in a screen used by four internal staff is high severity and low priority. A typo in the pricing on the landing page is low severity and drop-everything priority. QA owns the severity call because it is an assessment of impact. Priority belongs to whoever owns the product, and a QA engineer who understands that boundary stops a great many pointless arguments before they start.
Tone, which matters more offshore
A bug report is a message about somebody's work, and defensive developers slow everything down. Reports that describe the behaviour rather than the person get fixed faster. That is doubly true when the reporter and the developer are in different countries and have never shared a room, because there is no corridor conversation to smooth over a sentence that landed badly. It is a thing we watch for during trials, and it is a real reason a technically strong candidate sometimes does not make it through.
What Changes Between Junior, Senior and Test Architect
Years on the CV are a poor proxy in QA specifically, because a lot of QA careers involve executing the same regression script for four years. What follows is what we look for at each level regardless of what the CV says about duration.
Junior: executes well and asks good questions
Follows a test plan carefully, notices when something looks off even when it is not what they were checking, writes reports that need one round of clarification rather than four. Can write a straightforward automated test against an existing framework but should not be asked to design one. The signal to look for is curiosity: do they ask why the expected result is what it is, or do they just tick the box?
Mid: designs the tests for their own area
Given a feature, produces a sensible test approach without being told what to cover. Writes and maintains automated tests independently, debugs their own failures rather than reporting them as broken, and has started forming views about what is not worth testing. This is the level where you first see someone push back on a story because the acceptance criteria are unclear, which is a very good sign.
Senior: owns quality for a product area and argues for it
Sets the approach for a whole product area, including the unfashionable decisions about what will not be covered. Can look at a suite and diagnose why it is not trusted. Handles the release conversation with a delivery manager who wants to ship anyway. Mentors, reviews other people's tests, and can explain a risk in business terms to someone non-technical. This is also the level where you get the person who quietly deletes two hundred redundant tests and makes the whole team faster.
Test architect: decides across teams, and defends the decision
The architect works where multiple teams' choices interact. Their deliverables are a testing strategy that survives contact with reality, a decision about which layer owns which verification so that four teams stop duplicating the same end-to-end checks, an environment and test data strategy including how production-shaped data is handled without copying real customer records around, and a view on contract testing at service boundaries so integration failures are caught before a shared environment. They also own the metrics that tell you whether any of this is working: escaped defects, mean time to reproduce, flake rate, and the honest one, how often the suite blocked a release for a real reason.
Where an architect earns their fee is the argument. A strategy nobody follows is a document. The role only works with someone who can sit with three engineering managers, all defensive about their own pipeline, and get a decision made. If your problem is one team's messy suite, this is the wrong hire and a senior QA engineer will serve you better for less coordination cost.
Four Shapes of Problem That Land on Our Desk
What follows are recurring patterns, not accounts of particular clients. If one of them describes your situation, the recommended first hire is different in each case, which is the point.
The three-day manual regression before every release
A team ships monthly. Before each release, two or three people spend three days working through a spreadsheet of several hundred checks. It is exhausting, it delays every release, and by the third day people are ticking boxes without really looking. The obvious answer is to automate the spreadsheet, and it is the wrong first move.
What we do first is find out which of those checks has ever failed. In most spreadsheets of this kind, a large portion has never caught anything, having been added years ago for a feature that has since been rewritten. Retiring those costs nothing and buys back time immediately. The remainder splits: the high-value repetitive checks get automated at the lowest useful level, and a small set stays manual on purpose because it involves judgement about how something looks or feels. The right hire is an SDET, but the first two weeks of their work should be analysis rather than code.
The first QA hire at a startup with a dozen developers
Twelve developers, no dedicated QA, a product that has grown past the point where everyone knows how it all works. Bugs are found by customers. Each developer tests their own work sincerely and misses the same class of thing every time, because they are testing against their own mental model.
Here the wrong move is hiring an automation specialist and asking them to build a suite. There is no agreement yet on what matters, so the suite would encode whatever they guessed. The right first hire is a senior generalist QA engineer who spends the first month finding out where the product actually breaks, then builds automation against that evidence. Expect them to be unpopular for a fortnight while the true bug count becomes visible, and expect the count to be higher than anyone hoped.
The suite that is green and proves nothing
Eight hundred tests, all passing, and production incidents continue at the same rate. This is more common than teams admit and it usually has one of a few causes. Tests that assert only that a page loaded. Tests where everything downstream is mocked, so what is verified is the mocks. Tests written after the fact to match whatever the code already did, which lock in bugs rather than catching them. Or the suite covers the layers that were easy and skips the seams between services where real failures live.
The diagnostic we use is straightforward: take the last ten production incidents and ask, for each one, which test should have caught it. The gap between the answers and the existing suite is the actual work. The right hire is a senior QA engineer or an architect, because the deliverable is a decision about coverage rather than more tests. Where the missing layer turns out to be performance or the seams between services, our performance testing services in India page covers what that specialist work involves.
One tester covering web, iOS and Android alone
A single QA person supporting three platforms with different release cycles, app store review in the middle, and a device matrix nobody has ever agreed. The person is drowning, coverage is thin everywhere, and the mobile releases are the ones that slip. Adding a second generalist rarely fixes it because the problem is specialisation, not volume.
What usually works is separating the mobile work from the web work and staffing the mobile side with someone who has actually shipped through app review and understands interruption testing, permission changes across OS versions, and why a device matrix should come from your own analytics rather than a vendor's popularity list. The engagement side of that is covered on our mobile app testing services in India page.
How Does an India-Based QA Engineer Fit Into Your Working Day?
We would rather show the arithmetic than describe the time difference as manageable and hope you do not check. For QA specifically the answer has an unusual twist, because the gap that hurts a development team can work in your favour here.
The arithmetic, done properly
India sits at UTC+5:30 the whole year round and skips daylight saving entirely, which means the distance between us only ever moves when your own clocks do. An office day here finishes at 18:30 IST, having opened at 09:30. Put that into UTC and the working window becomes 04:00 through 13:00. Everything below follows from that one line.
| Where your team sits | Your 09:00 to 17:00 in UTC | Hours shared with 04:00 to 13:00 UTC |
|---|---|---|
| London, winter (GMT) | 09:00 to 17:00 | 4 |
| London, summer (BST) | 08:00 to 16:00 | 5 |
| Sydney, winter (AEST) | 23:00 to 07:00 | 3, all of it at the top of our morning |
| Sydney, summer (AEDT) | 22:00 to 06:00 | 2 |
| Auckland, winter (NZST) | 21:00 to 05:00 | 1 |
| New York (EST) | 14:00 to 22:00 | 0 |
| Chicago (CST) | 15:00 to 23:00 | 0 |
| San Francisco (PST) | 17:00 to 01:00 | 0 |
Three zeroes at the bottom of that column, and they are real. On standard business hours there is no shared minute between a North American team and an Indian team working normal Indian hours. Not a narrow window. None.
Why zero overlap is an advantage for testing specifically
This is the part worth understanding before you assume the gap is a problem to be solved. Your developers in New York merge through the afternoon and stop around 17:00 Eastern, which is 22:00 UTC. The Indian working day starts at 04:00 UTC, six hours later, and finishes at 13:00 UTC, which is 08:00 Eastern. So the entire Indian day sits inside your night and ends an hour before your team logs in.
For a QA function that arrangement is close to ideal. The full regression runs against what you merged yesterday. Failures get triaged by a person rather than left as a red pipeline. Each genuine failure becomes a reproduced, narrowed bug report with logs attached. Anything that turned out to be a flaky test gets fixed or quarantined with a note explaining which. By the time your standup happens, all of that is on the board and nobody has spent their morning working out what broke. You get one complete test cycle per calendar day instead of one per two, which over a quarter is a different release cadence.
The cost is genuine and worth stating. A question that occurs to the tester at noon in Pune waits until your morning for an answer, so an ambiguity can burn most of a day. That is why the written handover below matters more here than it would for a developer who can simply pick up the next task while waiting.
What buying live overlap actually costs
If you need conversation rather than handover, overlap is created by moving the Indian day later and somebody's evening pays for it. Push the working day here back so it opens at 13:30 IST and closes at 22:30. That is 08:00 until 17:00 in UTC, which hands a New York team on Eastern standard time three shared hours across their morning, roughly 09:00 to 12:00. Reaching the West Coast in any meaningful way needs an Indian day that ends after midnight, and we are not going to pretend that is sustainable as a standing arrangement.
Most US clients land on a partial shift of two or three hours. That buys a single call each day plus a live look at whatever cannot wait, and it does not wreck anyone's evening. Whichever shape you choose gets written into an explicit working agreement before the first day rather than being allowed to drift. One caution: continuous coverage is never thrown in. Rotating shifts have to be staffed by named people, every handover has to be written down, and somebody beyond the primary tester has to know the product well enough to take over. That is a design decision with a bill attached, and it gets scoped openly.
The handover that makes it work
When the shared window is short, a choice made verbally and recorded nowhere leaves the people who need it two days later with nothing to work from. So each Indian day closes with a written summary: what was tested and against which build, what failed and whether it looks like product or test, what could not be tested and why, and the specific questions that need an answer before the next Indian morning. Every question carries the tester's own best answer alongside it, so you can confirm or correct it in half a minute instead of putting a meeting in the diary.
Two practical rules make the difference. Anything blocked gets flagged the moment it blocks rather than at the end of the day, so you can unblock it while you are still awake. And bug reports are written to be actionable by a stranger, because in this arrangement the developer reading it will not be able to tap the tester on the shoulder. That constraint improves report quality in a way colocated teams never manage.
Where Offshore QA Actually Fails
There is a short list of ways this goes wrong, and it is the same list every time. Below is each one with the countermeasure, rather than a paragraph of reassurance.
The tester with no access
This is the biggest killer and it is almost always a client-side problem. A QA engineer who cannot see the logs, cannot reach a staging environment with realistic data, cannot get a test account with the right permissions, and cannot trigger a scheduled job on demand will produce weak work no matter how good they are. We ask about all of it during scoping and we say plainly if we think the first month will be wasted without it. Access is the one dependency we will push on hard, because everything else is downstream of it.
Ramp-up nobody budgeted for
Testing a product requires knowing what it is meant to do, and that knowledge is usually in people's heads. Expect the first two weeks to produce fewer findings and more questions than you hoped. The fastest route through is a recorded walkthrough of the product by whoever knows it best, access to old bug history, and permission to talk to whoever handles support. Teams that skip this and hand over a Confluence page get a slower start and blame the tester for it.
English and how it is actually assessed
Written English matters more than spoken English in this role, because most of the output is bug reports and handover notes that have to work without the author present. We assess it by having candidates write a real bug report and a real handover summary during the process, not by rating fluency in a call. Someone who speaks with a strong accent but writes a report a stranger can act on is a better hire here than the reverse, and a lot of screening gets that backwards.
Access, data and the security questions
QA work has an awkward relationship with production data, because realistic test data is what finds realistic bugs. The default we prefer is that production data does not leave production: masked or synthetic data in lower environments, generated to preserve the shapes that matter such as unusual characters in names, long addresses and edge-case currency values. Engineers work through your access controls on your accounts, with the same reviews and logging your own staff have. Where regulation applies to your data, whether that is health information, payment data or the various privacy regimes, treat the specifics as a question for your counsel and your compliance team rather than something a vendor page can answer, and we will work to whatever your policy sets out.
The person is technically fine and the fit is wrong
It happens. Someone assesses well and turns out to be a poor match for how your team communicates, or the role drifts into work they are not suited to. We would rather find that in week three than month six, so the first few weeks are structured around a specific piece of work with a review point at the end of it. Raise it the moment defects are being missed rather than found, and a different QA engineer stands ready within 48 hours, picked from a bench of testers rather than being the single name we first put forward, though notice in either direction still belongs in the signed agreement rather than an improvised conversation.
The QA engineer used as a shield
The failure mode we can do least about. If your developers stop testing their own work because there is now a QA person, quality gets worse rather than better and the QA engineer becomes a bottleneck who also gets blamed for anything that escapes. We flag it when we see the pattern starting, usually visible in how often pull requests arrive with no tests at all. Fixing it is a management decision on your side, not something a vendor can arrange.
Ways to Structure the Engagement
Three shapes cover almost everything we are asked for. Which one fits depends on whether your problem is ongoing capacity or a specific piece of work with an end.
One QA engineer embedded in your team
The most common arrangement. A single engineer joins your standups, works your board, and is treated as part of the team rather than an external service. Works best with a team of six to twelve developers and one product area. The main thing to get right is that they report into your delivery process, not into a parallel QA structure, because a tester with a separate reporting line ends up optimising for their own metrics.
A pair covering different disciplines
Where one person cannot cover the ground, the useful split is rarely two of the same. An exploratory-strong engineer alongside an SDET covers both the thinking and the machinery, and they sharpen each other: the explorer finds the classes of failure worth automating, the SDET makes the repetitive parts cheap. This also removes the single-point-of-knowledge risk that comes with one tester holding everything.
An assessment first, then a decision
If you are not sure what you need, a bounded piece of work is often the honest starting point. A senior engineer spends a few weeks examining what you have: the existing suite and what it actually verifies, the last several months of escaped defects, the release process and where the time goes, and the testability problems in the system itself. The output is a written view of where the risk sits and what the first three months of work should be. Sometimes the honest conclusion is that a QA hire would be premature, and saying so up front costs us a contract and saves you six months.
How we shortlist for any of these
We start from your failure history rather than your job description, because the failures tell us which of the three roles you actually need. Candidates go through the exercises described further up this page, including the feature scoping exercise and the bug report rewrite, and we send you the exercise output alongside the CV so you can judge the thinking rather than the formatting. You interview whoever you want to interview, and the decision is yours.
Where This Sits Alongside Our Other Work
This page is about the person: which QA role you need, how to assess one, and what it is like to work with someone in a different timezone. Where the need is a defined piece of testing work rather than a hire, the discipline pages go deeper into method and deliverables. Automated testing services in India covers suite design and the flakiness problem in detail. API testing services in India covers contract testing, schema validation and the failures that green integration suites miss. If you are still deciding what shape of team you need across roles, start with the overview on hiring developers in India.
Questions Buyers Ask Us Before the First QA Hire
What is the difference between a manual tester, an SDET and a test architect?
A manual tester finds defects by using the product, and the good ones find the defects nobody wrote a ticket for. An SDET writes code whose only job is to test other code, and owns the harness, the fixtures and the CI stage it runs in. A test architect decides what gets tested at which level across several teams and defends that decision when a deadline arrives. Three jobs, three interviews, three very different CVs.
How do you screen a QA engineer beyond asking which tools they know?
We hand over one real feature and ask what they would test. The answer we care about is the second half: what they would deliberately leave manual and why. Then we ask for a flaky test they personally fixed, root cause included. Someone who has only ever added a retry will say so within a minute, and that tells us more than any tool list on the CV.
Do I need a QA engineer at all, or should my developers just write more tests?
Developers should write the unit and integration tests, and no QA hire fixes a team that will not. What developers rarely do is design the test approach across a whole release, hunt for the failure nobody predicted, or say out loud that a feature is not ready. If your bugs are mostly logic errors inside one service, hire developers. If they are mostly surprises at the seams, hire QA.
How much overlap will we get with a QA engineer based in India?
India runs on UTC+5:30 and skips daylight saving, so an office day opening at 09:30 IST and closing at 18:30 lands in UTC as 04:00 through 13:00. London holds five of those hours in summer and four once the clocks go back. Sydney gets roughly three, right at the start of our morning. New York and San Francisco on standard hours get nothing at all.
Is the timezone gap actually worse for QA than for development?
For a US client it is usually better. Your team merges through the afternoon, the Indian working day sits inside your night, and the regression run plus the triage of everything it caught lands before your morning standup. You get a full test cycle per calendar day instead of per two. The cost is that a question raised in Pune at noon waits until your morning unless the shift is moved.
How quickly can a QA engineer actually start?
Shortlisting takes 48 hours. Once you have chosen someone, they can be at work seven days after that. Recruiting this profile yourself in India means sourcing, several rounds of interviews, an offer, and then whatever notice they still owe their current employer, which is how a search opened in January produces a first working day in April.
Our regression takes three days of manual clicking before every release. Where do you start?
Not with automation. First we watch the three days happen and record which checks have ever caught anything. Usually a large share of the script has never failed in its life and can be retired outright. What remains gets split into the parts worth automating and the parts that are cheaper to keep manual, and only then does anyone open an editor.
Who owns the tests, the fixtures and the test data your QA engineer produces?
You do. Everything is written into your repositories, under your branch rules and your reviewers, so the suite is never a private artefact on a machine you cannot reach. IP assignment, confidentiality and the rules for anything derived from production go into the agreement before a single test runs. What those rules say is negotiated with you; it is not something a marketing page gets to declare.