Tópico 3.7 — Testes e garantia da qualidade

Em uma frase: Na saúde e nos cuidados, os testes e a garantia da qualidade não são uma fase que se faz antes da liberação, mas uma disciplina contínua que fornece boa parte da evidência de que um serviço é clinicamente seguro, acessível, protegido e apto a tocar o cuidado de um paciente.

Por que isso importa na saúde e nos cuidados#

Todo serviço digital carrega defeitos; as únicas perguntas são quantos, quão graves e se você os encontra antes ou depois de um paciente ser afetado. Num aplicativo de consumo, um erro não detectado desperdiça a tarde de um usuário. Num sistema clínico, pode exibir as alergias do paciente errado, arredondar incorretamente uma dose pediátrica de medicamento ou jogar em silêncio um encaminhamento numa fila que ninguém monitora. O teste é o esforço organizado para encontrar esses defeitos cedo, e a garantia da qualidade é o sistema mais amplo de controles que impede que a qualidade dependa de sorte ou de heroísmo.

É por isso que o teste em TI de saúde é indissociável da segurança clínica. Os perigos registrados num registro de perigos DCB0129/0160 (ver Tópico 1.6 — Segurança clínica e gestão de riscos) só são genuinamente mitigados quando um teste prova que a mitigação funciona e continua funcionando após cada mudança subsequente. Um caso de segurança que alega "o sistema impede prescrições duplicadas" sem um teste repetível por trás é uma afirmação, e não garantia. O teste é a base de evidências sob o argumento de segurança clínica.

O que está em jogo é também a equidade e a confiança pública. Um serviço que nunca foi testado frente aos padrões de acessibilidade excluirá os usuários com deficiência por padrão (ver Tópico 1.9 — Inclusão digital e acessibilidade). Um serviço testado apenas com cópias de prontuários reais de pacientes corre o risco de uma violação de dados que corrói a confiança da qual o NHS depende. E o dinheiro não é trivial: retrabalhar um defeito encontrado em operação custa muitas vezes mais do que pegá-lo no projeto, e um incidente clínico grave custa bem mais do que ambos. Testar mal não é economia; é uma conta adiada e inflada, às vezes paga em dano.

Conceitos centrais#

Teste versus garantia da qualidade. Testar é o ato de exercitar um sistema para encontrar defeitos e confirmar o comportamento. A garantia da qualidade é o conjunto mais amplo de processos — padrões, revisões, definições de pronto, barreiras — que embutem a qualidade em vez de inspecioná-la no final. O teste diz se esta versão funciona; a garantia da qualidade é a razão pela qual as suas versões, em geral, funcionam. Ambos importam, e os líderes costumam financiar o primeiro e negligenciar o segundo.

A pirâmide de testes e o shift-left. Uma estratégia de testes saudável tem muitos testes unitários rápidos e baratos (que verificam funções individuais), menos testes de integração (que verificam se os componentes funcionam em conjunto) e um pequeno número de testes de ponta a ponta, lentos e caros (que verificam jornadas inteiras de usuário). Essa "pirâmide de testes" mantém a retroalimentação rápida e a manutenção acessível. Combina-se com o shift-left testing — mover o teste para mais cedo no ciclo de vida, de modo que os defeitos sejam eliminados no projeto de forma barata, e não encontrados numa correria frenética pré-liberação. Uma pirâmide invertida (sobretudo testes manuais de ponta a ponta) é lenta, frágil e um sinal de alerta.

Testes funcionais e não funcionais. O teste funcional pergunta "o sistema faz o que deveria?" — cálculos corretos, fluxos de trabalho corretos, dados corretos. O teste não funcional pergunta "quão bem ele se comporta?" — desempenho e carga (ele continua responsivo quando todo o hospital faz login às 8h?), segurança (pode ser violado?), confiabilidade e acessibilidade. Na saúde e nos cuidados, as falhas não funcionais costumam ser as mais perigosas: um sistema funcionalmente perfeito que expira durante uma chamada de ressuscitação falhou clinicamente.

