O que é cross browser testing? Três motores, não vinte navegadores

Cross browser testing é verificar que o seu site funciona nos navegadores que os seus visitantes usam de facto, e não naquele que está na sua secretária. Essa definição é pouco vistosa e está completa, e quase todos os artigos sobre o tema lhe entregam a seguir uma grelha com trinta combinações de navegador e versão, e é aí que a prática começa a correr mal.

Comece antes pelos motores. Há três que interessam: Blink, que é o Chrome, o Edge, o Opera, o Brave e a maior parte do resto; WebKit, que é o Safari em todo o lado e qualquer navegador em iOS seja qual for o nome que tenha; e Gecko, que é o Firefox. Que o Chrome e o Edge discordem sobre o seu layout é raro, porque são o mesmo motor de renderização com um invólucro diferente à volta. Que o Chrome e o Safari discordem é vulgar.

Testar trinta navegadores é sobretudo testar o Blink trinta vezes.

O que difere hoje, de facto

A era dos prefixos de fabricante acabou, e as diferenças que restam são de outra natureza. Quatro categorias cobrem quase todas.

• Codecs e multimédia. A categoria mais cara, porque falha por completo em vez de falhar no aspeto. Um vídeo que o navegador não consegue descodificar não é um vídeo degradado; é uma mensagem de erro.
• APIs que um motor não lançou. A deteção de funcionalidades é a resposta, e o modo de falha é uma funcionalidade que silenciosamente não faz nada, em vez de uma página com mau aspeto.
• Casos limite de layout. Menos do que já houve, mas os que restam tendem a estar nas partes mais recentes da especificação, exatamente onde se vai buscar a novidade.
• Cadência de lançamento. O motor do Safari é atualizado juntamente com o sistema operativo, por isso “o Safari mais recente” é uma afirmação sobre há quanto tempo alguém atualizou o seu Mac ou o seu telefone.

Vale a pena nomear as categorias porque exigem respostas diferentes. Os codecs exigem uma alternativa servida na página. As APIs em falta exigem deteção. O layout exige que se olhe para ele. A cadência exige as suas analíticas.

Um exemplo trabalhado, e foi o nosso

A nossa extensão grava vídeo em VP9 dentro de um contentor WebM. O Safari não tem descodificador de VP9. A página de partilha entregava ao navegador uma única fonte construída a partir do tipo do próprio ficheiro guardado, e um elemento de vídeo HTML a que se dá uma só fonte que não consegue reproduzir não se degrada: falha.

Por isso, durante algum tempo, um link enviado a alguém num Mac mostrava-lhe a palavra Error. Toda a promessa do produto é um link que outra pessoa possa abrir, e para um motor essa promessa estava quebrada.

Três coisas sobre como aquilo passou despercebido são típicas da categoria, e é por isso que vale a pena escrevê-lo em vez de o corrigir em silêncio.

O que tínhamos

Testes automatizados, todos a passar, todos a correr no Chrome. Nada registou um erro, porque do ponto de vista do servidor nada tinha falhado: um ficheiro foi servido, e o navegador não o conseguiu usar

O que o teria apanhado

Abrir uma gravação partilhada no Safari, uma vez. Sem ferramentas nenhumas, e sem que fosse preciso existir qualquer suite

Quem soube foi o destinatário. Quem enviou o link nunca soube, porque nada lhe diz que a página que partilhou não funcionou para a pessoa com quem a partilhou. É essa a propriedade que define as falhas entre motores: do sítio onde está, são invisíveis.

A correção foi codificar uma cópia em H.264 ao lado de cada carregamento e oferecer as duas fontes, e depois gravar diretamente em MP4 onde o navegador o permite.

Por onde começar, e não é uma matriz

Dois dados decidem a sua lista, e nenhum deles é um palpite.

As suas analíticas. Não a quota de mercado mundial. Os navegadores que os seus visitantes usam, nos seus países, nas suas páginas. Uma ferramenta B2B na Alemanha e um site de consumo no Brasil dão respostas diferentes, e ambas diferem dos números mundiais que qualquer artigo comparativo cita.

O seu registo de erros. Os erros agrupados por navegador dizem-lhe onde já se está a partir alguma coisa, o que é melhor priorização do que qualquer palpite sobre onde se poderá partir.

Daí sai uma forma que funciona: um smoke test nos três motores, e testes aprofundados nos seus dois principais. O smoke test é a mesma ideia que em qualquer outro lado - a página carrega, consegue entrar na conta, consegue completar o único fluxo que interessa - e fazê-lo no Safari e no Firefox apanha em minutos toda a categoria dos codecs e das APIs em falta.

Diga a matriz em voz alta no seu plano de testes, incluindo o que fica fora do âmbito. “Não testamos o Firefox em Android” é uma decisão quando está escrito e um acidente quando não está.

O que as ferramentas cobrem e o que não cobrem

Os serviços comerciais alugam-lhe máquinas com navegadores instalados, o que resolve o problema verdadeiro de não poder correr o Safari em Linux nem ter todas as versões do iOS na sua secretária. Vale o que custa quando é preciso.

O que não resolvem é saber para onde olhar. Uma captura da sua página em doze navegadores são doze capturas que alguém tem de comparar, que é o problema que os testes de regressão visual existem para automatizar - e essa suite tem o mesmo ponto cego, porque só verifica os navegadores de que lhe falou.

A automatização, seja de que tipo for, também se dá mal com a falha que aqui mais interessa. Um vídeo que não reproduz, um tipo de letra que não carrega, um campo de data que num motor aparece como uma caixa de texto: tudo isso passa qualquer asserção sobre o DOM, porque o DOM está bem. É a renderização que não está.

Os relatos são a outra metade

Por muito boa que a matriz seja, algum motor, alguma versão, algum dispositivo que não testou vai produzir um erro para uma pessoa real. A questão é se chega a saber.

É esse o argumento para facilitar o relato a partir de onde cada um está, e para que o relato transporte o navegador e a versão sem pedir a quem relata que os saiba. “No meu telemóvel não funciona” custa um dia. “Safari 26.1 em iOS, na gravação a área de vídeo aparece em branco, a consola diz que a fonte não é suportada” custa uma tarde, e a diferença está inteiramente no que o relato trazia, não no que quem relatou sabia.

Que é o limite honesto deste artigo: o cross browser testing estreita a distância, e os relatos que chegam dos navegadores que não cobriu são a forma de descobrir onde a distância ainda está. Nenhum substitui o outro, e uma equipa que faz só um deles tem meia imagem.