Teste de software baseado em risco - Revista Engenharia de Software Magazine 48

A atividade de teste tem como objetivo encontrar defeitos, reduzir os riscos associados a um sistema e identificar o máximo de problemas, efetivando a qualidade dos produtos desenvolvidos.

Uma vez que não é rentável testar exaustivamente, além da disponibilidade de tempo, os testes sofrem análise para sua seleção e execução. Umas das bases para essa análise é a visão do coordenador de teste e da equipe de teste quanto à execução e continuidade das atividades de testes. Em alguns casos, também é realizada uma reunião com a equipe do projeto para avaliar o nível de cobertura de teste para determinada funcionalidade, o impacto de defeitos na entrega, gargalos e a qualidade das linhas de base (baseline). Na informalidade, a equipe começa a discutir sobre o ponto de equilíbrio entre o custo do teste e o custo da falha para o negócio.

A técnica de teste baseada em riscos (Risk-basedTesting – RBT) é uma abordagem que minimiza a dificuldade de se priorizar teste e o esforço de teste. A sua execução favorece a identificação, análise e mitigação de fatores de riscos associados aos requisitos do produto de software, além de estimular a proposta de elaboração do plano de teste e caso de teste.

Dentro deste contexto, este artigo apresentará algumas técnicas sobre identificação de defeitos e o teste baseado em risco através das características e subcaracterísticas de qualidade.

Gerenciamento de risco em teste de software

A ausência de uma metodologia de teste e/ou melhoria nos processos de desenvolvimento de software nas organizações tende costumeiramente a tratar a atividade de teste como uma das etapas finais do desenvolvimento de software, sendo esta prática um fator de risco, pois o produto já se encontra “pronto”, acarretando em testes superficiais.

O envolvimento de todos no projeto é fundamental para a realização das avaliações e magnitude do risco. Estudos realizados demonstram que o esforço desprendido na atividade de teste é de 30% a 40% do esforço global do projeto. Embora o teste seja uma forma de mitigação do risco, é necessária uma estratégia de teste que incorpore: os estágios ou níveis a serem abordados (unidade, integração, sistema e aceitação); a fase do ciclo de vida de desenvolvimento em que se aplica determinado teste; e as técnicas de teste, ou seja, como testar (Estrutural e Funcional).

A atividade de teste de software está bastante relacionada ao risco. Quando um analista de teste não planeja a execução de um teste, ou não testa uma parte do sistema, a probabilidade do risco ocorrer é alta. A falta da avaliação do seu impacto compromete as novas etapas do projeto e pode ocasionar outros fatores de risco, tais como: financeiro, humano e recurso.

O teste orientado ao risco auxilia a disponibilização de recursos, prioriza a parte mais crítica do sistema, contribui com a análise de estratégia de teste e práticas de gestão de risco na área de teste, visando à maximização do sucesso do desenvolvimento do produto.

Enquanto não familiarizados com a técnica, podemos nos esbarrar em dúvidas sobre alguns itens como:

• Falta de definição precisa dos riscos (textos ou palavras com dupla interpretação);
• Subjetividade na avaliação do impacto de risco (ausência ou incompletude da causa e impacto);
• Riscos dinâmicos, ocorrendo em diferentes fases do ciclo de vida do projeto.

Para orientar a execução da abordagem de teste baseado em risco são identificadas três atividades distintas:

• Elaborar uma lista de riscos priorizada: Consiste na identificação e análise dos riscos técnicos associados aos requisitos do software;
• Realizar testes que explorem cada risco: Consiste na criação e/ou execução de testes que verificam a existência ou não do risco identificado;
• Acompanhar e controlar os riscos: Assim que um risco for eliminado, um novo risco surge e os esforços de testes devem ser realocados, focando nos riscos mais importantes.

Identificar o risco