Teste de regressão. O teste de regressão reexecuta os testes existentes após uma mudança para confirmar que corrigir ou acrescentar uma coisa não quebrou outra. Nos sistemas clínicos em produção, este é o hábito de segurança mais importante: a maior parte dos incidentes de software clínico vem não de novas funcionalidades, mas de mudanças que quebraram silenciosamente um comportamento que funcionava. Um conjunto confiável de regressão é o que lhe permite mudar um sistema em produção sem prender a respiração.

Automação de testes e integração contínua. A automação de testes usa software para executar testes de forma repetível, de modo que um grande conjunto roda em minutos a cada mudança. Combinada com a integração contínua — integrar e testar automaticamente as mudanças com frequência —, transforma o teste de um evento ocasional numa rede de segurança constante (ver Tópico 3.5 — Ciclos de vida de entrega). A automação não substitui o julgamento humano; libera os humanos para fazer os testes exploratórios e clínicos que as máquinas não conseguem.

Teste de aceitação. O teste de aceitação, e especificamente o teste de aceitação do usuário (UAT), é onde clínicos e usuários reais confirmam que o sistema funciona em seu contexto real antes de entrar em produção. O teste de aceitação operacional (OAT) confirma que o serviço pode ser operado, copiado e recuperado. O UAT com usuários finais genuínos pega os descompassos de fluxo de trabalho que nenhum teste de desenvolvedor pega.

Ambientes de teste e dados de teste seguros. Um ambiente de implantação é um sistema onde o software roda — tipicamente os níveis de desenvolvimento, teste, homologação e produção. O teste precisa de ambientes que se pareçam com a produção, mas nunca deve usar casualmente dados reais de pacientes. A prática segura usa dados sintéticos (gerados artificialmente) ou dados devidamente anonimizados, para que testar um formulário de encaminhamento não vaze o diagnóstico de um cidadão real.

Barreiras de qualidade, definição de pronto e gestão de defeitos. Uma definição de pronto declara o que significa "terminado" (testado, acessível, documentado, revisado quanto à segurança), para que a qualidade não seja negociável por funcionalidade. As barreiras de qualidade são pontos de verificação que uma mudança deve passar para avançar. A triagem de defeitos é o processo disciplinado de avaliar os defeitos encontrados quanto à gravidade e ao impacto clínico e decidir o que corrigir, quando e o que pode ser entregue como problema conhecido.

Boas práticas#

1. Construa a pirâmide e desloque o teste para a esquerda. Invista numa ampla base de testes unitários e de integração automatizados e rápidos, executados a cada mudança, para que os defeitos apareçam em minutos depois de escritos, e não semanas depois, no UAT. Reserve os testes de ponta a ponta, lentos, para o punhado de jornadas críticas — a prescrição, o encaminhamento, a correspondência de identidade. Isso torna o teste mais barato e mais rápido, que é o que de fato leva as equipes a fazer mais dele.

2. Trate o teste de regressão como um controle de segurança clínica. Antes que qualquer mudança chegue a um sistema clínico em produção, um conjunto automatizado de regressão deve confirmar que o comportamento existente e relevante para a segurança ainda funciona. Mapeie os seus maiores perigos do registro de perigos DCB0129/0160 diretamente a testes de regressão nomeados, de modo que uma mudança que reintroduziria um perigo conhecido faça a construção falhar automaticamente. Este é o mecanismo que lhe permite iterar sobre sistemas em produção sem acumular risco clínico silencioso.

3. Nunca teste com dados reais de pacientes por padrão. Provisione os ambientes de teste e de homologação com dados sintéticos ou robustamente anonimizados, governados pela mesma disciplina de governança da informação e de DPIA da produção (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança). Se um teste específico genuinamente exigir dados semelhantes aos de produção, trate-o como uma exceção controlada, com base legal documentada, minimização e auditoria — e não como conveniência rotineira. Um banco de dados de teste ainda é um banco de dados de pacientes.

