I’m Ujjwal Rupakheti, a full-stack developer in Itahari, Nepal. My regression testing services give your web app an automated Playwright suite that runs before every release, so a change to one feature cannot quietly break sign-in, checkout or anything else that already worked.
01Overview
Regression testing means re-running checks on features that already worked, after every change, to prove they still work. A regression is a bug in old behaviour caused by new code. Automating those checks turns a slow manual chore into a suite that runs in minutes before each release.
Most regressions are not dramatic. A CSS change hides the pay button on small phones. A new field makes an old form fail validation. A library update changes how dates are parsed. Each one is easy to fix once you know, and expensive to discover from an angry customer.
A regression suite is a list of the behaviours you cannot afford to lose, written as tests a computer runs for you. It turns “I think nothing broke” into a green tick you can trust, and it lets your developers change code with confidence instead of fear.
This page is about building and running that safety net for products that are already live. If you need a one-off bug hunt before a launch, my QA testing service is the better fit. If I am building the product for you, the suite can be part of the build from the first release, as on my SaaS projects and management systems.
If two or more of these are true, a suite will pay for itself.
02Comparison
QA testing is a person exploring the product to find new bugs, usually before a launch. Regression testing is an automated suite that checks known behaviour again and again, usually before every release. New products need QA first. Products that release often need regression tests to stay stable.
| Regression testing | QA testing | |
|---|---|---|
| When it runs | Before every release, automatically | Before a launch or a big feature |
| Who runs it | Your CI pipeline, in minutes | A tester, by hand |
| What it finds | Old features broken by new code | New bugs, confusing screens, edge cases |
| What you keep | A test suite in your repository | A bug report |
| Best for | Live products with regular releases | New products and one-off checks |
03What is tested
A good suite tests the few flows that would hurt most if they broke, at three levels: browser tests for user journeys, API tests for the contracts your front end and partners rely on, and small unit tests for rules such as prices and dates. Testing everything is not the goal.
01
Playwright drives a real browser through sign-up, login, checkout or booking and checks what the user sees at each step, at phone and desktop widths. These catch the regressions customers notice first.
02
Each important endpoint is called with good and bad input, and the status codes, response shape and error messages are checked. Useful when a mobile app or a partner depends on your API.
03
Fast tests for prices, VAT, discounts, points and Bikram Sambat date conversion, where one wrong digit matters. For a deeper review of those rules, see logic verification.
Screenshot comparisons for key pages, so a stray CSS change that moves or hides the pay button is flagged before release.
Scripts that create the same users, products and orders on every run, so a test fails because of the code and not because yesterday’s data changed. It starts with good database design.
Retries are limited, and every flaky test is fixed or quarantined with a note. A suite people learn to ignore protects nothing.
04Proof
On Jhino, my app publishing SaaS, Playwright tests run in Chromium, Firefox and WebKit. GitHub Actions runs type checks, the build and the Chromium tests on every push, and the full three-browser run every week. I set up the same pattern for clients, sized to how often they release.
Running every browser on every push is slow and rarely needed. A quick Chromium run catches most regressions while the change is still fresh in the developer’s head.
The weekly run in Firefox and WebKit catches engine-specific problems, such as a layout or date input that only breaks in Safari on an iPhone.
In Eknas, a bill retried with the same Idempotency-Key must return the original result with duplicate: true. A rule like that deserves a test, so a later refactor cannot start doubling points.
05Process
I rank your flows by risk, automate the top ones first, wire them into your CI, and hand over a suite your own developers can extend. Most of the value comes from the first few tests, so you see results early instead of waiting for full coverage.
List the flows and rules that would cost money or trust if they broke, and rank them.
Automate the top flows in Playwright with stable selectors and seeded test data.
A GitHub Actions workflow on pull requests and before deploys, with reports and traces for failures.
Add API and business-rule tests, then the remaining flows in order of risk.
A short guide to running, reading and adding tests, so your developers own the suite.
06Deliverables
A test suite in your own repository, a CI workflow that runs it, and a short guide to adding tests. I work best with JavaScript and TypeScript stacks such as Next.js, React and Node with Express or Fastify, and with Python back ends on FastAPI or Flask.
Yours to keep and extend, whoever maintains it later.
Tests run against a staging copy of your app, never against live customer data. If your app takes eSewa, Khalti or Fonepay payments, tests use sandbox credentials where the provider offers them, or a mocked response, so no real money moves.
07Pricing
Regression testing is quoted per project. Setting up the first suite is a one-time job priced by the number of flows and environments, and keeping it current can be a small monthly retainer. You get a fixed quote after I see the app and how you release.
If I am building your product, the suite can be part of the build from day one. A SaaS product’s first version starts from NPR 70,000, and every starting price is in the pricing table on my services page.
International clients are invoiced in USD by bank transfer, Wise or PayPal, and I am happy to sign an NDA before you share access. I work from Itahari on Nepal time (UTC+5:45), which gives a useful overlap with Europe, the Gulf and Australia.
Want the software and the tests from one person?I build custom business software and SaaS products with a regression suite from the first release, so stability is part of the build.
Software developmentExamples, tools, timelines and test data, answered before you ask.
Ask me on WhatsAppYou add a discount code field to checkout. A regression test then re-runs the existing checkout tests: add to cart, pay, see the confirmation. If the new field broke the old flow, for example by blocking the pay button on small screens, the test fails before the release goes live.
For anything you release more than once a month, yes. Manual regression rounds get slower and less careful with every release. Automate the stable, high-risk flows, and keep manual exploratory testing for new features and visual polish. A small suite that runs every time beats a long checklist nobody finishes.
For web apps I use Playwright. It drives Chromium, Firefox and WebKit from one test file, waits for pages properly and records traces that show exactly where a test failed. Cypress and Selenium are also common. The best tool is the one your developers will keep running.
It depends on the number of flows and how testable the app is. I automate the highest-risk flows first, so the first tests run in your CI early in the engagement, and coverage then grows in order of risk. The timeline is agreed in the quote.
Yes, that is the most common case. I start with end-to-end tests, because they need no changes to your code, then add API and unit tests where the code allows. Where a flow is hard to test, I suggest small changes such as stable test IDs on buttons.
No. Tests run against a staging or local copy with seeded test data. Payments use sandbox credentials where the provider offers them, or mocked responses, so no real orders, messages or money are created. Test accounts and seed data are kept apart from real customer records.
If you want. Many businesses hand the suite to their own developers using the guide I provide. Others keep me on to update tests when features change and to fix flaky tests, quoted as a monthly retainer. Either way, the tests live in your repository and belong to you.
Any web app Playwright can open in a browser, which is nearly all of them. For API and unit tests I work best with JavaScript and TypeScript on Next.js, React, Express or Fastify, and with Python on FastAPI or Flask, on PostgreSQL, MySQL or SQLite.
Usually not. A five-page website that rarely changes is better served by a one-off QA test round at launch. Regression testing pays off when an app has logins, payments or bookings and changes every few weeks. If your website later adds logins or payments, the suite can be added then.
Yes. I work remotely from Itahari on Nepal time (UTC+5:45), invoice international clients in USD by bank transfer, Wise or PayPal, and sign an NDA on request before you share repository or staging access. The suite runs on GitHub’s servers, so time zones never hold up a release.
Tell me your stack, how often you release and what broke last time. I reply within one working day with questions or a quote.
Ujjwal RupakhetiReplies within one working day
What do you need tested?
Opens WhatsApp with your message started.
