Teste de regressão visual: método de teste automatizado que compara capturas de tela de uma interface de usuário entre duas versões para detectar mudanças visuais não intencionais — definido pelo ISTQB como uma técnica de teste de regressão aplicada à camada de exibição de um sistema de software.
Aqui está uma pergunta que ninguém faz nas reuniões de conformidade: quando sua ferramenta de teste visual faz uma captura de tela do seu portal de pacientes, para onde vai essa imagem?
A captura mostra um painel com o nome do paciente, data de nascimento, resultados de exames, prescrições vigentes, talvez um histórico de consultas. É um ambiente de staging, sim. Mas os dados são realistas — porque testar com dados absurdos não testa absolutamente nada. E essa captura acabou de ser enviada para um servidor cloud nos Estados Unidos para ser comparada pixel a pixel com uma imagem de referência.
Parabéns: você acabou de criar um potencial incidente de conformidade.
Este artigo é destinado a responsáveis de qualidade, CIOs e DPOs de editores de software de saúde, hospitais, clínicas e startups healthtech que querem testar suas interfaces sem comprometer os dados de seus pacientes.
Interfaces de saúde não são interfaces comuns
Uma interface de saúde tem uma particularidade que poucos domínios compartilham: as informações que exibe podem ter consequências diretas na vida dos pacientes.
Uma dosagem de medicamento exibida com uma casa decimal mal posicionada. Um resultado de exame com uma unidade truncada. Um indicador de gravidade cuja cor mudou após uma atualização CSS — o vermelho "crítico" virou laranja "atenção moderada". Um calendário de consultas onde a data é exibida no formato errado e o paciente aparece no dia errado para um procedimento pré-operatório.
Esses cenários não são hipotéticos. A ANSM (Agência Nacional de Segurança de Medicamentos da França) e a FDA documentam regularmente incidentes relacionados a erros de exibição em softwares de saúde. O relatório de 2023 da FDA sobre recalls de softwares de dispositivos médicos identifica erros de interface do usuário como a terceira causa de recalls, atrás de erros de cálculo e problemas de transmissão de dados.
A diferença com outros setores é simples: no e-commerce, um bug visual custa dinheiro. Na saúde, um bug visual pode custar uma vida. Essa realidade muda fundamentalmente a forma como você deve pensar sobre o teste das suas interfaces.
Os profissionais de saúde que utilizam seu software — médicos, enfermeiros, farmacêuticos, técnicos de laboratório — trabalham sob pressão, muitas vezes fatigados, gerenciando dezenas de pacientes. Eles não têm tempo para verificar se a interface exibe as informações corretamente. Eles confiam no que veem. E essa confiança deve ser justificada por processos de teste rigorosos.
HIPAA, HDS, LGPD/RGPD: o tripé regulatório e suas implicações para o teste visual
RGPD e dados de saúde. O RGPD classifica dados de saúde como dados sensíveis (artigo 9), sujeitos a proteção reforçada. Uma captura de interface de paciente enviada a uma ferramenta SaaS constitui tratamento de dados sensíveis.
HIPAA (Health Insurance Portability and Accountability Act). Nos Estados Unidos, a HIPAA protege as PHI (Protected Health Information) — qualquer informação que identifica um paciente e está relacionada à sua condição de saúde, aos cuidados recebidos ou ao pagamento desses cuidados. A Security Rule da HIPAA exige salvaguardas técnicas para proteger as PHI eletrônicas, incluindo controle de acesso, trilhas de auditoria, integridade dos dados e segurança de transmissão. Uma captura de tela de uma interface de paciente contendo PHI é ela mesma uma PHI. Enviá-la para uma ferramenta SaaS de teste significa que o fornecedor se torna um Business Associate sob a HIPAA, exigindo um BAA (Business Associate Agreement) — e mesmo com um BAA, a responsabilidade em caso de violação permanece compartilhada. As multas da HIPAA variam de $100 a $50.000 por violação, com um teto de $1,5 milhão por categoria por ano. Em 2024, o OCR (Office for Civil Rights) emitiu mais de $130 milhões em multas acumuladas.
HDS (Health Data Hosting). Na França, a certificação HDS é obrigatória para qualquer hospedagem de dados pessoais de saúde. Introduzida pelo decreto de 26 de fevereiro de 2018 e reforçada pela atualização de 2024, essa certificação exige hospedagem dentro da União Europeia, com garantias técnicas e organizacionais específicas. Se sua ferramenta de teste visual envia capturas contendo dados de saúde para uma cloud não certificada HDS, você está em infração. A certificação HDS não é uma formalidade: envolve uma auditoria por um organismo acreditado pelo COFRAC, um sistema de gestão de segurança da informação em conformidade com a ISO 27001 e controles específicos sobre localização e acesso aos dados.
RGPD e dados de saúde. O RGPD classifica dados de saúde como dados sensíveis (artigo 9), sujeitos a proteção reforçada. O tratamento é proibido por padrão, com exceções limitadas — incluindo consentimento explícito e interesse vital. Uma captura de tela de interface de paciente contendo dados de saúde, enviada a uma ferramenta SaaS de teste, constitui tratamento de dados sensíveis. Esse tratamento deve ser justificado por uma base legal, documentado no seu registro de tratamento e submetido a uma DPIA (Data Protection Impact Assessment) caso a transferência seja fora da UE. A CNIL tem sido clara: transferir dados de saúde para os Estados Unidos, mesmo sob o Data Privacy Framework, requer vigilância reforçada.
O que essas três regulamentações dizem juntas é que os dados de saúde presentes nas suas capturas não são simplesmente imagens. São dados sensíveis protegidos por regimes jurídicos estritos. E cada vez que essas imagens saem da sua infraestrutura, você cria um ponto de risco regulatório.
Por que dados de staging são uma falsa sensação de segurança
"Não testamos com dados reais." Esse é o argumento que se ouve em quase todas as equipes de desenvolvimento de saúde. E é um argumento que não resiste bem a um exame cuidadoso.
Primeiro, há a questão do que significa "dados reais". Muitos ambientes de staging na saúde utilizam cópias anonimizadas ou pseudonimizadas de dados de produção. A anonimização perfeita é notoriamente difícil no domínio médico — estudos demonstraram que 87% da população dos EUA pode ser unicamente identificada com apenas três informações: CEP, data de nascimento e gênero. Um prontuário de paciente pseudonimizado que retém data de nascimento, CEP e diagnóstico principal não é anônimo — é reidentificável.
Depois, há os dados sintéticos. Sim, é possível gerar pacientes fictícios com nomes aleatórios, datas de nascimento inventadas e condições atribuídas algoritmicamente. Mas para que seus testes sejam relevantes, esses dados devem ser realistas. Uma HbA1c de 6,4% para um paciente diabético tipo 2 em uso de metformina. Um INR de 2,3 para um paciente em uso de varfarina. Esses valores são medicamente coerentes — e é exatamente isso que os torna potencialmente classificáveis como dados de saúde por um regulador cauteloso, se associados a um perfil de paciente suficientemente detalhado.
Finalmente, há a realidade do terreno. Desenvolvedores às vezes copiam dados de produção para o staging para reproduzir um bug. Um médico relata um problema de exibição no prontuário de um paciente específico, a equipe de desenvolvimento precisa reproduzir o contexto exato. Essas cópias "temporárias" têm uma tendência infeliz de se tornarem permanentes. E quando sua ferramenta de teste visual faz uma captura desse ambiente, ela pode capturar dados reais de pacientes.
A única forma de neutralizar estruturalmente esse risco é que as capturas nunca saiam do seu perímetro. Independentemente do que contenham — dados reais, pseudonimizados, sintéticos ou mistos — se ficam na sua máquina, o risco de transferência não autorizada é eliminado por design.
O teste visual como guardião da acessibilidade
Existe um aspecto do teste visual na saúde que é pouco discutido: a acessibilidade.
Os usuários de interfaces de saúde não são apenas profissionais de saúde. São também os próprios pacientes — via portais de pacientes, aplicativos de acompanhamento, prontuários eletrônicos digitais. E esses pacientes incluem idosos com visão degradada, pessoas daltônicas que não distinguem certas cores, pessoas com deficiências motoras que navegam pelo teclado ou com tecnologias assistivas.
Na França, o RGAA (Referencial Geral de Melhoria da Acessibilidade) exige que os serviços públicos digitais sejam acessíveis. Estabelecimentos públicos de saúde são diretamente concernidos. O setor privado também não escapa: a Diretiva Europeia de Acessibilidade Web (2016/2102) e o European Accessibility Act (2025) estendem progressivamente essas obrigações.
O teste visual detecta regressões de acessibilidade que se manifestam visualmente. Um contraste de texto caindo abaixo do ratio 4,5:1 exigido pelo WCAG 2.1 Nível AA. Uma área clicável reduzindo abaixo de 44x44 pixels. Um foco visível desaparecendo após uma refatoração CSS. Um texto que não aumenta corretamente quando o usuário aumenta o tamanho da fonte no navegador.
Para pacientes idosos — que representam uma parcela crescente dos usuários de portais de pacientes com o envelhecimento da população e a digitalização do percurso de cuidado — essas regressões não são meros inconvenientes. Uma fonte pequena demais em um resultado de exame significa um paciente que não consegue entender seus resultados. Um botão com contraste insuficiente em uma página de agendamento significa uma consulta perdida. Um formulário de renovação de prescrição sobreposto no mobile significa um paciente que não consegue acessar seu medicamento.
O teste visual não substitui uma auditoria completa de acessibilidade. Mas ele previne regressões — e em um contexto onde a auditoria inicial já foi realizada e o desafio é manter a conformidade ao longo dos sprints e atualizações, o teste de regressão visual é a rede de segurança mais eficaz.
O on-premise como única resposta estrutural
Recapitulemos as restrições. A HIPAA exige proteção das PHI e BAAs com cada fornecedor. A HDS impõe hospedagem certificada em território europeu. O RGPD classifica dados de saúde como sensíveis e restringe sua transferência. Dados de staging não são necessariamente mais seguros que dados de produção. E a acessibilidade impõe exigências visuais contínuas.
Diante dessas restrições, existem duas abordagens. A primeira é cumprir cada exigência individualmente: assinar um BAA com seu fornecedor SaaS, verificar sua certificação HDS, documentar a transferência no seu registro RGPD, realizar uma DPIA, implementar controles de anonimização no seu staging. É viável, mas é uma construção complexa onde cada elo deve resistir — e um único elo fraco é suficiente para criar uma brecha.
A segunda abordagem é eliminar o problema na raiz: se as capturas nunca saem da sua infraestrutura, a maioria dessas exigências se torna irrelevante. Sem transferência para documentar, sem BAA para assinar, sem certificação para verificar em terceiros, sem DPIA para realizar para o teste visual. Você mantém controle total, e sua postura de conformidade se simplifica radicalmente.
Essa é a abordagem on-premise. E no setor de saúde, não é uma escolha conservadora ou tecnofóbica. É a resposta mais racional a um ambiente regulatório que não perdoa aproximações.
Delta-QA e as especificidades do setor saúde
O Delta-QA é uma ferramenta de teste visual no-code que funciona inteiramente de forma local. Veja o que isso significa concretamente para o setor de saúde.
Zero transferência de dados. As capturas de tela das suas interfaces de pacientes ficam na máquina do seu testador. Sem cloud, sem API externa, sem servidor de terceiros. Independentemente de seu portal de pacientes exibir dados reais, pseudonimizados ou sintéticos, eles nunca saem do seu perímetro. Para um DPO, isso é um processo de conformidade consideravelmente simplificado.
Sem necessidade de competência de desenvolvedor. Na saúde, as equipes de QA são frequentemente compostas por perfis funcionais — pessoas que conhecem os percursos de cuidado, os processos de negócio, as exigências regulatórias, mas que não programam. O Delta-QA funciona por navegação: você abre sua aplicação, navega pelas telas como um usuário faria, e a ferramenta registra e compara. É uma habilidade que qualquer testador funcional já possui.
Detecção determinística e auditável. O algoritmo estrutural do Delta-QA analisa o CSS real em vez de comparar pixels. Quando detecta uma mudança, ele produz um relatório explícito: "o tamanho da fonte mudou de 16px para 14px no elemento .patient-name", "o contraste do botão .confirm mudou de 4,8:1 para 3,2:1". Em um contexto onde cada decisão de teste deve ser justificável — durante uma auditoria HDS, uma inspeção da ANSM ou uma investigação HIPAA — essa rastreabilidade é uma vantagem significativa em relação a abordagens de IA cujos resultados são uma probabilidade, não uma certeza.
Detecção de regressões de acessibilidade. Como o Delta-QA analisa a estrutura CSS, ele detecta mudanças que afetam a acessibilidade visual: modificações de contraste, reduções de tamanho de fonte, mudanças nas dimensões de áreas interativas. Não é uma ferramenta de auditoria de acessibilidade, mas é uma ferramenta que impede que regressões de acessibilidade passem despercebidas entre as auditorias.
Gratuito para começar. A versão Desktop do Delta-QA é gratuita, sem limites de capturas e sem período de teste. Para um hospital ou clínica que deseja avaliar o teste visual em seu prontuário eletrônico (EHR) ou portal de pacientes, não há processo de aquisição a iniciar. Você pode testar a ferramenta nas condições reais do seu ambiente antes de qualquer decisão orçamentária.
Limitações a conhecer
O teste visual, mesmo on-premise, não é uma solução universal na saúde.
Não se integra em pipeline CI/CD cloud. É uma ferramenta desktop para teste manual assistido.
O Delta-QA não se integra em um pipeline CI/CD cloud. Se sua organização investiu em um pipeline de integração contínua hospedado na cloud e você deseja que cada merge request acione automaticamente um teste visual, o Delta-QA não foi projetado para esse fluxo de trabalho. É uma ferramenta desktop, feita para teste manual assistido e campanhas de teste estruturadas. Para organizações de saúde, essa abordagem é frequentemente mais realista do que a automação completa, mas é uma limitação a avaliar com base na sua maturidade DevOps.
Não cobre todos os aspectos da acessibilidade. O teste visual detecta regressões de acessibilidade visual, não problemas estruturais. Um leitor de tela que não consegue navegar pelo seu formulário porque os papéis ARIA estão mal configurados não será detectado pelo teste visual. Uma auditoria de acessibilidade completa com ferramentas especializadas (axe, WAVE, Lighthouse) permanece necessária.
A cobertura depende dos seus cenários. O teste visual só testa as telas que você definiu como cenários de teste. Se um percurso de paciente crítico não estiver incluído nos seus cenários, as regressões visuais nesse percurso não serão detectadas. A qualidade da sua cobertura de teste visual depende da qualidade da sua seleção de cenários.
FAQ
As capturas de um portal de pacientes são PHI sob a HIPAA?
Sim, se contiverem qualquer um dos 18 identificadores definidos pela HIPAA: nome, data de nascimento, endereço, número de seguro social, número de prontuário médico ou qualquer outra informação que identifique o paciente. Uma captura de painel de paciente mostrando nome e resultados de exames é uma PHI eletrônica, sujeita às mesmas exigências de proteção que o próprio prontuário.
Uma ferramenta SaaS de teste visual deve ser certificada HDS na França?
Se a ferramenta recebe e armazena capturas contendo dados pessoais de saúde, mesmo temporariamente, ela atua como hospedeira desses dados. A certificação HDS é então obrigatória. Na prática, muito poucas ferramentas SaaS de teste visual são certificadas HDS — não é seu negócio principal. É por isso que a abordagem on-premise, que elimina a necessidade de certificação de terceiros, é estruturalmente mais simples para a conformidade.
Como o teste visual ajuda na acessibilidade das interfaces de saúde?
O teste visual detecta regressões de acessibilidade visual: contraste de texto caindo abaixo dos ratios do WCAG 2.1 (4,5:1 para texto normal, 3:1 para texto grande), redução do tamanho de área clicável, desaparecimento de foco visível, mudanças de tamanho de fonte. Para pacientes idosos ou com deficiência visual, essas regressões podem tornar uma interface inutilizável. O teste visual não substitui uma auditoria RGAA/WCAG completa, mas previne a degradação entre auditorias.
Quanto tempo leva para configurar o teste visual em um prontuário eletrônico?
Com o Delta-QA, a configuração inicial leva entre um e três dias, dependendo da complexidade do seu prontuário. O primeiro dia consiste em identificar os percursos críticos (consulta de prontuário, prescrições, resultados de exames, agendamento). O segundo dia envolve a criação de cenários de teste e capturas de referência. O terceiro, se necessário, permite ajustar os limiares de sensibilidade e treinar a equipe QA. Nenhuma competência de desenvolvimento é necessária.
O teste visual pode detectar erros de exibição de dosagem de medicamentos?
O teste visual detecta mudanças de exibição em relação a uma referência. Se uma dosagem era exibida corretamente na versão de referência (por exemplo, "500 mg") e uma atualização CSS modificou a exibição (por exemplo, truncando para "500" sem a unidade, ou reformatando para "5,00 mg"), o teste visual detectará essa mudança. No entanto, se a dosagem exibida está incorreta desde a versão de referência (erro de backend), o teste visual não a detectará — esse é o papel dos testes funcionais.
Qual é a diferença entre anonimização e pseudonimização para dados de staging na saúde?
A anonimização torna impossível identificar uma pessoa, mesmo com informações adicionais. É um processo irreversível. A pseudonimização substitui os identificadores diretos (nome, número de seguro social) por pseudônimos, mas a identificação permanece possível com a tabela de correspondência. O RGPD não se aplica a dados verdadeiramente anonimizados, mas se aplica a dados pseudonimizados. Na prática, é extremamente difícil garantir a anonimização perfeita de dados médicos, o que reforça o argumento a favor do on-premise: se você não tem certeza de que seus dados de staging estão perfeitamente anonimizados, não os envie para fora.
Conclusão
O teste visual na saúde não é uma questão de perfeccionismo estético. É uma questão de segurança do paciente, conformidade regulatória e confiança.
A abordagem on-premise não é um compromisso. É a única abordagem que elimina estruturalmente o risco de transferência não autorizada de dados de saúde. E com ferramentas como Delta-QA, não requer orçamento significativo, nem competências de desenvolvimento, nem infraestrutura dedicada.
Seus pacientes confiam em você com seus dados mais íntimos. Suas capturas de teste merecem o mesmo nível de proteção.
Experimente o Delta-QA Gratuitamente →