4. Teste os requisitos não funcionais tão seriamente quanto os funcionais. Execute testes de desempenho e de carga contra a demanda de pico realista — passagens de plantão, logins de segunda-feira de manhã, uma indisponibilidade regional redirecionando o tráfego —, porque um sistema clínico que fica lento sob carga falhou quando mais importa. Inclua testes de segurança e de acessibilidade frente às Web Content Accessibility Guidelines (WCAG) como tipos de teste permanentes e não opcionais. Os defeitos não funcionais são fáceis de adiar e caros de descobrir em produção.

5. Automatize o teste de acessibilidade e depois verifique-o com pessoas. As verificações automáticas da WCAG pegam uma fração significativa dos problemas (rótulos ausentes, contraste ruim, estrutura) a baixo custo em cada construção, mas deixam passar os que mais importam para os usuários reais de tecnologia assistiva. Combine a varredura automatizada com testes manuais por pessoas usando leitores de tela, navegação apenas por teclado e ampliação. A acessibilidade é um dever legal para os órgãos públicos e uma questão de segurança clínica quando o usuário excluído é um clínico ou um paciente que gerencia o próprio cuidado.

6. Conduza o teste de aceitação do usuário com clínicos reais em condições realistas. Agende o UAT com as pessoas que de fato usarão o sistema — enfermeiros, clínicos gerais, administrativos, farmacêuticos —, exercitando fluxos de trabalho reais, idealmente num ambiente que espelhe a enfermaria ou a clínica, e não numa sala de reuniões silenciosa. O retorno deles pega descompassos perigosos de fluxo de trabalho (um aviso mostrado no momento errado, um padrão que convida ao erro) que os testes unitários não pegam. Reserve tempo de cobertura clínica no orçamento, para que o UAT seja feito direito, e não espremido na base da boa vontade.

7. Torne explícitas e impostas a definição de pronto e as barreiras de qualidade. Acorde o que significa "pronto" no seu contexto — testes aprovados, conformidade de acessibilidade, varredura de segurança limpa, revisão de segurança clínica concluída, documentação atualizada — e imponha isso como uma barreira, e não como um desejo. Uma definição de pronto escrita, mas rotineiramente dispensada sob pressão de prazo, é pior do que nenhuma, porque lava trabalho inseguro como concluído. As barreiras devem ser automatizadas sempre que possível, para que não possam ser puladas em silêncio.

8. Faça a triagem e a gestão dos defeitos com a gravidade clínica em primeiro plano. Avalie todo defeito não apenas quanto à gravidade técnica, mas quanto ao impacto clínico e à probabilidade, usando a mesma lente de risco do seu registro de perigos. Um erro cosmético pode esperar; um defeito que poderia contribuir para uma dose errada bloqueia a liberação independentemente da data de entrada em produção. Mantenha um registro visível de defeitos e seja honesto sobre os problemas conhecidos entregues como riscos aceitos e mitigados, e não escondidos.

9. Integre o teste à esteira de entrega, e não depois dela. Ligue testes automatizados, varredura de segurança e verificações de acessibilidade à esteira de integração e entrega contínuas, para que toda mudança seja testada antes de poder avançar (ver Tópico 3.5 — Ciclos de vida de entrega). Isso torna a qualidade contínua e barata e significa que a capacidade de implantar rapidamente uma correção testada — em si, um controle de segurança — está sempre disponível. As fases manuais de teste de fim de projeto são lentas, tardias e a primeira coisa sacrificada quando o tempo aperta.

Perguntas para discutir com a sua equipe#

