Melhorando a Qualidade do Software

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.

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.

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).

Capacidade	O requisito realiza a função requerida?
Confiabilidade	A funcionalidade resiste a falhas em todas as situações?
Usabilidade	Quão fácil é a utilização da funcionalidade pelo usuário?
Instalabilidade	Quão fácil é a instalação do software?
Manutenibilidade	Quão econômicas são as manutenções corretivas e evolutivas?
Portabilidade	Quão econômica é a portabilidade para outra plataforma?

Tabela 1. Lista de categorias de critérios de qualidade [Bach 1999].
2. Listas genéricas de riscos: são aquelas que possuem riscos universais a qualquer sistema. Um exemplo é mostrado na Tabela 2.

Complexo	Qualquer coisa desproporcionalmente grande.
Novo	Qualquer coisa que não possua histórico no produto.
Modificado	Qualquer coisa que tenha sido modificada ou melhorada.
Crítico	Qualquer coisa cuja falha poderia causar um dano substancial.
Preciso	Qualquer coisa que deva atender a requisitos exatos.
Popular	Que será muito usado.
Terceirizado	Qualquer coisa usada no seu produto, mas que foi desenvolvida fora do projeto.
Distribuído	Qualquer coisa que esteja espalhada em relação a tempo ou espaço, e que seus elementos devam trabalhar juntos.
Falhou recentemente	Qualquer coisa com uma história recente de falha.

Tabela 2. Lista genérica de riscos [Bach 1999].
3. Os catálogos de risco: São listas de riscos que pertencem a um domínio em particular. A Tabela 3 apresenta uma versão resumida do que seria um catálogo de riscos para o instalador de um software.

Instalação dos arquivos errados.

Arquivos corrompidos.

Hardware não foi configurado de forma apropriada.

Outras aplicações corrompidas.

O protetor de tela interfere no instalador.

Não há detecção de aplicações incompatíveis.

O instalador silenciosamente substitui ou modifica arquivos críticos ou parâmetros.

O processo de instalação é muito lento.

O processo requer o constante monitoramento do usuário.

O processo de instalação é confuso.

Tabela 3. Catálogo de riscos para um instalador [Bach 1999].

Após a identificação dos riscos usando umas das abordagens explicadas anteriormente, valores são atribuídos a cada um dos riscos em uma escala de interesse. Os requisitos associados aos riscos com maior valor são testados primeiramente.

A principal dificuldade dessa abordagem está no conhecimento prévio do negócio a fim de realizar a análise dos riscos da maneira mais fiel possível. Existe a possibilidade da análise ter sido realizada de forma errada e, conseqüentemente, os “verdadeiros” riscos não terem sido atacados da forma correta.

Técnica Baseada em Métricas

Esta técnica foi desenvolvida por [Amland 1999] e consiste em um conjunto de métricas para a análise de riscos com o objetivo de subsidiar um processo de teste. Essas métricas foram aplicadas em estudo de caso de uma aplicação de instituição financeira. Existem três fontes de análise de riscos representadas pela Equação 1,

1. Qualidade da função (área) a ser testada: projetos de má qualidade, programador inexperiente, funcionalidade complexa, e outras variáveis resultam em funções com maior exposição a falhas. Essa função corresponde à probabilidade P(f).
2. As conseqüências de uma falha em uma função do ponto de vista de um cliente em uma situação de produção podem ser representadas pela probabilidade de ameaça legal, perda de posicionamento no mercado e pelo não cumprimento de regulamentações governamentais por causa de falhas, entre outras. Estas conseqüências representam o custo para o consumidor C(c).
3. As conseqüências de uma falha em uma função do ponto de vista do vendedor do serviço estão relacionadas à probabilidade de publicidade negativa, altos custos de manutenção de software, e outros, devido a uma função com falhas. Estas conseqüências representam o custo para o vendedor C(v).

Tendo em vista o grau de exposição ao risco Re(f), as áreas com risco mais alto têm a maior prioridade nos testes. Durante os testes, à medida que falhas vão ocorrendo, os graus de exposição ao risco vão sendo atualizados e a prioridade das funcionalidades pode ser modificada.

Um exemplo do grau de exposição ao risco para a função Fechar Contas é mostrado na Tabela 4. O Custo é calculado através da média aritmética de C(v) e C(c). Os números entre parênteses são os pesos definidos para cada métrica. A probabilidade é calculada como a média ponderada das métricas, dividida pela maior média ponderada de todas as métricas, resultando em uma probabilidade na faixa de [0,1].

