CSV baseada em risco: onde focar testes

Validar tudo da mesma forma é o caminho mais caro pra entregar um pacote fraco. A abordagem baseada em risco dirige esforço pra onde o impacto é alto.

O GAMP 5 (2ª edição), o ICH Q9 (R1) e a draft guidance do FDA sobre CSA (Computer Software Assurance) convergem num mesmo princípio: validar com proporcionalidade ao risco. Em vez de testar 200 casos de teste no mesmo nível de profundidade, identifica quais funcionalidades realmente impactam segurança do paciente, integridade dos dados, ou qualidade do produto — e foca lá.

Esse artigo mostra como classificar funcionalidades por risco, como ajustar a profundidade dos testes, e onde está a armadilha que faz a abordagem virar desculpa pra cortar canto.

Os três níveis clássicos de risco em CSV

A maioria das implementações de risk-based CSV usa três faixas:

1. Risco alto: funcionalidades que impactam direto segurança do paciente, integridade dos dados regulados, ou qualidade do produto liberado. Ex: assinatura eletrônica, audit trail, controle de versão, workflow de aprovação de batch record.
2. Risco médio: funcionalidades que impactam indiretamente — automatizam processos GxP mas com camada humana de revisão. Ex: notificações de prazo, dashboards de KPI, agendamento de treinamento.
3. Risco baixo: funcionalidades suporte que não tocam em dados regulados. Ex: temas de UI, preferências de usuário, busca interna sem impacto em decisão regulada.

Como ajustar o teste por nível

Risco alto

• Casos de teste detalhados (positivo + negativo + edge case)
• Teste manual com evidência (screenshot, log)
• Cobertura de matriz de transição de estados
• Trace bidirecional: requisito → caso de teste → execução

Risco médio

• Testes focados no fluxo principal
• Evidência pode ser amostral (não 100% dos cenários)
• Pode usar testes automatizados quando disponível

Risco baixo

• Smoke test ou "fit for use" simples
• Documentação leve
• Em alguns casos, basta vendor assurance + verificação pontual

A armadilha que vira achado

O risco do risk-based: usar como desculpa pra subdimensionar testes em coisas que deveriam ser de risco alto. Auditor experiente identifica isso rápido:

• "Vocês classificaram audit trail como risco médio. Justifiquem com base no impacto à integridade dos dados."
• "O workflow de aprovação de lote tem só smoke test. Como vocês garantem segregação Part 11?"
• "A análise de risco menciona ICH Q9, mas não vejo a justificativa documentada pra cada classificação."

A defesa precisa estar escrita: cada classificação deve ter base documentada (impacto × probabilidade × detectabilidade), revisada por pessoa competente.

Onde mora o ganho real

A vantagem da abordagem baseada em risco não é fazer menos teste. É fazer o teste certo no lugar certo. Validar 100 casos triviais em vez de 30 críticos significa pacote inchado mas frágil. O foco em alto risco entrega:

• Menos noise em revisão
• Evidência mais forte onde importa
• Menor custo total (porque o esforço é direcionado)
• Defesa melhor em inspeção

Conexão com a 2ª edição do GAMP 5

A 2ª edição do GAMP 5 reforça três pontos:

• "Critical thinking" — engenheiro de validação tem que pensar, não só seguir template
• Iterativo/Agile aceito desde que com governança
• Foco no resultado, não no volume de documentação

Isso reforça a abordagem baseada em risco: documentação proporcional, não volumosa por hábito.

FDA CSA: mesma direção, com nome novo

A draft guidance de Computer Software Assurance (CSA) do FDA reforça o mesmo princípio em outra linguagem. Em vez de "validar tudo", o FDA pede "assegurar o que importa" — com testes scriptados onde o risco é alto, e testes exploratórios ou unscripted onde o risco é baixo. Veja a leitura dedicada do guia CSA.