Requirements review
We read the specifications and find contradictions before development starts. The cheapest bugs are the ones found in the requirements.
The value of testing lies not in finding bugs as such but in the accumulated set of scenarios that gets checked every time.
We read the specifications and find contradictions before development starts. The cheapest bugs are the ones found in the requirements.
Documented scenarios with the expected result. They are reused rather than invented again each time.
Main scenarios, boundary values and behaviour on invalid input.
Checking that the new work has not broken the old. The main cause of recurring defects.
With reproduction steps, the environment and the expected behaviour, so the developer does not have to guess.
What was checked, what was not, and which risks remain at the point of release.
The first cycle takes longer because the test cases are written from scratch. After that regression runs faster.
We learn the product and what is critical for the business as opposed to secondary.
What is checked and to what depth, and where the boundaries lie. Testing everything endlessly is impossible.
Running the scenarios, documenting findings and retesting the fixes.
A readiness verdict with the list of remaining risks.
A test report does not say there are no bugs. It says what was checked, what was not and which risks remain. Claiming there are no bugs is unprovable, whereas a deliberate decision to release with known risks is normal practice.
They do, but they look at their own work with a tired eye and check the scenario they had in mind. A dedicated tester checks what the developer did not anticipate: invalid input, a dropped connection, a button pressed twice.
Roughly a quarter to a third of development time. Less than that means only the main scenarios are checked and some defects will reach users. That is acceptable if the decision is deliberate.
Yes, and it is a common request: the system exists and its quality raises questions. We start with a review and write the test cases from the product itself rather than from documentation, which usually does not exist.
Tell us what the system is and what raises doubts. We will draw up a test plan and estimate the scope.
Request received
We can already see it. We will reply within one business day, and for urgent matters we will bring in the on-duty engineer right away.
City not found. Please check the spelling.