13º Workshop de Teses e Dissertações em Engenharia de Software
RBTProcess - Modelo de Processo de Teste de Software
baseado em Riscos
Aluna
Ellen Polliana Ramos Souza
Orientadora
Profª Dra. Cristine Martins Gomes de Gusmão
Mestrado Acadêmico em Engenharia da Computação
Departamento de Sistemas e Computação – Universidade de Pernambuco (UPE)
Rua Benfica, 455 Madalena, 50750-410, Recife, PE – Brasil
{eprs,cristine}@dsc.upe.br
Nível: Mestrado
Ano de Ingresso: Julho de 2006
Previsão de Conclusão: Dezembro de 2008
Aprovação da Proposta: Outubro de 2007
Resumo. A busca pela qualidade de software é um fator crítico que tem
crescido com a complexidade das tecnologias e a competitividade entre as
empresas. O processo de teste exerce um importante papel dentro da garantia
de qualidade de software assegurando que os requisitos satisfazem as
necessidades das partes envolvidas. No entanto, o processo de teste requer
bastante esforço, pois é grande o domínio de entradas e saídas de um
software, bem como são muitas as possibilidades de caminhos possíveis a
serem testados dentro de restrições de custo e prazo. Teste baseado em riscos
(risk-based testing) consiste num conjunto de atividades que favorece a
identificação de fatores de riscos associados aos requisitos do software. Uma
vez identificados, os riscos são priorizados de acordo com a sua
probabilidade de ocorrência e impacto. Os casos de testes, por sua vez, são
projetados com base nas estratégias para tratamento dos fatores de riscos
identificados. O controle da execução dos casos de testes permite uma
mitigação dos fatores de riscos associados. Dessa forma, o uso da abordagem
permite priorizar esforços e alocar recursos para os componentes de software
que necessitam ser testados cuidadosamente. Este trabalho tem como objetivo
a construção de um modelo de processo de teste de software baseado em
riscos com artefatos, guias, métricas e atividades, apoiado por ferramenta e
avaliado através de estudos de casos.
Palavras-chave. Teste de Software, Teste baseado em Riscos, Modelo de
Processo, Riscos Técnicos.
7
13º Workshop de Teses e Dissertações em Engenharia de Software
1. Caracterização do Problema
A atividade de teste de software tem se mostrado fundamental no desenvolvimento de
software evitando, principalmente, que falhas cheguem aos clientes, deixando-os
insatisfeitos e causando prejuízos. No entanto, esta atividade é difícil e custosa de ser
realizada, uma vez que, o domínio de entradas e saídas de um software é diverso, bem
como são muitas as possibilidades de caminhos possíveis a serem testados. Além disso,
segundo Kaner e demais autores (1999), a atividade de teste é bastante cara, chegando a
custar até 45% do valor inicial de um produto em desenvolvimento.
Com relação aos riscos de software é bastante comum projetos enfrentarem
diversos problemas afetados por riscos inesperados, não planejados ou simplesmente
ignorados. Desta forma, à medida que o tamanho e a complexidade dos sistemas
crescem, aumenta a necessidade da utilização de metodologias para gerenciamento de
riscos.
A técnica de teste baseada em análise de riscos Risk-based Testing (RBT) surgiu
como uma abordagem para minimizar alguns dos problemas relacionados ao esforço da
atividade de teste e da gerência de riscos. O teste baseado em riscos, em resumo,
consiste em atividades para identificação, análise e mitigação de fatores de riscos
associados aos requisitos do produto de software, priorizando esforços e alocando
recursos para os componentes de software que necessitam ser testados mais
cuidadosamente. Assim, a atividade de testes é melhorada a partir da gerência dos riscos
técnicos de software que podem ser mitigados através da realização de teste de software.
Apesar da abordagem RBT se mostrar simples, a comunidade de teste de
software ainda encontra 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. Também, não foram encontrados processos com atividades, papéis e
artefatos bem definidos que possam guiar os engenheiros de testes no uso da abordagem
e ferramentas específicas o que, provavelmente, dificulta sua aplicação e disseminação.
Dentro deste contexto, este trabalho apresenta o RBTProcess – Modelo de
Processo de Teste de Software baseado em Riscos. Após esta Seção introdutória, a
Seção 2 apresenta a fundamentação teórica da abordagem RBT. Na Seção 3 é descrito o
modelo de processo proposto, protótipo, simulações e estudos de caso. A Seção 4
apresenta o estado atual do trabalho. Na Seção 5 é apresentada uma comparação das
principais abordagens RBT citadas na Seção 2. Finalmente, na Seção 6, são
apresentados os resultados esperados.
2. Fundamentação Teórica
Ao analisar as abordagens existentes, três atividades distintas foram identificadas: i.
Elaborar uma lista de riscos priorizada; ii. Realizar testes que exploram cada risco e iii.
Acompanhar e controlar os riscos.
A primeira atividade consiste na identificação de requisitos com alto grau de
risco associado. A segunda atividade consiste na criação e execução de testes que
verificam a existência ou não do risco identificado. As abordagens encontradas na
literatura não fornecem metodologias para a atividade de criação dos casos de teste. No
entanto, para a execução, diversas estratégias foram encontradas. Na terceira atividade,
8
13º Workshop de Teses e Dissertações em Engenharia de Software
assim que um risco for eliminado, um novo risco surge e os esforços de testes devem ser
ajustados para que foquem sempre nos riscos mais importantes.
Bach (1999) define duas abordagens baseadas em heurística para a atividade de
identificação dos riscos. Na abordagem “Inside-Out”, o produto é 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
produto. Para cada risco, é identificado se o mesmo se aplica ou não a um determinado
componente. São atribuídos valores através de uma escala de interesse e os riscos com
maior valor são testados primeiramente.
Amland (1999) desenvolveu um conjunto de métricas para a análise de riscos
com o objetivo de subsidiar um processo de teste. Três fontes de análise de riscos são
utilizadas: i. Qualidade da área a ser testada; ii. Conseqüências de uma falha em uma
função do ponto de vista de um cliente em situação de produção e iii. Conseqüências de
uma falha em uma função do ponto de vista do vendedor do serviço.
Besson (2004) define uma abordagem baseada em uso. Segundo o autor,
qualquer atividade de teste implica numa diminuição de riscos. A idéia é investir o
mínimo de esforço em teste possível para maximizar a redução dos riscos. O autor
controla o esforço de teste baseado na utilização do software, seguindo a teoria de
Pareto, que afirma que 20% das funcionalidades permitem ao usuário realizar 80% do
seu trabalho.
Chen (2002) define uma estratégia para execução de testes de regressão baseada
em especificação. A autora define teste de regressão para os componentes que foram
alterados e teste de regressão, baseado em riscos, para os componentes que
“aparentemente” não sofreram modificações.
Rosenberg e demais autores (1999) fornecem uma abordagem para identificação
de classes que estejam mais propensas a erros. Através da aplicação de métricas de
complexidade de software orientado a objetos, pode-se chegar a classes que possuam
maior probabilidade de apresentar falhas.
3. Caracterização da Contribuição
O objetivo geral desse trabalho é a criação de um Modelo de Processo de Testes de
Software baseado em Riscos. A Figura 1 esboça uma visão inicial do modelo de
processo proposto que será, também, apoiado por um protótipo.
3.1. Modelo de Processo
O RBTProcess1 é um modelo de processo baseado no RUP (2003), iterativo, orientado a
riscos, modelado no nível “M1” do Software Process Engineering Metamodel (SPEM2)
e descrito utilizando o Eclipse Process Framework (EPF3). O modelo de processo
possui quatro fases distintas: i. Planejamento: Planejamento inicial dos testes com base
na análise dos riscos. Tem como marco a priorização dos requisitos através da
1 Versão inicial do RBTProcess na web: www.dsc.upe.br/~eprs/rbt/process/
2 SPEM na web: www.omg.org/technology/documents/formal/spem.htm
3 EPF na web: www.eclipse.org/epf/
9
13º Workshop de Teses e Dissertações em Engenharia de Software
identificação e análise dos riscos; ii. Projeto: Os casos de testes planejados são
projetados com base na análise dos riscos. O marco desta fase é a criação de casos de
testes que verificam a existência ou não dos riscos identificados; iii. Execução: Os casos
de testes planejados e projetados são executados e iv. Controle: Os resultados da
execução dos testes são coletados, avaliados e os ricos são controlados.
Figura 1. Proposta do Modelo de Processo de Teste de Software baseado em Riscos
e Relacionamento dos Artefatos em cada Fase.
Os artefatos com borda pontilhada na Figura 1 são originados do processo de
teste baseado em riscos. Os artefatos com sombra fazem parte do processo de teste
padrão. Os demais são alguns dos artefatos criados durante o processo de
desenvolvimento de software.
Os papéis identificados são os mesmos de um processo de testes padrão com
exceção do “Analista de Riscos” que é um papel da gerência de riscos, essencial para
identificação, análise e controle dos riscos.
As atividades “Identificar Riscos”, “Analisar Riscos” e “Controlar Riscos” são
provenientes do gerenciamento de riscos e baseadas no Guia PMBOK (Project
Management Body of Knowledge) (2004) e no CMMI (Capability Maturity Model
Integration) – nível três (2004). As atividades “Elaborar Plano de Teste”, “Projetar
Testes”, “Executar Testes” e “Avaliar Testes” são provenientes de processo de teste
padrão e baseadas no TMM (Test Maturity Model) – nível três (2005) e nos padrões
IEEE 829 e 1012 (1998).
Para identificação dos riscos são utilizadas técnicas como listas de verificação,
reuniões de brainstorm e questionário baseado em taxonomia de riscos adaptado, pela
autora, para teste de software. Para a análise, métricas definidas por Amland (1999) e
utilizadas por Chen (2002) são adotadas com algumas adaptações. O planejamento dos
testes, definição de estratégias e escopo são realizados com base na avaliação de riscos.
Os casos de teste são projetados para mitigar os riscos identificados e também, de
acordo com o grau de exposição ao risco, casos de teste são projetados para explorar os
fluxos principais, alternativos e de exceção. Os casos de testes são executados de acordo
com o cálculo de exposição ao risco e os riscos são avaliados em cada iteração.
10
13º Workshop de Teses e Dissertações em Engenharia de Software
3.2. Protótipo
Além do processo, um protótipo está em desenvolvimento para atender às atividades da
abordagem RBT, auxiliando os engenheiros de testes, principalmente, nas atividades de
identificação, análise e controle dos riscos técnicos de software.
É importante registrar que os requisitos para a construção do protótipo estão
sendo avaliados através das simulações e que se espera realizar os estudos de casos com
o apoio do mesmo, conforme trata a seção a seguir.
3.3. Simulações e Estudos de caso
Simulações estão sendo realizadas com o objetivo de ajustar as atividades, artefatos e
papéis do processo, identificando oportunidades de melhorias.
Estudos de caso estão sendo planejados e servirão para avaliar o uso do
RBTProcess com o propósito de caracterizar o impacto da sua adoção em empresas de
desenvolvimento de software, com respeito ao número de defeitos encontrados e tempo
para realização das atividades definidas no processo.
4. Estado Atual do Trabalho
Nesse momento, a segunda versão do modelo de processo está sendo ajustada de acordo
com os problemas apontados nas primeiras simulações e um protótipo está em
desenvolvimento para fornecer suporte às atividades definidas na abordagem RBT.
Dois estudos de caso serão planejados com o intuito de avaliar o resultado geral
do processo sob o ponto de vista, principalmente, da qualidade do produto final.
Uma pesquisa4 sobre a abordagem RBT foi elaborada com o intuito de capturar,
dentre outras informações, a formação dos engenheiros de testes com relação a riscos,
quem utiliza e formas de utilização.
5. Trabalhos Relacionados (Visão Comparativa)
A Tabela 1 apresenta um resumo das atividades incluídas nas principais abordagens
encontradas na literatura e apresentadas na Seção 2. Com exceção da abordagem de
Rosenberg e demais autores (1999), todas as outras utilizam a abordagem funcional ou
caixa-preta para construção dos casos de testes no nível de sistema. Apenas o
RBTProcess fornece o artefatos, guias, métricas, papéis e fluxos para todas as
atividades.
Tabela 1. Atividades Incluídas nas Abordagens ou Processos RBT.
Abordagens / Processo
Identificar
Riscos
Analisar
Riscos
Planejar
Testes
Projetar
Testes
Executar
Testes
Avaliar
Testes
Controlar
Riscos
SIM
Baseada em Heurística [Bach 1999]
SIM
SIM
NÃO
NÃO
SIM
NÃO
Baseada em Métricas [Amland 1999]
NÃO
SIM
NÃO
NÃO
SIM
NÃO
SIM
Baseada em Uso [Besson 2004]
SIM
NÃO
SIM
NÃO
SIM
NÃO
SIM
Testes de Regressão [Chen 2002]
NÃO
SIM
SIM
SIM
SIM
NÃO
SIM
SIM
SIM
NÃO
NÃO
NÃO
NÃO
NÃO
SIM
SIM
SIM
SIM
SIM
SIM
SIM
Código Fonte Orientado a Objetos
[Rosenberg et al 1999]
Processo de Testes [RBTProcess]
4 Questionário está disponível em: https://spreadsheets.google.com/viewform?key=phStItq91u07jHMuTXTv4dQ&e
11
13º Workshop de Teses e Dissertações em Engenharia de Software
6. Avaliação dos Resultados
Testes tradicionais sempre utilizam a idéia de teste baseado em riscos, mas de uma
forma ad hoc e baseado em julgamento pessoal [Chen 2002]. De acordo com os
resultados das diversas abordagens encontradas na literatura, a técnica de teste baseado
em riscos permite reduzir tempo e esforço para verificar o software, uma vez que o
universo de testes é menor como resultado da priorização dos cenários e, como
conseqüência, minimizar custos da atividade de testes como um todo.
Com relação ao RBTProcess, apoiado pelo protótipo, espera-se confirmar, com a
realização de estudos de casos, que: i. As atividades da gerência de risco não tragam um
esforço maior para o processo de teste padrão já que as atividades de projeto e execução
de testes devem ser realizadas com menor esforço por conta da priorização dos
requisitos e casos de testes; ii. Os esforços sejam alocados para os componentes de
software que necessitam ser, de fato, testados mais cuidadosamente; iii. A qualidade do
produto final seja melhorada como conseqüência de uma atividade de testes bem
planejada.
Referências
Amland, S. (1999) “Risk Based Testing and Metrics: Risk analysis fundamentals and
metrics for software testing”. In 5th International Conference EuroSTAR’99.
Bach, J. (1999) “James Bach on Risk-Based Testing: How to conduct heuristic risk
analysis”. In Software Testing & Quality Engineering Magazine.
Besson, S. (2004) “A Strategy for Risk-Based Testing”. Disponível em <http://www
stickyminds.com>. Acesso em agosto de 2007.
Chen, Y. (2002) “Specification-based Regression Testing Measurement with Risk
Analysis”. Dissertação de mestrado, University of Ottawa, Canada.
CMMI – Capability Maturity Model Integration (2006), Software Engineering Institute,
Carnegie Mellon University. Disponível em <http://www.sei.cmu.edu/cmmi/>.
Acesso em fevereiro de 2008.
Goldsmith, R. (2006) “Early and Effective: The Perks of Risk-based Testing”. In
Software Test & Performance Magazine.
IEEE Std. 829 (1998) “Standard for Software Test Documentation”.
IEEE Std. 1012 (1998) “Standard for Software Verification and Validation”.
Kaner, C., Falk, J., Nguyen, H. Q. (1999) “Testing computer software”, 2a edição.
PMBOK - Project Management Institute (2004) “A Guide to the Project Management
Body of Knowledge”.
Rosenberg, L. H.; Stapko, R.; Gallo, A. (1999) “Risk-based object oriented testing: In
24th Annual Software Engineering Workshop, NASA SEW24.
RUP - Rational Unified Process (2003) Disponível em <http://www.wthreex.com/rup/>.
Acesso em janeiro de 2008.
TMM - Test Maturity Model (2005), Illinois Institute of Technology. Disponível em <
http://www.tmmifoundation.org/>. Acesso em fevereiro de 2008.
12