Testes entre navegadores de alto impacto e esforço mínimo

O teste entre navegadores é demorado e trabalhoso. No entanto, os desenvolvedores são preguiçosos por natureza: aderindo ao princípio DRY, escrevendo scripts para automatizar coisas que de outra forma teríamos que fazer manualmente, fazendo uso de bibliotecas de terceiros; ser preguiçoso é o que nos torna bons desenvolvedores .

A abordagem tradicional para testar 'corretamente' em vários navegadores é testar em todos os principais navegadores usados ​​pelo seu público, movendo-se gradualmente para os navegadores mais antigos ou mais obscuros para dizer que você os testou. Ou, se o tempo e os recursos forem curtos, testar um pequeno subconjunto de navegadores ad hoc e esperar que a ausência de um bug lhe dê confiança na integridade do aplicativo. A primeira abordagem incorpora 'bom' desenvolvimento, mas é ineficiente, enquanto a segunda incorpora preguiça, mas não é confiável.

Leitura adicional no SmashingMag:

• A transição de Noah para o teste de usabilidade em dispositivos móveis
• Noções básicas de automação de teste para aplicativos, jogos e a Web móvel
• Como criar seu próprio plano de teste de site front-end
• Onde estão os melhores laboratórios de dispositivos abertos do mundo?

Nos próximos quinze minutos, espero poupar horas de esforço desperdiçado descrevendo uma estratégia de teste que não é apenas menos trabalhosa , mas mais eficaz na captura de bugs. Quero documentar uma estratégia de teste realista mais relevante e valiosa do que simplesmente “testar TODAS as coisas!”, baseando-me na minha experiência como Desenvolvedor em Teste no Jornalismo Visual da BBC.

Contexto

Como um aparte, vale ressaltar que fazemos mais do que apenas testes manuais em nossa equipe. O teste entre navegadores não substitui os testes de unidade (Jasmine/QUnit), testes funcionais (Cucumber) e, quando apropriado, testes de regressão visual automatizados (Wraith). De fato, os testes automatizados são mais baratos a longo prazo e são essenciais quando seu aplicativo atinge um determinado tamanho.

No entanto, alguns bugs só se manifestam em determinados navegadores, e a automação de testes ainda não entrou de forma confiável no domínio dos testes entre navegadores. Como um computador pode saber que seu evento de rolagem automatizado acabou de ocultar metade do título quando visualizado em um iPhone 4? Como ele saberia que isso é um problema? Até que a inteligência artificial cresça a um ponto em que os computadores entendam o que você construiu e apreciem a narrativa e a arte que você está tentando demonstrar, sempre haverá a necessidade de testes manuais. Como algo que deve ser realizado manualmente, devemos a nós mesmos tornar o processo de teste entre navegadores o mais eficiente possível.

Qual é o seu objetivo?

Antes de mergulhar cegamente no teste entre navegadores, decida o que você espera obter dele. O teste entre navegadores pode ser resumido como tendo dois objetivos principais:

1. Descobrindo bugs Isso envolve tentar quebrar seu aplicativo para encontrar bugs a serem corrigidos.
2. Verificação de sanidade Isso envolve verificar se a maioria do seu público recebe a experiência esperada.

A primeira coisa que quero que você tire deste artigo é que esses dois objetivos entram em conflito um com o outro .

Por um lado, sei que posso verificar a experiência de quase 50% do nosso público no Reino Unido apenas testando no Chrome (Desktop), Chrome (Android) e Safari (iOS 9). Por outro lado, se meu objetivo é encontrar bugs, vou querer lançar meu aplicativo da web nos navegadores mais problemáticos que temos que suportar ativamente: no nosso caso, IE8 e navegador nativo do Android 2.

Os usuários desses dois navegadores representam uma porcentagem cada vez menor de nosso público (atualmente em torno de 1,5%), o que torna os testes nesses navegadores um mau uso do nosso tempo se nosso objetivo é verificar a sanidade. Mas eles são ótimos navegadores para testar se você quiser ver o quanto seu aplicativo bem projetado pode se tornar quando lançado em um mecanismo de renderização obscuro.

