O que o teste manual entre navegadores custa realmente às agências

As agências web vivem raramente de um único projeto. O caso normal é uma carteira: vinte, trinta, cinquenta sites de clientes, que são acompanhados, atualizados e mantidos a funcionar. Desse acompanhamento faz parte um trabalho que quase nunca aparece como rubrica própria numa proposta e que, ainda assim, surge com regularidade: verificar, depois de cada alteração, se a página continua em todo o lado com o aspeto que deve ter. Este trabalho invisível tem um preço muito visível — basta calculá-lo uma vez.

Um exemplo de cálculo, deliberadamente conservador: um site de cliente tem oito tipos de página que cobrem o risco de layout — página inicial, dois modelos de conteúdo, panorâmica de serviços, formulário de contacto, artigo de blogue, páginas legais, página de erro. A verificação faz-se em três navegadores e três classes de dispositivo. Isso dá 72 vistas por site e por ronda. Quem precisa de apenas meio minuto por vista — abrir, deslizar, olhar — fica ocupado mais de meia hora. Por site. Por ronda.

Ora, este número multiplica-se em duas direções. Primeiro, pela carteira: com trinta sites acompanhados, a meia hora transforma-se num dia de trabalho inteiro sem fazer mais nada senão olhar. Segundo, ao longo do tempo: os sistemas de gestão de conteúdos e os seus plugins querem ser atualizados com regularidade, muitas vezes todos os meses, por razões de segurança quase sempre sem adiamento. Cada uma dessas atualizações pode deslocar o layout — e deveria, a rigor, desencadear uma ronda de verificação. Quem soma as duas coisas chega depressa a vários dias-pessoa por mês dedicados exclusivamente a inspeção visual repetida.

Na realidade, esta conta raramente é paga — e é exatamente esse o problema. São muito poucos os contratos de manutenção que apresentam o teste de navegadores como rubrica. O trabalho acaba, portanto, por cair sem pagamento na margem da agência, ou é cortado em silêncio: verifica-se só um navegador, só a página inicial, só quando há tempo. Ambas as coisas são decisões de gestão, mesmo que raramente sejam assim chamadas. A primeira custa lucro, a segunda compra risco.

A mesma conta pode fazer-se pelo lado do orçamento: quanta verificação cabe afinal num contrato de manutenção habitual? Uma quota de duas horas por mês está normalmente esgotada com atualizações, pequenas alterações de texto e apoio ocasional antes de a primeira verificação de navegadores ter sequer começado. A inspeção visual não concorre, portanto, com tempo morto, mas com outro trabalho mais visível — e perde estruturalmente essa concorrência, porque a sua ausência, à partida, não dá nas vistas a ninguém. É precisamente por isso que apelar à disciplina ajuda pouco. Uma verificação que deve acontecer com fiabilidade tem de constar do contrato como rubrica paga própria ou tornar-se tão pequena em esforço que aconteça de passagem. Na prática, são quase sempre precisas as duas coisas: a rubrica, para que o trabalho seja pago, e a automatização, para que caiba dentro dela.

A isto acresce um fator que as tarifas horárias não representam: a inspeção visual repetida é cansativa, e olhos cansados deixam passar coisas. Quem olha pela quadragésima vez para a mesma página inicial vê aquilo que espera ver — não os três píxeis de deslocação no cabeçalho ou o botão que, em ecrãs estreitos, passou agora a mudar de linha. A fiabilidade da verificação desce justamente onde a sua extensão sobe. As pessoas são excelentes a julgar criticamente um layout uma vez, e más a julgar criticamente o mesmo layout, inalterado, todos os meses.

E quanto custa, ao contrário, não verificar? A variante mais cara é a mais frequente: o cliente descobre o erro primeiro. Um formulário de contacto estragado no iPhone, um menu sobreposto no Firefox — durante semanas sem que ninguém repare, até chegar um e-mail irritado. O dano verdadeiro raramente é o esforço de reparação, mas a perda de confiança: o contrato de manutenção, que devia evitar exatamente estes casos, visivelmente não funcionou. A isso somam-se as intervenções de emergência a más horas, que deslocam o trabalho planeado e geram, por sua vez, custos consequentes.

É neste ponto que a automatização altera a conta — não porque o software olhe com mais rigor do que uma pessoa, mas porque paraleliza a criação das vistas e assume a comparação. Os serviços de capturas de ecrã criam a partir de um URL, em pouco tempo, o conjunto completo de vistas de navegador e de dispositivo; no ScanU, uma ronda dessas demora cerca de 30 segundos e cobre o Chrome, o Firefox e o Safari em vistas de telemóvel, tablet e computador. O decurso de uma dessas séries de verificação explica-o o ScanU no seu site. De meio dia a percorrer páginas a cliques passa-se a um quarto de hora a ver relatórios.

A alavanca decisiva não é, nisto, a captura de ecrã individual, mas a comparação. Se depois de cada alteração aprovada for guardado um estado de referência, na atualização seguinte já ninguém tem de avaliar 72 vistas — apenas os sítios onde alguma coisa mudou. A máquina responde à pergunta «está alguma coisa diferente de antes?», a pessoa à pergunta «isso é grave?». É uma divisão de trabalho bastante melhor do que a anterior, em que a pessoa tinha de responder às duas perguntas ao mesmo tempo, vista a vista.

De uma conta honesta fazem parte os custos das ferramentas. O ScanU escalona por créditos, projetos e número de dispositivos: o nível gratuito abrange 500 créditos por mês com um projeto, o nível Pro 3000 créditos e cinco projetos por 19 euros, o Pro+ 10000 créditos e dez projetos por 29 euros, o nível Max 50000 créditos e vinte projetos por 49 euros por mês — os detalhes enumera-os a panorâmica de preços do ScanU. Se isso se sustenta, pode cada agência calculá-lo com a sua própria tarifa horária: os custos mensais do maior nível correspondem, na maioria das agências, a menos de uma única hora de trabalho faturável.

