Development
QA and testing
Checking the product before release: manual test passes, automated tests, defect reports with steps to reproduce.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 5–7 days
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Days 1–3
The critical list
We go through the product as a user, not as code: where sign-in is, where money moves, where data is written, what must never break. Along the way it turns out that some behaviour is written down nowhere — those places become questions rather than defects.
You get — The critical points listed, with open questions
Days 4–7
Cases and environment
We write the checks out: steps, data, expected result, worded so that another person can run them. Test accounts are created for every role, and we agree on an environment: production is not where you test, and how the staging copy differs from it has to be known in advance. The first pass over the critical list happens here — by the end of the week you have a defect list, not a test plan.
You get — Test cases, accounts and a first defect list
Weeks 2–4
Runs and automation
We run the cases by hand and file defects so that a developer reproduces them on the first attempt: steps, environment, expected against actual, a screen recording. In parallel, whatever will need re-checking at every release goes into automated tests: sign-in, payment, the main flow.
You get — Reproducible defects and tests for the main flows
Before you ship
The decision to ship
A short pass over the critical list, on real devices and in the browsers your users actually have. The pass ends not with “all clear” but with the list of what is still open, with a read on the risk in each item: the decision to ship is yours, taken with that list in hand.
You get — The open items with their risk
Every release
The suite in CI
The automated suite lives in your repository and runs in CI on every build. When the product changes the tests change with it: a suite that starts failing on its own stops being read within a couple of weeks, and from then on it protects nothing.
You get — An automated suite in your repository, kept current
What the work covers
The critical list
a walk-through as a customer, the points where money moves and data is written, the list every release gets checked against.
Test cases
steps, test data and the expected result, grouped by role and by how often each set gets run.
Defect reports
steps to reproduce, environment and build number, what should have happened against what did, a screen recording or a screenshot.
Automated tests for what repeats
sign-in, payment and the main flow, run by one command and on every build, with failures looked into.
Checks on real devices
the phones and tablets, browsers and versions on your list, behaviour on a narrow screen.
The decision to ship
what was checked, what is still open, and what each open item risks — shipping or waiting is your call.
What we need from you
- A staging copy with a current build, and test accounts for every role — testing does not happen on production.
- The list of platforms you support — browsers, versions of iOS and Android, the device models the product has to work on.
- Someone who can say how the product is meant to behave where that is written down nowhere.
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.