This week I finally closed a browser QA gap in eventOS that had been hanging around through several rounds of product work.
The suite now runs the same 141 scenarios against two versions of the interface: the stable one and the redesign. Scenarios that do not apply to a version are skipped on purpose and counted, and none fail in either.
The count matters less than what had to change to get there.
Some failing tests were protecting the wrong thing
A browser suite can look like product protection while quietly becoming a museum of old selectors and old copy.
That had happened in a few places. The product had moved on, but parts of the suite were still asking whether yesterday's DOM structure was present. Fixing those tests did not mean weakening them. It meant moving the assertion back to the behaviour that mattered.
An attendee tour should survive navigation and still bring the relevant target into view. A scanner should preserve its manual-entry contract. Ticket geometry should remain usable across the widths we support. An account-access test should care about the access boundary, not a sentence that happened to sit beside it six weeks ago.
That distinction became especially important because eventOS now has two visual modes that share the same product responsibilities.
The redesign should not need a second definition of correctness
I did not want a stable suite that passed because it understood the old interface and a redesign suite that passed because it had its own looser rules.
Both modes now run the same discovered scenario count. The visual implementation can differ, but the journeys and boundaries still have to hold.
That forced a cleaner separation between product truth and presentation detail. Where the redesign genuinely changed a surface, the test had to recognise the supported variation without turning into a blanket escape hatch.
The homepage hero is a good example. The redesign can use a newer treatment while the stable experience keeps the earlier one. The assertion now understands that deliberate product variation instead of pretending one of them is the only valid homepage.
Geometry belongs in the release conversation too
The closeout was not only about clicks and text.
I also kept geometry and overflow checks in the release evidence because a route can be functionally correct and still be broken at the widths people actually use.
That work sits alongside the browser matrix: global horizontal overflow masks have been removed, intentional overflow is owned locally, organiser shell geometry is exercised across widths and pointer types, and the assistant launcher is clamped against the live navigation boundary rather than a hard-coded offset.
Those are small implementation details individually. Together they make the interface much harder to accidentally break with the next responsive or navigation change.
A green browser suite is a checkpoint, not a finish line
I do not read a passing run as proof that the product has no browser defects.
What it tells me is narrower and more useful: the journeys we have chosen to make executable are currently passing in both supported visual modes, and the known stable failures in that matrix have been closed rather than ignored.
There are still separate gates that a local browser suite cannot replace. Authenticated production checks, provider behaviour and deployment infrastructure each need their own evidence.
That separation is becoming a recurring theme in how I test products: make each piece of evidence say exactly what it proves, and resist the temptation to let one green signal stand in for the whole system.