Skip to content

Manual Testing and QA in the US

We are an Indian engineering team working with businesses in the US. Written scope before any code, and a fixed quote in USD.

Working hours

Our day ends at 07:30 in the US (08:30 on summer time), before yours begins, so we work asynchronously: written updates land overnight and are waiting when you start.

Quoted in USD

There is no general VAT in the US at present, so the quote is the amount you pay.

Data protection

Work for this market is scoped against state privacy law, principally the CCPA and CPRA in California, agreed before development starts rather than retrofitted afterwards.

Written scope

Every engagement starts with a written scope and a fixed USD 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.

Send the scope and you get a written scope and a fixed USD quote back within 24 hours.

Get a quote in USD

Trusted Tester results, FDA's unscripted testing records and the IRS test gate in US manual QA

For a federal agency buyer, manual accessibility testing comes with a named method and a named credential. OMB memorandum M-24-08 of 21 December 2023, still listed as current on Section508.gov, tells agencies to run manual conformance validation testing, such as the DHS Trusted Tester Conformance Test Process for the Web, in addition to automated scans, because automated tools cannot judge the criteria that need human judgment. It also says the employees or contractors tasked with that testing should at a minimum have completed a certified Section 508 conformance training program, and the DHS Trusted Tester certification is the example it gives. DHS states that agencies adopting the process accept results only from individuals certified as Trusted Testers. Certification means DHS's free online course, finished within 180 days, and a score of 85 per cent or more on its exam. The method is code inspection rather than impression: each test follows a documented step, uses approved tools and returns a repeatable result against the ICT Testing Baseline, which the memo describes as the minimum checks for Section 508 conformance and not a test process in its own right. Two details matter when the work is planned. DHS no longer trains or certifies on version 4, and testers already certified are told to work on 5.1 or above, so a report produced against an older process is weaker evidence than it looks. And the memo asks agencies to validate a vendor's conformance documentation before purchase and again whenever the product changes, whether a new version, a feature or a bug fix, so retesting a federal product is a release task rather than an annual audit. The first question for any testing supplier, ours included, is therefore which named tester holds a current certificate, and the test plan lists the pages and flows the agency has asked to see on every release. Whether your contract requires certified testers is for your contracting officer.

If your customer makes medical devices, the software they buy to run production or their quality system is tested under FDA's Computer Software Assurance guidance, issued in final form on 3 February 2026 and superseding the version of 24 September 2025. It covers systems such as a complaint handling portal, a CAPA tracker, a manufacturing execution screen or a spreadsheet that trends nonconformances, not the device's own software, and for that kind of system it replaces section 6 of FDA's General Principles of Software Validation. What makes it a manual testing document is its position on scripts. For features whose failure would not be a high process risk, FDA says manufacturers may consider unscripted methods such as scenario testing, error-guessing and exploratory testing, which it describes as the tester designing and running tests on the spot from knowledge of the product and of common failure modes. Unscripted does not mean unrecorded. For exploratory testing the guidance expects a high-level plan with objectives and pass or fail criteria for each, with no step-by-step procedure needed, and a record of the intended use, the risk analysis, a summary of what was tested, the issues found, a conclusion on acceptability with each issue resolved or justified, and who tested and when. It also prefers system logs, audit trails and other digital records to screenshots. So on this kind of engagement each exploratory session starts from a written charter, the notes and defects go into the test management tool under the tester's name and the date, and high-risk functions, such as anything that releases product, still get scripted cases. Part 11 sits behind it: a Part 820 record kept electronically is generally an electronic record, and FDA's enforcement discretion on validating such systems does not extend to production and quality system software. How your customer rates process risk is for their own quality and regulatory team.

