Service
Quality Assurance and Testing
Testing aimed at the rules that carry money, time and access, with automated coverage where regression is likely and manual coverage where judgement is needed.
The problem
What usually goes wrong
Test coverage as a percentage tells you almost nothing. A suite can cover ninety percent of lines and none of the pricing rules, and the bug that reaches a customer is always in the rule nobody tested.
The other failure is a suite so slow and flaky that people stop reading it. A red build that is usually a false alarm is the same as no build at all.
Quality work should start from the list of things that must never be wrong.
Scope
What we deliver
Risk based test plan
The behaviours ranked by what a failure would cost: money, time, access, data loss, reputation. Coverage follows that ranking.
Automated unit and integration tests
Around pricing, permissions, scheduling, tax, state transitions and anything that writes to a third party.
End to end tests
A small suite over the paths a customer or operator cannot be allowed to lose, run against a seeded environment.
Integration failure simulation
Timeouts, duplicate webhooks, out of order events and provider errors reproduced deliberately rather than discovered live.
Manual and exploratory passes
Structured sessions on the areas where judgement beats assertion, with findings recorded against the specification.
Accessibility and performance testing
Keyboard paths, screen reader semantics, contrast and target size, plus page timings against seeded production scale data.
Method
Technical approach
We write the risk list first, with the client, in business terms. An incorrect invoice total, a booking on an unavailable slot, a user seeing another tenant data. Those become the tests that must exist.
Unit tests target pure logic: calculations, eligibility, state machines. They run in seconds and are the ones developers will actually keep green.
Integration tests run against a real database with seeded data, because most real defects live in the gap between the query and the assumption.
End to end coverage is deliberately small. A handful of paths, stable selectors, no waiting on arbitrary timers, and full isolation between runs so a failure means something.
Failure simulation is a first class part of the plan. We replay duplicate webhooks, force timeouts and reorder events, because those are the conditions production supplies and a happy path suite never sees.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Risk ranked test plan agreed with your team
- 02Unit and integration suites over the ranked behaviours
- 03End to end suite over the critical paths
- 04Seed data and fixtures for repeatable runs
- 05Failure simulation covering integration edge cases
- 06Accessibility audit against WCAG 2.2 AA
- 07Performance measurements against production scale data
- 08Defect log, test documentation and continuous integration configuration
Related
Systems this service builds
- Payment IntegrationWe integrate your software with processors such as Stripe, Square and Adyen using hosted fields, tokenization and processor managed checkout, which keeps card data out of your systems and reduces your PCI scope.
- Booking and SchedulingAvailability, rules and reservations that hold under concurrency, with the buffers, resources and cancellation policies your business actually uses.
- Ecommerce PlatformsStorefronts built for the catalogue and the fulfilment model you actually have, with checkout through a processor and orders that reach fulfilment without manual steps.
FAQ
Questions people actually ask
What coverage target do you aim for?
None as a number. We aim for full coverage of the ranked risk list and accept low coverage elsewhere. A percentage target produces tests written to raise a percentage.
Can you test software we did not build?
Yes. A testing engagement can stand alone, starting with the risk list and an exploratory pass, and ending with an automated suite your team runs.
How do you keep end to end tests from becoming flaky?
By keeping the suite small, isolating data per run, using stable selectors rather than text that changes, and waiting on application state instead of a timer.
Do you test payment flows against a live processor?
Against the processor test environment, including webhook delivery, duplicate events and failed payments. Live processing is never used for testing.
Is accessibility testing automated?
Partly. Automated checks catch contrast, labelling and structural issues. Keyboard operation and screen reader behaviour are checked manually because tooling cannot judge them.
Do we get the tests?
Yes, along with the fixtures, the continuous integration configuration and the documentation, as part of the handover.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.