What to Send a QA Team, and What You Should Get Back

A manual testing engagement usually fails before anyone opens the application. Somebody sends a staging link and the words please test this, gets back forty screenshots with the caption not working, and concludes that manual QA is not worth paying for. The testing was never the problem.

We run manual QA on every build we ship before it goes near a client, which is why we offer it as a standalone service at all. This is what that process actually needs at the start, and what it should produce at the end, written so you can hold any QA team to it, including us.

The five things to send, before the link

A tester who has only a URL can test whether the software works. A tester who has the five things below can test whether it does what the business needs, which is a different and much more valuable question.

1. What this release changed. Not the whole application, the diff. A tester who knows the checkout was touched and the login was not will spend their time where the risk is. Without it every round is a full regression and you pay for the same coverage repeatedly.
2. Test accounts that survive the day. One per role, with the passwords, and not reset overnight. More engagements stall on this than on anything technical. If the customer, the admin and the delivery user behave differently, that is three accounts, and a tester who has to ask for them loses a day.
3. The devices and browsers you actually care about. Pull the top five from your own analytics rather than guessing. In India that list usually looks nothing like a developer's assumptions, and it is the difference between testing what your users have and testing what the tester has.
4. What must not break. Every application has three or four flows where a failure is a business problem rather than a bug: the order goes through, the payment reconciles, the OTP arrives, the invoice has the right number on it. Name them. They become the regression set that runs every release forever.
5. Where to file, and who reads it. A shared sheet is fine. What is not fine is bugs arriving in three places, because then nobody owns the list and the same issue is reported twice and fixed never.

That is a thirty-minute job once, and it is the difference between a test round that finds things and one that produces screenshots.

What a bug report has to contain

A bug report exists to let a developer reproduce something without talking to the person who found it. Everything below serves that one purpose, and a report missing any of it will cost a round trip.

• Steps that start from a known state. Not click checkout. Log in as this account, add this specific item, go to checkout. A developer should be able to follow it without inferring anything.
• Expected and actual, separately. Half the arguments in a bug tracker are about whether something is a bug at all, and they happen because the report never said what should have happened.
• Environment. Device, operating system, browser and version, and which build. A bug on Chrome 141 and a bug on an old in-app browser are different bugs even when the symptom matches.
• Frequency. Every time, or one in five. This is the field that decides whether the developer looks at the code or at the data, and it is the one most often left out.
• Evidence. A screenshot for layout, a screen recording for anything involving a sequence, and the console or network tab when something failed silently. A recording of a checkout failing is worth more than four screenshots of it.
• A severity you can defend. Not a feeling. Does it lose money, block a user with no workaround, or is it cosmetic? Three buckets is enough, and a list where everything is critical is a list nobody triages.

Here is the shape, which is deliberately boring and copies into any tracker:

textTITLE     Checkout fails silently when the coupon field is left empty
SEVERITY  High, blocks purchase, no workaround
BUILD     staging, 19 Sep, commit a1c9f20
ENV       Android 14, Chrome 141, 360x800
FREQ      Every time, 5 of 5

STEPS
  1. Log in as test.customer@example.com
  2. Add "Besan Ladoo 500g" to the cart
  3. Go to checkout, leave the coupon field empty
  4. Tap Place Order

EXPECTED  Order is placed, confirmation screen appears
ACTUAL    Button shows a spinner, nothing happens, no error shown
          Console: TypeError: Cannot read properties of null (reading 'trim')
          Network: POST /api/orders never fires

EVIDENCE  recording-142.mp4 (0:08 onwards)

The console line in that example is what turns a two-day investigation into a ten-minute fix, and a tester who never opens the developer tools will never produce it. That is a reasonable thing to ask about before you hire anyone.

How to tell a good round from a bad one

You do not need to be technical to judge the output. Four signals, and none of them is the number of bugs found.

• The severity spread is realistic. A real round has a few high, more medium, a tail of cosmetic. All critical means nobody made a judgement; all cosmetic usually means nobody went past the first screen.
• Some entries are questions, not defects. A tester who understood the brief will come back with two or three cases the specification did not cover. Those are often worth more than the bugs.
• The regression set is named and repeatable. If the flows that must not break are not written down as a list somebody can rerun next release, you are buying the same discovery work every time.
• Closed bugs get verified. A fix is not done because a developer said so. The person who filed it should reopen or close it, on the build where it was supposedly fixed.

When manual testing is the wrong spend

Manual QA is the right tool for a new feature, for anything involving judgement about whether a screen is usable, for exploratory work, and for real devices. It is the wrong tool for the same twenty flows every week for a year. That is what automation is for, and a QA firm that never tells you this is selling you hours rather than coverage.

The honest sequence is manual first, because you cannot automate a flow you have not yet described, then automate the regression set once it stops changing, then keep manual for everything new. Anyone proposing an automation suite before the flows are stable is proposing to rewrite it twice.