As estratégias de teste tradicionais, compreensivelmente, dão mais ênfase ao teste em navegadores populares. No entanto, um número desproporcional de bugs existe apenas nos navegadores mais obscuros, que sob o modelo de teste tradicional não serão descobertos até o final do teste. Então você se depara com um dilema...

O que você faz quando encontra um bug no final da fase de teste de cauda longa?

1. Ignore o erro.
2. Corrija o bug e espere que você não tenha quebrado nada.
3. Corrija o bug e teste novamente em todos os navegadores testados anteriormente.

Em um mundo ideal, a última opção é a melhor, pois é a única maneira de ter certeza de que todos os navegadores ainda estão funcionando conforme o esperado. No entanto, também é monstruosamente ineficiente - e é algo que você provavelmente teria que fazer várias vezes. É o equivalente de teste manual de um tipo de bolha.

Portanto, nos encontramos em uma situação Catch-22: para eficiência máxima, queremos corrigir todos os bugs antes de iniciarmos os testes entre navegadores, mas não podemos saber quais bugs existem até começarmos a testar.

A resposta é ser inteligente sobre como testamos: cumprindo nossos objetivos de localização de bugs e verificação de sanidade testando de forma incremental, no que eu gosto de chamar de ataque trifásico .

Ataque Trifásico

Imagine que você está em uma zona de guerra. Você sabe que os bandidos estão agachados no QG do outro lado da cidade. À sua disposição, você tem um agente especial, uma equipe de guerrilheiros endurecidos pela batalha e um grande grupo de milícias locais levemente armadas. Você lança um ataque em três fases para recuperar a cidade:

1. Reconhecimento Envie seu espião para o QG inimigo para ter uma ideia de onde os bandidos podem estar escondidos, quantos deles existem e o estado geral do campo de batalha.
2. Ataque Envie sua equipe de crack direto para o coração do inimigo, eliminando a maioria dos bandidos em um ataque surpresa feroz.
3. Liberação Envie a milícia local para pegar os bandidos restantes e proteger a área.

Você pode trazer a mesma estratégia militar e disciplina para seus testes em vários navegadores:

1. Reconhecimento Realize testes exploratórios em um navegador popular em uma máquina de desenvolvimento. Tenha uma ideia de onde os insetos podem estar se escondendo. Corrija quaisquer bugs encontrados.
2. Invadir Teste manualmente em um pequeno punhado de navegadores problemáticos que provavelmente demonstrarão a maioria dos bugs. Corrija quaisquer bugs encontrados.
3. Clearance Sanity verificando se os navegadores mais populares entre seu público estão liberados para obter a experiência esperada.

Esteja você no campo de batalha ou testando o dispositivo, as fases começam com o mínimo de tempo gasto e crescem à medida que a operação se torna mais estável. Há muito reconhecimento que você pode fazer - você deve ser capaz de detectar alguns bugs em muito pouco tempo. O ataque é mais intenso e demorado, mas oferece resultados muito valiosos e estabiliza significativamente o campo de batalha. A fase de liberação é a mais trabalhosa de todas, e você ainda precisa se manter alerta para o caso de um vilão sem mancha aparecer do nada e te causar dano – mas é um passo necessário para poder afirmar com confiança que o campo de batalha está agora seguro.

As duas primeiras etapas do nosso ataque trifásico cumprem nosso primeiro objetivo: descoberta de bugs . Quando estiver confiante de que seu aplicativo é robusto, você desejará passar para a fase três do ataque, testando o número mínimo de navegadores que correspondem à maioria dos comportamentos de navegação do seu público, cumprindo o objetivo número dois: verificação de sanidade. Você pode então dizer com confiança apoiada quantitativamente que seu aplicativo funciona para X% do seu público.

