Test every release before your customers do

Software testing checks that your app does what it should, on the devices people use, before customers rely on it. QA, quality assurance, is the wider habit of making bugs rarer: clear requirements, written test plans, code reviews and automatic checks on every change.

Both serve one goal: your customers should not be the people who find your bugs. A bug found in testing is one more task for a developer. The same bug found by a customer costs a refund, a support call, a bad review and sometimes the customer.

Our job is to find problems early and to give a plain answer to the question every release raises: is this ready to go out? When the answer is no, we say exactly why and what needs fixing.

Testing pays off first where a mistake costs money or trust. Payments, invoices and refunds; sign-up and login; the one or two journeys most customers take; calculations such as prices, taxes and payroll; and the integrations with outside services all come before cosmetic screens.

We also look at your history. Past bugs, support tickets and app reviews show where your software breaks most often, and those areas get tests first. A feature that broke twice will probably break again.

This risk-based order means you get value from the first test round, rather than waiting for complete cover of a product that keeps changing.

A good test plan reads like a list of things your customers do. For a store: find a product, add it to the cart, apply a coupon, pay by UPI, receive the GST invoice, return an item. For a clinic: book a slot, move it, get a reminder, join a video visit.

Each journey then gets its awkward cases, because that is where bugs live: cancelling halfway, pressing back, paying twice by accident, opening the app in two tabs, losing signal in a lift, a name with an apostrophe, a pin code the courier doesn’t serve, a date that crosses midnight or a time zone.

We write the plan with your team, so it reflects the rules only your staff know, and keep it in your own tools so it grows with the product.

The same checks are needed before every release, and people skip them when time is short. Automated tests don’t. We turn the checks that repeat into tests that run on every change in your build pipeline on GitLab or GitHub.

There are layers. Small unit tests check calculations and rules in the code. API tests check that each part of the system answers correctly, including when it should refuse. End-to-end tests, written with tools such as Playwright, Cypress or Flutter’s own testing, drive the app the way a customer would.

Automated tests must be trustworthy. A test that fails at random teaches the team to ignore failures, so we fix or remove unreliable tests quickly. What can’t be automated well, such as new features, design and the unexpected things real people do, stays with people.

Your customers don’t all use the latest iPhone on office Wi-Fi. We test on the devices your analytics show, which in India usually means a range of mid-range Android phones, and abroad a larger share of iPhones and Safari.

We test small and large screens, larger text settings, dark mode, slow 3G and patchy 4G, and what happens when the connection drops in the middle of a payment or a form. For apps that must work offline, such as a check-in app at a busy venue, we switch the network off on purpose.

Real devices catch problems that simulators miss, such as the keyboard hiding a button or a camera that won’t focus on a QR code. We test on real phones alongside a device cloud such as BrowserStack.

Anything that touches money is tested case by case. For payments, that means more than a successful card: UPI payments that stay pending, payments that succeed after a timeout, failed cards, refunds, partial refunds and a customer who taps Pay twice. All of it runs in the gateway’s test mode, so no real money moves.

Calculations are checked against figures your team trusts: prices with discounts and rounding, GST on mixed baskets, e-invoices and e-way bills, payroll with PF, ESI and professional tax, and prices in several currencies.

When a new system replaces an old one, the strongest test is to run both side by side. For a support company in Pune and Ahmedabad, payroll ran on the old spreadsheets and the new portal for a full cycle, compared line by line until every payslip matched.

Most apps fail under pressure on the one day that matters most: a festival sale, results day, the start of admissions or the first hour of an event. We rehearse that rush before it happens.

Load tests with tools such as k6 send realistic traffic to a test copy of your system and show what slows down first: a database query, a search, a payment callback or a server that runs out of memory. Your developers fix the first bottleneck, and we test again.

Some rehearsals need people as well as tools. Before a conference organiser in Utrecht ran its first event on the ticketing platform we built, we rehearsed doors opening in full, with staff, badge printers and a crowd of test tickets, and the venue’s Wi-Fi switched off.

A good bug report saves more time than any tool. Ours go straight into your tracker, such as Jira, GitLab or GitHub, with the steps to repeat the bug, what should have happened and what did, screenshots or a short screen recording, the device and app version, and any error from the logs.

Each bug is rated by its effect on customers, so your developers fix what matters first. Once a fix arrives, we retest it, check nothing nearby broke and, where it makes sense, add an automatic test so the same bug can’t return unnoticed.

Every release ends with a clear go or no-go. You see what was tested, what passed, what failed and which known issues remain, so the decision is yours and based on facts.

Larger changes can go out in stages: a pilot group first, a phased release in the app stores, or a feature switched on for some customers before everyone. After release, we run a short check on the live app and watch its error reports in tools such as Sentry.

Every bug that slips through becomes a lesson: we ask why testing missed it and add the test that would have caught it.

We can be the testing team beside your own developers, test the work of another company, or test software our own team builds. In each case testing works best when it starts early: we read new requirements and ask how each one will be tested before code is written.

That changes how work is written. Each new feature gets a few checks in plain words, such as “a customer whose card is declined sees why and can pay another way”, so developers know when it is done and testers know what to check. Small releases, code reviews and a test copy that matches the live system make every later step easier.

Each month you get a short report: what was tested, how many bugs were found before release and how many after, and where they cluster. Over time the number found by customers should fall, and the report shows whether it does.