A técnica definida por Amland foi utilizada para testar dois módulos de uma aplicação financeira contendo, respectivamente, doze e trezentas funcionalidades. Sendo que, para o segundo, por falta de tempo, foram avaliadas as vinte funcionalidades mais importantes definidas pelo cliente. Um dos maiores problemas relatados por Amland foi a falta de conhecimento de algumas funcionalidades, que dificultou a análise e produziu resultados não confiáveis.

Um nível mínimo de teste foi definido para as funcionalidades com baixa exposição ao risco e testes extras foram definidos para funcionalidades com maior exposição ao risco. O cliente avaliou o produto entregue como de excelente qualidade. O número de defeitos encontrados foi similar ao das versões anteriores. No entanto, o tempo gasto para concluir os testes foi menor e o número de recursos utilizados também foi menor.

O grande desafio para definição da técnica, segundo Amland, foi a identificação dos indicadores de custo de falha e de qualidade. Foi utilizada uma abordagem simples, mas satisfatória de acordo com os estudos apresentados. Assim, como na maioria das técnicas, é mantido foco somente na análise dos riscos.

Técnica para Código-fonte Orientado a Objetos

A idéia desta técnica é que, através da aplicação de métricas de complexidade de software orientado a objetos, pode-se chegar a classes que possuem maior probabilidade de apresentar falhas. Seis métricas de medição de projetos orientadas a objeto são utilizadas, identificadas e aplicadas pelo SATC (Software Assurance Technology Center) da NASA (Goddard Space Flight Center). Segundo os autores, foi comprovado [Rosenberg et al 1999] que o código mais complexo tem uma maior incidência de erros ou problemas. As métricas são:

1. Número de métodos (Number of Methods – NOM): é a contagem dos diferentes métodos existentes em uma classe.
2. Número ponderado de métodos por classe (The Weighted Methods per Class –WMC): é a soma ponderada dos métodos em uma classe.
3. Acoplamento entre objetos (Coupling Between Objects – CBO): é a contagem do número de outras classes nas quais uma classe está acoplada.
4. A resposta a uma classe (The Response for a Class – RFC): é a cardinalidade do conjunto de todos os métodos que podem ser invocados em resposta a uma mensagem para um objeto da classe.
5. Profundidade na árvore (The Response for a Class – RFC): é a cardinalidade do conjunto de todos os métodos que podem ser invocados em resposta a uma mensagem para um objeto da classe.
6. Número de filhos (Number of Children – NOC): é o número de subclasses que herdam diretamente da classe na hierarquia.

Por mais de três anos, o SATC tem coletado e analisado código orientado a objetos escritos tanto em C++ quanto em Java. Mais de 20.000 classes de mais de 15 programas foram analisadas. Os seguintes valores limites para as métricas individuais, apresentados na Tabela 5, foram derivados do estudo da distribuição das métricas coletadas.

Uma métrica nunca dever ser utilizada sozinha para avaliar os riscos do código. São necessárias, pelo menos, duas ou três métricas para dar uma indicação de problema em potencial. Portanto, para cada projeto, o SATC cria uma tabela de classes que possuem alto risco. Classes que têm ao menos duas métricas que excedem os limites recomendados possuem alto risco.

A Tabela 6 mostra um exemplo de métricas para classes de um projeto Java. As células em vermelho representam métricas fora do limite aceitável.

A análise das classes é fácil de ser aplicada, inclusive pode ser realizada de forma automática. No entanto, os autores não propõem estratégias de testes para o código, tampouco formas de rastreamento das funcionalidades impactadas por classes com alto risco de falhas.

Técnica para Teste de Regressão baseado em Riscos

Essa técnica define uma estratégia para execução de testes de regressão baseada em especificação [Chen 2002]. A justificativa principal é que teste de regressão baseado em código é bom para teste de unidade, mas tem problemas de escalabilidade. À medida que o tamanho do sistema cresce, torna-se difícil gerenciar a informações dos testes e criar matrizes de rastreabilidade. Nesta técnica, dois conjuntos de testes de regressão são definidos:

1. Testes de regressão para os componentes que foram alterados: pelo menos um teste é executado para cada componente inserido ou alterado.
2. Testes de regressão baseados em riscos para os componentes que “aparentemente” não sofreram modificações: para estes, uma análise de riscos é realizada a partir de questionários submetidos aos participantes do projeto.