Configuração: Conheça seu inimigo

Não entre na guerra de ânimo leve. Antes de começar a testar, você vai querer descobrir como os usuários estão acessando seu conteúdo.

Descubra as estatísticas do seu público (do Google Analytics ou de qualquer ferramenta que você use) e obtenha os dados em uma planilha em um formato que você possa ler e entender. Você desejará ver cada combinação de navegador e sistema operacional com uma porcentagem associada da participação total do mercado.

As estatísticas de uso do navegador só são úteis se puderem ser consumidas facilmente: você não quer ser presenteado com uma longa e assustadora lista de combinações de navegador/SO/dispositivo para testar. Além disso, testar todas as combinações possíveis é um esforço desperdiçado. Podemos usar nosso conhecimento de desenvolvedor web para consolidar heuristicamente nossas estatísticas.

Simplifique as estatísticas de uso do seu navegador

Como desenvolvedores da web, não nos importamos particularmente em qual sistema operacional o navegador de desktop está sendo executado – é muito raro que um bug do navegador se aplique a um sistema operacional e não ao outro – então mesclamos as estatísticas dos navegadores de desktop em todos os sistemas operacionais.

Também não nos importamos se alguém está usando o Firefox 40 ou Firefox 39: as diferenças entre as versões são insignificantes e a atualização das versões é gratuita e muitas vezes automática. Para facilitar nossa compreensão das estatísticas do navegador, mesclamos versões de todos os navegadores de desktop – exceto o IE. Sabemos que as versões mais antigas do IE são problemáticas e generalizadas, por isso precisamos rastrear seus números de uso.

Um argumento semelhante se aplica a navegadores de SO portáteis. Não nos importamos particularmente com a versão do Chrome ou Firefox para dispositivos móveis, uma vez que eles são atualizados com regularidade e facilidade – por isso, mesclamos as versões. Mas, novamente, nos preocupamos com as diferentes versões do IE, então registramos suas versões separadamente.

A versão do sistema operacional de um dispositivo é irrelevante se estivermos falando de Android; o importante é a versão do navegador Android nativo usado, pois este é um navegador notoriamente problemático. Por outro lado, qual versão do iOS um dispositivo está executando é muito relevante, pois as versões do Safari estão intrinsecamente vinculadas ao sistema operacional. Depois, há toda uma série de navegadores nativos para outros dispositivos: eles representam uma porcentagem tão pequena de nosso público geral que também têm seus números de versão mesclados.

Finalmente, temos uma nova onda de navegadores crescendo rapidamente em popularidade: navegadores no aplicativo, implementados principalmente em plataformas de mídia social. Este ainda é um terreno novo para nós, por isso estamos ansiosos em listar todas as plataformas de navegador no aplicativo e seus respectivos sistemas operacionais.

Depois de usar nosso conhecimento especializado de domínio para mesclar estatísticas relacionadas, reduzimos ainda mais a lista removendo todos os navegadores que representam menos de 0,05% de nosso público (sinta-se à vontade para ajustar esse limite de acordo com seus próprios requisitos).

Navegadores de desktop

Navegadores portáteis

Navegadores no aplicativo

Quando terminar, sua planilha deve ficar assim (ignore a coluna "Prioridade" por enquanto - falaremos sobre isso mais tarde):

Agora você tem sua planilha simplificada, mostrando os principais navegadores da perspectiva do desenvolvedor da Web, cada um associado a uma porcentagem total de participação no mercado. Observe que você deve manter esta planilha atualizada; atualizar uma vez por mês deve ser suficiente.

Agora você está pronto para embarcar no ataque trifásico.

1. Reconhecimento: encontre bugs independentes do navegador

Muito antes de pensar em sacar um dispositivo para testar, faça a coisa mais fácil possível: abra seu aplicativo da web em seu navegador favorito. A menos que você seja um masoquista completo, é provável que seja o Chrome ou o Firefox, ambos estáveis ​​e com suporte a recursos modernos. O objetivo deste primeiro estágio é encontrar bugs independentes do navegador .