1. Se mudarmos uma coisa no nosso sistema clínico em produção amanhã, quão confiantes estamos de que descobriríamos — antes de um paciente — se isso quebrou outra coisa? Esta pergunta sonda a maturidade do seu teste de regressão e a honestidade das suas alegações de segurança. A maioria dos incidentes graves de software clínico não são falhas novas e exóticas, mas regressões: uma mudança que quebrou silenciosamente um comportamento que todos supunham estável, descoberta apenas quando um clínico ou paciente esbarrou nela. Uma boa discussão rastreia uma mudança real recente até os testes que teriam pego uma regressão e pergunta se os maiores perigos do registro de perigos DCB0129/0160 são, cada um, amparados por um teste automatizado que falha quando o perigo reaparece. A tensão a trazer à tona é entre a pressão de entregar correções depressa e a disciplina de provar que nada mais quebrou — e se a sua esteira torna essa prova automática ou a deixa para alguém se lembrar de verificar. Considerem quanto tempo o conjunto de testes leva para rodar, se roda a cada mudança e se alguém desativou em silêncio testes que falhavam para cumprir um prazo. Uma resposta honesta distingue "temos um conjunto de regressão ligado aos nossos perigos clínicos e confiamos nele" de "testamos a mudança que fizemos e esperamos o melhor". Se a resposta é a segunda, vocês estão carregando um risco clínico que não conseguem ver.

2. De onde vêm os nossos dados de teste, e um teste poderia algum dia expor as informações de um paciente real? Os ambientes de teste são uma via comum e pouco examinada para uma violação de dados, porque as equipes sob pressão recorrem aos dados realistas mais fáceis — uma cópia da produção — e os prontuários de pacientes resultantes passam a ficar em sistemas de teste, notebooks ou ambientes de fornecedores menos protegidos. Esta pergunta pede à equipe que rastreie todo ambiente de teste e de homologação até a sua fonte de dados e confronte com honestidade se cópias "só desta vez" de dados reais viraram rotina. A concessão a debater é realismo versus segurança: dados sintéticos e anonimizados são mais seguros, mas podem deixar passar os casos extremos bagunçados que os dados reais contêm, ao passo que os dados reais são realistas, mas um passivo de governança e de violação, e a anonimização verdadeira é mais difícil do que parece porque os registros podem ser reidentificados quando combinados. Ângulos concretos incluem quem pode acessar os ambientes de teste, se os bancos de dados de teste são criptografados e auditados como a produção e se os ambientes de teste dos fornecedores cumprem a mesma barra. Uma resposta forte descreve uma estratégia deliberada — dados sintéticos por padrão, anonimização bem feita, dados reais apenas como exceção documentada, minimizada e de prazo limitado — em vez de um acidente à espera de uma investigação de governança da informação.

3. Quando a data de entrada em produção e a barra de qualidade colidem, o que de fato cede — e quem decide? Toda entrega acaba enfrentando o momento em que o teste não terminou, um defeito está sem solução ou a conformidade de acessibilidade está incompleta, e a data de lançamento se aproxima; o comportamento da sua organização nesse momento revela se a qualidade é um controle genuíno ou meramente aspiracional. Esta pergunta pede à equipe que lembre a última vez que isso aconteceu e descreva com honestidade o que foi cortado: foi o backlog cosmético, ou foi o teste de regressão, o UAT ou a auditoria de acessibilidade? A tensão é real e não deve ser descartada — as datas importam, os ciclos de financiamento são implacáveis e o teste interminável pode ser, em si, um modo de falha —, mas a resolução deve ser governada pelo risco clínico e de equidade, e não por quem grita mais alto. Discutam quem tem autoridade para segurar um lançamento por razões de qualidade sem risco de carreira, se a sua definição de pronto é alguma vez formalmente dispensada e por quem, e se os defeitos conhecidos entregues na entrada em produção são registrados como riscos aceitos ou enterrados em silêncio. Uma boa resposta mostra uma via de decisão clara e nomeada, uma linha nítida abaixo da qual um defeito bloqueia a liberação independentemente da data (qualquer coisa que pudesse contribuir para dano ao paciente) e uma cultura em que dizer "ainda não, não é seguro" é recompensado, e não punido.