Tax software has its own federal test gate, and it opens this month. Under Publication 1436, revised in October 2026, the IRS Assurance Testing System for individual returns opens on 13 October 2026, and a software developer has to complete the scenarios that apply to its product before it is accepted into the Form 1040 Modernized e-File program for tax year 2026. This year's set is six Form 1040 returns, two 1040-SS returns, one Form 4868 and three 1040-NR scenarios, and the IRS says each must be correctly prepared and computed before it is transmitted, so a tester keys every scenario into the product as a preparer would and checks the figures before sending rather than after. Processing runs schema validation and then business rule validation, and the developer keeps transmitting until every business rule rejection is cleared. Several rules shape the plan. ATS is not configured like production and is not to be used for load testing. A new Software Identification Number is needed for each tax year and each package. Forms added after passing ATS are the developer's to self-test. Federal scenarios come before state ones, and each state supplies its own. Test identities have a rule too: an SSN on an ATS return must have 00 as its fourth and fifth digits, or business rule R0000-129-01 rejects it. The opposite failure is worth testing in any US product that collects SSNs. Since 25 June 2011 the Social Security Administration has issued numbers randomly, with the area number no longer tied to a state and the High Group List frozen, and previously unassigned area numbers are now issued, apart from 000, 666 and 900 to 999. A form still checking SSNs against the old state ranges rejects real people, so the validator is tested against the current rules, including the excluded ranges that must fail. Whether your product needs ATS acceptance is for your own tax counsel.

How we work with US clients

A US engagement gets agreed twice. Once with the person who wants the thing built, and then again with legal, security, procurement and finance, who arrive separately and rarely in the same week. That second round is where a supplier outside the country loses the calendar: a master services agreement to redline, a security questionnaire, a certificate of insurance, and a vendor portal that assumes everyone it onboards can sign a W-9. Send all of it while the scope is still being written rather than in the week you wanted to start, and where the honest answer to a row is that we do not hold something, we write that in rather than leaving it blank.

You are also buying from a company you cannot drop in on, so the evidence has to do the work an office would otherwise do. What we send is live production URLs rather than a deck, a written scope with one fixed number against it, and the names of the people who will do the work rather than a bench that changes after signature. What we will also tell you is the shape of what you are hiring: a small team in Noida that has been building since 2021, not a firm that can put four more people on your project next Monday. If that is what your timeline needs, we say so before the contract rather than after it.

Send the scope and you get a written scope and a fixed USD quote back within 24 hours.

Get a quote in USD

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 US clients ask

Does our site have to meet ADA accessibility requirements?

If you are consumer facing in the US, build as though it does. Demand letters over inaccessible websites are routine and cheap to send, federal work brings Section 508 with it, and the Department of Justice rule under Title II sets WCAG 2.1 AA for state and local government entities on a timetable your counsel can confirm for your size band. We work to WCAG 2.2 AA and test with a screen reader rather than relying on an automated scan, because automated tools catch perhaps a third of real issues and the other two thirds are the ones that end up in a letter.

How do we know you will still be here in two years?

Nobody can promise you that, and a supplier who does is selling something. We have been building since 2021 and we maintain what we build, which is the honest version of the answer. The useful version is that it should not have to matter. The repository is in your GitHub organization, the domain and hosting accounts are in your company name, the stack is Next.js, Laravel, Flutter and Postgres rather than anything only we can read, and the handover document exists before you ask for it. If we vanished tomorrow, another agency could pick it up without needing to call us.

Can you sign our NDA and work under our MSA?

Yes to the NDA. Send your standard one and it comes back signed within 24 hours, before you describe the project in any detail. Yes to the MSA too, with the caveat that we read it properly rather than signing to be agreeable. The two clauses we usually come back on are unlimited liability, where we ask for a cap tied to the fees, and an IP clause drafted broadly enough to sweep in the internal tooling we bring to every project. Everything built for you transfers to you in full on final payment. We mark up those two and sign the rest.

Something breaks at two in the afternoon in Chicago. What actually happens?

Two in the afternoon in Chicago is past midnight here, half past midnight in summer and half past one in winter, so the truthful answer depends on what you are paying for. Monitoring does not keep our hours and the alert fires whatever the clock says. Whether a person is awake to act on it depends on your plan, because we are not a 24/7 on-call operation as standard, and we would rather tell you that while you are choosing a plan than while your checkout is down. Without out-of-hours cover written into the contract, the realistic answer is that it is picked up at the start of our day, which is the middle of your night, and you should price that in when you decide.

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.

Send the scope and you get a written scope and a fixed USD quote back within 24 hours.

Get a quote in USD

Other markets we work in

Working with the US

Tell us what you are building in the US

Send the scope, or just the problem. You get a written scope and a fixed USD quote back within 24 hours, from the engineers who would do the work.