Automated Testing Services in India

Why Does a Suite Everyone Was Proud Of Stop Being Trusted?

Almost every team that calls us about automated testing services in India has the same story, and it is never the story they open with. They open with "we need more coverage". What has actually happened is that the suite they built two years ago stopped meaning anything.

The sequence is predictable. Someone writes a hundred end-to-end tests during a quiet quarter. They pass. Six months later a redesign changes the class names on the checkout page and forty tests go red on a change that broke nothing. Someone fixes the selectors under time pressure by pinning them to whatever is on screen that day. A few months after that, three tests fail intermittently and nobody can reproduce it locally, so a retry is added. Then two retries. Then a nightly cron replaces the pull request run because forty minutes of waiting was unbearable.

By the time we are called, the suite is red more often than green, and the team has quietly learned to merge anyway. That is the real cost, and it is worse than having no tests at all. A team with no automated tests is careful. A team with a suite they no longer read is careless and thinks it is covered.

The symptoms are easy to list and worth naming, because you probably recognise several. Pull request checks take longer than the code review. A rerun button is part of the merge ritual. Nobody can say what the suite covers without opening the files. The one engineer who understood the framework left. Coverage numbers are quoted in status reports while production incidents keep landing in flows that are supposedly tested.

None of that is fixed by writing more tests. It is fixed by deciding what the suite is for, deleting what does not serve that, and rebuilding the parts that do on foundations that survive a redesign. That is the work this page describes.

Playwright, Cypress or Selenium, and When Each One Is Wrong

This is the first argument on every project and the one most often decided badly, usually by whichever tool someone used last. Here is our honest position on all three, including where each one is the wrong answer.

Playwright

Our default for new work. Microsoft's runner drives Chromium, Firefox and WebKit through a single API, and the design decisions that matter were made correctly. Locators are lazy and re-resolve on every action, so the classic stale element problem largely disappears. Auto-waiting is built into the actionability checks rather than bolted on, so you are not writing explicit waits everywhere. Browser contexts give you a clean, isolated session per test at a fraction of the cost of a fresh browser launch, which is what makes real parallelism cheap.

The trace viewer is the feature that changes team behaviour. When a test fails in CI at 3am, you open the trace and get a timeline with a DOM snapshot at every step, the network log, the console, and the exact locator that failed. Engineers stop saying "it works on my machine" because they no longer have to reproduce anything. That alone justifies the migration for most teams drowning in CI failures they cannot explain.

When Playwright is wrong: when your team has a large, healthy Cypress suite and a working debugging habit around it, rewriting for marginal gain is a bad trade. When you need to test on real physical devices or a broad matrix of legacy browser versions, Playwright's bundled browser builds are not the same thing as the browser your customer runs, and you want a device cloud or Selenium Grid instead. And it is the wrong tool if you are trying to test a native desktop or mobile application, which it does not do.

Cypress

Cypress earned its reputation for a reason. Running inside the browser alongside your application gives it a debugging experience nothing else has matched: the interactive runner with time travel, where you hover a command in the log and see the DOM as it was at that moment, is genuinely excellent, and its automatic assertion retry made an entire category of timing bug go away for teams that had never used explicit waits properly.

The constraints come from the same architectural choice. Because it lives in the browser's run loop, anything that leaves that page is awkward. Multiple tabs are not supported. Cross-origin flows need cy.origin and remain more constrained than the equivalent Playwright test. The command chain is not a promise, which trips up every engineer arriving from async JavaScript in their first week. Parallelisation across machines is straightforward through Cypress Cloud, which is a commercial service, or through self-hosted orchestration if you would rather not pay for it.

When Cypress is wrong: OAuth and single sign-on redirect chains across several domains, anything involving a second tab or a popup window, and applications where you need to intercept and control traffic outside the page context. If your critical flow is "log in through the identity provider, get redirected back, then open the invoice in a new tab", you will spend more time fighting the tool than writing the test.

Selenium and WebDriver

