Core User Flows
Sign-up, login, password reset, search, booking, checkout and anything else a customer must finish. I test the happy path and the ways people leave it: the back button, double taps, and refreshing in the middle of a payment.
I’m Ujjwal Rupakheti, a full-stack developer in Itahari, Nepal. My QA testing services cover websites, web apps and SaaS products: manual testing of real user flows, Playwright tests in three browser engines, and bug reports with exact steps your developer can reproduce.
01Overview
QA testing services check that your website or app does what it should before real users find out it does not. I test the flows that earn or lose you money, such as sign-up, checkout, booking and payment, and give you a list of bugs with exact steps to reproduce each one.
QA stands for quality assurance. For most small businesses and startups in Nepal it means one person who did not write the code using the product the way customers will, on the devices customers own, and writing down everything that breaks or confuses.
QA bug testing was my role at Ektukra Digital Agency before I became a full-stack web developer there, and I test my own products, from Nimtto to Eknas, the same way before they ship. Because I also build websites and SaaS products, my reports point to the likely cause of a bug, not only the symptom, so your developer spends less time guessing.
This page is about finding bugs in a test round, usually before a launch. If you release often and need tests that run on every release, see my regression testing service. If the risk is in a calculation, a limit or a permission, a logic review goes deeper.
Businesses that ship software without a dedicated tester.
02Scope
The parts of your product that matter most to users: core flows, forms and validation, sign-in and permissions, payments, browsers and devices, and basic accessibility and speed. We agree the list before I start, so you know exactly what was tested and what was not.
Sign-up, login, password reset, search, booking, checkout and anything else a customer must finish. I test the happy path and the ways people leave it: the back button, double taps, and refreshing in the middle of a payment.
Empty fields, very long names, Nepali Unicode text, phone numbers with and without +977, and Bikram Sambat dates where your app uses them. Every error message should tell people what to fix.
eSewa, Khalti and Fonepay flows, failed and cancelled payments, and what the user sees afterwards. A failed payment must never show as paid, and a retry must never charge twice.
What a customer, a staff member and an admin can see and change. I try the URLs and API calls a user should not reach, because hiding a button is not the same as blocking the action. The same rule applies to the APIs behind your screens.
Chromium, Firefox and WebKit, the engine behind Safari, at phone, tablet and desktop widths. Many people in Nepal browse on low-cost Android phones over mobile data, so I test on throttled connections too.
Keyboard use, focus order, form labels, colour contrast and page weight. For a full review of usability, accessibility and conversion, book a separate UI/UX audit.
03Proof
I hold my own software to the standard I offer clients. Jhino, my HTML app publishing SaaS, has a Playwright suite that runs in Chromium, Firefox and WebKit. GitHub Actions runs type checks, the build and the Chromium tests on every push, and all three engines every week.
A layout that works in Chrome can still break in Safari on an iPhone. Running the same tests in WebKit and Firefox catches those differences before users report them.
In Jhino, two people can save the same app at the same moment. The server refuses the older write and merges both changes. That is the kind of behaviour worth testing.
QA testing is part of my work at Ektukra Digital Agency, which runs every day on Eutaa, the HR, payroll and finance system I built. Real daily users find the bugs that matter.
Process
Five steps: agree the scope, write test cases, run the round, report bugs by severity, then retest the fixes. You see the test plan before I start and the results as I go, so nothing is a surprise at the end.
We list the flows, roles, browsers and devices to test, and agree what a finished round looks like.
Short test cases for each flow, including edge cases, shared with you before testing starts.
Every case run on staging or production, each bug logged with steps, expected and actual result, and a screenshot or video.
Bugs ranked critical, major or minor in GitHub Issues, Jira, Trello or a shared sheet.
After the fixes, I retest each bug and check the fix did not break anything nearby.
04Deliverables
A written test plan, a bug report with every issue ranked by severity, short screen recordings for anything hard to describe, and a retest of every fix. If you choose automation, you also get Playwright test files in your own repository.
Written so your developer or agency can act on it without a meeting.
| Severity | What it means | Example |
|---|---|---|
| Critical | A core flow is blocked, or money or data is at risk. Fix before launch. | A retried payment charges the customer twice |
| Major | A feature works wrongly, but there is a workaround. Fix soon. | The booking date picker ignores Bikram Sambat input |
| Minor | A visual or wording problem that does not stop anyone. Fix when convenient. | An error message is cut off on small screens |
05Choosing
QA testing suits a launch or a product with bugs you cannot pin down. The table shows when one of my other testing or audit services fits better, so you only pay for the check you need.
| Service | Best when | Main output |
|---|---|---|
| QA testing (this page) | You are about to launch, or users report bugs you cannot reproduce | A bug report from a full test round |
| Regression testing | You release often and old features keep breaking | An automated test suite in your CI |
| Logic verification | Money, points, dates or permissions must be exactly right | A code review with failing cases and fixes |
| UI/UX audit | People visit but do not sign up, enquire or buy | Prioritised usability, accessibility and conversion fixes |
06Pricing
QA testing is quoted per project, because a five-page website and a SaaS app with three user roles need very different amounts of testing. You get a fixed quote before I start, in NPR or USD.
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). Starting prices for websites, web apps and SEO audits are in the pricing table on my services page.
Need the product built as well as tested?I build business software, SaaS products and websites with tests from the first release, so QA is part of the build rather than an afterthought.
Software developmentManual or automated, tools, mobile, payments and price, answered before you ask.
Ask me on WhatsAppSoftware testing is the act of running a product to find defects. QA, or quality assurance, is the wider habit of preventing them with clear requirements, test plans, reviews and retests. Small businesses often use the two terms for the same thing, and my service covers both the testing and the process around it.
Both. I start with manual exploratory testing, because a person notices confusing screens and odd edge cases that scripts miss. For flows that must keep working after every release, I write automated Playwright tests that run in Chromium, Firefox and WebKit through GitHub Actions.
Playwright for automated browser tests, GitHub Actions to run them on every push, browser developer tools for network and console errors, and Lighthouse for speed and basic accessibility. Bugs go into your tracker, such as GitHub Issues or Jira, or into a shared sheet if you prefer.
Yes. I need a link, a test account for each user role and a short list of what the site should do. Code access helps with deeper checks but is not required. The report is written so your developer or agency can act on it without a meeting.
My focus is the web: websites, web apps and progressive web apps, tested in mobile browsers at phone sizes and on slow connections. If your product is a native Android or iOS app, tell me what it is built with and I will tell you honestly whether I am the right fit.
Yes. I test successful, failed and cancelled payments and what the customer sees after each one. Where the provider offers sandbox credentials I use them, so no real money moves. A failed payment must never show as paid, and a retry must never charge twice.
A link to the site or staging app, a test account for each role, the flows that matter most and your release date. Read-only code access is optional but helps me point to the cause of a bug. I am happy to sign an NDA first.
It depends on the number of flows, roles, browsers and devices. A small website is a short job, and a SaaS app with several roles takes longer. The timeline is fixed in the quote, and you see results as I go rather than all at the end.
QA testing is quoted per project, based on the number of flows, user roles, browsers and devices, and whether you want automated tests. You get a fixed quote before work starts. Starting prices for my other services are in the services pricing table.
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 staging access or code. Reports are written in clear English, so any developer can act on them.
Tell me what your product does, which flows matter most and when you plan to release. 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.