Bugs independentes de navegador são erros de implementação que não têm nada a ver com o navegador ou hardware usado para acessar seu aplicativo. Por exemplo, digamos que sua página da web seja publicada e você comece a receber relatórios de bugs obscuros de pessoas reclamando que sua página parece lixo em seu HTC One no modo paisagem. Você perde muito tempo determinando qual versão de qual navegador foi usada, usando o modo de depuração USB do Android e procurando ajuda no StackOverflow, imaginando como diabos você vai consertar isso. Sem que você saiba, esse bug não tem nada a ver com o dispositivo: em vez disso, sua página parece com bugs em uma certa largura da janela de visualização, que por acaso é a largura da tela do dispositivo em questão.

Este é um exemplo de um bug independente do navegador que se manifestou falsamente como um bug específico do navegador ou do dispositivo. Você foi levado por um caminho longo e inútil, com relatórios de bugs agindo como ruído, ofuscando a causa raiz do problema. Faça um favor a si mesmo e pegue esse tipo de bug logo no início, com muito menos esforço e um pouco mais de previsão.

Ao corrigir os bugs agnósticos do navegador antes mesmo de começarmos o teste entre navegadores, devemos enfrentar menos bugs em geral. Eu gosto de chamar isso de efeito iceberg derretido . Estamos derretendo os insetos que estão escondidos sob a superfície, salvando-nos de cair e nos afogar no oceano - e nem percebemos que estamos fazendo isso.

Abaixo está uma pequena lista de coisas que você pode fazer em seu navegador de desenvolvimento para descobrir bugs independentes do navegador:

• Tente redimensionar para ver a capacidade de resposta. Houve um ponto de interrupção funky em algum lugar?
• Amplie e reduza. As posições de fundo do seu sprite de imagem foram tortos?
• Veja como o aplicativo se comporta com o JavaScript desativado. Você ainda recebe o conteúdo principal?
• Veja como fica o aplicativo com o CSS desativado. A semântica da marcação ainda faz sentido?
• Tente desativar JavaScript E CSS. Você está obtendo uma experiência aceitável?
• Tente interagir com o aplicativo usando apenas o teclado. É possível navegar e ver todo o conteúdo?
• Tente limitar sua conexão e veja a rapidez com que o aplicativo é carregado. Quão pesado é o carregamento da página?

Antes de passar para a fase 2, você precisa corrigir os bugs encontrados. Se não corrigirmos os erros agnósticos do navegador, acabaremos apenas relatando muitos erros falsos específicos do navegador mais tarde.

Ser preguiçoso. Corrija os bugs independentes do navegador. Então podemos passar para a segunda fase do ataque.

2. Invasão: teste primeiro em navegadores de alto risco

Quando corrigimos bugs, temos que ter cuidado para que nossas correções não introduzam mais bugs. Ajustar nosso CSS para corrigir o preenchimento no Safari pode quebrar o preenchimento no Firefox. Otimizar esse pouco de JavaScript para rodar mais suavemente no Chrome pode quebrá-lo completamente no IE. Cada mudança que fazemos traz riscos.

Para ter certeza de que as novas mudanças não prejudicaram a experiência em nenhum dos navegadores que já testamos, temos que voltar e testar nos mesmos navegadores novamente. Portanto, para minimizar a duplicação de esforços, precisamos ser inteligentes sobre como testamos.

Análise estatística da distribuição de bugs

Considere a tabela a seguir, onde o ícone de cruz significa que o navegador tem o bug.

Digamos que vamos testar nosso conteúdo em ordem crescente de risco: navegador de baixo risco, navegador de risco médio, navegador de alto risco. Se isso ajudar você a visualizar isso, esses navegadores podem mapear para o Google Chrome, IE 9 e IE 6, respectivamente.

