Teste de regressão visual: processo automatizado de comparação de capturas de ecrã de uma interface antes e depois de uma modificação, permitindo detetar qualquer alteração visual não intencional — segundo o glossário do ISTQB (International Software Testing Qualifications Board), trata-se de uma forma específica de teste de regressão aplicada à camada de apresentação.
Um agente imobiliário em Marselha publica um anúncio de um T3 com vista para o mar. Cola o título a partir de um documento Word. O título contém 247 caracteres, duas quebras de linha ocultas e um caractere Unicode invisível. O template do cartão de anúncio, concebido para títulos de 80 caracteres no máximo, explode: o texto transborda sobre o preço, o preço empurra a imagem para baixo, o botão "Contactar" desaparece abaixo do fold.
Este anúncio é visto 3.000 vezes em 24 horas. 3.000 potenciais compradores que veem uma página quebrada, que não encontram o botão de contacto, que vão para a concorrência. O agente não compreende por que o seu anúncio não gera leads. A plataforma nem sequer sabe que o problema existe — porque ninguém verifica a renderização de 300.000 anúncios ativos.
Este é o quotidiano do imobiliário online. E é exatamente o problema que o teste visual resolve.
O imobiliário online: um volume de conteúdo que ninguém controla
As plataformas imobiliárias francesas operam a uma escala que poucas pessoas imaginam. O SeLoger reivindica mais de 2 milhões de anúncios. O Leboncoin Immobilier é o primeiro site imobiliário de França em audiência. Logic-Immo, Bien'ici, PAP, MeilleursAgents — cada um exibe centenas de milhares de anúncios ativos num dado momento, segundo dados da Médiamétrie.
Este conteúdo não é produzido pela plataforma. É produzido por dezenas de milhares de agentes imobiliários, particulares, promotores e mandatários, cada um com os seus hábitos de inserção de dados, as suas ferramentas e o seu nível de domínio digital. É conteúdo gerado pelo utilizador (UGC) no sentido mais estrito — e o UGC é o inimigo natural dos templates.
Um template é um contrato: "dê-me um título de X caracteres, uma imagem de Y píxeis, um preço no formato Z, e mostro-lhe um cartão limpo". Mas o utilizador não lê o contrato. Cola um título demasiado longo. Carrega uma foto de 400x300 em vez de 1200x800. Escreve "Preço sob consulta" em vez de um número. Adiciona 47 fotos em vez de 10. E o template tem de aguentar.
Por que as plataformas imobiliárias são particularmente vulneráveis a bugs visuais
A vulnerabilidade vem da combinação de três fatores que poucos setores reúnem.
Um volume massivo de conteúdos heterogéneos
Cada anúncio é único. As combinações possíveis entre comprimento do título, número de fotos, presença ou ausência de determinados campos (certificado energético, preço, área, número de quartos, andar, encargos de condomínio), formatos de morada e opções de destaque são praticamente infinitas. Testar manualmente uma amostra representativa é um exercício estatisticamente vão — nunca cobrirá combinações suficientes.
Atualizações frequentes do template
As plataformas imobiliárias fazem evoluir os seus templates regularmente: novos formatos de cartão, adição de badges (favorito, exclusivo, descida de preço), integração de novos dados (certificado energético com nova regulamentação, estimativa de preço, taxa de crédito indicativa). Cada modificação deve funcionar com todo o stock de anúncios existente, não apenas com os anúncios de teste da equipa de desenvolvimento.
Multiplicidade de páginas e contextos de exibição
Um mesmo anúncio aparece em pelo menos cinco contextos diferentes: a página de resultados de pesquisa (cartão compacto), a página de detalhe (formato extenso), a página de alerta por email (formato digest), a versão mobile (cartão deslizável), e potencialmente os widgets de parceiros (integração em sites de terceiros). Um bug pode aparecer num contexto e não nos outros.
O certificado energético: um exemplo concreto de desafio visual
Desde 1 de julho de 2021, a exibição do Diagnóstico de Desempenho Energético (DPE) é obrigatória nos anúncios imobiliários em França, segundo o decreto n° 2020-1609. O novo formato DPE, com a sua dupla etiqueta energia/clima, tem uma renderização visual complexa: uma escala de cores de A a G, valores numéricos e um indicador de posição.
Integrar este componente DPE no template do anúncio é um campo minado para regressões visuais. Os casos problemáticos multiplicam-se: um anúncio com DPE "G" (a faixa mais larga) que empurra o bloco de preço para fora do seu contentor. Um anúncio antigo sem DPE que deixa um espaço vazio desagradável. Um DPE "em branco" (imóvel em diagnóstico) que não se exibe como previsto. Um DPE em formato novo ao lado de um DPE em formato antigo numa página de comparação.
Testar manualmente cada combinação DPE × tipo de imóvel × formato de cartão × resolução de ecrã é impossível. O teste visual automatiza esta verificação: define uma baseline para cada variante de cartão, e qualquer desvio é automaticamente detetado.
O cartão de anúncio: o componente mais testado e menos fiável
O cartão de anúncio — aquele retângulo que exibe a foto, o título, o preço, a área e algumas características-chave — é paradoxalmente o componente mais importante e mais frágil de uma plataforma imobiliária.
Importante, porque é o componente que o utilizador mais vê. Numa página de resultados de pesquisa, um comprador vê 20 a 50 cartões. A sua decisão de clicar ou não é tomada em 1 a 2 segundos, com base no que o cartão mostra. Um cartão quebrado — imagem distorcida, preço ilegível, badge que tapa a morada — é um clique perdido.
Frágil, porque o cartão deve absorver uma diversidade de conteúdo considerável. Estas são as variações comuns que põem à prova o template:
Títulos de 20 a 250 caracteres. "T3 Marselha" versus "Magnífico apartamento T3 transversal com vista panorâmica para o mar, terraço 25m², estacionamento subterrâneo, cave, porteiro, perto da praia e comércio — OPORTUNIDADE".
Preços de 50.000 € a 15.000.000 €. A formatação, o espaço disponível e o alinhamento mudam consideravelmente entre "89.000 €" e "12.500.000 €".
Fotos de qualidade e proporção variáveis. De fotos de smartphone em baixa resolução a sessões profissionais em ultra HD. De retrato a paisagem. De 1:1 a 16:9.
Campos opcionais presentes ou ausentes. Alguns anúncios têm certificado energético, outros não. Alguns mostram encargos, outros não. Alguns indicam preço por m², outros não. Cada combinação de campos cria um layout ligeiramente diferente.
Badges e etiquetas acumulados. "Exclusivo" + "Descida de preço" + "Favorito" + "Novo" — quando quatro badges se sobrepõem, o design cede.
Pesquisa e filtros: uma superfície de teste subestimada
A página de resultados não é apenas uma lista de cartões. É um sistema complexo de filtros, ordenações, paginação, mapa geográfico e formatos de exibição (lista, grelha, mapa).
Cada combinação de filtros produz um resultado diferente. Uma pesquisa "casa 4 quartos, 300.000 a 500.000 €, raio de 30 km à volta de Lyon" não produz o mesmo layout que uma pesquisa "estúdio, Paris 11, mobilado". O número de resultados, a densidade dos cartões, a presença ou ausência de publicidade intercalada — tudo isto afeta a renderização.
O mapa geográfico — componente já padrão nos portais imobiliários — acrescenta uma camada de complexidade. Os marcadores de preço no mapa devem manter-se legíveis mesmo quando 50 anúncios estão no mesmo bairro. O zoom deve re-renderizar os marcadores sem sobreposição. O painel lateral que mostra o detalhe do anúncio selecionado deve exibir-se corretamente independentemente do tamanho do ecrã.
São dezenas de combinações de componentes interativos, cada uma podendo revelar um bug visual específico. O teste manual cobre uma fração ínfima destas combinações.
Mobile: onde os bugs visuais custam mais caro
Segundo os dados do mercado, o mobile representa entre 60 e 70% do tráfego dos portais imobiliários franceses. Um comprador que procura apartamento fá-lo no metro, na pausa do almoço, à noite no sofá. A experiência mobile não é secundária — é a experiência principal.
E o mobile é implacável com os bugs visuais. O espaço é limitado. Um título demasiado longo que se exibe em 3 linhas em vez de 2 empurra o preço abaixo do fold. Uma imagem que não redimensiona corretamente cria um scroll horizontal indesejado. Um botão "Ligar" demasiado pequeno para ser tocado com o polegar torna o anúncio inútil.
As plataformas imobiliárias oferecem frequentemente funcionalidades específicas para mobile: o swipe entre as fotos do anúncio, o tap-to-call, a geolocalização para "anúncios perto de mim". Cada uma destas interações tem um componente visual que pode regredir.
O funil de contacto: a conversão em jogo
O objetivo de uma plataforma imobiliária é pôr em contacto compradores e vendedores (ou inquilinos e senhorios). O funil de contacto — o formulário que permite pedir uma visita, ligar ao agente, enviar uma mensagem — é o ponto de conversão crítico.
Um bug visual no funil de contacto tem um impacto financeiro direto e mensurável. Um botão "Enviar" oculto por outro elemento. Um formulário com campos sobrepostos num ecrã estreito. Uma mensagem de confirmação que não se exibe. Um botão "Ligar" que mostra o número num texto demasiado pequeno para ler.
São bugs que não quebram a funcionalidade no sentido estrito — o formulário pode tecnicamente ser submetido — mas impedem o utilizador de o fazer porque a interface já não o guia corretamente. O teste funcional passa. O teste visual falha. A conversão também.
Como o teste visual protege uma plataforma imobiliária
O teste visual proporciona três garantias essenciais às plataformas imobiliárias.
A primeira: a verificação dos templates contra a diversidade do conteúdo. Cria uma baseline com um conjunto representativo de anúncios — título curto, título longo, muitas fotos, sem fotos, DPE A, DPE G, sem DPE, preço baixo, preço alto. Cada modificação do template é testada contra este conjunto. Se uma variante quebra, sabe antes da produção.
A segunda: a deteção de regressões após atualizações. Novo badge, novo campo, nova regulamentação a integrar. Cada adição é visualmente comparada com o estado anterior. A ferramenta identifica com precisão as alterações: "o margin-bottom do bloco DPE passou de 16px para 0px, o que cola o DPE ao bloco de preço". Não é um diff de código — é um diff visual, compreensível por um product manager.
A terceira: a cobertura cross-device sistemática. Desktop, tablet, mobile. Chrome, Safari, Firefox. iPhone, Samsung, Xiaomi. A matriz de combinações é coberta de forma exaustiva, algo que o teste manual não pode garantir.
Delta-QA e as plataformas imobiliárias
O Delta-QA é particularmente adequado ao contexto imobiliário por várias razões.
A abordagem no-code permite às equipas de produto — não apenas aos programadores — verificar a renderização dos templates. Um product manager que quer garantir que o novo badge "Descida de preço" não quebra o cartão no mobile pode fazê-lo ele próprio, sem esperar disponibilidade da equipa técnica.
O algoritmo estrutural de 5 passagens analisa o CSS real, não apenas os píxeis. Distingue uma alteração de conteúdo (o título do anúncio mudou, é normal) de uma alteração estrutural (o contentor do título mudou de tamanho, é potencialmente uma regressão). Esta distinção é crucial numa plataforma onde o conteúdo muda constantemente mas a estrutura deve permanecer estável.
O funcionamento local garante que os dados dos anúncios — moradas, preços, fotos — nunca saem da sua máquina. Para uma plataforma que gere dados pessoais (números de telefone dos agentes, moradas dos imóveis), esta garantia simplifica a conformidade com o RGPD.
E a versão Desktop é gratuita, sem limites. Para uma startup proptech que lança a sua plataforma ou para um grande portal estabelecido, a barreira de entrada é inexistente.
Armadilhas específicas do teste visual imobiliário
Não teste com dados perfeitos. A tentação é criar anúncios de teste com um título de 60 caracteres, 5 fotos em 16:9 e um preço redondo. Mas são os dados imperfeitos que quebram o layout. Teste com os piores casos: o título de 250 caracteres, a foto em 1:1, o preço de 8 dígitos, o anúncio sem foto.
Teste os estados vazios e de erro. "Nenhum resultado para a sua pesquisa." "Este anúncio já não está disponível." "A carregar." Estes estados são frequentemente negligenciados no design e nos testes, mas são vistos por milhares de utilizadores todos os dias.
Não esqueça os emails transacionais. O email de alerta "Novos anúncios correspondentes aos seus critérios" contém cartões de anúncios com a sua própria renderização. Um bug visual neste email — que é frequentemente o primeiro ponto de recontacto com o utilizador — pode custar uma visita ao site.
FAQ
O teste visual pode detetar um problema de exibição causado por um título de anúncio demasiado longo?
Sim. O teste visual compara a renderização real da página, incluindo transbordamentos de texto, sobreposições e deslocamentos causados por conteúdo que excede os limites previstos pelo template. É um dos casos de uso mais frequentes nas plataformas imobiliárias.
Como testar 300.000 anúncios ativos? É irrealista, não?
Não se testa cada anúncio individualmente. Testa-se o template com uma amostra representativa de casos extremos: título mais longo, título mais curto, máximo de fotos, sem fotos, todos os badges ativados, nenhum badge. Se o template resiste aos casos extremos, resistirá aos casos normais.
O teste visual funciona com mapas geográficos interativos?
O teste visual captura o estado estático da página, incluindo o mapa a um determinado nível de zoom. Deteta alterações de posição, tamanho ou estilo dos marcadores e do painel lateral. Para interações dinâmicas (zoom, clique no marcador), testa-se os estados resultantes em vez da interação em si.
Como distinguir uma alteração de conteúdo normal de um bug visual numa plataforma onde o conteúdo muda constantemente?
É precisamente a vantagem da abordagem estrutural do Delta-QA. O algoritmo analisa as propriedades CSS, não o conteúdo textual. Se o texto de um título muda mas o seu tamanho, fonte e espaçamento permanecem idênticos, nenhum alerta é disparado. Se, pelo contrário, o contentor do título muda de altura ou de margem, o alerta é levantado.
O teste visual substitui os testes funcionais no funil de contacto?
Não. O teste visual e o teste funcional são complementares. O teste funcional verifica que o formulário submete corretamente os dados. O teste visual verifica que o formulário é visível, legível e utilizável. Um formulário pode ser funcionalmente correto mas visualmente inutilizável — é exatamente esse cenário que o teste visual deteta.
Como integrar o teste visual no workflow de uma equipa de produto imobiliário?
O teste visual integra-se naturalmente nos ciclos de sprint. Antes de cada colocação em produção, a equipa compara a renderização das páginas-chave (página de resultados, página de detalhe, funil de contacto) com a baseline validada. Sendo o Delta-QA no-code, um product manager ou um QA pode efetuar esta verificação sem depender de um programador.
Conclusão
As plataformas imobiliárias são máquinas de exibir conteúdo heterogéneo em templates padronizados. É uma proeza técnica diária — e uma fonte permanente de regressões visuais que ninguém tem tempo de verificar manualmente.
O teste visual é a única abordagem que escala. Verifica que os seus templates resistem à diversidade do conteúdo do utilizador, que cada modificação de design funciona com todo o stock de anúncios, e que a experiência mobile — onde se encontra a maioria dos seus utilizadores — é irrepreensível.
O Delta-QA torna esta verificação acessível a toda a equipa, não apenas aos programadores. No-code, local, determinístico. Os seus anúncios, as suas capturas, os seus resultados — tudo fica na sua máquina.
Experimentar Delta-QA Gratuitamente →