Essa técnica utiliza as métricas de análise de risco desenvolvidas por Amland e apresentadas anteriormente.

A fase de seleção de casos de teste envolve os seguintes passos:

1. Estimar o custo de cada caso de teste. Ou seja, o custo que uma falha possa causar. O custo é calculado da mesma forma proposta por [Amland 1999];
2. Derivar a severidade para cada caso de teste. Esse valor é computado a partir do número de defeitos e da severidade destes defeitos;
3. Calcular o grau de exposição de risco para cada caso de teste. A exposição ao risco é calculada a partir do custo e da severidade, e;
4. Selecionar os casos de teste que têm os maiores valores de exposição ao risco.

A seleção de cenários baseados em riscos deve obedecer duas regras:

1. Selecionar os cenários para cobrir os casos de teste mais críticos, e;
2. Garantir que os cenários cubram tantos casos de teste quanto possível.

1. Calcular a exposição de riscos para cada cenário. Calculado a partir da soma da exposição ao risco dos casos de testes associado a este cenário;
2. Selecionar os cenários com maior exposição ao risco;
3. Atualizar a matriz de rastreabilidade, removendo os cenários selecionados e os testes já cobertos e recalculando a exposição ao risco, e;
4. Repetir os passos 1, 2 e 3, o quanto necessário.

Esta técnica se mostrou bastante eficiente de acordo com os resultados apresentados. Além disso, a análise realizada através de questionários submetidos aos desenvolvedores, com questões que os mesmos dominam, não constituiu uma tarefa complexa. Com a ajuda de ferramentas, todo o processo é realizado de forma rápida.

Como a abordagem toma como base a documentação do sistema, essa deve encontrar-se sempre atualizada. Riscos não são identificados nesta técnica e assume-se que os casos de testes já estão prontos. Dependendo da quantidade de casos de testes, essa técnica pode ser inviável, uma vez que a análise de riscos é feita a partir dos casos de teste.

Técnica RBT baseada em Uso

Esta técnica define uma estratégia baseada em uso, onde qualquer atividade de teste implica em uma diminuição dos riscos [Besson 2004]. De acordo com o autor, independente da quantidade de testes executados, sempre haverá um risco. A idéia é investir o mínimo de esforço em teste possível para maximizar a redução dos riscos.

Os esforços de teste são controlados tomando como base a utilização do sistema, seguindo a teoria de Pareto, que afirma que vinte por cento das funcionalidades permitem ao usuário realizar oitenta por cento do seu trabalho.

A Figura 3 apresenta o esforço necessário para eliminar todos os riscos identificados (reta em vermelho). Seguindo a idéia de Pareto, a relação entre risco e esforço ficaria mais parecida com o gráfico representado pela linha em azul. Logo, diminuir o risco em cinqüenta por cento pode ser alcançado em um curto espaço de tempo se uma priorização dos testes é feita a partir de uma análise dos riscos.

A técnica é dividida em cinco passos:

1. Identificar funcionalidades vitais que podem previnir o usuário de utilizar o sistema se um defeito for encontrado, ou seja, um defeito com alta severidade. Uma forma eficiente de listar essas funcionalidades é a partir de pesquisas com os usuários finais do sistema, especialistas no domínio do sistema ou através de dados estátisticos de uso de versões anteriores. Uma vez que o risco aumenta com a frequencia de uso, as funcionalidades mais usadas terão maior risco.
2. Projetar casos de teste para cada funcionalidade listada no Passo 1.
3. Estimar tamanho (em horas ou minutos) do esforço necessário para executar os casos de teste identificados.
4. Ordenar os casos de teste em ordem ascendente, de acordo com o esforço. Dessa forma, os casos de teste com menor esforço são executados primeiro.
5. Iniciar a execução dos casos de teste na ordem estabelecida no Passo 4 até que o tempo termine.

A análise dos riscos é, de certa forma, fácil de ser realizada, uma vez que o usuário especifica as funções que são mais utilizadas no sistema, ou seja, as funções que permitem ao usuário realizar oitenta por cento das suas atividades.

Como a execução dos testes é baseada em esforço, os testes que gastam menos tempo são executados primeiro até que o tempo acabe. Essa técnica pode ser útil em culturas organizacionais avessas ao teste.