Testando o navegador de baixo risco (Chrome) primeiro, encontraríamos e corrigiríamos o bug nº 2. Quando passamos para o navegador de Risco Médio, o bug #2 já está corrigido, mas descobrimos um novo bug: #4. Mudamos nosso código para corrigir o bug – mas como podemos ter certeza de que não quebramos algo no navegador de baixo risco? Não podemos ter certeza, então temos que voltar e testar nesse navegador novamente para verificar se tudo ainda funciona conforme o esperado.

Agora passamos para o navegador de alto risco e encontramos os bugs nº 1, nº 3 e nº 5, que exigem um retrabalho significativo para serem corrigidos. Uma vez que estes foram corrigidos, o que temos que fazer? Volte e teste novamente os navegadores de risco Médio e Baixo. Isso é muita duplicação de esforço. Tivemos que testar nossos três navegadores um total de seis vezes.

Agora vamos considerar o que teria acontecido se tivéssemos testado nosso conteúdo em ordem decrescente de risco.

Logo de cara, encontraríamos os erros nº 1, nº 3, nº 4 e nº 5 no navegador de alto risco. Depois de corrigir esses bugs, iríamos direto para o navegador de risco médio e descobriríamos o bug nº 2. Como antes, essa correção pode ter quebrado algo indiretamente, portanto, é necessário voltar ao navegador de alto risco e testar novamente. Por fim, testamos no navegador de baixo risco e não descobrimos novos bugs. Nesse caso, testamos nossos três navegadores em um total de quatro ocasiões diferentes, o que representa uma grande redução no tempo necessário para descobrir e corrigir efetivamente o mesmo número de bugs e validar o comportamento do mesmo número de navegadores .

Pode haver uma pressão sobre os desenvolvedores para testar primeiro nos navegadores mais populares, descendo para os navegadores menos usados ​​no final de nossos testes. No entanto, os navegadores populares são provavelmente navegadores de baixo risco.

Você sabe que precisa dar suporte a um determinado navegador de alto risco, então tire esse navegador do caminho logo no início. Não desperdice esforço testando navegadores que são menos propensos a gerar bugs, porque quando você muda para navegadores que geram mais bugs, você só terá que voltar e olhar para os navegadores de baixo risco novamente.

Corrigir bugs em navegadores ruins torna seu código mais resiliente em bons navegadores

Muitas vezes você descobrirá que os bugs que surgem nesses navegadores problemáticos são o resultado inesperado de um código ruim de sua parte. Você pode ter estilizado desajeitadamente um div para se parecer com um botão, ou hackeado em um setTimeout antes de acionar algum comportamento arbitrário; existem melhores soluções para ambos os problemas. Ao corrigir os bugs que são sintomas de código ruim, você provavelmente estará corrigindo bugs em outros navegadores antes mesmo de vê-los. Há aquele efeito de derretimento do iceberg novamente.

Ao verificar o suporte a recursos, em vez de assumir que um navegador suporta algo, você está corrigindo esse bug doloroso no IE8, mas também está tornando seu código mais robusto para outros ambientes hostis. Ao fornecer esse fallback de imagem para o Opera Mini, você está incentivando o uso de aprimoramento progressivo e, como subproduto, está melhorando seu produto mesmo para usuários de navegadores que cortam a mostarda. Por exemplo, um dispositivo móvel pode perder sua conexão 3G com apenas metade dos ativos do seu aplicativo baixados: o usuário agora obtém uma experiência significativa que não teria antes.

Mas tome cuidado: se você não for cuidadoso, corrigir bugs em navegadores obscuros pode piorar seu código . Resista à tentação de farejar a string user-agent para entregar conteúdo condicionalmente a navegadores específicos, por exemplo. Isso pode corrigir o bug, mas é uma prática completamente insustentável. Não comprometa a integridade de um bom código para suportar navegadores estranhos.

Identificando navegadores problemáticos

