The cost of a bug by stage

The same bug costs differently depending on when it is found. That is the main argument for testing as a process rather than a one-off service before handover.

At design time

Cost ×1. It is enough to change a line in the requirements before work starts.

During development

Cost ×3. The developer fixes the code before it reaches the build.

During testing

Cost ×10. The task goes back to the developer and the cycle starts again.

After release

Cost ×30. An urgent hotfix outside the normal release schedule is required.

Found by a customer

Cost ×100. On top of the fix cost come lost revenue and reputation.

Automated tests pay off not on the first run but on the twentieth. So it makes sense to automate stable scenarios that are checked before every release. Automating something that changes every week is a way to spend the budget on maintaining the tests themselves.

How we test

The result is not a list saying everything is bad but reproducible defects with priorities a developer can start on immediately.

01

Product review

We study the scenarios, the audience and what matters most for the business. Testing everything with equal rigour makes no sense.

02

Plan and checklists

We record what is tested and on which devices and browsers. The plan is agreed with you and also defines the scope and the price.

03

Test run and report

Every defect comes with reproduction steps, a screenshot and a priority. Without that a report is useless to the development team.

04

Retesting

After fixes we check not only the defect itself but also that nothing nearby has broken.

Frequently asked questions

They do, but they check that what they wrote works as intended. A dedicated tester checks something else: what happens if you do not do it as intended. These are different roles, and combining them in one person works badly because the eye gets used to the work.

Yes, this is a common request before accepting a contractor work. We have no interest in hiding defects, so the report is genuinely independent. It is better to order such a review before signing the acceptance certificate, not after.

It is decided from your analytics, not from a generic list. Usually it is two or three mobile resolutions and three browsers covering more than ninety percent of visitors. Testing everything is expensive and does not pay off.

Three numbers: how many concurrent users the system handles comfortably, where slowdown begins and what exactly is the limit, whether processor, disk, database or code. With that you can decide knowingly whether to add resources or optimise.

We will test the product before your users do

Tell us what needs testing and by when. We will draw up a test plan and quote based on the number of scenarios.