Услуга · Тестирование и QA

Functional testing

The aim is to confirm the product behaves correctly not only on the happy path but on all the others too. A defect found before release costs several times less than one reported by a customer.

Scenarios
documented and reusable
Before release
a full run
Defects
with steps to reproduce
Риски
listed in writing

What the work includes

The main value lies not in individual defects found but in the accumulated set of scenarios run from version to version.

Discuss the scope

Requirements analysis

We read the specification and find contradictions before any code is written. Defects caught here are the cheapest of all.

The scenario set

Documented tests with expected results, suitable for reuse.

Functional checks

The main paths, boundary values, the reaction to deliberately invalid data.

Re-testing after fixes

We confirm the new work has not broken what already worked. This is where most regressions are found.

Writing up the defects

The steps, the environment and the expected behaviour so the developer does not have to guess.

The verdict

What was tested, what fell outside the scope and which risks you accept by releasing.

How it goes

The first cycle takes longer because the scenario set is written from scratch. Subsequent runs go considerably faster.

01

Getting to know it

We get to know the product and establish what is critical for the business and what is secondary.

02

План

We define the scope and boundaries of the testing. It is impossible to check an infinite set of variants.

03

The run

We walk the scenarios, record what we find and re-check after the fixes.

04

The verdict

A release readiness statement listing the uncovered areas and the remaining risks.

A defect without steps to reproduce will be closed by the developer as unreproducible. A message saying «checkout does not work» comes straight back and travels between people for weeks. Precise steps, data and environment cut the fix time several times over.

Questions and answers

They do test, but they walk the path they had in mind and do not notice their own assumptions. A separate person tests exactly what the author did not think of: invalid input, a lost connection, a button pressed twice.

Roughly a quarter to a third of the development time. Less than that and only the main paths are covered, so some defects will reach users. Sometimes that is a deliberate and perfectly reasonable choice.

Yes, and it is a common request: the system is live but the quality raises questions. We start by studying it and build a set of scenarios from the actual behaviour, since documentation as a rule does not exist.

We will test your product

Describe the system and what worries you. We will draw up a test plan and estimate the effort.