Skip to main content

Testes Baseados em Risco

Conceito de risco em QA

Em QA, risco representa a possibilidade de uma falha gerar impacto negativo no sistema, no negócio ou no usuário final. Esse impacto pode ser técnico, operacional, legal ou relacionado à experiência do usuário.

Na DBSeller, testar baseado em risco significa não tratar todas as funcionalidades da mesma forma, mas direcionar esforço de teste para onde o impacto de erro é maior. Isso é essencial em sistemas complexos e integrados, como o e-Cidade, onde uma alteração pontual pode afetar diversos módulos e rotinas.

Risco não é apenas “algo pode dar errado”. Risco é a combinação entre:

  • o impacto caso algo dê errado

  • a probabilidade de isso acontecer

Como identificar riscos

A identificação de riscos começa antes da execução dos testes, ainda na análise da demanda. O QA deve olhar a task não apenas como “o que precisa ser feito”, mas como “o que pode dar errado”.

Na prática, o QA deve analisar:

Contexto da funcionalidade

  • módulo envolvido (educação, saúde, financeiro, etc.)

  • tipo de dado tratado (cadastros, relatórios, dados sensíveis)

  • integração com outras rotinas ou módulos

Tipo de alteração

  • nova funcionalidade

  • melhoria em funcionalidade existente

  • correção de bug

Quanto mais a alteração interfere em algo já existente, maior tende a ser o risco de impacto colateral.

Impacto x Probabilidade

Após identificar os riscos, o QA deve avaliá-los considerando dois fatores principais:

Impacto

Pergunta-chave: se isso falhar, o que acontece?

Exemplos de impacto:

  • informação incorreta em relatórios oficiais

  • divergência entre tela e relatório

  • exposição de dados incorretos ao usuário

  • necessidade de retrabalho manual

Probabilidade

Pergunta-chave: quão provável é essa falha ocorrer?

A probabilidade aumenta quando:

  • a funcionalidade depende de múltiplas regras

  • há histórico de problemas similares

  • existem integrações com outras rotinas

  • o comportamento depende de dados variáveis

A combinação desses dois fatores orienta a priorização dos testes.

Exemplo prático de análise de risco

Contexto da demanda 

Uma demanda solicita a criação de um relatório de dados de uma entidade, baseado em um modelo específico fornecido pelo cliente. O relatório deve refletir exatamente as informações exibidas na tela, respeitando layout, regras de exibição e vínculos relacionados.

A funcionalidade envolve:

  • geração de relatório

  • dados vindos de múltiplas rotinas

  • regras condicionais de exibição

  • possível impacto legal ou administrativo

Identificação inicial de riscos

Ainda na análise da demanda, o QA poderia levantar os seguintes pontos de risco:

Risco 1: Divergência entre tela e relatório

  • A tela pode exibir corretamente os dados

  • O relatório pode não refletir todas as variações

Pergunta do QA:

Todos os cenários exibidos na tela também precisam ser refletidos no relatório?

Risco 2: Múltiplos vínculos associados

  • Um registro pode possuir mais de um vínculo associado

  • O layout do relatório pode não comportar todos

Pergunta do QA:

O que acontece quando há mais de um vínculo associado?
O relatório deve paginar ou omitir dados?

Risco 3: Dados inativos ainda exibidos

  • Informações marcadas como inativas podem continuar aparecendo

  • Isso gera inconsistência e risco de uso indevido da informação

Pergunta do QA:

Dados inativos devem ser exibidos?
Essa regra é válida tanto para tela quanto para relatório?

Risco 4: Dependência de dados de outras rotinas

  • O relatório busca informações de cadastros externos

  • Alterações nessas rotinas podem impactar o resultado

Pergunta do QA:

De onde cada dado do relatório é originado?
O comportamento é o mesmo em todos os cenários?

Como o risco influencia o escopo de teste

Ao identificar esses riscos, o QA ajusta o escopo de teste de forma inteligente, sem testar “tudo igual”.

No exemplo acima, o escopo deveria incluir:

  • cenários com um único vínculo

  • cenários com múltiplos vínculos

  • dados ativos e inativos

  • validação comparativa entre tela e relatório

  • regressão em rotinas relacionadas

Esse tipo de análise poderia antecipar problemas que, no fluxo tradicional, só seriam encontrados após ajustes sucessivos ou em produção.

Benefícios do teste baseado em risco

Ao aplicar testes baseados em risco, a DBSeller consegue:

  • reduzir retrabalho

  • antecipar falhas críticas

  • melhorar a qualidade dos testes

  • direcionar esforço para o que realmente importa

O QA deixa de ser apenas executor e passa a atuar como analista de impacto, contribuindo diretamente para decisões mais seguras.

Teste baseado em risco como prática contínua

Testes baseados em risco não são uma etapa isolada. Eles devem ser aplicados:

  • no refinamento

  • no planejamento

  • na execução

  • na análise pós-release

Cada nova demanda gera aprendizado que alimenta as próximas análises de risco, tornando o processo de qualidade mais maduro e eficiente ao longo do tempo.

Back to top