4. Os nossos testes de fato cobrem as coisas que poderiam prejudicar um paciente, ou apenas as que são fáceis de testar? Uma construção verde só tranquiliza se os testes por trás dela exercitam os perigos clínicos reais, e é incomodamente comum que um número saudável de cobertura repouse sobre um conjunto que verifica métodos triviais de leitura e escrita enquanto o índice de deterioração, a correspondência de identidade e a exibição de alergias ficam sem teste. Esta pergunta pede à equipe que confronte o conjunto de testes com o registro de perigos DCB0129/0160 e as jornadas de maior risco e pergunte, perigo a perigo, "que teste nomeado falharia se isto desse errado?". A tensão é que as métricas de cobertura premiam o volume, e não a relevância para o risco, e as equipes são tentadas a perseguir uma porcentagem em vez de enfrentar os casos incômodos e difíceis de automatizar — valores-limite, entradas ausentes, combinações clínicas incomuns — que são exatamente onde os pacientes se machucam. Ângulos concretos incluem revisar se os casos-limite e extremos são testados, se o teste exploratório e clínico (o julgamento que as máquinas não substituem) tem lugar ao lado da automação e se alguém já rastreou um incidente real até uma lacuna que os testes deveriam ter pego. Uma resposta honesta fala de cobertura ponderada pelo risco e consegue nomear os testes que guardam os principais perigos, em vez de citar uma única porcentagem como se fosse garantia.

5. Quando testamos a acessibilidade, há usuários reais com deficiência e clínicos reais na sala, ou apenas um verificador automático? As verificações automáticas da WCAG são baratas e pertencem a toda construção, mas detectam apenas uma fração das barreiras que de fato excluem as pessoas, e um serviço pode passar em todas as regras automáticas e continuar inutilizável com um leitor de tela ou apenas pelo teclado. Esta pergunta indaga se os seus testes de acessibilidade e de aceitação do usuário alcançam pessoas reais usando tecnologia assistiva e clínicos reais percorrendo fluxos de trabalho genuínos, ou se "testamos a acessibilidade" significa, em silêncio, "o verificador estava verde". A concessão a trazer à tona é custo e logística versus honestidade: recrutar usuários de tecnologia assistiva e cobrir o tempo clínico para um UAT realista é caro e fácil de pular, e, no entanto, pulá-lo é como se viola um dever legal e como um descompasso perigoso de fluxo de trabalho — um aviso no momento errado, um padrão que convida ao erro — chega a uma enfermaria em produção. Discutam quem vocês envolvem, quão representativos são, se o teste acontece num ambiente que espelha a clínica, e não numa sala de reuniões silenciosa, e o que fazem com o que encontram. Uma resposta forte descreve verificações automáticas combinadas com testes manuais por usuários com deficiência e UAT conduzido por clínicos como prática permanente e orçada, e não uma caixa marcada uma vez antes da entrada em produção.

6. Quando uma mudança cruza a fronteira entre o nosso sistema e o de outra parte, quem testa a junção — e perceberíamos se quebrasse? Os serviços modernos de saúde e cuidados são montagens de sistemas integrados — um prontuário eletrônico, um serviço da espinha dorsal nacional, uma alimentação de patologia, o módulo de um fornecedor terceirizado —, e os defeitos mais perigosos muitas vezes moram não dentro de um componente, mas nas costuras entre eles, onde uma mudança de um lado de uma interface quebra silenciosamente o outro. Esta pergunta pede à equipe que mapeie suas integrações críticas e pergunte, para cada uma, quem é dono do teste de ponta a ponta, que dados sintéticos fluem pela fronteira e como uma mudança incompatível numa versão de um fornecedor seria detectada antes de chegar aos pacientes. A tensão é que nenhuma equipe isolada se sente totalmente responsável por uma interface compartilhada, os contratos e os conselhos consultivos de mudança andam em velocidades diferentes e testar através de fronteiras organizacionais é lento, político e fácil de deixar ao acaso. Ângulos concretos incluem testes de contrato e de interface, ambientes de teste compartilhados, como as notificações de mudança de fornecedores são tratadas e se o seu conjunto de regressão exercita a jornada integrada (encaminhamento enviado, recebido, confirmado) e não apenas a sua metade. Uma resposta honesta nomeia quem responde por cada junção e mostra um mecanismo — automatizado sempre que possível — que pega uma regressão entre fronteiras, em vez de supor que a outra parte tem isso coberto.

