Este artigo ainda não foi publicado e não é visível para os motores de busca.
Delta-QA vs Percy: Teste Visual Estrutural ou Screenshots na Nuvem?

Delta-QA vs Percy: Teste Visual Estrutural ou Screenshots na Nuvem?

Delta-QA vs Percy: Teste Visual Estrutural ou Screenshots na Nuvem?

Teste visual por captura de tela (screenshot testing): método de detecção de regressões visuais que consiste em capturar uma imagem completa de uma página ou componente web, e depois compará-la pixel a pixel com uma imagem de referência — qualquer diferença acima de um limiar configurável é sinalizada como uma regressão potencial.

Percy foi por muito tempo o primeiro nome que vinha à mente quando se falava em teste visual automatizado. Adquirido pela BrowserStack em 2020, a ferramenta se consolidou como a solução "óbvia" para equipes que queriam adicionar uma camada de comparação visual ao seu pipeline de testes. E por muito tempo, foi de fato a melhor opção disponível — mais por padrão do que por excelência, mas a melhor mesmo assim.

O cenário mudou. E a pergunta que cada equipe deveria se fazer hoje não é mais "como integro o Percy nos meus testes?" mas "a abordagem do Percy ainda é a mais relevante para a minha necessidade?"

Delta-QA propõe uma resposta radicalmente diferente para o mesmo problema. Sem screenshots, sem nuvem, sem SDK, sem cobrança por screenshot. Uma abordagem estrutural, local, no-code e gratuita. Vamos comparar os dois sem rodeios.

Percy: o teste visual como extensão dos seus testes existentes

Percy funciona segundo um princípio aparentemente simples: em pontos estratégicos dos seus testes automatizados, você dispara uma captura de tela. Essa captura é enviada aos servidores da BrowserStack, onde é comparada pixel a pixel com uma imagem de referência (a baseline). As diferenças são exibidas em um painel web onde sua equipe pode aprovar ou rejeitar cada mudança.

A ideia é elegante. A execução, nem tanto.

Para usar o Percy, você precisa primeiro ter testes automatizados — Cypress, Playwright, Selenium, Puppeteer, ou um dos muitos frameworks suportados. Depois você instala o SDK do Percy correspondente ao seu framework. Modifica seus testes para adicionar chamadas de captura nos pontos relevantes. Configura um token de autenticação para se comunicar com os servidores do Percy. E torce para que seu pipeline CI tenha uma conexão de rede suficientemente estável para enviar screenshots de alta resolução a cada execução.

Se você é um desenvolvedor confortável com ferramentas de teste, tudo isso é factível em algumas horas. Se você não é desenvolvedor — e uma proporção significativa das pessoas responsáveis pela qualidade visual não são — você depende inteiramente de outra pessoa para configurar e manter sua ferramenta de teste visual.

Delta-QA: o teste visual como atividade autônoma

Delta-QA se baseia em um postulado inverso: o teste visual não deveria ser um enxerto nos seus testes funcionais. É uma atividade própria, com suas próprias necessidades, seus próprios usuários e suas próprias restrições.

Na prática, você fornece ao Delta-QA duas versões de uma página (duas URLs, dois ambientes, ou dois momentos no tempo), e a ferramenta analisa as diferenças estruturais entre elas. Sem capturas de tela enviadas para a nuvem. Sem comparação de pixels. Delta-QA examina o DOM, as propriedades CSS calculadas e a hierarquia dos elementos para identificar o que mudou.

O resultado é um relatório claro das diferenças significativas: elementos adicionados, removidos, modificados, deslocados, com as propriedades CSS afetadas. Sem interpretação vaga, sem "este pixel mudou de cor em uma nuance imperceptível". Fatos estruturais, verificáveis e explicáveis.

E tudo isso sem escrever uma única linha de código. Se você consegue usar um navegador web, você consegue usar o Delta-QA. Essa frase não é um slogan de marketing — é literalmente a realidade da interface.

Código vs no-code: por que muda tudo

