QA and Software Testing in India (2026): What to Test and What to Automate

Most testing conversations start in the wrong place: how much to automate, which framework, what coverage percentage to target. Those are downstream questions. The upstream one is what failures would actually hurt the business, because that determines where testing effort belongs.

This guide covers how to decide what to test, what genuinely benefits from automation, and why test suites so often become a cost rather than a safety net.

Start From Consequences, Not Coverage

List the things that must not break: a customer cannot complete a purchase, a payment is taken twice, one tenant sees another's data, a report used for a financial decision is wrong, login stops working. These carry real commercial or legal consequence.

Then list what would be embarrassing but survivable: a misaligned layout, a slow page, a cosmetic bug on a rarely used screen.

Testing effort should be distributed according to that list, not spread evenly across the codebase. Teams that chase a uniform coverage figure routinely end up with thorough tests of trivial code and thin tests of the checkout.

What Automation Is Actually Good At

• Regression. Confirming that what worked yesterday still works. This is the strongest case for automation and the reason to have a suite at all.
• Critical journeys. Sign up, log in, search, add to cart, pay. Small in number, high in consequence, run on every change.
• API contracts. Fast, stable, and they catch breakage before it reaches a user interface.
• Data validation. Calculations, transformations and business rules where correctness is objectively checkable.
• Cross-device and cross-browser checks where the matrix is too large to cover by hand - particularly relevant for the range of Android devices in the Indian market.

What Should Stay Manual

• Exploratory testing. A skilled tester deliberately trying to break things finds defect classes no scripted test anticipates. This remains the highest-value manual activity by a distance.
• Usability. Whether something is confusing is a judgement, not an assertion.
• Visual review. Automated visual comparison catches pixel changes but cannot tell you the design is wrong.
• Anything changing rapidly. Automating a screen still in flux costs more in maintenance than it returns.
• First release of anything. Test manually until the behaviour settles, then automate the paths worth protecting.

Why Suites Turn Into Maintenance Burdens

The common failure is tests written against implementation rather than behaviour. A test that asserts a particular function was called with particular arguments breaks whenever the code is restructured, even though the behaviour is unchanged. Enough of those and every refactor triggers a day of test repair, so the team stops refactoring - which is the opposite of what tests are for.

The second failure is flakiness. A test that fails intermittently for timing or environment reasons trains everyone to re-run rather than investigate. Once failures are routinely ignored, the suite provides no information at all while still consuming build time.

The discipline that prevents both: assert on observable behaviour rather than internals, and treat a flaky test as a defect to be fixed or deleted the week it appears. A smaller reliable suite is worth considerably more than a large unreliable one.

Getting QA Involved Early

The cheapest defect is one that never gets built. A tester reading a specification asks what happens when the field is empty, when the payment is declined, when the same request arrives twice, when the user's session expires mid-flow. Those questions cost minutes at requirements stage and days after release.

This is why QA-at-the-end is poor value. It can report defects but cannot prevent the design decisions that produced them, and by then the cost of changing course is highest.

Performance and Security Testing

Both are frequently deferred until something goes wrong. Performance testing under realistic load - realistic being the traffic you expect during a campaign, not the average - reveals problems that only appear under concurrency. Security testing should at minimum cover authentication and authorisation boundaries, input handling, and whether one user can reach another's data by changing an identifier in a request.

For applications handling personal data, this is not optional diligence. See application security services and data protection and compliance.

What Good Looks Like

A healthy testing setup is recognisable: the suite runs automatically on every change and finishes fast enough that people wait for it; failures are investigated rather than re-run; every fixed bug gained a test preventing its return; critical journeys are covered end to end; and testers are involved before code is written rather than after.

None of that requires an elaborate framework. It requires deciding what matters and being disciplined about the rest.

Building a Test Approach From Nothing

If a team currently has no automated testing, the instinct to start by writing tests everywhere is a reliable way to produce a slow, brittle suite nobody trusts. A more effective sequence:

1. Write a test for the next bug you fix. Every defect that reaches production is evidence of an untested path, and the test is cheap to write while the cause is fresh.
2. Automate the three journeys that must never break. Not thirty - three. Run them on every change.
3. Add tests around code you are about to change. This gives immediate value by making the change safer, rather than testing code nobody is touching.
4. Cover business logic where correctness is checkable - pricing, tax, eligibility, calculations.
5. Only then think about coverage figures, and treat them as diagnostic rather than as a target.

This produces a small suite that earns trust, which matters more than size. A suite people believe gets acted on; one they do not gets skipped.

Testing in the Indian Device Landscape

For consumer-facing products in India, device and network diversity is a genuine test dimension rather than an afterthought. A large share of users are on mid-range Android hardware over connections that vary through the day, and behaviour on that hardware differs materially from a developer's machine.

Practical measures: maintain a small set of real devices representing what your analytics say users actually hold, rather than the newest flagship; test on throttled connections deliberately; check behaviour when connectivity drops mid-transaction, because it will; and verify text rendering if your interface supports Indian language scripts, where font fallback and line breaking behave differently.

Where Testing Effort Pays Back Most

If budget is limited, three areas return more than anything else. First, the payment and checkout path, because failures there are immediate lost revenue and are often invisible until a customer complains. Second, authorisation boundaries - whether a user can reach data belonging to someone else by altering a request. This is the defect class that becomes a disclosure incident rather than a bug report. Third, anything involving money arithmetic: pricing, discounts, tax, refunds and reconciliation, where a small error repeated across thousands of transactions becomes a serious problem quietly.

Everything else can usually wait. Layout issues get reported by users and fixed cheaply; a rounding error in tax calculation does not get reported and compounds.

What to Ask a Testing Partner

• "How would you decide what to automate first on our product?" A good answer starts with our risk, not with their framework.
• "What do you do when a test fails intermittently?" The answer should involve fixing or removing it, not re-running.
• "How do you test things that need judgement?" If everything in the answer is automated, exploratory testing is missing.
• "What would you need from our team to be effective?" Testing in isolation from product context finds shallow defects.
• "How will we know the testing is working?" Defects escaping to production is the honest measure, not tests written.

Frequently Asked Questions

What should be automated and what should stay manual?

Automate what is repetitive, stable and objectively verifiable - regression paths, critical user journeys, API contracts, data validation. Keep manual what needs judgement: exploratory testing, usability, visual design review, and anything changing so fast that maintaining the test costs more than running it by hand.

How much test coverage is enough?

Coverage percentage is a poor target on its own - it is easy to reach a high number while testing nothing that matters. A better standard is that every critical user journey has an automated test, every fixed bug has a test preventing its return, and the core business logic is well covered. Uniform coverage across an entire codebase is rarely worth the cost.

When should QA get involved in a project?

At requirements, not after development. A tester reading a specification finds ambiguities and missing edge cases while they are cheap to resolve. QA arriving only at the end can report defects but cannot prevent the design decisions that caused them.

Why do automated test suites become a burden?

Because they are written to mirror implementation rather than behaviour, so every refactor breaks tests that were not testing anything meaningful. Add flaky tests that fail intermittently, and teams start ignoring failures - at which point the suite costs time and provides no confidence.

Where Brainguru Can Help

See QA and testing services for the overall practice, with automation testing, functional testing, mobile app testing and usability testing covering specific needs. For engineering practice more broadly see quality engineering, or get in touch on +91-8010010000.