Na prática: um exemplo de saúde e cuidados#

Um hospital de agudos do NHS está lançando um novo módulo de observações eletrônicas e de escore de alerta precoce (EWS) dentro de seu prontuário eletrônico do paciente, substituindo as fichas de papel em que os enfermeiros registram sinais vitais e o sistema calcula um escore de deterioração. O perigo clínico é óbvio: um escore errado poderia significar que um paciente em deterioração não seja escalado.

A equipe constrói a pirâmide desde o início. Os testes unitários cobrem o cálculo do EWS frente às regras nacionais de pontuação, incluindo casos-limite (os limiares exatos em que um escore passa a exigir escalonamento) e entradas difíceis (frequência respiratória ausente, um paciente em oxigênio suplementar). Os testes de integração confirmam que o escore flui corretamente para o alerta de escalonamento e a lista de tarefas de enfermagem. Um pequeno conjunto de testes de ponta a ponta exercita a jornada completa, da entrada à beira do leito até um alerta disparado. Cada perigo do registro de perigos DCB0160 é mapeado a testes nomeados, e todo o conjunto roda automaticamente a cada mudança na esteira de integração contínua.

Os ambientes de teste são provisionados com pacientes sintéticos — padrões realistas de sinais vitais, incluindo trajetórias de deterioração —, de modo que nenhum prontuário real jamais sai da produção. O teste de desempenho simula uma ronda completa na enfermaria na passagem de plantão, confirmando que os alertas disparam em segundos sob carga de pico. O teste de acessibilidade, automatizado em cada construção e verificado manualmente com uma enfermeira usando ampliação de tela, pega um banner de alerta de baixo contraste.

O UAT numa enfermaria-piloto, com enfermeiras reais percorrendo cenários simulados, traz à tona uma falha de fluxo de trabalho que nenhum desenvolvedor havia visto: o diálogo de confirmação aparecia depois do escore, tentando a equipe a dispensá-lo por reflexo. A equipe redesenha o fluxo e acrescenta um teste de regressão. Na entrada em produção, três defeitos cosméticos são entregues como problemas documentados e aceitos; dois que tocavam o cálculo foram corrigidos e bloquearam a liberação até passarem, e o caso de segurança cita diretamente a evidência dos testes. Seis meses de operação depois, uma mudança de rotina na lista de tarefas aciona um teste de regressão que, sem detecção, teria suprimido um alerta de escalonamento — pego na esteira, corrigido antes da implantação, sem jamais chegar a uma enfermaria.

Perspectivas setoriais#

Startup#

Uma pequena empresa de saúde digital tem a vantagem de incorporar testes automatizados e integração contínua ao seu DNA desde o primeiro dia, sem processo manual de teste legado a desfazer, e consegue uma iteração rápida e segura que uma grande organização invejaria. O perigo é tratar o teste como luxo a adiar enquanto persegue o encaixe produto–mercado e economizar nos testes não funcionais e de segurança clínica que nenhum cliente inicial ainda exige. O fundador deve lembrar que as obrigações da DCB0129 recaem sobre o fabricante independentemente do porte da empresa; assim, a evidência de regressão por trás de uma alegação de segurança não é opcional nem antes da receita. Os dados de teste sintéticos também são amigos da startup: evitam o fardo de governança de tratar dados reais de pacientes antes de a empresa ter os controles para fazê-lo com segurança.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — geralmente compra os seus sistemas clínicos em vez de construí-los; assim, a sua tarefa de teste é de aceitação, e não de construção: confirmar que uma atualização de fornecedor ou uma nova integração ainda funciona com segurança no fluxo de trabalho real antes que a equipe dependa dela. Com pouca ou nenhuma capacidade de TI dedicada, a disciplina prática é uma lista de verificação curta e repetível, executada contra as jornadas de maior risco (agendamento, prescrição, registro de observações) após cada mudança do fornecedor, idealmente num ambiente de teste ou treinamento com pacientes sintéticos, e não com prontuários reais. Aplicam-se os mesmos deveres de segurança de implantação DCB0160 e de acessibilidade de um grande hospital, mas sem a equipe de teste; assim, o movimento realista é apoiar-se na garantia do fornecedor, retendo o punhado de verificações locais de aceitação que só vocês podem fazer — isto se encaixa em como esta clínica realmente funciona? Um pequeno prestador que pula até isso e testa as mudanças diretamente em pacientes reais está a uma atualização ruim de distância de um incidente de segurança que não tem como detectar.