A diferença mais fundamental entre Percy e Delta-QA não é técnica — é organizacional.

Percy é uma ferramenta de desenvolvedor. Vive no código, é instalada via npm ou pip, é configurada em arquivos de configuração e é executada em pipelines CI/CD. É perfeitamente lógico quando seus testers são desenvolvedores. É um muro quando não são.

Pense na sua equipe. Quem se importa com a qualidade visual do seu produto? Os desenvolvedores, certamente. Mas também os designers que criaram os mockups. Os product owners que validaram as jornadas do usuário. Os QA managers que definem os critérios de aceitação. Os responsáveis de marketing que gerenciam as páginas de conteúdo. Nenhuma dessas pessoas deveria precisar escrever código para verificar que o site está com a aparência correta.

Percy os exclui estruturalmente do processo de teste visual. Eles podem consultar os resultados no painel — aprovar ou rejeitar mudanças — mas não podem configurar novos testes, adicionar novas páginas para monitorar ou ajustar os parâmetros de detecção. São consumidores passivos de uma ferramenta projetada para outros.

Delta-QA os inclui. Qualquer pessoa da equipe pode lançar uma comparação visual, adicionar páginas para monitorar, configurar limiares de sensibilidade e interpretar os resultados. O teste visual se torna uma responsabilidade compartilhada em vez de uma tarefa técnica delegada.

A cobrança por screenshot: um modelo que pune o rigor

O modelo econômico do Percy merece atenção especial porque cria um incentivo perverso.

Percy cobra por número de screenshots por mês. Os planos começam com uma cota de screenshots incluída, e cada screenshot adicional além da cota é cobrado. Quanto mais você testa, mais paga. Quanto mais rigorosa sua cobertura visual, maior a fatura.

Pense por um momento no que isso significa na prática. Você tem um site e-commerce com 500 páginas de produto. Quer verificar visualmente cada página após cada deploy. São 500 screenshots por deploy. Se você faz deploy diariamente, são 15.000 screenshots por mês. Se testa em três resoluções (desktop, tablet, mobile), são 45.000 screenshots por mês. O plano que cobre esse volume não será o de 400 dólares.

Esse modelo cria uma tensão doentia entre a cobertura de teste e o orçamento. As equipes acabam limitando as páginas testadas, reduzindo a frequência dos testes ou testando em menos resoluções — não porque seja a decisão técnica correta, mas porque o orçamento impõe. O modelo de preços da ferramenta degrada ativamente a qualidade dos testes.

Delta-QA não cobra nada. Nem por screenshot, nem por página, nem por mês. Você testa tantas páginas quanto quiser, com a frequência que quiser, em tantas resoluções quanto quiser. O rigor da sua cobertura de teste é limitado pela sua ambição, não pela sua carteira.

Nuvem vs local: a soberania dos seus dados

Cada screenshot enviado ao Percy transita pelos servidores da BrowserStack e é armazenado lá. Para a maioria dos sites públicos, isso não é um problema. Mas os sites públicos são apenas uma fração do que as equipes testam.

E o seu backoffice de administração? O seu painel interno com dados de clientes? O seu ambiente de staging com dados de produção anonimizados (ou nem sempre perfeitamente anonimizados)? O seu portal médico, sua interface bancária, seu sistema de gestão de RH?

Enviar screenshots dessas páginas para os servidores de um terceiro, mesmo um terceiro de confiança certificado SOC 2, levanta questões que algumas organizações não podem ignorar. As regulamentações setoriais (LGPD, HIPAA, PCI-DSS), as políticas de segurança internas e o bom senso em matéria de proteção de dados impõem limites ao que pode transitar por servidores externos.

Delta-QA elimina a questão. A ferramenta é executada localmente. Suas páginas são analisadas localmente. Os resultados permanecem locais. Nenhum dado sai do seu ambiente. Isso não é uma funcionalidade premium ou uma opção de implantação enterprise — é a arquitetura base da ferramenta.

A estabilidade dos resultados: pixels caprichosos vs estrutura confiável

