Service · Software testing and QA

Functional testing

Software almost never breaks on the route somebody planned. It breaks on the route nobody pictured: a discount counted twice because the page got reloaded, a VAT rounding that lands two cents apart on the screen and in the PDF, an address pasted out of a spreadsheet carrying a line break in its middle. Functional testing means travelling those routes on purpose, writing down what genuinely happens, and holding that against the promise made in the brief.

Scenarios
written once, replayed every release
Full pass
one complete round per delivery
Findings
reproducible at the first reading
Verdict
ship now or repair first

Where this service reaches

Catching individual defects is only part of what you get. What lasts is the scenario library: it grows release after release and each pass through it costs less time than the one before.

Put your scope to an engineer

Reading the requirements

Before a single line of code exists we work through the user journeys and the brief. A discount rule counted on the gross amount in one paragraph and on the net amount three pages further on costs one meeting at this point, and a week of rework half a year later.

Test scenarios

Numbered steps, each with the result it ought to produce, held in a shared spreadsheet, in TestRail or in Xray. Your own people can replay them without us, and automated scripts later grow out of the same material.

Boundaries and awkward input

A quantity of zero, then one of 9,999. The 29th of February. A postcode opening with a nought, a surname carrying an apostrophe, a field stuffed with four hundred characters. Forms tend to surrender to exactly this sort of thing.

The integration chain

One order gets followed the whole way: the record written into Sage, Cegid or Pennylane, VAT charged at the rate matching the goods, a Colissimo label produced, the Chronopost delivery status arriving back in the customer area, the Stripe payment matched against the right order.

Regression

Fresh work must leave the working parts alone. After each delivery we replay whatever covers the areas your developers touched, together with the features that already have a history of trouble.

Writing up findings

Steps, environment, browser and version, test data, the result observed against the result expected, filed directly in whichever tracker you keep, be it Azure DevOps, GitLab or Jira. Nobody needs to come back with questions before starting.

Release report

A summary of the ground covered, the ground skipped on purpose, every finding still open, and the risk you carry by shipping today instead of a week from now.

The way an engagement runs

The opening round is the longest, since everything has to be written from nothing. Later ones move noticeably quicker. All of it happens remotely, on your test environment or on a staging copy.

01

Meeting the product

We work out how the thing behaves, then settle with you which features earn money and which can wait their turn.

02

Test plan

Coverage, browsers, devices and, above all, whatever gets knowingly left aside. Nothing can be checked exhaustively, so priorities follow the risk.

03

Execution

Scenarios get run, findings get raised, and every repair is confirmed the moment it reaches the test environment.

04

Release verdict

Ship or hold, stated plainly, with each open finding listed and each uncovered area named.

“The basket is broken” is a mood, not a defect report. A message of that shape bounces between three people for a fortnight before somebody closes it as impossible to reproduce. Everything we write is built so that a developer reproduces it at the first try: numbered steps, the test account used, the data behind it, the browser and its version, a screenshot or a short recording.

Questions and answers

That follows from the number of journeys and the depth you ask for; the hour count appears in the plan, agreed before anything begins. A lighter variant exists, covering only the principal journeys and accepting that a share of the findings will land on your users instead. Sometimes that is a sensible trade, provided it is deliberate and written down.

Not at all. We open with exploratory work: a newcomer route through the product, with its real behaviour recorded as we go. A first functional description falls out of that, and quite often it is the only one that will ever exist.

The ones your visitors actually hold. Your analytics give the real split: Chrome and Safari on handsets for a consumer service, Edge across a uniform Windows estate for an internal tool. Models we do not own are reached through an online device farm.

Time spent, EUR 95 an hour excluding VAT, under a ceiling of hours approved in the plan. Where releases come thick and fast, recurring rounds sit inside a monthly Start, Business or Premium plan, which keeps the figure steady from month to month.

Put your product through a proper round

Tell us about the system and about whatever keeps worrying you. Back comes a test plan with an estimate of the hours it needs.

When we are around
Weekdays, 8:00 to 18:00 CET; answers land inside one working day
Talking it through
A call on Teams or Google Meet, whenever writing is not enough

We set strictly necessary cookies only: they keep the site running and remember the city you chose. Nothing here is used for advertising or tracking. More in our privacy policy.