O processo de identificação de risco permite aos projetos de desenvolvimento de software a exposição das incertezas que podem ocorrer durante o teste. Para isto, exige um bom conhecimento dos requisitos, perspectivas de negócios do usuário e da interação entre aplicação/interfaces e o ambiente de implantação.

Para identificar o risco com as possibilidades de testes, Bach (1999) orienta o uso de algumas técnicas: de dentro para fora (Inside-Out), de fora para dentro (Outside-in), lista genérica de risco e o questionário baseado em taxonomia de riscos (Taxonomy Based questionnaire –TBQ).

Na primeira abordagem, de dentro para fora (Inside-Out), a estratégia utilizada é realizar repetidamente a pergunta: o que poderia dar errado aqui? O objetivo é considerar quais eventos cuja ocorrência poderá acarretar em perdas, baseando-se nas seguintes perdas:

• Vulnerabilidade: Quais fraquezas ou possíveis falhas existentes neste componente?
• Ameaça: Que entradas ou situações poderiam existir que podem explorar uma vulnerabilidade e disparar uma falha neste componente?
• Vítimas: Quem ou o quê poderia ser impactado por uma possível falha e quão ruim isto seria?

Na segunda técnica, de fora para dentro (Outside-in), os riscos são explorados a partir de listas baseadas nos modelos de qualidade: NBR ISO/IEC 9126, Hewlett Packard – FURPS (Functionality, Usability, Reliability, Performance, Supportability) e outras fontes. Para cada atributo de qualidade da lista abaixo é feito a seguinte pergunta: O que aconteceria se os requisitos associados a este atributo não forem cumpridos?

· Capacitação: Ele pode desempenhar as funções necessárias?

· Confiabilidade: Será que vai funcionar bem e resistir aos defeitos em todas as situações exigidas?

· Usabilidade: O usuário conseguirá realizar com sucesso as tarefas pretendidas pelo sistema?

· Performance: O sistema terá uma resposta aceitável pelo usuário nas realizações de suas funções?

· Instabilidade: O sistema pode ser instalado facilmente nas principais plataformas existentes no mercado?

· Compatibilidade: O sistema é compatível com componentes externos ou outras configurações?

· Suportabilidade: O suporte aos usuários do sistema está dentro do orçamento do projeto?

· Testabilidade: Como o produto pode efetivamente ser testado?

· Manutenibilidade: A tarefa de construir, corrigir ou melhorar o produto não será mais onerosa que o planejado?

· Portabilidade: A tecnologia utilizada para a elaboração do sistema poderá ser utilizada para outros produtos?

· Localizabilidade: A tarefa de publicar o sistema para outras línguas não será uma tarefa mais onerosa que o planejado?

Na terceira abordagem os riscos mais comuns de ocorrer para qualquer sistema, ou seja, riscos genéricos:

· Complexo: seu funcionamento é complexo ou de difícil entendimento;

· Novo: não existia no produto;

· Mudado: seu funcionamento é frequentemente alterado ou “melhorado”;

· Dependente: qualquer anormalidade em seu funcionamento causará falha em cascata no resto do sistema;

· Crítica: qualquer anormalidade em seu funcionamento poderia causar danos substanciais;

· Preciso: seu funcionamento deve cumprir exigências;

· Popular: seu funcionamento é rotineiro;

· Estratégico: seu funcionamento tem importância especial para o negócio, como uma característica que o diferencia da concorrência;

· Terceirizado: seu funcionamento e criação foram desenvolvidos por outra equipe diferente da equipe do projeto;

· Distribuídos: seu funcionamento depende e está relacionado a diversos componentes;

· Pegajoso/Infectado: seu funcionamento é conhecido através do histórico problemático;

· Falha recente: seu funcionamento tem histórico recente de fracasso.

Para auxiliar na criação da lista de riscos genéricos são usadas as perguntas: Esse problema pode ocorrer no meu produto? Qual a possibilidade de isto acontecer? O que aconteceria?

O questionário baseado em taxonomia de riscos (Taxonomy Based Questionnaire – TBQ ...