Qualquer pessoa que já usou uma ferramenta de teste visual baseada em screenshots sabe que os falsos positivos são a praga da abordagem. Percy fez progressos significativos com algoritmos de comparação inteligentes, limiares de sensibilidade configuráveis e zonas de exclusão. Mas o problema fundamental persiste: comparar pixels é inerentemente instável.

A renderização de uma fonte varia de um sistema operacional para outro. O anti-aliasing difere dependendo da placa gráfica. Animações capturadas em momentos ligeiramente diferentes produzem imagens diferentes. Conteúdos dinâmicos (datas, contadores, anúncios) mudam entre as capturas. Imagens carregadas de um CDN podem chegar em uma ordem diferente. Uma barra de rolagem que aparece ou desaparece desloca todos os elementos alguns pixels.

Cada um desses casos gera um "diff" no Percy que não é um bug real. E cada falso positivo consome tempo: alguém tem que olhar o diff, decidir que não é um problema real e aprová-lo. Multiplique por centenas de screenshots e dezenas de deploys, e você obtém horas de trabalho desperdiçadas classificando falsos positivos. Existem coisas mais empolgantes na vida — praticamente todas, aliás.

A abordagem estrutural do Delta-QA é imune a esses problemas. A renderização da fonte pode variar — a estrutura CSS permanece idêntica. O anti-aliasing pode diferir — as propriedades CSS calculadas não mudam. O conteúdo textual pode se atualizar — a hierarquia DOM e os estilos permanecem estáveis. A taxa de falsos positivos da abordagem estrutural é uma fração da abordagem por screenshots.

A integração CI/CD: duas abordagens, mesmo destino

Percy se integra aos pipelines CI/CD via seu SDK. É uma integração madura que funciona bem com os principais sistemas CI (GitHub Actions, GitLab CI, Jenkins, CircleCI). Mas adiciona uma dependência de rede: se os servidores do Percy estão lentos ou indisponíveis, seu pipeline é impactado.

Delta-QA também se integra aos pipelines CI/CD, mas sem SDK nem dependência externa. A ferramenta é executada localmente no seu runner CI. Sem latência de rede, sem timeouts se um serviço de terceiros cair. Seu pipeline depende apenas da sua própria infraestrutura.

Quando Percy continua sendo a escolha certa

Percy é uma boa ferramenta em certos contextos específicos.

Você quer o teste visual como complemento dos seus testes funcionais existentes. Se você já tem uma suíte de testes Cypress ou Playwright robusta, adicionar Percy a essa suíte é o caminho de menor resistência. Você adiciona capturas nos momentos-chave dos seus testes, e sua cobertura visual é imediatamente operacional.

Você precisa de teste visual cross-browser. Percy pode capturar screenshots em diferentes combinações navegador/resolução via a infraestrutura da BrowserStack. Se verificar a renderização visual em Chrome, Firefox, Safari e Edge simultaneamente é um requisito, Percy oferece essa capacidade.

Sua equipe é composta exclusivamente de desenvolvedores. Se as únicas pessoas que farão teste visual são desenvolvedores confortáveis com SDKs e pipelines CI/CD, a barreira de entrada do Percy é insignificante.

Quando Delta-QA é a melhor opção

O teste visual é uma necessidade em si, não uma extensão dos seus testes funcionais. Se você quer teste visual independentemente dos seus testes automatizados — ou se simplesmente não tem testes automatizados — Delta-QA é autossuficiente.

Não-desenvolvedores precisam participar do teste visual. QA, designers, product owners, marketing — se esses perfis precisam poder lançar e interpretar testes visuais sem passar por um desenvolvedor, Delta-QA é a única escolha realista.

O orçamento é limitado ou você recusa a cobrança por volume. Se você não quer que sua cobertura de teste seja ditada pelo seu orçamento de screenshots, a gratuidade do Delta-QA elimina essa restrição.

A confidencialidade dos dados é inegociável. Se suas páginas contêm dados sensíveis ou suas políticas de segurança proíbem o envio de screenshots para servidores de terceiros, a abordagem local do Delta-QA é a única opção em conformidade.

