QA and Software Testing Services

Webontwikkeling Schaalbaar Veilig Performance Betrouwbaar Langdurige support

Webontwikkeling

Every system has a small number of paths where a bug costs real money: the checkout, the price calculation, the order that has to reach the ERP, the export the accountant relies on. Everything else is a nuisance by comparison.

So that is where the testing goes. A coverage number across the whole codebase tells you almost nothing about whether those paths work.

What gets tested, in what order

The money paths first: add to cart, price and tax, discounts, payment, order confirmation
The integration boundaries, where most real failures live - what happens when the ERP is slow, or answers with something unexpected
The permission rules: who can see which price, which customer, which document
Then the rest, in order of how often it is used

Manual and automated, and which is which

Automated

Worth the cost when it runs on every release and would otherwise be redone by hand:

End-to-end checkout on the browsers and devices that actually appear in your analytics
API contract tests against the integrations, so a partner change is caught by us rather than by a customer
Regression suites around the rules that have been broken before

Manual

Better done by a person, and not worth automating:

Exploratory testing of anything newly built, where the interesting bugs are the ones nobody thought to specify
A one-off release check on a change that will not be made again
Anything about how it feels rather than whether it works

What you get back

Defects written so they can be reproduced by someone who was not there - the steps, the data, the environment, and what was expected instead. A bug report that says the checkout is broken costs more to investigate than it did to find.

Veelgestelde vragen

Can you test software you did not build?

Yes, and it is often more useful that way - we come to it without the assumptions the people who wrote it cannot help making.

Do you set up automated tests in our pipeline?

Yes, running on your CI rather than on a machine of ours, so the suite outlives the engagement and fails your build rather than emailing us.

What about load and performance testing?

For a store with a seasonal peak this is the test that matters most, and it has to run against realistic data volumes - a load test against an empty catalog measures nothing.

Should we aim for full coverage?

No. Chasing a percentage produces a suite that is large, slow and brittle, and that can pass while the checkout is broken. Test the paths where a failure is expensive, keep that suite fast, and it will still be running in two years.

Which failure would hurt most?

Answering that one question - the release that must not go wrong, or the bug that already reached a customer - is enough for us to say what testing is worth doing and what is not.

Start uw project