A feature that matches the demo and one that matches the spec are not the same claim
Functional Testing Services
A feature can look finished in a demo and still fail the requirement it was actually built against. A demo shows the path someone chose to click through, not the path the specification describes. This practice tests against the written requirement itself, tracing every test case back to the acceptance criteria a feature was supposed to satisfy.
How a test case traces back to a written requirement
Acceptance criteria, execution and defect logging that names the exact rule broken.
90 secSample frame · video pending01Before scoping execution
Manual or scripted execution is a real choice here
Both are legitimate, and picking the wrong one either wastes engineering time or leaves a repeated flow untested every release. Four questions settle it against your actual feature.
How often will this exact flow be tested again?
A feature tested once before a single release rarely earns back the cost of scripting it. A flow re-tested every release earns that cost quickly.
How stable is the requirement behind it?
Scripting against a requirement still being revised means rewriting the script almost as often as running it.
How much judgement does the test actually need?
Visual or usability nuances often need a human eye, while deterministic input-output behaviour scripts cleanly.
What is the cost of a missed defect here?
A checkout flow justifies more rigorous, repeatable execution than an internal admin screen a handful of people use.
| Manual execution | Scripted execution | |
|---|---|---|
| Setup cost | Low, start immediately | Higher, pays back on reuse |
| Best for | One-off or exploratory checks | Flows re-tested every release |
| Catches | Usability and visual nuance | Deterministic regressions fast |
| Best fit | New or unstable requirements | Stable, frequently repeated flows |
02Agreed before execution starts
The ledger that keeps a sign-off honest
Functional testing drifts when 'it passed' gets said about the path someone happened to click, not the requirement actually on file. This ledger sets out what you bring, what we execute, what comes back, and what stays yours to decide.
- Your side
You bring
- The requirement or user story the feature was built against
- Access to a working build of the feature
- Any acceptance criteria already agreed with stakeholders
- Our side
We build
- Test cases derived directly from the requirement and its acceptance criteria
- Manual and scripted execution across the feature's real paths
- Defects logged and traced back to the specific criterion violated
- Your side
You receive
- A sign-off report mapped to every acceptance criterion
- A defect list a developer can act on without reinterpreting it
- A regression pack the feature can be re-verified against later
Never leaves you
- The requirement and the decision to change it
- The call on which defects block release versus ship as known issues
- The relationship with the product owner who wrote the requirement
Where the line sitsWe test against the requirement; you decide what counts as done. A traced defect list settles disagreements a demo alone never can.
03From requirement to traced sign-off
Four stages, each closing on a specific artefact
A sign-off that means nothing usually skipped one of these stages along the way. This system closes each stage on something a developer or product owner can actually use.
Design test cases from the requirement
Test cases get written directly from the user story or requirement document, not from clicking around the feature and guessing at intended behaviour.
Requirements as the actual test specExecute across the feature's real paths
Manual and scripted execution covers the paths the requirement actually describes, including the branches and exceptions a quick demo tends to skip.
Every documented path, not just the obvious oneLog defects against the specific criterion
Every defect gets tied to the exact acceptance criterion it violates, so a developer knows precisely what to fix rather than guessing at intent.
A defect traced to the rule it brokeReport sign-off against the requirement, not a vibe
The final report states plainly which acceptance criteria passed, which failed, and which were never actually testable as written.
Sign-off that means something specific
04What actually moves the number
Four drivers, sized from the requirement
Functional testing is priced against the feature's actual complexity, because these four factors change scope well beyond a simple page count.
Number of paths and branches in the requirement
A simple linear flow tests faster than a feature with several conditional branches and exception paths to cover.
How mature the requirement is
A clearly written requirement with defined acceptance criteria tests faster than one that needs clarifying before a single test case can be designed.
Manual versus scripted execution mix
A one-off manual pass costs less upfront than building scripts, which pay back only once the same flow gets tested repeatedly.
Regression scope around the feature
Testing one isolated feature costs less than also re-verifying every neighbouring feature a change could plausibly have touched.
05Evidence and proof
Sign-offs traced to a requirement, not a click-through.
Functional testing proof here is a defect traced to the exact acceptance criterion it violated. These records carry that bar while written approvals are secured.
Explore case studiesA checkout flow signed off against fourteen acceptance criteria, not a demo click-through.
Aster North needed its new checkout flow verified before a peak sales period. Test cases traced to every acceptance criterion found three defects a demo walkthrough had missed entirely.
- Acceptance criteria verified
- 14
- Defects found before release
- 3
A regression pass that separated one new defect from two pre-existing ones.
Koru Health changed a scheduling feature and worried about effects on three neighbouring flows. A traced regression pass showed only one genuinely new defect.
- Neighbouring flows re-verified
- 3
- New defects introduced by the change
- 1
The defect list didn't just say something broke. It said exactly which requirement it broke, which ended the argument fast.
Sample · pending client approval
06Read this first
When a single feature check is the wrong scope
Booking a narrow feature check when the real need spans an entire release leaves most of the risk untested. The exits are marked plainly.
- Software Testing
You need the whole release covered, not one feature
When quality needs owning across an entire release rather than one flow, software testing takes that broader scope instead.
- Test Automation
The same flow gets tested every release already
A flow re-tested on a fixed cadence usually justifies investing in an automated suite instead of repeating manual execution each time.
- QA Consulting
The question is really about strategy, not execution
When the real gap is deciding what to test and how, not running the tests themselves, QA consulting is the better starting point.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Single feature check | One flow needs sign-off before release | Acceptance criteria and release timing | Test design and execution |
| Regression pass | A change risks affecting nearby features | Scope of what could be affected | Re-execution and new defect triage |
| Ongoing feature testing | Every release ships several features needing checks | Release cadence and priorities | A repeatable design-and-execution rhythm |
07Straight answers
Asked before a feature gets signed off.
01What's included in a functional testing engagement?
Test-case design from requirements and user stories, manual and scripted execution against agreed acceptance criteria, and defect logging traced to the specific requirement violated. The scope stays narrow: one feature or flow against its own written specification.
02How is this different from software testing?
Functional testing verifies one feature against its specific requirement. Software testing owns quality across an entire release, blending functional, regression and exploratory work in one engagement.
03Do you write test cases from our user stories, or do we provide them?
Either. Test cases can be designed directly from your existing user stories, or drafted from a requirement document if formal user stories do not exist yet.
04What happens when the requirement itself is ambiguous?
Ambiguity gets surfaced as a specific, written question back to whoever owns the requirement, rather than guessed at silently. A test case built on a guess proves very little.
05Do you test manually, or do you script everything?
Both, chosen against how often a flow will be tested again. A one-off release check often stays manual, while a frequently repeated flow earns the cost of scripting.
06What does functional testing cost?
Cost scales with the number of paths and branches in the requirement, and whether execution is manual or scripted. A simple linear flow costs far less than one with many branches.
07Can you also test what a change might have broken nearby?
Yes, a regression pass re-executes existing test cases against neighbouring features a change could plausibly affect, distinguishing genuinely new defects from pre-existing ones.
08How is this different from test automation?
Functional testing designs and executes the test cases themselves. Test automation builds and maintains the framework those test cases can run on repeatedly, a distinct engineering discipline.