Grande organização#

Um hospital do NHS ou um grande fornecedor conduz o teste em escala e sob plena garantia: ambientes de teste dedicados, UAT formal com cobertura clínica, teste de aceitação operacional, testes de intrusão de segurança e conselhos consultivos de mudança controlando as liberações para sistemas clínicos em produção. O desafio característico é o legado — sistemas grandes e antigos com pouca cobertura de testes automatizados, em que toda mudança é temida porque ninguém tem certeza do que ela pode quebrar, produzindo ciclos de regressão manuais, lentos e caros. O movimento estratégico é investir de forma constante em cobertura de testes automatizados em torno das áreas de maior risco, convertendo o medo em confiança e versões lentas em rápidas e seguras. As grandes organizações também carregam o fardo de coordenação do teste entre sistemas integrados, onde uma mudança no produto de um fornecedor pode quebrar o de outro.

Governo#

Um órgão nacional conduz o teste sob o Service Standard, avaliações de serviço publicadas e o mais alto nível de responsabilização pública, onde uma falha de teste num sistema nacional pode afetar milhões e chegar ao Parlamento. O teste de acessibilidade frente à WCAG é um dever legal imposto aos órgãos do setor público, e o teste não funcional em escala nacional — carga, resiliência, segurança — é existencial, e não opcional. O desafio é coordenar a garantia da qualidade entre muitos fornecedores e serviços integrados e manter uma definição consistente de pronto num programa extenso. Os serviços nacionais também moldam o ecossistema: os dados de teste, as ferramentas e os padrões que um órgão governamental torna obrigatórios ou publica se tornam a norma segundo a qual os fornecedores constroem.

Modos de falha comuns#

• A pirâmide invertida. O teste é sobretudo de verificações lentas, manuais e de ponta a ponta; a retroalimentação é lenta, a cobertura é fina e o teste de regressão é pulado sob pressão de tempo. Antídoto: investir numa ampla base de testes unitários e de integração automatizados e rápidos.
• O teste como fase final. O teste é uma etapa espremida antes da entrada em produção e a primeira coisa cortada quando o cronograma escorrega. Antídoto: deslocar para a esquerda e ligar o teste à esteira de integração contínua, para que seja contínuo e barato.
• Dados reais em ambientes de teste. Prontuários reais de pacientes são copiados para sistemas de teste menos protegidos em nome do realismo, criando uma violação à espera de acontecer. Antídoto: dados sintéticos e anonimizados por padrão; dados reais apenas como exceção governada.
• Construção verde, sem confiança. Os testes passam, mas cobrem trivialidades enquanto os perigos clínicos reais ficam sem teste. Antídoto: mapear explicitamente os testes ao registro de perigos e às jornadas de maior risco.
• A acessibilidade como caixa automática. Uma varredura automática aprovada é tratada como conformidade enquanto usuários reais de tecnologia assistiva nunca são envolvidos. Antídoto: combinar verificações automáticas com testes manuais por usuários com deficiência.
• A definição de pronto dispensada. "Pronto" é definido, mas rotineiramente anulado sob pressão de prazo, lançando trabalho inseguro como concluído. Antídoto: automatizar as barreiras e dar a alguém autoridade para segurar um lançamento por razões de qualidade.

