02 /QA & Manual Testing
Manual & Exploratory Testing
Scripted test execution against the flows you have agreed, plus unscripted investigation by someone who is deliberately trying to break the product. The second half is where defects nobody wrote a case for get found — a test case can only ever check what its author already thought of.
What you get
Test cases with expected results
Written before execution, reviewed with you, and specific enough that a second tester would reach the same verdict. Vague cases produce vague results and arguments about whether something is a bug.
Timeboxed exploratory sessions
Charter-driven investigation with a written record of what was covered and what was found. Unscripted does not mean unaccountable — the session notes are a deliverable.
Defect reports that can be acted on
Reproduction steps, environment, expected versus actual, severity with the reasoning shown. A report an engineer can act on without a follow-up conversation.
Cross-browser and cross-device passes
Against the combinations your analytics actually show, weighted by value rather than by session count — which is usually a narrower and older set than the team expects.
A coverage summary per cycle
What was tested, what was not, and where the risk was accepted. The list of what was not covered is the part most reports omit and the part that matters at release.
How it runs
- 01
Understand the product
We walk the application with someone who knows it, agree what "working" means for each flow, and identify which areas carry business risk rather than which areas are newest.
You provide: Access, a walkthrough, and a view on what hurts most if it breaks
- 02
Write and agree the cases
Cases are drafted and reviewed before anything is executed, so the scope is settled while it is still cheap to change and nobody is surprised by what was left out.
We produce: A reviewed test case set · An explicit out-of-scope list
- 03
Execute and explore
Scripted execution against the agreed set, then timeboxed exploratory sessions around the areas the cases could not reach. Defects are raised as they are found, not batched to the end.
We produce: Execution records · Session notes · Defect reports
- 04
Report and retest
A cycle summary covering coverage, findings and accepted risk, then verification of the fixes once they land — because an unverified fix is a defect with optimism attached.
We produce: Cycle report · Retest verification
Where this stops
- Not a substitute for automation. Manual regression scales linearly with the number of releases; if you release weekly, this is the wrong long-term answer on its own.
- Not a security assessment. Finding functional defects and finding vulnerabilities are different disciplines with different methods.
- Not performance or load testing, which needs instrumentation and a controlled environment rather than a person clicking.
- Not a promise of "full coverage". Nobody can test everything; what we can do is be explicit about what was covered and what was not.
Related reading
- Quality assurance
How to write a bug report a developer can act on
A defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- Test automation
When to automate a test, and when the answer is no
Not a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
FAQ
Manual & Exploratory Testing questions we hear often
Is manual testing still worth paying for?
For the work automation cannot do, yes. Exploratory investigation, usability judgement, and any first pass over a feature that is still changing shape are all cheaper done by a person than encoded in a script that will be rewritten next sprint. What manual testing is bad at is repetition — and that is precisely what automation is for.
How many test cases do we need?
Fewer than most teams assume. A large suite of shallow cases takes longer to maintain than it takes to find anything, and it creates the impression of coverage without the substance. We would rather write a smaller set that covers the flows carrying real consequence and be honest about the rest.
Can you test without documentation?
Yes, and it is common. Where there is no specification we establish expected behaviour from the product, from your team and from what a reasonable user would assume, then write it down — so the by-product of the first cycle is the documentation that did not exist.
How do you decide a defect’s severity?
From consequence, not from how broken it looks. A cosmetic misalignment on a checkout button that reduces completion is more severe than a crash in a screen nobody visits. The reasoning is written into the report so you can disagree with it explicitly rather than silently.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.