Selenium is the oldest of the three and still the right answer more often than the internet suggests. It is a W3C standard rather than a product, which means the widest browser and language support of anything available, first-class Java, C# and Python bindings, and a grid model that has been running at scale in enterprises for over a decade. If your organisation already has a Selenium Grid, a licensed browser matrix and a team of Java engineers, replacing it with a Node-based runner is a large cost for a benefit you may not need.

The trade-off is that WebDriver gives you almost nothing for free. There is no auto-waiting, so every interaction needs a considered explicit wait, and the difference between a good Selenium suite and a nightmare is entirely down to whether the team disciplined itself about that. Selenium 4 improved matters with relative locators and BiDi support, and the WebDriver BiDi standard is closing the gap on the bidirectional features that made Playwright feel modern. But out of the box, a naive Selenium test is far more likely to be flaky than a naive Playwright test.

When Selenium is wrong: a greenfield JavaScript or TypeScript project with no existing grid investment and no requirement for exotic browsers. You will write more code for less feedback. It is also the wrong choice if the team writing the tests are not primarily engineers, because the discipline it demands around waits and synchronisation is not optional.

What about the record-and-playback and low-code tools?

Codegen tools that watch you click and emit a test are useful for one thing: getting a first draft of a locator chain and a flow shape in front of an engineer. Playwright's codegen and Selenium IDE both do this well. What they produce is a starting point, not a test. The selectors are usually positional, there is no data strategy, and there are no meaningful assertions.

The commercial low-code platforms that promise self-healing locators solve a real pain and introduce a different one. When the tool silently repairs a selector because a button moved, you have lost the signal that the button moved. Sometimes that is exactly what you wanted. Sometimes the button moved because a developer broke the layout. We are not against these tools, but we will ask what happens to your suite when the subscription lapses, and whether your tests are portable out of the vendor's format.

The decision in one paragraph

New project, web only, JavaScript or TypeScript team, no existing investment: Playwright. Existing healthy Cypress suite with a team that likes it: keep it and fix the selectors instead. Large enterprise with an existing grid, Java or C# engineers, and a broad browser matrix: Selenium, done properly with explicit waits. Native mobile applications: not any of these, and see our mobile testing work. We will tell you if the answer is "keep what you have", which is more often than you would expect from anyone selling a rebuild.

Flaky Tests: Root Causes, Quarantine, and Why Retries Hide Bugs

Flakiness is the reason automated testing programmes fail. Not lack of coverage. A test that passes 92 percent of the time is worse than useless, because it teaches the team that red does not mean broken, and that lesson generalises to every other test in the suite.

The root causes, in the order we find them

Waiting on time instead of state. A hardcoded sleep of two seconds is a bet that the machine will never be slower than it was on the day someone wrote it. Under parallel load in CI, that bet loses. The fix is to wait for the condition you actually care about: the network request settling, the element becoming enabled, the spinner disappearing from the DOM.

Animations and transitions. A modal that fades in over 300 milliseconds is clickable at pixel coordinates that are still moving. The click lands on whatever is underneath. This class of flake is invisible locally because a human is slower than the animation and CI is not. Disabling CSS animations in the test environment removes an entire category of failure in one line.

Genuine race conditions in the product. The important one. A button rendered before its event handler is attached. A page that reads a value it just wrote before the write has propagated. A toast notification that appears over the element the next step needs to click. These are user-facing bugs. They fail your test at the rate they fail your customers, which is the whole point.

Shared state between tests. Test A creates a user, test B lists all users and asserts a count. They pass in sequence and fail in parallel, and the failure moves around depending on scheduling. This is the single largest cause of flakes we see once teams turn on parallel execution.

Time, timezone and locale. A test that creates something "due tomorrow" and asserts a formatted date will break at month end, on a leap day, or the first time the runner is in UTC and the developer is in IST. Freeze the clock or generate the expectation from the same source the application uses.

Third-party content. An analytics script, a chat widget, an embedded map, a payment iframe. Each is a network dependency you do not control that can be slow or down. In test environments most of these should be blocked at the network layer, and the one you genuinely need to test should be stubbed except in a small number of integration tests.