No entanto, esta técnica não garante que as funcionalidades que estão sendo atacadas sejam as mais propensas a apresentar falhas.

Modelo de Processo de Teste de Software baseado em Riscos

O RBTProcess é um modelo de processo de teste de software baseado em riscos proposto por [Souza e Gusmão 2008], construído a partir de atividades presentes no gerenciamento de riscos e nos processos de teste de software disponíveis na literatura. O RBTProcess possui quatro fases distintas juntamente com seus marcos e atividades, como mostrado na Figura 4.

1. Planejamento: esta fase tem como foco o planejamento inicial dos testes com base na análise dos riscos. O marco desta fase é a priorização dos requisitos através da identificação e análise dos riscos.
2. Projeto: nesta fase, os casos de teste planejados são projetados com base na análise dos riscos. O marco desta fase é a criação de casos de teste que verificam a existência ou não dos riscos identificados.
3. Execução: os casos de teste planejados e projetados são executados. O marco desta fase é a mitigação dos riscos identificados através da execução de casos de teste que verificam a existência ou não dos riscos identificados.
4. Controle: os resultados da execução dos testes são coletados e controlados. Na disciplina Avaliar Testes, é verificado o conjunto de números, estratégias, tempo de execução e solicitações de mudança dos testes. Na disciplina Controlar Riscos, é realizado o acompanhamento dos riscos. Os riscos mitigados são eliminados da lista de riscos identificados e serve de entrada para o planejamento da próxima iteração. O marco desta fase é o controle dos riscos mitigados.

A seguir, uma breve descrição das disciplinas que compõem o modelo de processo:

1. Identificar Riscos: nesta disciplina, os riscos são identificados através de questionário baseado em taxonomia de riscos (Taxonomy Based Questionnaire – TBQ). O objetivo do TBQ é diminuir o nível de abstração da atividade de identificação de riscos, uma vez que os engenheiros de teste têm conhecimento básico sobre identificação de riscos. A equipe do projeto responde a perguntas relacionadas aos requisitos, sem saber que estão identificando riscos. A Tabela 7 apresenta um exemplo das questões contidas no TBQ para o elemento Requisito da classe Engenharia de Produto. Neste exemplo, caso o entrevistado responda “sim”, indica a existência de riscos na funcionalidade ou requisito analisado.

   Classe: Engenharia de Produto
   Elemento: Requisito
   Atributo:	[01] Os requisitos da funcionalidade estão mudando enquanto ela está sendo desenvolvida?	Estabilidade	Se SIM, qual parte da funcionalidade está mudando?
   Atributo:	[02] Ainda existe algo para ser especificado nesta funcionalidade?	Completude	Se SIM, qual parte da funcionalidade não está especificada?

   Tabela 7. Questões de estabilidade e completude para o elemento Requisito.
   Após a identificação dos riscos através do TBQ, é realizada uma reunião brainstorm com toda a equipe de desenvolvimento a fim de validar os riscos levantados na atividade anterior. São utilizadas as listas de riscos propostas por [Bach 1999] para guiar a reunião. O artefato de saída dessa disciplina é uma lista de riscos identificados para cada requisito.
2. Analisar Riscos: tem como objetivo a priorização dos requisitos a serem testados com base na análise dos riscos técnicos identificados. A fórmula utilizada para priorização dos riscos foi proposta por [Amland 1999] com algumas adaptações. Para a probabilidade P(f), é calculada a média dos valores atribuídos às métricas Nova Funcionalidade, Projeto/Qualidade, Tamanho, Complexidade e Dependência. Sendo que a última foi proposta neste processo e corresponde ao nível de dependência com as demais funcionalidades do software. Os participantes desta atividade são os mesmos que realizaram a identificação dos riscos. Um guia é fornecido para atribuição dos indicadores das métricas de acordo com a atividade realizada pelo participante. Para a métrica de qualidade, por exemplo, são sugeridos os valores apresentados na Tabela 8. Se a pessoa que está respondendo o questionário é um desenvolvedor e não tem conhecimento da linguagem e ambiente de desenvolvimento, ela deve informar o valor “uma” para a métrica de Projeto/Qualidade.

   Indicador	Desenvolvedor	Testador	Analista de requisitos
   1	Não tem conhecimento das tecnologias/ferramentas utilizadas no desenvolvimento do software	Funcionalidade não apresentou defeitos nas últimas versões	Requisito está estável
   2	Tem conhecimento razoável das tecnologias/ferramentas utilizadas no desenvolvimento do software	Funcionalidade apresentou alguns defeitos nas últimas versões	Requisito ou funcionalidade tem sofrido poucas alterações
   3	Domina a tecnologias/ferramentas utilizadas no desenvolvimento do software	Funcionalidade apresentou muitos defeitos nas últimas versões	Requisito ou funcionalidade tem sofrido muitas alterações

   Tabela 8. Exemplo de indicadores para a métrica de Projeto/Qualidade.
