> OTOH, it's amazing that apparently they don't have UI tests for FF mobile.
Why? They don't have UI tests for Opera on the Nintendo Wii either, and at this point I bet the install base for Wii-Opera is still larger than the install base for FF mobile.
TBH, when I was there it surprised me that Google didn't have a dedicated hardware test-bench room with rows upon rows of browser deployments that every UI change needed to be burn-in tested on, but... They don't. They never did. In general, their strategy is to be nimble and deploy rapidly (with the expectation they can roll back rapidly). In that context, it actually makes sense why they don't have that warehouse of test-bench installations... They'd slow-down rollbacks as well as rollouts.
A handful of projects have dedicated testing targets. They're driven mostly by the ideology of individual Googlers (some people really like Firefox) and a handful of high-value users that have specific installs Google isn't interested in pissing off. Since they do very little (relatively speaking) B2B business, that's a very short list of names.
That sounds pretty far from being nimble and deploying rapidly. Not really a knock on the people doing the work — doing stuff in high stress sucks. But it's clear that they're intentionally deprioritizing a competitor.
For one, that "deprioritize a competitor" is not clear at all. Why would that be so? Isn't it far more likely, given the rarity of these events, that a test regression occurred or some other subtle issue rather than assumed malfeasance?
For two, that "next update in 12 hours" is user comms. For me, at least, google.com works fine both on curl and my browser. That's a fairly normal cadence for big companies.
On the larger point about "nimble and deploying rapidly", the people who generally brag about "being nimble and deploying rapidly" almost never serve an even 1/100th the audience the size of Google.com does, and it's really questionable if, at that scale, you actually want to risk global regressions even on trivial bugs.
So I don't know what that user is talking about, and I agree with you that they are obviously not that.
That approach may be antithetical to the modern startup engineer frantic to prove their stock's hypothetical worth to their investors, unconcerned about trivial revenue loss from frontpage issues because of whatever latest node.js drama nuked their continuously deployed website. But the fact that "the landing search page is broken for 1% of users in a rare but public use case" is news at all is because Google's approach for search sets our expectations that this won't happen.
I think the parent comment's point is: if this were affecting a version of Google-branded Chrome with similar market share, do you think we would still be getting "next update in 12 hours"?
I remember an internal mantra in Google along the lines of "if you break something in production, roll back first, ask questions about how it happened later, even if you think it's a simple fix". It feels telling that this is not what is happening in this circumstance.
They're the only one (I can find) with "Mobile" inside the parens; bet you money the issue is a badly-formatted regex tripping over the paren / symbol combination and thinking that UA describes some deny-listed crawler somewhere (or falls off the end of recognizable UAs and trips a fallback to "Vend nothing").
Since they're always testing on Chrome Desktop, and Chrome Mobile emits an almost-identical UA string, my previous statement holds: issues with Chrome mobile are generally more likely to come up in testing on Chrome Desktop than issues in Firefox Mobile are likely to come up in testing on Chrome Desktop.
Google's strategy for search ux is decidedly not "nimble and rapid" and I don't understand why anyone with first hand knowledge would ever suggest that.
It is gated on a lot of things, especially relative to early days of the company. It's just that browser compatibility isn't generally one of those things... They still handle that by the belief they can roll back quickly.
Relatively speaking, you can still undo the change to the front page faster than you can, say, roll out a new version of a desktop application, especially if the change fixes an active fire.
Why? They don't have UI tests for Opera on the Nintendo Wii either, and at this point I bet the install base for Wii-Opera is still larger than the install base for FF mobile.
TBH, when I was there it surprised me that Google didn't have a dedicated hardware test-bench room with rows upon rows of browser deployments that every UI change needed to be burn-in tested on, but... They don't. They never did. In general, their strategy is to be nimble and deploy rapidly (with the expectation they can roll back rapidly). In that context, it actually makes sense why they don't have that warehouse of test-bench installations... They'd slow-down rollbacks as well as rollouts.
A handful of projects have dedicated testing targets. They're driven mostly by the ideology of individual Googlers (some people really like Firefox) and a handful of high-value users that have specific installs Google isn't interested in pissing off. Since they do very little (relatively speaking) B2B business, that's a very short list of names.