Resource contention. Eight parallel browser workers on a two-core CI runner is not a test suite, it is a load test with assertions. Half the "flaky test" reports we investigate resolve to a runner that is out of CPU or memory.

Why we do not fix flakes with retries

Retries are the standard response and they are mostly wrong. Consider what a retry does: a test fails, the runner runs it again, it passes, the build goes green, and nobody looks. If the cause was infrastructure noise, no harm done. If the cause was the third item on that list above, you have just used your test suite to hide a race condition from yourself, and the next report of it will come from a customer.

Our policy is one retry, with every retry recorded and reported as a distinct number. Flake rate becomes a metric on the dashboard next to pass rate. A test that needed a retry is not a passing test, it is a test with an open question against it. Teams that adopt this find real product bugs in the first month, reliably.

The quarantine policy we implement

Zero tolerance for flakes is a policy that survives about three weeks before someone starts skipping tests without telling anyone. What works is a structured quarantine.

Every test gets a rolling failure rate, measured by running the suite against unchanged code on a schedule. Anything over an agreed threshold moves to a quarantine lane. Quarantined tests still run and still report, so you keep the data, but they cannot block a merge. Each one gets a named owner and a date. If it is not fixed by that date, the test is deleted, along with the coverage it was pretending to provide. The quarantine list is reviewed weekly and its size is reported. If the list grows for three weeks running, that is escalated as a delivery problem rather than a testing problem, because it usually is one.

Test Data and Isolation

Selectors are the most common cause of test maintenance cost. Test data is the most common cause of flakes once selectors are fixed. The two together account for most of what makes automation feel expensive.

The shared fixture database problem

The usual starting point is a shared test environment with a snapshot of data loaded once, and tests written against known records. It works until two things happen: tests start mutating that data, and tests start running in parallel. Then test 14 cancels the order that test 31 was about to assert on, and the failure appears in a test that is entirely correct.

Restoring the database between tests is the obvious fix and it is far too slow to survive contact with a real suite. Restoring between runs leaves you unable to run two branches at once. Neither scales.

What we build instead

Each test creates the data it needs and owns it exclusively. Where the application has an API, setup happens through that API rather than by driving the browser, which is faster by an order of magnitude and removes the possibility of your login flow breaking every test in the suite. A factory layer generates records with sensible defaults so a test only specifies what matters to it, and identifiers are made unique per run so parallel workers cannot collide.

The strongest form of isolation, if your product supports it, is a fresh tenant or organisation per test. Multi-tenant SaaS products get this nearly for free and should use it. Where that is not possible, unique-per-run identifiers and a cleanup step get you most of the way.

Cleanup deserves a policy rather than a habit. We prefer cleanup at the start of a test over cleanup at the end, because a test that crashes never runs its teardown, and the residue accumulates until something breaks weeks later. A scheduled sweep of test-created records is a cheap safety net.

Stubbing and when it is dishonest

Network interception, through Playwright's routing or Cypress's intercept, is the right tool for third-party dependencies, error path testing and slow endpoints. Testing that your interface handles a 500 correctly is nearly impossible without it.

It also lets you write a test that passes against a backend contract that no longer exists. A stub is a copy of an agreement, and copies drift. Our rule is that stubs are for the paths you cannot otherwise reach, and that the contract itself is verified elsewhere by contract tests rather than assumed. If every one of your end-to-end tests runs against mocks, you have built a very elaborate front-end unit test suite and should be honest with yourself about that.

Production data is not test data

Worth saying plainly because it still happens. Copying production data into a test environment for realism moves real personal information into a system with weaker access control, generally without a lawful basis, and creates a problem under GDPR and comparable regimes that is much larger than the testing problem it solved. Use generated data, or a properly anonymised extract signed off by whoever owns data protection at your end. This is a point to check with your counsel rather than take from us.

Visual Regression Testing, and Where It Goes Wrong