Você está cansado dos falsos positivos. Se já experimentou o teste visual por screenshots e a triagem dos falsos positivos fez você desistir, a abordagem estrutural do Delta-QA vai reconciliá-lo com o teste visual.

O veredito sem filtro

Percy é uma ferramenta madura, bem integrada ao ecossistema BrowserStack, e eficaz para equipes de desenvolvimento que querem adicionar uma camada visual aos seus testes automatizados. É uma boa ferramenta para seu caso de uso específico.

Mas esse caso de uso é mais estreito do que o marketing do Percy sugere. A maioria das equipes não precisa de um SDK, de um serviço em nuvem e de uma cobrança por screenshot para detectar regressões visuais. Elas precisam de uma ferramenta simples, rápida, acessível a todos, e que não puna o rigor de teste com uma fatura crescente.

Delta-QA é essa ferramenta. Não porque seja mais sofisticada que o Percy — não é, e não pretende ser. Mas porque resolve o problema do teste visual com menos fricção, menos custo e mais acessibilidade. E no mundo real, a ferramenta que é adotada é sempre mais útil do que a ferramenta que impressiona.

FAQ

O Percy é gratuito?

Percy oferece um plano gratuito limitado a um certo número de screenshots por mês (o limite tem variado ao longo do tempo). Além disso, os planos pagos começam em várias centenas de dólares por mês e escalam conforme o volume de screenshots. Para um uso profissional sério com uma cobertura de teste significativa, o plano gratuito é insuficiente. Delta-QA é gratuito sem limitação de volume.

É possível usar o Percy sem escrever código?

Não. Percy requer a integração de um SDK em um framework de teste automatizado. Mesmo as soluções de integração mais simples (Percy CLI com URLs) requerem o uso de um terminal e comandos de linha. Delta-QA é inteiramente no-code — a interface web é suficiente para configurar e executar testes visuais.

A abordagem estrutural detecta os mesmos bugs que os screenshots?

Ela detecta a grande maioria das regressões visuais — aquelas causadas por mudanças de CSS, de estrutura HTML ou de layout. Ela não detecta problemas de renderização gráfica pura (corrupção de imagem, problema de webfont, bug de renderização específico de um navegador) que requerem uma comparação visual pixel a pixel. Para a maioria das equipes, as regressões estruturais representam mais de 90% dos bugs visuais encontrados na prática.

O Percy lida com páginas com autenticação?

Sim, mas apenas no contexto dos seus testes automatizados. Seu script de teste deve lidar com a autenticação (login, cookies, tokens), e então o Percy captura os screenshots das páginas autenticadas. Com o Delta-QA, o acesso às páginas autenticadas é direto já que a ferramenta é executada no seu ambiente local onde você já tem acesso às suas aplicações.

Quanto tempo se economiza eliminando os falsos positivos?

Equipes que usam ferramentas de teste visual baseadas em screenshots relatam regularmente que a triagem dos falsos positivos representa entre 30% e 60% do tempo dedicado ao teste visual. Em uma semana típica com 20 deploys e centenas de screenshots, são várias horas de trabalho humano dedicadas a aprovar diferenças que não são bugs. A abordagem estrutural do Delta-QA reduz drasticamente essa proporção.

Percy e Delta-QA podem coexistir?

Com certeza. Você pode usar o Percy nos seus testes automatizados para a comparação pixel de componentes críticos, e o Delta-QA em paralelo para a cobertura diária de todas as suas páginas. As duas ferramentas são independentes e não interferem uma na outra. É até uma combinação inteligente se você quer o melhor dos dois mundos.


O teste visual deveria ser uma rede de segurança implantada amplamente, não uma ferramenta de luxo reservada a equipes que podem se dar ao luxo de um SDK e uma assinatura na nuvem. Percy abriu o caminho. Delta-QA o torna acessível a todos.

Experimentar Delta-QA Gratuitamente →