Melhorando a Qualidade do Software e Otimizando Recursos com Teste baseado em Riscos

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Este artigo apresenta uma visão geral da abordagem de teste baseado em riscos e técnicas disponíveis para o planejamento, projeto e execução de testes de software.

Esse artigo faz parte da revista Engenharia de Software 10 edição especial. Clique aqui para ler todos os artigos desta edição

 

Validação, Verificação e Teste

Melhorando a Qualidade do Software e Otimizando Recursos com Teste baseado em Riscos

 

De que se trata o artigo:

Apresentação de uma visão geral da abordagem de teste baseado em riscos e técnicas disponíveis para o planejamento, projeto e execução de testes de software.

Para que serve:

Fornecer uma motivação para o uso da abordagem de teste baseado em riscos, destacando seus benefícios, limitações e aplicações.

Em que situação o tema é útil:

O processo de teste de software exerce um importante papel dentro da garantia de qualidade de software assegurando que os requisitos satisfazem as necessidades das partes envolvidas. Este processo, entretanto, requer bastante esforço, dentro de restrições de custo e prazo. A abordagem de teste baseado em riscos permite identificar funcionalidades com grande probabilidade de apresentar falhas, de forma a alocar melhor os recursos disponíveis, diminuindo o tempo e custo necessários para se testar. Este artigo apresenta a abordagem de teste baseado em riscos, suas aplicações, limitações, bem como as técnicas disponíveis para o planejamento, projeto e execução de testes funcionais e estruturais.

 

As empresas, de forma geral, têm despertado para a importância da atividade de teste de software como forma de melhorar a qualidade dos seus produtos e manterem-se competitivas no mercado. Além disso, a complexidade das tecnologias utilizadas e dos softwares produzidos tem crescido, tornando-se necessária a utilização de processos, técnicas e ferramentas que permitam a realização de teste de software de maneira sistematizada, com o objetivo de aumentar a qualidade do software com o menor custo possível.

Da mesma forma, a gerência de riscos tem sido fortemente debatida, estudada e utilizada em ambientes de desenvolvimento de software com o propósito de administrar oportunidades, aumentando a probabilidade de entregar o software com o menor custo, no menor tempo possível e com maior qualidade.

A atividade de teste de software, no entanto, é complexa e demanda tempo considerável para ser realizada, chegando a custar até metade do valor inicial de desenvolvimento de um software. 

O teste baseado em riscos (RBT – Risk-based Testing), por sua vez, permite priorizar esforços e alocar recursos para os componentes de software que necessitam ser testados mais cuidadosamente a partir da identificação, análise e controle dos riscos técnicos associados aos requisitos do software.

O consultor James Bach é considerado o pai da abordagem de Teste baseado em Riscos. Ele descreveu a idéia em seu artigo intitulado: The Challenge of Good Enough Software, em outubro de 1995, na revista American Programmer. Somente em 1999, [Bach 1999] apresenta uma técnica baseada em heurísticas para RBT e desde então, diversas técnicas têm sido propostas e utilizadas para testar produtos de software com diferentes domínios, em empresas como IBM® [Chen 2002] e outras. Estas técnicas são apresentadas neste artigo, destacando seus pontos fortes, aplicações e limitações.

Por que Realizar Teste baseado em Riscos?

É bastante freqüente organizações depararem-se com restrições de tempo e recursos para o desenvolvimento de software, em especial, para realização de teste de software. A abordagem RBT permite justamente fazer melhor uso dos recursos disponíveis, priorizando os requisitos do software que necessitam ser testados prioritariamente. Assim, a quantidade de teste planejada e realizada para o software será na proporção do risco envolvido. Quanto maior o risco, mais teste é necessário. Da mesma forma que requisitos ou funcionalidades com baixa exposição ao risco não necessitam ser testados exaustivamente.

Além disso, de acordo com estudos realizados, os defeitos com maior severidade podem ser descobertos mais cedo, tendo em vista que os requisitos mais problemáticos serão testados prioritariamente, e conseqüentemente serem corrigidos mais cedo.

RBT também é uma valiosa ferramenta para o gerente de teste que pode planejar as atividades e alocar/solicitar recursos considerando, não somente a informação das funcionalidades do software que estão em desenvolvimento ou manutenção, mas também quais riscos estão associados a cada funcionalidade e quais funcionalidades são mais críticas com relação ao teste de software.

Por fim, como conseqüência de uma atividade de teste bem planejada, a qualidade do software é melhorada. 

Teste de Software não é baseado em Riscos?

É consenso que a realização de qualquer atividade de teste diminui o risco de um software apresentar falhas em produção. Teste é primariamente uma forma de controlar os riscos associados aos requisitos ou funcionalidades de um software. A partir dessas definições podem surgir as seguintes perguntas: Porque então o termo Teste baseado em Riscos? Esse termo não parece redundante? De certa forma, o termo é sim redundante, entretanto ele é utilizado para destacar um conjunto de atividades da gerência de riscos que pode ser utilizado para estabelecer melhorias nos processos de teste de software, tais como:

  1. Identificar riscos associados aos requisitos ou funcionalidades do software.
  2. Analisar e Priorizar os riscos identificados, através dos valores de probabilidade de ocorrência e impacto. Como os riscos estão associados aos requisitos, estes últimos são priorizados indiretamente.
  3. Projetar casos de teste com base nas estratégias para tratamento dos riscos identificados. Um ou mais casos de teste podem ser projetados para mitigar um risco.
  4. Controlar os riscos priorizados através da execução dos casos de teste. Quando executamos um caso de teste baseado em riscos e este falha, o software necessita ser corrigido para que o risco seja mitigado.

 