Então, o que é um navegador de alto risco? A resposta é um pouco confusa e depende dos recursos do navegador que seu aplicativo usa. Se seu JavaScript usa indexOf , ele pode quebrar no IE 8. Se seu aplicativo usa position: fixed , você deve verificar no Safari no iOS 7.

Can I Use é um recurso inestimável e um bom lugar para começar, mas esta é uma daquelas áreas que novamente vem da experiência e da intuição do desenvolvedor. Se você lançar aplicativos da Web regularmente, saberá quais navegadores sinalizam problemas repetidamente e poderá refinar sua estratégia de teste para acomodar isso.

A coisa útil sobre bugs que você encontra em navegadores problemáticos é que eles geralmente se propagam. Se houver um bug no IE9, é provável que o bug também exista no IE8. Se algo parece estranho no Safari no iOS 7, provavelmente ficará ainda mais pronunciado no iOS 6. Percebeu um padrão aqui? Os navegadores mais antigos tendem a ser os mais problemáticos. Isso deve ajudá-lo a criar uma boa lista de navegadores problemáticos.

Dito isto, faça backup com estatísticas de uso. Por exemplo, o IE 6 é um navegador muito problemático, mas não nos preocupamos em testá-lo porque sua participação total no mercado é muito baixa. O tempo gasto corrigindo bugs específicos do IE6 não valeria o esforço para o pequeno número de usuários cuja experiência seria melhorada.

Nem sempre são os navegadores mais antigos que você deseja testar na fase de invasão. Por exemplo, se você tiver um projeto de tela 3D WebGL experimental com fallback de imagem, os navegadores mais antigos obterão apenas a imagem de fallback, portanto, é improvável que encontremos muitos bugs. O que gostaríamos de fazer é alterar nossa escolha de navegador problemático com base no aplicativo em questão. Nesse caso, o IE9 pode ser um bom navegador para testar porque é a primeira versão do IE que suporta canvas.

Os navegadores proxy modernos (como o Opera Mini) também podem ser uma boa opção para um teste de invasão, se seu aplicativo fizer uso de recursos CSS3, como gradientes ou raio de borda. Um erro comum é renderizar texto branco em um gradiente não suportado, resultando em texto branco sobre branco ilegível.

Ao escolher seus navegadores problemáticos, use sua intuição e tente antecipar onde os bugs podem estar escondidos.

Diversifique seus navegadores problemáticos

Navegadores e versões de navegadores são apenas uma parte da equação: o hardware também é uma consideração importante. Você vai querer testar seu aplicativo em uma variedade de tamanhos de tela e diferentes densidades de pixels e tentar alternar entre o modo retrato e paisagem.

Pode ser tentador agrupar navegadores relacionados porque há um desconto percebido no custo do esforço. Se você já tem o VirtualBox aberto para testar o IE8, agora pode parecer um bom momento para testar no IE9, IE10 e IE11 também. No entanto, se você estiver nos estágios iniciais de teste de seu aplicativo da Web, você desejará lutar contra essa tentação e, em vez disso, escolher três ou quatro combinações de hardware de navegador que são marcadamente diferentes umas das outras, para obter o máximo de cobertura sobre o total espaço de bug como você possivelmente pode.

Embora eles possam variar de projeto para projeto, aqui estão meus navegadores problemáticos atuais de escolha:

• IE 8 em uma VM Windows XP;
• navegador Android 2 nativo em um tablet Android de médio porte;
• Safari em um iPhone 4 com iOS 6;
• Opera mini (só vale a pena testar com conteúdo que deve funcionar sem JavaScript, como datapics).

Ser preguiçoso. Encontre o maior número possível de bugs lançando seu aplicativo nos navegadores e dispositivos suportados mais problemáticos. Com esses bugs corrigidos, você pode passar para a fase final do ataque.

3. Liberação: verificação de sanidade

Agora você testou seu aplicativo nos navegadores mais severos que você tem que suportar, com sorte, pegando a maioria dos bugs. Mas seu aplicativo ainda não está completamente livre de bugs. Estou constantemente surpreso com o quão diferente até as versões mais recentes do Chrome e do Firefox renderizarão o mesmo conteúdo. Você ainda precisa fazer mais alguns testes.

