Requirements analysis
We read the specification and find contradictions before any code is written. Defects caught here are the cheapest of all.
The main value lies not in individual defects found but in the accumulated set of scenarios run from version to version.
We read the specification and find contradictions before any code is written. Defects caught here are the cheapest of all.
Documented tests with expected results, suitable for reuse.
The main paths, boundary values, the reaction to deliberately invalid data.
We confirm the new work has not broken what already worked. This is where most regressions are found.
The steps, the environment and the expected behaviour so the developer does not have to guess.
What was tested, what fell outside the scope and which risks you accept by releasing.
The first cycle takes longer because the scenario set is written from scratch. Subsequent runs go considerably faster.
We get to know the product and establish what is critical for the business and what is secondary.
We define the scope and boundaries of the testing. It is impossible to check an infinite set of variants.
We walk the scenarios, record what we find and re-check after the fixes.
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.
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.
Describe the system and what worries you. We will draw up a test plan and estimate the effort.
Request received
It is already with a manager. You will get an answer within the working day, and urgent requests go to the duty engineer immediately.
There is no such city in the list. Check the spelling.