Testes Baseados em Riscos (Risk-Based Testing)
Uma abordagem importante para prever e mitigar inconsistências na aplicação.
Os riscos estão presentes em diversas áreas de conhecimento, porém eles têm um significado distinto em cada contexto. A definição generalizada do termo, segundo a Wikipedia:
É a possibilidade de algo ruim acontecer. Envolve incertezas/implicações sobre o efeito de uma atividade com relação a algo que os humanos valorizam, geralmente focando nas consequências negativas e indesejáveis.
No contexto de engenharia de software, os riscos podem estar relacionados diretamente ao gerenciamento do projeto como um todo ou voltados estritamente para o uso da aplicação, focando nas possíveis experiências negativas que serão percebidas pelos usuários do produto. É aí que entra a abordagem de testes baseada em riscos!
Segundo um artigo da ReQtest, essa técnica checa a probabilidade de ocorrência de falhas na aplicação, utilizando casos de teste previamente criados para prever o impacto do que foi desenvolvido nos negócios do cliente. Além disso, partes críticas da aplicação são priorizadas, onde a probabilidade de ocorrer falhas é maior e onde também deve ser investido esforço na correção de bugs críticos.
Aplicação dos testes baseados em riscos
Dependendo do contexto (tradicional ou ágil), há diferenças de como os dados são coletados, das cerimônias realizadas e dos artefatos produzidos. A seguir, será detalhada uma abordagem mais genérica da aplicação dessa técnica.
Passo 1: Identificação dos Riscos
Para identificar os riscos, podemos realizar:
- Reuniões de brainstorming, envolvendo, se possível, todas as áreas participantes do projeto, tanto a área técnica quanto a de negócios ou até mesmo o próprio usuário. O intuito da cerimônia é que cada um identifique um risco na aplicação/projeto.
- Histórico de falhas/Riscos já conhecidos: quantas vezes o deploy de determinada funcionalidade gerou bugs em produção? Qual a funcionalidade mais problemática nos últimos meses? Qual parte do sistema gera mais queixas dos usuários? Coletando essas informações, podemos ter uma noção básica de pontos da aplicação que precisam ser observados com mais cautela e possíveis riscos já identificados anteriormente, devido ao histórico de problemas no software.
- Estratégia Inside Out: fazer repetidas vezes a pergunta “o que pode dar errado aqui?”. As respostas devem levar em consideração as possíveis falhas que podem vir a existir na aplicação, situações de vulnerabilidade e também quem será impactado pela possível falha.
- Estratégia Outside In: os riscos são explorados baseando-se em modelos de qualidade, a exemplo da NBR ISO/IEC 9126, e para cada tópico desse modelo é feita a pergunta: “O que pode acontecer se esse item não for atendido?”.
- Avaliação da complexidade da aplicação ou funcionalidade: devido ao nível de complexidade do que foi desenvolvido, o que pode dar errado? Como essa funcionalidade influencia no sistema? O código da funcionalidade está muito acoplado?
Passo 2: Priorização dos riscos
Após a identificação dos riscos, eles devem ser priorizados. As abordagens comumente utilizadas são a relação probabilidade x impacto e a matriz de riscos.
Probabilidade x Impacto
Para cada risco é dado um valor, de 1 a 5 para a probabilidade e para o impacto. Quanto menor o valor, menor a probabilidade da situação ocorrer e menor o impacto para os usuários/negócios. Posteriormente, o valor da probabilidade e do impacto são multiplicados, resultando no fator de risco, o qual será utilizado para priorização. Os riscos com maior pontuação precisam de maior atenção e demandarão maior tempo para testes.
Geralmente, a probabilidade é definida pelo time técnico do produto e o impacto pela área de negócios.
Matriz de riscos
A matriz de riscos segue a mesma linha de raciocínio da tabela anterior, no entanto são utilizadas as palavras-chave baixo (low), médio (medium) e alto (high) ao invés de valores para determinar a priorização das atividades, conforme figura abaixo:
Nessa figura, os riscos foram priorizados de acordo com os valores da tabela anterior.
Passo 3: Definir as estratégias para a mitigação dos riscos
Com os riscos devidamente identificados, sabemos onde investir esforços em testes. Usando o exemplo anterior, podemos associar cada módulo do sistema a um risco específico, por exemplo, o risco 1 diz respeito ao módulo 1.
Os riscos 4 e 3 tiveram as maiores pontuações, então eles devem ser o foco da estratégia. O plano de mitigação pode englobar:
- Definir quais técnicas de testes serão utilizadas para cobrir os riscos;
- Criar casos de testes especificamente voltados para a cobrir os riscos encontrados;
- Priorizar a execução de todos os casos de testes associados à esses módulos;
- Realizar uma análise mais aprofundada dos impactos na modificação desses dois módulos no ambiente de produção, levando em consideração o histórico de falhas;
- Negociar o aumento do prazo para a entrega do projeto, visto que foram detectados pontos críticos nos módulos 3 e 4 (esse ponto pode estar diretamente relacionado ao anterior).
Outros pontos também podem estar englobados no plano de mitigação, tudo depende do contexto do projeto.
Testes baseados em riscos no contexto ágil
Em um artigo da InfoQ, Ben Linders relata a experiência de Csaba Szökőcs na implementação de testes baseados em riscos em um time ágil que utiliza o Scrum.
Csaba afirma que os times tentaram coletar os riscos de cada história antes do planejamento da sprint e que isso os ajudou a como pensar em testar as atividades antes que as histórias fossem implementadas. Depois de coletados, dois profissionais priorizam os riscos através da relação probabilidade x impacto e todos os pontos críticos com alta exposição devem ser tratados de alguma forma.
Esse tipo de teste normalmente é adotado quando se tem um curto espaço de tempo para testar e é feito por equipes de teste para encontrar os casos mais críticos que precisam ser testados, onde os testadores executam testes separados e independentes baseados nos riscos identificados para quase todas as histórias de usuários.
Abaixo, o depoimento de Csaba em uma entrevista com o InfoQ, onde ele comenta sobre a coleta dos riscos:
Coletamos os riscos no contexto da história do usuário respondendo à pergunta: “O que pode dar errado nesta história?”.
Além disso, tentamos imaginar que o novo recurso já em funcionamento e pensamos em diferentes cenários, como será usado da maneira correta e como será mal utilizado. Nós tentamos combinar o novo recurso com outros recursos existentes, respondendo à pergunta: “Pode dar errado de alguma forma?
Prós e contras da adoção dos testes baseados em riscos
Henriette Harmse lista algumas vantagens e desvantagens da adoção desta técnica:
Vantagens
- Os itens mais críticos são desenvolvidos e testados primeiro, o que reduz o risco geral no projeto;
- Se o prazo for apertado, existe uma diretriz para guiar o que deve ser testado e o que não deve ser testado;
- A qualquer momento, pode-se indicar novos riscos no projeto. Dessa forma os riscos podem ser priorizados novamente, levando em conta os itens mais críticos que ainda não foram testados;
- Os riscos identificados são uma informação valiosa para todos os envolvidos no projeto e podem ser utilizadas em negociações.
Desvantagens
- Com essa abordagem, partes do sistema não serão testadas intencionalmente;
- Os valores atribuídos aos riscos podem ser subjetivos, por isso é necessário discutir com o time os valores propostos;
- Pode aumentar a carga de documentação.
Riscos x Incertezas
James Thomas, em seu artigo publicado no Ministry of Testing, traz uma reflexão sobre relação entre risco e incerteza na aplicação da abordagem de testes baseados em riscos e todo o conteúdo dessa seção é baseado nesse artigo.
Segundo Frank Knight:
Riscos: são reservados para cenários em que podem ser medidos quantitativamente, geralmente usando a probabilidade;
Incerteza: situações que não são quantificáveis ou medidas, com as ferramentas que o time tem atualmente.
Sabendo das diferenças, podemos construir uma matriz que traz a relação entre esses dois conceitos, conforme a figura abaixo:
James afirma que os riscos estão associados ao primeiro quadrante (known known), onde todo o time está ciente do problema e entende todas as suas nuances a ponto de medi-lo quantitativamente.
Em todos os outros quadrantes, há um nível de incerteza que pode ser desvendado com as atividades de testes e análise mais aprofundada da situação. A ideia é transformar todos os níveis de incerteza em algo sabido e mensurável!
Conclusão
Os testes baseados em riscos ajudam a priorizar esforços em histórias e partes críticas da aplicação e existem diversas formas de como colocar essa técnica em prática.
Traçando um bom planejamento de como adotar essa estratégia em seu time irá te ajudar na antecipação de diversas situações que só seriam perceptíveis no ambiente de produção, o que causa uma experiência negativa do produto para o usuário final.
Já utiliza RBT ou gostaria de utilizar? Acredita que valha a pena adotar essa prática? Deixa nos comentários a sua opinião! #hugs.
Referências
- Risks - Wikipedia
- Why Risk Based Testing is Your Best Bet to Deliver Software? - ReQtest
- Brainstorming - Wikipedia
- Teste de software baseado em risco - Devmedia
- Adaptando o teste baseado em risco para equipes ágeis: Pense em testar antes de codificar - Ben Linders
- Risk Based Testing - Henriette Harmse
- Not Sure About Uncertainty - James Thomas
- Testes Baseados em Riscos - Matera
- Risk Based Testing - Pyiorot
- Simplify Risk Based Testing: Keep it RIL - Smartbear
- Risk Based Testing: When and How? - Yukti Srivastava
- QA Journal: Risk-Based Testing - SimbirSoft