3. Planejar Testes: tem como objetivo direcionar e controlar as atividades de teste com base na avaliação de riscos. Consiste na definição dos requisitos que serão testados ou não, tomando, como base, a análise dos riscos. A priorização dos requisitos é realizada a partir dos valores de exposição ao risco. O RBTProcess sugere que, a cada iteração, sejam testados, por exemplo, um conjunto de requisitos de acordo com a sua prioridade. Os requisitos classificados como de baixa prioridade somente são testados se houver tempo disponível. Diversas estratégias podem ser utilizadas com base na análise dos riscos. Uma delas é, por exemplo, a automação dos testes para os requisitos classificados como de alta prioridade.
4. Projetar Testes: tem como objetivo identificar e descrever os casos de teste para os requisitos a serem testados com base na análise de riscos. Consiste na identificação dos cenários, além da definição da abordagem e tipo de testes que serão utilizados. O processo sugere diferentes coberturas para os requisitos de acordo com sua importância: i. requisitos com baixa exposição ao riscos: testar somente os cenários relacionados aos riscos caso haja tempo disponível; ii. requisitos com média exposição ao riscos: testar os cenários relacionados aos riscos, fluxo principal e fluxos alterados/incluídos e iii. requisitos com alta exposição ao riscos: testar os cenários relacionados aos riscos e todos os fluxos do requisito (principal, exceção e alternativo). Para cada risco identificado, testes são criados com o propósito de mitigar os fatores de riscos. O estilo de criação dos casos de testes para execução recomendado pelo processo é independente, de forma que os casos de testes possam ser executados em qualquer ordem.
5. Executar Testes: esta é a atividade em que, de fato, os riscos são mitigados através da execução de casos de teste baseado em riscos. Tem como objetivo executar testes e verificar a corretude do software, avaliando os resultados e registrando os problemas encontrados. O testador é responsável por esta atividade e executa os testes na ordem de priorização definida pela análise dos riscos.
6. Avaliar Testes: tem como objetivo medir quantitativamente e qualitativamente o progresso dos testes e gerar um relatório de avaliação. O projetista de testes avalia o resultado da execução dos casos de teste sem se preocupar com os riscos que foram mitigados. Esta atividade não sofre alterações para a abordagem de teste baseado em riscos, uma vez que todo o controle a acompanhamento dos riscos está definido na disciplina Controlar Riscos, sob a responsabilidade do analista de riscos.
7. Controlar Riscos: essa disciplina é responsável pelo acompanhamento dos riscos identificados. O analista de riscos é responsável pela identificação e documentação do percentual de riscos mitigados por funcionalidade. Além da criação do relatório de avaliação dos riscos, o analista de riscos é responsável pela atualização do documento de identificação e análise dos riscos, principal entrada para a atividade de planejamento dos testes.

Em um primeiro momento, o RBTProcess aparece como um processo pesado mas, de acordo com os estudos realizados, as atividades da gerência de riscos de software incluídas no processo não exigem muitos esforços. Os resultados obtidos no estudo de caso forneceram uma forte indicação de que a abordagem RBT permite: concentrar os esforços de teste nos requisitos de software que possuem maior probabilidade de apresentar falhas e mostrar que os defeitos, com maior severidade, podem ser descobertos mais cedo, tendo em vista que os requisitos mais problemáticos são testados prioritariamente

Análise Comparativa

Com exceção da técnica para código-fonte orientado a objetos, todas as outras utilizam a abordagem funcional ou caixa-preta para construção dos casos de testes no nível de sistema. Apenas a técnica baseada em heurística e o RBTProcess propõem diferentes formas de identificação de riscos.

A técnica baseada em métricas objetiva redução do custo da fase de teste do projeto e a redução de futuros custo de manutenção do software em potencial através da otimização do processo de teste. As métricas propostas levam em consideração que funcionalidades complexas, novas, construídas com pouca qualidade e grandes (tamanho) possuem mais probabilidade de apresentar falhas. A técnica não fornece nenhuma orientação sobre a criação dos casos de teste.

