Software testing that catches it before your users do
Automated test suites for web applications — end-to-end, API, regression and cross-browser — written into your repository and wired into your pipeline, so a broken build stops at the merge instead of at your customer. On software I built, or on software someone else wrote. Delivered remotely to teams in India, the US, the UK, the Gulf, Europe and Australia.
What actually gets tested
Six areas, in the order they tend to break.
End-to-end user journeys
The paths that cost money when they break: sign-up, checkout, payment callback, file upload, password reset. Driven in a real browser with Playwright, so the test fails for the same reason a user would.
Regression packs
Every bug that gets fixed earns a test that reproduces it first. The pack grows with the product, and the same defect cannot ship twice - which is what most teams are actually paying for.
API and contract tests
Status codes, payload shape, auth boundaries, rate limits and the error paths nobody exercises by hand. Run against a live environment, so a backend change that breaks the client is caught before the client does.
Cross-browser and device
Chromium, Firefox and WebKit, plus mobile viewports. Safari is where most India-built sites break first, because it is the browser least likely to be on the developer's machine.
Performance and Core Web Vitals
Lighthouse and real-load measurement of LCP, INP and CLS on the pages that receive traffic. Reported with the specific asset or query responsible, not a score out of a hundred.
Accessibility and form validation
Keyboard navigation, focus order, labels, contrast and screen-reader output, checked with axe. Forms get the hostile input too: empty, oversized, duplicated and injected.
Four steps, and you can stop after the first
Audit
A read of the codebase and a pass over the running application. You get a written list of what is untested, what is fragile and what is already broken - with reproduction steps. This stands alone: plenty of clients stop here.
Write the suite
Tests against the critical paths first, in priority order agreed from the audit. Written in your repository, in your stack's own tooling, so they are yours and not locked to me.
Wire it to CI
The suite runs on every pull request and blocks a merge that breaks it. A test suite nobody runs is documentation; a test suite in the pipeline is a gate.
Hand over
A short written guide on running, reading and extending the tests, plus a walkthrough call. Your developers should be able to add the next test without me.
What this is not
Testing is a wide field and one engineer does not cover all of it. These are outside the service, and saying so now is cheaper for both of us than discovering it halfway through:
- Penetration testing or security certification - that needs a licensed specialist
- Native iOS and Android app testing - web and hybrid only
- Load testing above roughly 10,000 concurrent users
- Manual test-case execution by a team of testers - this is automation-first
Questions about testing
The ones that decide whether an engagement makes sense.
Yes, and it is a large part of the work. The usual case is a product built by an agency or an in-house team that now has no test coverage and is afraid to deploy. I start with a written audit of the existing application, then write the suite against the paths that matter most. No access to the original developers is needed - only the repository and a staging environment.
The audit is a fixed fee and delivers a written report you keep regardless of what happens next. A test suite for a typical business application - roughly 20 to 40 end-to-end tests plus API coverage, wired into CI - is quoted per project after the audit, because the honest price depends on how the application is built. Ongoing maintenance of the suite is available as a monthly retainer.
Playwright for end-to-end and cross-browser work, Vitest or Jest for unit and integration tests, and axe for accessibility. GitHub Actions for the pipeline in most cases. These are the tools your team is most likely to already know, which matters more than picking the newest one - a suite in an unfamiliar framework gets abandoned.
The audit is typically three to five working days. A first test suite covering the critical paths is usually two to three weeks after that, delivered incrementally so tests start running in CI before the whole suite is finished.
Yes. The work is remote and asynchronous by default: the deliverables are commits, a pipeline and written reports, none of which need a shared working day. I am in India (IST, UTC+5:30) and hold overlap hours in the morning for clients in the US and in the evening for the UK, Europe, the Gulf and Australia.
Yes, and on projects I build the tests are written alongside the code rather than bolted on afterwards. For testing-only engagements it is worth knowing that a developer who also wrote the code has a blind spot - if the application is already live and critical, a second pair of eyes on top of your own team's tests is the stronger arrangement.
Not sure what your coverage looks like?
Send the repository or a link to the running application. The audit comes back as a written list of what is untested and what is already broken — and it is useful to you whether or not the rest of the work happens.