Manual Testing and QA in the UK
We are an Indian engineering team working with businesses in the UK. Written scope before any code, and a fixed quote in GBP.
Working hours
Our day runs 09:00 to 18:00 India time, which is 03:30 to 12:30 in the UK, or 04:30 to 13:30 while you are on summer time, so most of your morning overlaps with ours.
Quoted in GBP
Quotes exclude the 20% VAT in the UK, shown separately on the invoice.
Data protection
Work for this market is scoped against the UK GDPR and the Data Protection Act 2018, agreed before development starts rather than retrofitted afterwards.
Written scope
Every engagement starts with a written scope and a fixed GBP quote within 24 hours, so the price is set before work begins.
About Manual Testing and QA
We run manual QA on every website and app we build, so we offer it as a standalone service too. Send us a staging URL or a build and we write a test plan, run functional, regression, exploratory, cross-browser, and cross-device passes, then hand back bug reports your developers can actually act on. Flat quote against a written scope, GST included, back in 24 hours.
What the engagement includes
- A clear title and a one-line summary of exactly what is wrong.
- Numbered steps to reproduce, from a known starting point, so anyone can follow the same path to the same failure.
- Expected result versus actual result, side by side, so the defect is unambiguous and not a matter of opinion.
- The environment it happened in: browser and version, device, OS, screen size, and the specific build or URL.
- A screenshot or screen recording, plus the relevant console or network error where it helps pin down the cause.
- A severity and priority call, so your team fixes the checkout blocker before the cosmetic misalignment.
- Everything logged in your tracker (Jira, Trello, GitHub Issues, Linear, or a shared sheet), in the format your team already uses, not a PDF nobody opens.
What UK rules and UK users add to a manual test plan
On a UK public sector site, a manual testing services engagement also produces the evidence behind your accessibility statement, so the report has to be written in the shape the statement takes. The government's sample statement records when the site was last tested, who tested it and how, and lists each problem against the WCAG success criterion it fails, under three fixed groups: non-compliance, disproportionate burden, and content outside the regulations' scope. A bug list sorted by severity cannot be pasted into that, so every accessibility defect we log carries its success criterion number and a suggested group, and whether to claim disproportionate burden stays your decision. The device list is the part buyers underestimate. Before public beta the GOV.UK Service Manual expects a service to work with JAWS on Chrome or Edge, NVDA on Chrome, Firefox or Edge, VoiceOver on iOS with Safari, TalkBack with Chrome, Windows Magnifier or Apple Zoom, and Dragon on Chrome. Dragon is the one a screen reader plan leaves out, and it fails differently: a control whose accessible name does not contain its visible label is hard to operate by voice. GOV.UK's own guidance says every UK service provider must make reasonable adjustments under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland, and that duty is owed to disabled people generally rather than triggered by a complaint.
The quickest route to realistic testing is copying production into staging, and for a UK business using testers in India that copy is a legal event rather than a convenience. The ICO's guidance on international transfers, updated on 15 January 2026, treats making personal information accessible to a separate organisation outside the UK as a restricted transfer even when nothing is sent, and its worked example is an Indian service provider logging in to systems the UK company holds. A staging database our testers can read counts, and so does a bug ticket with a customer's record pasted into it. Masking does not settle it either: the ICO's position is that pseudonymised data is still personal data for anyone who holds the additional information, and in a test environment the lookup often sits in the same database. So our default is synthetic data shaped like UK data. Bank details, for instance, need sort code and account number pairs that pass modulus checking, and Vocalink revises the weight table those checks run on; the version on its site takes effect on 17 October 2026, so a form still validating against an older copy can start rejecting real customers. Where live data is genuinely needed, the IDTA or the UK Addendum and a transfer risk assessment come first, and which fits your case is for your own counsel.
For firms the FCA regulates, the Consumer Duty turns part of exploratory testing into evidence. It has applied to products open to sale since 31 July 2023 and to closed books since 31 July 2024. PRIN 2A.6 says retail customers must not face unreasonable barriers when they want to switch, complain, claim or cancel, and PRIN 2A.5 requires firms, where appropriate, to test communications before sending them. So alongside the purchase flow we script the exit, count the steps it takes against the ones it took to buy, and record the result for your compliance team. Payments bring UK states worth walking by hand. Confirmation of Payee answers with a match, a close match that shows the real account name, no match, or unavailable, which covers a timeout, and each needs its own wording and a sensible next step. Drip pricing has been banned under the DMCC Act since 6 April 2025, and the CMA can now fine up to 10 per cent of global turnover, so we check the first price shown against the total at the final step. On devices, StatCounter put iOS at 51.47 per cent of UK mobile traffic in August 2026 against 7.15 per cent in India, and Samsung Internet at 4.88 per cent of UK mobile browsing, so a matrix built from our own team's phones would be the wrong one for you.
How we work with UK clients
UK engagements tend to start with procurement questions rather than technical ones. Who holds the data, which law governs the contract, whether you can produce a record of processing if the ICO asks. We answer those in the proposal instead of leaving them to a legal review three weeks in, because that review is where UK projects usually stall.
Invoicing is the other thing worth settling early. We are outside the UK, so services we supply generally fall under the reverse charge and your finance team accounts for the VAT rather than paying it to us. Our invoices say so explicitly. We quote in pounds, the figure does not move with the exchange rate mid-project, and payment by bank transfer avoids the card fees that make a five-figure invoice unnecessarily expensive.
Full service detail
This page covers how we work with clients in your market. The complete Manual Testing and QA page, with the full technical detail, process and frequently asked questions, is written in English.
Read the full service page (English)Questions UK clients ask
How does VAT work if you are based in India?
For most business-to-business services supplied from outside the UK, the reverse charge applies: you account for the VAT in your own return rather than paying it to us, and it is typically neutral if you are fully recoverable. Our invoices state the position clearly so your accountant is not guessing. If your situation is unusual, for example partial exemption, we would rather your accountant confirms the treatment before we invoice than after.
Are you compliant with UK GDPR and the Data Protection Act 2018?
We build to it rather than claiming a certificate. In practice that means data minimisation designed in rather than bolted on, a documented lawful basis for each processing activity, retention periods that actually delete, subject access and erasure handled as features rather than manual database work, and hosting in a region you approve. Where we process personal data on your behalf we sign a processor agreement setting out exactly that.
We are a public sector body. Can you meet the accessibility regulations?
Yes, and it is scoped from the start because retrofitting accessibility is considerably more expensive than building it in. We work to WCAG 2.2 AA, test with a screen reader rather than relying on an automated scan, and produce the accessibility statement the regulations require. Automated tools catch perhaps a third of real issues, which is why the manual pass is not optional.
Which law governs the contract, and what about IR35?
We are happy to contract under English law with the courts of England and Wales, and most UK clients prefer that. IR35 does not apply to us: it governs individuals working through an intermediary, and you are engaging a company for a defined deliverable rather than a person for their time. Your accountant will want to see that the contract reflects that, and ours does.
Manual Testing and QA: common questions
What is manual testing, and how is it different from automated testing?
Manual testing is a real person using your software against a plan, walking the actual flows and judging whether each one works and feels right. Automated testing is code that re-checks known paths on every build. Manual is better for new features, changing interfaces, and exploratory and usability work; automation is better for re-running a large, stable regression suite fast. Most teams need both, and manual QA is the honest first step because it finds bugs without you building a test framework first.
Can you test software you did not build?
Yes. Manual QA is a standalone service, so you do not need us to have built the product. Send a staging URL or a build and tell us what it is supposed to do. We write a test plan and run functional, regression, exploratory, cross-browser, and cross-device passes, then hand back bug reports your developers can act on. We test our own builds the same way, so the discipline is identical whoever wrote the code.
How do you report bugs, and what tools do you use?
Every issue is logged so an engineer can reproduce and fix it without asking us what we meant: a clear title, numbered steps to reproduce, expected versus actual result, the environment (browser, device, OS, build), and a screenshot or recording with the relevant console error. We log into your tracker, whether that is Jira, Trello, GitHub Issues, Linear, or a shared sheet, in the format your team already uses. Each bug gets a severity and priority so the blocker is fixed before the cosmetic issue.
Do you do cross-browser and cross-device testing?
Yes. We verify your product across Chrome, Safari, Firefox, and Edge, and across real phones, tablets, and desktops on iOS and Android. Layout and interaction bugs often show up in only one browser or on one screen size, so we test the matrix that matters for your users rather than assuming a build that works on one laptop works everywhere.
How much does manual testing cost?
It depends on scope: how many flows, how many browsers and devices, and whether you want one release tested or ongoing cycles. We do not publish a single rate that falls apart on a real brief. Send the build and what it should do, and we write a test plan and quote one flat INR number against it, with GST, inside 24 hours. Overseas clients can be invoiced in USD, CAD, GBP, or AED.
Other markets we work in
Tell us what you are building in the UK
Send the scope, or just the problem. You get a written scope and a fixed GBP quote back within 24 hours, from the engineers who would do the work.