TESTES BASEADOS EM RISCOS

De acordo com um estudo realizado pelo NIST – National Institute of Standards and Techonology as organizações vem aumentando consideravelmente seus investimentos na área de testes. Na década de 1960-70 cerca de 10% dos custos de desenvolvimento de software eram destinados à atividades de testes que se resumiam em testes de integração e de sistemas. Já na década de 90 cerca de 30% do valor gasto no desenvolvimento eram destinados a testes partindo da fase de codificação. No século 21 ganhou ainda mais importância onde a abrangência dos testes aumentou começando já na fase de especificação de requisitos.

Sabendo que é impossível testar exaustivamente uma aplicação e que um bom planejamento é essencial num projeto de testes é de extrema importância conhecer o software que será testado e mapear seus riscos considerando o seu nível de impacto e probabilidade de acontecimento.

Abaixo vamos entender um pouco sobre testes baseados em riscos e como fazê-lo:

 Testes Baseados em Riscos

Teste é um exercício com o objetivo de reduzir riscos. Portanto, necessitamos de uma alternativa que seja pragmática, acessível, rápida e que forneça resultados, ou seja, necessitamos de uma priorização dos testes baseados em riscos.

Devemos priorizar os testes levando em consideração primeiramente o nível de risco para o projeto. Se uma falha ocorrer no sistema qual será a consequência? Exemplo: num sistema de Empréstimo um módulo de pagamento é muito mais importante que o módulo de relatórios. Deste modo a maior carga de testes deve ser realizada no módulo de pagamento para garantir maior confiabilidade e buscar evitar falhas que possam interromper o fluxo de negócio do usuário.

Riscos podem ser classificados em dois tipos:

Risco de Projeto:

  • Risco de Fornecedores
    • Riscos contratuais
    • Terceiros falharem com suas entregas
  • Riscos Organizacionais
    • Ausência de funcionários qualificados
    • Riscos relacionados a treinamento e suporte
    • Riscos de Comunicação
  • Técnicos
    • Requisitos incompletos ou sua total ausência
    • Qualidade da análise ou do código
    • Solução de arquitetura adotada

Risco de Produto

  • Sistema entregue com muitos bugs
  • Sistema não atender seus requisitos
  • Sistema com problemas de:
    • Funcionalidade
    • Segurança
    • Confiabilidade
    • Desempenho
  • Riscos do produto são riscos para o projeto

Devemos saber identificar os riscos e suas consequências. Pra isso podemos seguir um boas práticas:

  1. Avaliar problemas já enfrentados em outros projetos
  2. Reuniões de brainstorming com os envolvidos
  3. Realizar revisão da documentação do sistema
  4. Utilizar uma lista de verificação com os riscos conhecidos
Medindo Riscos

Para identificar os riscos, priorizá-los e saber quais estratégias tomar, podemos realizar uma análise qualitativa levando em consideração a medida do risco.

Medida do Risco (criticidade) = Probabilidade x Impacto

Probabilidade é a possibilidade ou change de um evento de risco acontecer.

Impacto é o efeito no projeto se o evento de risco acontecer.

riscos
Figura 1 – Probabilidade x Impacto

Para medirmos os riscos podemos utilizar a matriz de priorização onde o objetivo é compará-los e identificar quais são os mais importantes e que merecem maior atenção. A priorização é importante porque normalmente os recursos de um projeto são escassos e, portanto, devemos concentrar esforços nos riscos mais críticos.

Podemos classificar os riscos com números de 1 à 9. Por exemplo: do 1 ao 3 criticidade Baixa, do 4 ao 6 criticidade Média e do 7 ao 9 criticidade Alta. Após o levantamento e classificação multiplicamos a Probabilidade pelo Impacto. Vejamos o exemplo abaixo:

diagrama-21
Figura 2 – Matriz de Priorização

Os riscos que apresentarem criticidade média e alta deverão ter uma atenção maior durante o andamento do projeto de testes.

Planejamento de Ações

Com os riscos identificados será necessário desenvolver um plano de ação para cada um. Para isso, existem 4 estratégias que nos ajudam a analisar e selecionar a melhor abordagem para cada risco:

Mitigar: Ações que minimizam a probabilidade da ocorrência do risco ou seu impacto com o objetivo de torná-lo aceitável.

Evitar: Ações que podem modificar o projeto a fim de evitar o risco. Normalmente riscos com esta classificação são considerados de grande impacto.

Aceitar: Aceitar o risco significa que se caso o risco ocorra no decorrer do projeto nenhuma ação será tomada. Isso porque estes riscos são considerados baixos e caso ocorram podem ser facilmente tratados.

Transferir: Repassar as consequências e responsabilidades do risco para outra pessoa melhor preparada para gerenciar.

Abaixo veremos exemplos de planos de ação:

Casos de Exemplo

Cenário 1

Problema: Não teremos tempo para executar todos os testes planejados.

Plano de Ação: Como já identificamos e classificamos os riscos vamos concentrar os esforços de testes nos cenários com maior risco e então entregar a funcionalidade com menor probabilidade de impacto no negócio.

Cenário 2

Problema: De 300 casos de testes somente 150 passaram. Os demais apresentaram falha. Vamos liberar a funcionalidade?

Plano de Ação: Como já conhecemos os riscos devemos analisar seus potenciais. Qual o risco/impacto oferecido que esses casos testes com falha oferecem para o negócio?

Na Prática…
  • O teste pode nos ajudar na identificação de novos riscos, principalmente durante o planejamento
  • Teste reduz a probabilidade e impacto de um risco ocorrer
  • Teste nos fornece um feedback sobre riscos residuais, através da medição de defeitos críticos e planos de ação
  • Em testes baseados em riscos além de determinarmos a prioridade dos testes também conseguimos levantar quais técnicas de testes serão utilizadas
Conclusão

Em todo e qualquer projeto devemos levantar os potenciais riscos que ele pode oferecer e ter em mãos planos de ações para minimizar os impactos no projeto. Se tratando de um projeto de testes o princípio mais importante da identificação e classificação dos riscos é que priorizá-los é de suma importância para que sempre que seja necessário parar os testes tenhamos certeza que realizamos o nosso melhor teste dentro do tempo disponível.

DICA! Aproveite para ler também Planejamento de Testes.

Referências:

[1] http://projetogerenciado.com.br/5-maneiras-de-gerenciar-os-riscos/

[2] http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?UserActiveTemplate=site%2Cmobile&infoid=44847&sid=15

Por EMANUELLE BERNARDO SPONTON

Formada em Tecnologia e Análise de Desenvolvimento de Sistemas, Certificada em Testes (Foundation Level - CTFL), e-learning em Gestão de Projetos - FGV, cursando Gestão e Estratégia de Empresas - Instituto Unicamp

Postado em: 12 de abril de 2017

Confira outros artigos do nosso blog

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Protractor – Testes automáticos end-to-end para aplicações em Angular

07 de dezembro de 2017

Jacqueline Costa

Testes em Node.js

04 de dezembro de 2017

Alan Cesar Elias

Deixe seu comentário