É aquela velha regra 80:20. Figurativamente, você corrigiu 80% dos bugs depois de testar 20% dos navegadores. Agora, o que você quer fazer é verificar a experiência de 80% do seu público testando 20% de navegadores diferentes.

Priorizando os navegadores

A abordagem simples e óbvia agora é voltar aos testes 'tradicionais' entre navegadores, abordando cada navegador em ordem decrescente de participação de mercado. Se o Chrome desktop for a maior proporção de compartilhamento de navegador do seu público, seguido pelo Safari no iOS 8, seguido pelo IE11, então faz sentido testar nessa ordem, certo?

Esse é um sistema amplamente justo, e não quero complicar demais esta etapa se seus recursos já estiverem sobrecarregados. No entanto, o fato é que nem todos os navegadores são criados iguais. Na minha equipe, agrupamos os navegadores de acordo com uma árvore de decisão que leva em consideração o uso do navegador, a facilidade de atualização e se o navegador é ou não o padrão do sistema operacional.

Até agora, sua planilha deveria ter uma coluna para o navegador e uma coluna para sua participação de mercado; agora você precisa de uma terceira coluna, designando em qual prioridade o navegador se enquadra. Verdade seja dita, esse trabalho de priorização deveria ter sido feito antes do lançamento do ataque trifásico, mas para os propósitos deste artigo fazia mais sentido descrevê-lo aqui, pois as prioridades não são realmente necessárias até a fase de liberação.

Aqui está nossa árvore de decisão:

Projetamos nossa árvore de decisão para que os navegadores P1 cubram aproximadamente 70% de nosso público. Os navegadores P1 e P2 combinados cobrem aproximadamente 90% do nosso público. Finalmente, os navegadores P1, P2 e P3 nos dão uma cobertura de audiência quase completa. Nosso objetivo é testar em todos os navegadores P1, seguido pelo P2, seguido pelo P3, em ordem decrescente de participação de mercado.

Como você pode ver na planilha anterior neste artigo, temos apenas alguns navegadores P1. O fato de podermos verificar a experiência de mais de 70% do nosso público tão rapidamente significa que temos poucas desculpas para não testar novamente nesses navegadores se a base de código mudar. À medida que avançamos para os navegadores P2 e P3, temos que despender esforços cada vez maiores para verificar a experiência de um tamanho de público cada vez menor, por isso temos que definir ideais de teste mais realistas para os navegadores de prioridade mais baixa. Como orientação:

• P1 . Devemos verificar a integridade desses navegadores antes de assinar o aplicativo. Se fizermos pequenas alterações em nosso código, devemos verificar a integridade desses navegadores novamente.
• P2 . Devemos verificar a integridade desses navegadores antes de assinar o aplicativo. Se fizermos grandes alterações em nosso código, devemos verificar a integridade desses navegadores novamente.
• P3 . Devemos verificar esses navegadores uma vez, mas somente se tivermos tempo.

Não se esqueça da necessidade de diversificar seu hardware. Se você puder testar em vários tamanhos de tela diferentes e em dispositivos com recursos de hardware variados enquanto segue esta lista, faça isso.

Resumo: o ataque trifásico

Depois de se esforçar para conhecer seu inimigo ( simplificando as estatísticas do seu público e agrupando os navegadores em prioridades ), você poderá atacar em três etapas:

1. Reconnaissance : teste exploratório em seu navegador favorito, para encontrar bugs independentes do navegador.
2. Raid : testando em seus navegadores suportados mais problemáticos em uma variedade de hardware, para encontrar a maioria dos bugs .
3. Clearance : verificar a experiência do seu aplicativo nos navegadores mais usados ​​e estrategicamente importantes, para dizer com confiança garantida quantitativamente que seu aplicativo funciona .