A test phase can find defects. Quality Engineering also asks why those defects were allowed to become expensive. The useful work begins during discovery: who will use the product, which journeys matter, what could go wrong and what evidence would make a release acceptable?
In design, those questions become concrete. Can someone complete the journey with a keyboard? What happens when a request fails? What should a restricted user be able to see? Reviewing these states before implementation gives the team something more useful than a picture of the happy path.
During the build, checks grow with the product. A small unit test may suit a calculation; an API test may suit an integration; a browser test may suit a complete enquiry or buying journey. Each should protect a behaviour people depend on, rather than duplicate implementation details.
Before launch, the team reviews the evidence and the gaps. A passing suite does not mean every behaviour was tested. A useful release review says what was checked, what failed, what was fixed and what remains uncertain, with a recovery plan appropriate to the change.
After launch, the same discipline supports improvement. Monitoring, customer feedback and support findings inform the next checks. Tests are maintained as the service changes, so they remain a useful part of everyday delivery.