Functional tests answer whether the button works. They do not answer whether the button is now white on white, or whether the footer has collapsed on top of the terms link. For products where the interface is the product, that gap matters.

Visual regression fills it by capturing screenshots and comparing them against approved baselines. Playwright has this built in through screenshot assertions with a configurable pixel difference tolerance. Percy, Applitools and Chromatic are the hosted options, with Chromatic being the natural fit if you already maintain a Storybook and Applitools differentiating on perceptual comparison rather than raw pixel diffing.

The failure mode nobody warns you about

Visual testing fails when it produces diffs nobody reads. Font rendering differs between macOS and Linux, so a baseline captured on a developer's laptop will fail on a CI runner every time. Anti-aliasing differs between GPU and headless rendering. Any dynamic content, a timestamp, an avatar, a chart with live data, produces a diff on every run.

Within a month of an undisciplined rollout, every build has fourteen visual diffs, someone is clicking approve-all as a formality, and the entire mechanism is now a checkbox that catches nothing.

How we make it useful

Baselines are captured in the same containerised environment CI uses, never locally. Dynamic regions are masked explicitly. Comparison runs against component states in isolation, which is far more stable than full-page shots of a page assembled from live data. Coverage is deliberately narrow: the design system components, the two or three highest-traffic pages, and the responsive breakpoints that actually matter to your traffic. Approval is a review step with a named person, not a bulk action.

If you do not have the discipline for the approval step, we will say so and recommend not adopting visual regression at all. A mechanism that is ignored is worse than an absent one, because it occupies the space where a working control should be.

When Not to Automate a Test

A test automation supplier telling you to automate less is unusual, so here is the reasoning. Every automated test is an asset with a maintenance liability attached. If the liability exceeds the value, the test is a net loss even though it passes.

Do not automate a flow that is about to change

If the checkout is being redesigned next quarter, automating the current one buys you a few weeks of regression safety and a rewrite. Test it manually until the design settles. The exception is when the redesign is exactly the risk, in which case a small set of tests written against roles and visible labels rather than markup will survive it.

Do not automate what a person judges better

Whether the layout looks right on an ultrawide monitor. Whether the error message makes sense. Whether the onboarding flow feels confusing. Whether a chart is legible. Machines check equality. People notice wrongness. Visual regression catches unintended change, which is not the same as catching bad design.

Do not automate the once-a-year path

A test for the annual data export that runs on every commit for twelve months costs more in maintenance and CI minutes than the twenty minutes a person would spend testing it before the export. Scripted manual testing is a legitimate answer for genuinely rare flows.

Do not automate against an interface with no stable hooks and no willingness to add them

If you are automating a third-party portal that changes without notice and offers no test identifiers, expect a high ongoing maintenance cost and decide up front whether it is worth paying. Sometimes it is, because the flow is critical. Often it is not, and monitoring the outcome in production is cheaper than testing the path.

Do not automate to hit a coverage number

Coverage targets imposed from above produce tests written to touch lines rather than to detect defects, and those tests still cost maintenance forever. We would rather report that sixty flows are covered and name them than report a percentage that means nothing to anybody.

Three Situations We Get Called Into

None of these map to one client. Each is built from the failure mode as it actually shows up, stripped of anything that would identify who it happened to.

The suite nobody trusts

A B2B platform with around three hundred Cypress tests, a pipeline sitting near thirty five minutes, and a merge culture where clicking rerun twice was normal. The team's request was more coverage on a new module. Measurement told a different story: a large share of tests failed at least once across repeated runs of unchanged code, and the great majority of those traced to two causes, positional CSS selectors from a rushed redesign fix and shared seeded data being mutated by parallel workers.

The work was not new tests. It was rewriting locators onto roles and test identifiers, moving setup from the browser to the API so each test owned its data, deleting the tests that duplicated other tests, and moving form validation checks down to component level. The suite ends up smaller, the pipeline ends up faster, and the important change is behavioural: red starts meaning something again, so people start reading it.

The team with no automation and a compliance deadline

