NovAfter a release, I test more than the new page
A feature can work perfectly and still break shared components, routes or user journeys elsewhere on the platform.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A new page can pass every local check and still make the release worse.
A shared component shifts the layout of older cards. A filter changes URL behaviour. A data change breaks comparison. None of those failures appears if testing ends with the ticket that was just completed.
After a shared-component release I test several page families, including the catalogue and a developer profile, because regressions often show up far from the page that triggered the work.
Start with the blast radius
Not every change deserves the same test scope. Editing one paragraph is usually local. Modifying a shared card, router, language mechanism or data source can affect many parts of the site.
Before release, I map what depends on the changed piece: templates that reuse the component, routes that rely on the rule, interfaces that display the same field, and integrations that consume the same data.
That is more efficient than trying to retest everything every time. The test surface expands when the architecture says it should.
Walk through journeys, not files
Opening the changed page is a weak test. Browse from the catalogue, open a property, compare it, switch language, submit a form, return with the browser back button and repeat the important steps on mobile.
The exact journey depends on the change. Shared cards need checks across different page families. Data changes need checks everywhere the field is rendered. Routing changes need old links, unusual parameter combinations and saved URLs.
Browser state matters too. A clean development session can hide problems that appear with stale cache, narrow screens or back-navigation.
Release quality continues after deployment
Pre-release testing cannot cover every real combination. I still want failures to be easy to recognise and associate with the change that caused them.
Useful safeguards include clear error logging, a small set of representative pages for post-release checks, and a predictable way to reverse a critical change if needed. The goal is not elaborate process for its own sake; it is shortening the distance between a regression appearing and someone understanding it.
Reusable architecture makes development efficient because many pages share the same code. That same property increases the cost of a shared mistake.
A release is complete when the new feature works and the important journeys that already existed still work too.