Guide · Production quality
Automated tests and synthetic monitoring: complementary roles
A successful test helps validate a release. It does not confirm that the same journey will remain available over time. Continuous monitoring extends that validation around an observable business outcome.
Comparison of roles
What automated tests provide before production
Automated tests provide repeatable feedback during product development and delivery. They check the behaviours selected by the team and reduce the risk of publishing a regression that is already identifiable in that context.
This validation remains essential. But it answers a question within the delivery process. It is not a permanent observation of the live service.
What continuous monitoring adds after release
Synthetic monitoring regularly checks a defined path from its starting point to its business outcome. It can follow sign-in, search, adding an item to a cart, a request or a confirmation without reducing the view to the availability of one page.
Naosaki connects the journey outcome with failure evidence and performance history. This helps teams review a disruption and its evolution without claiming to explain its origin automatically.
Why can a tested journey still fail?
The service continues to change after release: content, configuration, dependencies, available data and later changes may alter the observed experience. A page may also respond while an essential step in the journey no longer completes.
Monitoring does not challenge the quality of the tests. Its role is to provide a regular view of a small number of journeys whose disruption would have a business or operational impact.
Connect QA, product and operations around the same journey
Start with a shared business definition: starting point, essential steps, expected final outcome, important variants and possible impact. This prevents the same journey from having a different name for each team.
- Validate expected behaviour during the delivery cycle.
- Choose a representative variant to monitor over time.
- Connect failures with context useful to the teams involved.
- Review the scope when the journey or its importance changes.
Which journeys should be monitored first?
Prioritise an important, repeatable journey with an observable outcome. Signing in to a customer portal, receiving confirmation for a form or moving an item from its product page towards an order are easier to frame than a broad goal such as “the site works”.
For a deeper framing method, read the guide to synthetic monitoring for user journeys and the page about failure evidence.
Frequently asked questions
Does synthetic monitoring replace automated tests?
No. Automated tests validate behaviour in a delivery context. Synthetic monitoring regularly checks whether a defined journey remains usable on the live service. They address different questions at different moments.
Why monitor a journey that has already been tested?
A successful test before release does not describe the lasting state of the service afterwards. The journey may change with its environment, content, dependencies or subsequent releases.
Which journey should be monitored first?
Choose an important, repeatable journey with an observable final outcome, such as signing in, confirming a request or reaching an order stage.
What should QA, product and operations share?
A shared journey name, its business steps, expected outcome, disruption impact and the information needed to review a failure.
Next step
Connect your tests to a critical journey
Tell us about the journey, its expected outcome, the checks already in place and the possible impact of a disruption. We will assess the appropriate monitoring scope with you.