A técnica baseada em riscos para teste de regressão objetiva reduzir a quantidade de casos de teste a serem executados, além de possibilitar que as áreas mais críticas sejam testadas prioritariamente. Nesta técnica, assume-se que os casos de teste já estão prontos.

A técnica baseada em uso utiliza a informação de percentual de uso da funcionalidade para priorização. Isto a torna fácil de ser utilizada. No entanto, não garante que as funcionalidades que estão sendo atacadas sejam as mais propensas a apresentarem falhas e precisem ser mais bem testadas.

A finalidade do RBTProcess é fornecer conhecimento e recursos necessários para que os engenheiros de teste possam utilizar a abordagem RBT em todas as atividades do teste de software, através da definição de disciplinas e papéis, e fornecimento de artefatos, guias, templates e métricas.

A Tabela 9 apresenta uma análise comparativa das principais técnicas e processo apresentados neste artigo. Para a comparação, foram elencadas atividades mínimas de gerência de riscos e teste de software.

Considerações Finais

Apesar da abordagem RBT se mostrar simples, engenheiros de teste ainda encontram dificuldades em aplicá-la na prática [Goldsmith 2006], principalmente, porque a análise de riscos é algo complexo e necessita de conhecimento para sua aplicação. Não existem ainda ferramentas comerciais específicas para RBT o que, provavelmente, dificulta sua aplicação e disseminação.

É consenso entre os autores das técnicas apresentadas neste artigo, que a abordagem RBT permite reduzir esforços de teste e identificar funcionalidades críticas, entretanto, nenhum autor informa o percentual de esforço reduzido e a confiabilidade alcançada com a adoção da abordagem.

A constante busca pelo desenvolvimento de software com melhor qualidade e com baixo custo tem motivado inúmeras pesquisas na área engenharia de software, em especial na área de teste baseado em riscos.

Ferramentas estão em desenvolvimento [Souza e Gusmão 2008] visando auxiliar na utilização e disseminação da abordagem RBT que tem muito a contribuir na qualidade de software.

Referências

• [Amland 1999] Amland, S. (1999) “Risk Based Testing and Metrics: Risk analysis fundamentals and metrics for software testing including a financial application case study”, 5o International Conference EuroSTAR'99. [Bach 1999] Bach, J. (2009) “James Bach on Risk-Based Testing: How to conduct heuristic risk analysis@, Software Testing & Quality Engineering Magazine, p.23-28.
• [Besson 2004] Besson, S. (2004) “A Strategy for Risk-Based Testing”, disponível em <StickyMinds.com>.
• [Carr et al 1993] Carr, M. J.; Konda, S.L.; Monarch, I.; Ulrich, F. C.; Walker, C. (1993) “Taxonomy Based Risk Identification”, Technical Report CMU/SEI-93-TR-6. Software Engineering Institute, Carnegie Mellon University/USA.
• [Chen 2002] Chen, Y. (2002) “Specification-based Regression Testing Measurement with Risk Analysis”, dissertação de Mestrado, University of Ottawa/Canada.
• [Goldsmith 2006] Goldsmith, R. (2006) “Early and Effective: The Perks of Risk-based Testing”, Software Test and Performance Magazine, v.3, p.24-30.
• [Rosenberg et al 1999] Rosenberg, L. H.; Stapko, R.; Gallo, A. (1999) “Risk-based Object Oriented Testing” 24o Annual Software Engineering Workshop, NASA SEW24.
• [Souza e Gusmão 2008] Souza, E.; Gusmão C. (2008) “RBTProcess - Modelo de Processo de Teste de Software baseado em Riscos”, 13º WTES - Workshop de Teses e Dissertações em Engenharia de Software, SBES'08.
• Cristine Gusmão cristine@dsc.upe.br Professora Assistente do Departamento de Sistemas e Computação da Escola Politécnica da Universidade de Pernambuco (POLI – UPE), onde leciona várias disciplinas na graduação e pós-graduação (especialização e mestrado) e das Faculdades Integradas Barros Melo. Doutora e Mestre em Ciência da Computação pela Universidade Federal de Pernambuco. Graduada em Engenharia Elétrica – Eletrotécnica pela Universidade Federal de Pernambuco.