Manual QA and release test plans

What this actually solves

Somebody on your team built a feature, tried it, and it worked. That is almost always true, and it is almost always the problem. The person who builds a thing walks the route they had in their head while building it — the clean one. New account, empty basket, the exact quantity the rule was written for, no coupon, nothing left over from last week. The industry calls that the happy path, and it is the one route that is guaranteed to have been tested already.

The money is on the other routes. A buy-three-get-one-free rule that behaves perfectly on an empty cart can apply twice when the cart already holds an item added before the promotion started, and every affected order quietly loses you the price of a garment. Nobody files a complaint about it. The accountant finds it a week later, if anyone finds it at all. That is the shape of the bugs this service exists to catch — not crashes, which you would have seen, but logic that is wrong only under a condition nobody wrote down.

There is a second reason this gets bought, and it is less about defects than about sleep. A founder deploying on a Thursday night wants a written statement from someone who is not the developer saying what was checked, what passed, what is still open and why it is acceptable to ship anyway. That page is cheap to produce and it is the most valuable thing we hand over.

How the work runs

The order matters. Testing before you know what "correct" means produces a list of opinions, not defects.

1. Six questions, in writing, before anything is opened. What is new in this release, feature by feature. Who your customers actually are and which browsers and devices they arrive on. Which part of the product stops your business if it breaks. What accounts and test cards we need. Whether there is a staging environment and who resets it. And what customers have complained about most in the last three months — that last answer is the one people never ask for and it hands you the three places bugs are already living. Half a day, plus waiting on access.
2. An unguided walk through the product, testing nothing. Just mapping — how many screens, how many flows, where money changes hands, where data is entered. At the end of the first day you get a short note saying what we received, what is still missing and what we have already noticed. Half a day to a day.
3. The test plan, and your approval on it. One page. What is in scope, which browsers and devices and why those, how long it takes, the exit criteria that block a release — and, most importantly, an explicit list of what is out of scope. That section is what protects both of us three weeks later when somebody asks why the mobile app was not checked. Half a day.
4. Writing the cases. Six fields each — identifier, title, preconditions, numbered steps, expected result, status. Two rules make the difference. One case tests one thing, so "test checkout" is not a case and "with three items in the cart the fourth is charged at zero" is. And the expected result has to be checkable, not admiring — "the discount applies correctly" is worthless, "the cart total equals the price of three items and one discount line appears, not two" cannot be argued with by two people reading it. Writing these usually surfaces gaps before any testing starts, because somebody has to decide whether the free item is the cheapest one or the dearest one. One to two days for a first set of forty.
5. Running the cycle and writing the bugs. Every failure gets a screen recording, the browser console, the build or commit, the account used and the time. Each report carries steps precise enough that a developer reproduces it without messaging you, an expected and actual result, a separate severity and priority, and a note on what the failure depends on. Two to five days per cycle depending on scope.
6. Retest, regression, sign-off. Fixes are verified, every fixed bug becomes a permanent regression case, and the release closes with a one-page statement — what was tested, what passed, which defects remain open and why they are acceptable. Half a day to a day per cycle.

What moves the price

The range is $15–$45/hr and it is ongoing work. Three things decide where inside it you land.

How expensive a mistake is in your domain. A content site and a payments flow are not the same job even when the number of screens is identical. Anything handling money, health records or regulated data demands slower, more paranoid work and a heavier evidence trail, and it is priced accordingly.

How much responsibility you are buying. Executing cases somebody else wrote sits at the bottom of the range. Owning the plan, the severity calls and the sign-off that says a release is fit to ship sits at the top, because that is a judgement with your business attached to it.

How much of it is writing. A tester who reports verbally is cheap and forgettable. The monthly report — defects caught by severity, what escaped to customers, which areas keep producing failures — is the part that lets you decide whether this is worth paying for, and it is real work with real hours in it.

What usually goes wrong

Everything gets marked critical. New testers grade by how annoying a bug feels, so a misaligned heading arrives at the same severity as a double-charging cart. Within two weeks your developers stop reading the critical queue, because the label no longer means anything, and the day a genuine critical arrives it waits in line with the rest. The tell is what the word is doing — once critical stops being the exception, it has stopped distinguishing anything, and the critical queue is just the queue under a louder name. The cure is a severity table written into the contract, so a grade is argued from what the bug does to the business — trading stopped, a workaround exists, only appearance — and not from how it felt to whoever found it.

Bugs travel by chat and never reach the tracker. It feels faster to send a screenshot straight to the developer, and for that hour it is. Three weeks later nobody can prove the issue was ever raised, nobody knows whether it was fixed, and it never became a regression case so it will come back. Everything goes into your tracker with a number, even when it also goes to chat.

Urgency gets written into the report. "Urgent, site down, everyone is angry" does not make anything get fixed sooner. It pressures a developer into a hurried fix, which is how the second bug arrives, and it puts the tester on the opposite side of the team from the person who has to do the repair. Impact belongs in the report as a fact — how many orders are affected and what each one costs. Emotion does not belong in it at all.