A healthcare-adjacent product where an audit required evidence that critical workflows were verified before each release, and where all regression testing was a spreadsheet worked through by two people over three days. Not a technology problem so much as an evidence problem.

Here the build starts from the audit requirement backwards. Identify the workflows the auditor cares about, automate exactly those first in Playwright, and make the reporting output something a non-engineer can read as evidence: which workflow, which build, when, pass or fail, with a trace attached. The three day manual cycle compresses to a pipeline run, and the two testers move to exploratory work on the areas the script never covered. What we do not do is make claims about your compliance posture. We build the mechanism; your compliance function decides whether it satisfies the standard.

The migration nobody has time for

A retail front end on an ageing Selenium suite in Java, maintained by one engineer who had left, with tests failing on Chrome updates and nobody able to fix the grid. The internal debate had been running for a year: rewrite in Playwright, or repair what exists.

The answer was neither, initially. First we made the existing suite explicable: catalogue what each test covers, run the grid in containers so browser versions are pinned rather than floating, and get to a known state. Only then does the rewrite question become answerable, and it is answered per flow rather than as a single decision. High-value flows get rewritten in Playwright with proper locators. Low-value ones get deleted rather than migrated, which is the cheapest migration available. Running two frameworks side by side for a period is normal and is much safer than a big-bang cutover that leaves you with no working tests for six weeks.

What Goes Wrong, and How We Handle It

The environment is the real blocker

The most common reason an automation engagement stalls is not testing at all. It is that there is no stable environment to test against: the shared staging box is broken three days a week, the database has drifted from production, or a dependency is only available from your office network. We check this in week one and say so early, because no amount of test writing fixes it and it usually needs your team, not ours.

Access and onboarding take longer than anyone plans

VPN, source control, CI, the test environment, any device or browser cloud, the issue tracker. On engagements with security review this can take a fortnight, and it is dead time if it starts on day one instead of before. We ask for the access list to be started before the engagement begins, and we work from a documented list rather than requesting things one at a time as we discover we need them.

Nobody owns the flake list

A suite decays without a named owner for triage. When that role is unassigned, the quarantine list grows, the retry count creeps up, and within a quarter you are back to where you started. We insist on the role being named, on our side or yours, and we report the flake rate weekly whether or not anyone asks.

The tests find real bugs and nobody wants them

This happens more than you would think. A new suite surfaces genuine defects in flows that have been broken quietly for months, and now there is a backlog nobody budgeted for. Worth anticipating at the start, because the pressure to soften the tests instead of fixing the product is real and it arrives around week four.

Security, access and IP

Work happens on managed machines with disk encryption and controlled access, over your VPN where you require one, with credentials held in your secret manager rather than in test files or a spreadsheet. Test accounts are scoped and separate from production. Ownership of the code and test assets, confidentiality, and any data processing arrangements are settled in the agreement before work starts rather than described on a web page, so ask for those terms early and read them. If your context brings HIPAA, GDPR or a sector regulator into scope, that is a conversation for your counsel and ours before scope is agreed.

Continuity

Loss of the one person who understands the framework is a genuine risk in every automation engagement, and it is the reason so many suites are abandoned. We mitigate it with conventions written down rather than held in someone's head, at least two engineers familiar with any suite, and documentation treated as a deliverable rather than an afterthought. The handover and continuity terms themselves are agreed in the contract before work begins.

Where This Sits Alongside Our Other Work

Functional UI automation is one layer. Load and stress behaviour, contract verification between services, security testing and accessibility conformance are separate disciplines and we scope them separately rather than folding them into a browser suite where they do not belong.

The suite is only as useful as the pipeline it runs in, so this work usually runs alongside CI/CD pipeline engineering, and it overlaps with the broader QA and testing practice where manual and exploratory work sits. Where you need testers embedded in your team rather than a project, you can hire QA testers directly, and for device-level work our mobile testers cover the native side. If the automation gap is really a shortage of engineers who can write typed test code well, teams often start by choosing to hire TypeScript developers in India and grow the capability internally.