O escalonamento por projetos e créditos impõe, nisto, uma disciplina útil: que projetos de clientes precisam de verificação apertada, quais se bastam com uma ronda mensal? Uma loja online em desenvolvimento ativo justifica mais séries de verificação do que um site-cartão-de-visita estático, mexido duas vezes por ano. Quem ordena a sua carteira uma vez desta maneira fica, já agora, com uma base para a próxima negociação do contrato de manutenção — o âmbito da verificação passa de repente a poder ser quantificado e apresentado como prestação, em vez de evidência silenciosa.

Como pode decorrer, em concreto, uma introdução ao longo de uma carteira inteira esboça-se em quatro passos. Primeiro, o levantamento: todos os sites acompanhados numa lista, anotando por projeto com que frequência ali muda efetivamente alguma coisa e que tipos de página existem. Segundo, a classificação: os projetos com alterações frequentes ou com processos de encomenda recebem um perfil de verificação apertado, as páginas estabelecidas e tranquilas um perfil mensal. Terceiro, criar baselines — e a partir de um estado que alguém verificou e aprovou, não simplesmente do estado atual, que talvez já contenha um erro despercebido. Quarto, pendurar a verificação na rotina de atualizações existente, de modo que depois de cada atualização de plugin ou de CMS surjam automaticamente novas vistas e sejam comparadas com a baseline. Realisticamente, isto arrasta-se por algumas semanas, quando a carteira abrange trinta projetos — não porque a tecnologia seja lenta, mas porque criar estados de referência limpos para cada projeto exige uma decisão de qualidade curta, mas verdadeira, que ninguém deveria despachar em lote.

Um efeito secundário é de natureza documental: os relatórios de verificação partilháveis podem ser integrados na comunicação com o cliente. Em vez de garantir «testámos tudo», a agência pode mostrar o que foi verificado, quando e em que navegadores. Isso não substitui uma relação de confiança, mas torna o trabalho invisível visível pela primeira vez — e o trabalho visível é mais fácil de pagar do que o invisível.

Em muitas agências fica em aberto a questão de quem vê afinal os relatórios. Para as séries motivadas por um acontecimento concreto, a resposta é simples: quem instalou a atualização avalia os desvios assinalados — é essa pessoa que os consegue enquadrar mais depressa. Para as séries regulares sem motivo concreto, dá bom resultado um turno rotativo, como muitas equipas conhecem da caixa de correio do apoio: uma pessoa designada por semana, com o mandato de registar as anomalias diretamente como tarefa em vez de apenas tomar conhecimento delas. Menos importante do que a regra concreta é a sua existência. Os relatórios que não pertencem a ninguém transformam-se em poucas semanas em ruído de fundo — e então toda a automatização fica sem efeito, por muito fiável que tecnicamente seja.

Igualmente claro deveria ser o que a automatização não faz. As comparações de capturas de ecrã verificam a apresentação, não a função: se o formulário envia efetivamente, se o pagamento chega ao fim, se a pesquisa encontra — isso esclarecem-no apenas os testes funcionais ou o trabalho manual. Também a avaliação dos desvios assinalados continua a ser trabalho humano, e os falsos alarmes causados por banners publicitários, carrosséis ou conteúdos variáveis custam, por sua vez, tempo até os ambientes de verificação estarem bem configurados. Quem introduz automatização troca trabalho de rotina por trabalho de configuração e manutenção — a troca compensa quase sempre, mas não é gratuita.

De um planeamento realista faz por isso parte: as primeiras semanas são as mais penosas. As carteiras são heterogéneas — um site de cliente traz um carrossel de notícias, o seguinte banners publicitários variáveis, o terceiro um widget de reservas com datas do dia. Cada uma destas fontes produz no início falsos alarmes, até as definições de verificação assentarem em cada projeto. Quem não conta com isso vive a introdução como uma deceção e desiste antes de o benefício se tornar visível. Mais sensato é tratar a mudança como um pequeno projeto interno: com responsável, orçamento de tempo e o objetivo declarado de ter, ao fim de algumas semanas, um sinal de verificação tranquilo e digno de confiança para cada projeto. As respostas às perguntas típicas de configuração reúne-as o fornecedor nas perguntas frequentes sobre o ScanU.

E a conta não é igual para todas as agências. Quem acompanha dois sites que raramente mudam verifica à mão numa hora aquilo que a automatização dificilmente despacha mais depressa. A matemática vira com a quantidade: com cada projeto adicional, cada ciclo de atualizações adicional, cada navegador a mais na lista de verificação. Há um ponto a partir do qual o trabalho manual é a escolha mais honesta — e um a partir do qual apenas o parece.

Para começar, presta-se uma experiência controlada: representar um único projeto de cliente movimentado no nível gratuito, deixá-lo correr um mês em paralelo com a prática anterior e comparar depois — desvios encontrados, tempo consumido, falsos alarmes. Uma panorâmica do serviço em português é dada pela página inicial em português do ScanU. Ao fim desse mês está em cima da mesa um número próprio em vez de uma estimativa.

No fim, é uma decisão simples sobre a forma dos custos. Verificar é preciso de uma maneira ou de outra — a questão é apenas se uma agência paga para isso horas de trabalho recorrentes, cuja fiabilidade desce com a repetição, ou se constrói estrutura uma vez e suporta custos correntes de ferramentas. Ambas as coisas são legítimas. Só a terceira variante, deixar a verificação cair em silêncio, não é uma poupança. É um crédito sobre a confiança dos clientes, e um dia vence.