Os processos de teste disponíveis na literatura tratam os riscos associados aos requisitos de software de forma ad hoc [Bach 1999]. Casos de teste são planejados, projetados, executados e controlados com o propósito de diminuir riscos. Mas que riscos são estes que estão sendo tratados? São os riscos mais importantes? As funcionalidades que apresentam maior risco foram testadas adequadamente? Essas e outras perguntas podem ser respondidas com a adoção de processo ou técnicas de teste baseado em riscos.

Quais Riscos são Tratados pela Abordagem RBT?

O Instituto de Engenharia de Software (SEI) [Carr et al. 1993] define risco como a possibilidade de sofrer perdas nos objetivos do projeto, tais como: impactar na qualidade do produto final, atrasar cronograma, aumentar custos ou mesmo falhar o projeto.

Os riscos de software podem ser classificados de diversas formas. Neste artigo, é apresentada a classificação definida pelo SEI, que fornece uma taxonomia para os riscos de acordo com a sua origem (Figura 1):

  1. Engenharia de Produto: problemas no produto que estão relacionados às ações técnicas; também conhecidos como riscos técnicos.
  2. Ambiente de Desenvolvimento: problemas no processo (desenvolvimento) produtivo do software.
  3. Restrições dos Programas: problemas que acontecem no projeto e no processo devido a ações da gerência.

 

A Figura 1 apresenta um subconjunto da classificação de riscos de software definida pelo SEI [Carr et al 1993]. Os riscos relacionados à engenharia de produto são os que podem ser tratados pelo teste de software, mais especificamente os que estão relacionados aos requisitos do software, como estabilidade, completude, claridade, viabilidade, validade, precedente, escala e outros. O risco está associado à possibilidade de uma funcionalidade do software funcionar de forma inadequada, ou até mesmo não funcionar.

 

Figura 1. Classificação dos riscos de software.

 

Para exemplificar, suponha que a funcionalidade Cadastrar Usuário foi definida, documentada e será implementada. Ao revisar a funcionalidade, a equipe de testes identificou que um dos fluxos não está muito claro, é muito complexo ou gerou margem para diversas interpretações. Prontamente, o analista de teste projeta um caso de teste para verificar se esse fluxo foi implementado da forma correta pelos desenvolvedores e mitigar o risco identificado.

Após a identificação dos riscos, estes necessitam ser priorizados de acordo com a sua probabilidade de ocorrência e impacto. Alguns estudos [Amland 1999] indicam que funcionalidades extensas, complexas, desenvolvidas sob pressão, com pouco tempo e por desenvolvedores inexperientes ou sem conhecimento da tecnologia utilizada, possuem uma grande probabilidade de apresentar falhas.  Similarmente acontece com funcionalidades que estão em constante manutenção ou que têm apresentado muitas falhas. Esses indícios nos ajudam a identificar a probabilidade de ocorrência de falhas.

Com relação ao impacto, uma forma bastante simples de priorizar os riscos é verificando o impacto de ocorrência de uma falha em uma funcionalidade para o cliente. Se a atividade fim de um cliente é vender livros e existe um risco associado à funcionalidade de venda, o seu impacto é bastante alto, uma vez que o cliente poderá ter sérios prejuízos caso as vendas não possam ser realizadas.

Técnicas e Processo de Teste baseado em Riscos

Nesta seção, são apresentadas algumas das técnicas e processos disponíveis para a abordagem de teste baseado em riscos, que é utilizada, mais fortemente, no planejamento e na estratégia de execução dos casos de testes [Bach 1999]. Seu uso, entretanto é recomendado também já na de fase construção ou projeto dos casos de teste, como forma de otimizar o processo de teste de software, projetando casos de teste apenas para os requisitos prioritários.

A Figura 2 apresenta o modelo de atividades do processo de gerência de riscos, alterado por [Amland 1999] para incluir elementos relevantes ao teste baseado em risco. As caixas ovais representam as alterações realizadas por Amland e são artefatos produzidos ou atividades do teste de software realizadas com o apoio de atividades (retângulos) do processo de gerência de riscos.

 

Figura 2. Atividades relevantes para o teste baseado em riscos [Amland 1999].

 

Para cada atividade do ciclo de vida do processo de teste de software, há uma correspondente na gerência de riscos, com o intuito de fornecer o tratamento e acompanhamento adequado para os riscos técnicos identificados.

A atividade de identificação de riscos produz como resultado um lista de riscos associados aos requisitos a serem testados. A partir da avaliação qualitativa e/ou quantitativa, os riscos são priorizados. Também, estratégias para mitigação dos riscos são elaboradas de acordo com sua prioridade e estas informações servem como base para criação do plano de testes. 

Quando os testes ou inspeções são realizados, os riscos são mitigados, ou pelo menos, são minimizados para que o impacto dos fatores de riscos seja menor. A comunicação dos riscos fornece os dados para definição e acompanhamento dos riscos através de um conjunto de métricas.

 

Técnica Baseada em Heurística

[Bach 1999] define uma técnica baseada em heurística utilizando duas abordagens distintas para a atividade de identificação dos riscos: na abordagem “Inside-Out”, o software é estudado e é questionado repetidamente, o que pode dar errado neste produto; na abordagem “Outside-In”, uma lista de potenciais riscos é utilizada, juntamente com detalhes do software. Para cada risco, é identificado se este se aplica ou não a uma determinada funcionalidade.

Nessa técnica, três tipos de listas são utilizadas para auxiliar a identificação dos riscos:

  1. Lista de categorias de critérios de qualidade: são categorias desenvolvidas para atenderem a diferentes tipos de requisitos. Um exemplo deste tipo de lista é apresentado na Tabela 1, que foi desenvolvida a partir dos critérios do padrão ISO 9126 e HP FURPS (Functionality, Usability, Reliability, Performance, Supportability).

 

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?