Modelo de maturidade#

Lista de verificação#

• Existe uma pirâmide de testes: ampla cobertura automatizada unitária/de integração, poucos testes de ponta a ponta, todos executados na integração contínua.
• Os maiores perigos do registro de perigos DCB0129/0160 estão, cada um, mapeados a testes de regressão automatizados e nomeados.
• Um conjunto de regressão roda e precisa passar antes que qualquer mudança chegue a um sistema clínico em produção.
• Os ambientes de teste e de homologação usam dados sintéticos ou anonimizados; os dados reais de pacientes nunca são usados casualmente.
• O teste de desempenho e de carga é executado contra a demanda de pico realista das jornadas clínicas críticas.
• Os testes de segurança e de acessibilidade WCAG (automáticos mais manuais com usuários de tecnologia assistiva) são tipos de teste permanentes.
• O teste de aceitação do usuário é conduzido com clínicos reais em condições realistas, com tempo de cobertura orçado.
• Existem uma definição de pronto e barreiras de qualidade impostas, que não são dispensadas em silêncio sob pressão de prazo.
• Os defeitos são triados por impacto clínico, e os problemas conhecidos entregues na entrada em produção são registrados como riscos aceitos e mitigados.
• A evidência dos testes é citada diretamente no relatório do caso de segurança clínica.

Fontes-chave#

• NHS England Digital — normas de gestão de riscos clínicos DCB0129 e DCB0160; registro de perigos e relatório do caso de segurança clínica.
• NHS England — NHS Service Standard e NHS Digital Service Manual (acessibilidade, testes e operação de um serviço confiável).
• GOV.UK Service Manual (Government Digital Service) — orientações sobre testes, dados e ambientes de teste, acessibilidade e entrega contínua.
• W3C Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) 2.2 e técnicas de teste.
• NHS England — Digital Technology Assessment Criteria (DTAC), incluindo segurança clínica, garantia técnica e usabilidade/acessibilidade.
• ISTQB (International Software Testing Qualifications Board) — terminologia fundamental de testes e níveis de teste.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
• Mike Cohn — o conceito da pirâmide de testes; Martin Fowler / Continuous Delivery (Humble e Farley) — automação de testes e prática de CI/CD.

Referências#

1. Software testing — Wikipedia — https://en.wikipedia.org/wiki/Software_testing
2. Quality assurance — Wikipedia — https://en.wikipedia.org/wiki/Quality_assurance
3. Unit testing — Wikipedia — https://en.wikipedia.org/wiki/Unit_testing
4. Integration testing — Wikipedia — https://en.wikipedia.org/wiki/Integration_testing
5. Shift-left testing — Wikipedia — https://en.wikipedia.org/wiki/Shift-left_testing
6. Non-functional testing — Wikipedia — https://en.wikipedia.org/wiki/Non-functional_testing
7. Regression testing — Wikipedia — https://en.wikipedia.org/wiki/Regression_testing
8. Test automation — Wikipedia — https://en.wikipedia.org/wiki/Test_automation
9. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
10. Acceptance testing — Wikipedia — https://en.wikipedia.org/wiki/Acceptance_testing
11. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
12. Deployment environment — Wikipedia — https://en.wikipedia.org/wiki/Deployment_environment
13. Synthetic data — Wikipedia — https://en.wikipedia.org/wiki/Synthetic_data
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
16. Testing your service, and test data and environments — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology
17. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/WAI/standards-guidelines/wcag/
18. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-tools/digital-technology-assessment-criteria-dtac/
19. Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK Government / GOV.UK — https://www.legislation.gov.uk/uksi/2018/952/contents/made
20. Continuous Delivery — Jez Humble and David Farley — https://continuousdelivery.com/