ads:
i
Universidade de Pernambuco
Escola Politécnica de Pernambuco
Departamento de Sistemas e Computação
Programa de Pós-Graduação em Engenharia da Computação
Ellen Polliana Ramos Souza
RBTProcess: Modelo de Processo de Teste
de Software baseado em Riscos
Dissertação de Mestrado
Recife, Dezembro de 2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
DISSERTAÇÃO APRESENTADA AO PROGRAMA
DE PÓS-GRADUAÇÃO EM ENGENHARIA DA
COMPUTAÇÃO DA UNIVERSIDADE DE
PERNAMBUCO COMO REQUISITO PARCIAL
PARA OBTENÇÃO DO TÍTULO DE MESTRE EM
ENGENHARIA DA COMPUTAÇÃO.
ELLEN POLLIANA RAMOS SOUZA
RBTProcess: Modelo de Processo de Teste de
Software baseado em Riscos
Orientador: Prof. Dra. Cristine Martins Gomes de Gusmão
Recife, Dezembro/2008.
ads:
iii
S729r Souza, Ellen Polliana Ramos
RBTProcess: Modelo de Processo de Teste de
Software baseado em Riscos /
Ellen Polliana Ramos
Souza. – Recife : O Autor, 2008.
vi, 129 f. : 27 fig., 39 tab.
Dissertação (mestrado) –
Universidade de
Pernambuco. DSC Engenharia da Computação, 2008.
Inclui bibliografia e apêndice.
1. Engenharia de Software. 2. Teste de Software.
3.
Processo de Teste de Software I. Título.
CDU - U
PE
CDU(681.300:681.3.06)
iv
Dedico este trabalho
Aos meus pais, que sempre acreditaram em mim, fornecendo todo
apoio necessário para que eu pudesse alcançar meus objetivos.
Ao meu filho Gabriel que, com o seu sorriso, contagia a minha vida
de alegria, coragem e força de vontade para crescer cada vez mais.
Á Alberto, meu companheiro, amigo, cúmplice de todos os
momentos bons ou ruins, sempre me apoiando e me confortando.
Aos meus irmãos Day, Leu e Jó e familiares, pelo apoio e incentivo
em todos os momentos.
v
Agradecimentos
A minha orientadora, Cristine Gusmão, que aceitou o desafio de orientar uma aluna
cansada, desmotivada e sem tempo para dedicar-se ao mestrado. Sem o seu apoio, eu jamais
teria concluído esse trabalho.
A todos os professores do DSC, pela preocupação contínua com o aprendizado e
extrema dedicação a este programa de pós-graduação.
A todos os colegas da primeira turma de mestrado, que, nos momentos difíceis,
estiveram sempre ao meu lado, não me deixando fraquejar e nem desistir do mestrado. São
eles: Naida, Lilian, Renata, César, Henrique, Marcelo, Mário, Alexandre, Petrônio, Diogo,
Thyago, Danilo, Anthony, George e Bernardo.
A Renata, Keldjan, Júlio e Ed, pela amizade, dedicação e contribuição com os seus
trabalhos de iniciação científica e/ou conclusão de curso.
Aos queridos voluntários, Emanoel, Hilda, Liliane, Raphael e Everton, que chegavam
às 7h da manhã para participar do estudo de caso.
À equipe MPhyScas, formada por César, Renata, Fernando, Danilo e Marcelo, pela
disponibilidade para realização do estudo de caso.
À Ana Georgina, secretária do DSC, pelo carinho e dedicação, sempre nos orientando
e ajudando para que pudéssemos estudar com tranqüilidade.
Ao amigo Breno Spindola, pelas valiosas contribuições, pelos conselhos e pela revisão
deste e de outros trabalhos.
Ao amigo Humberto Rocha, pela realização das simulações e revisão do modelo de
processo.
Aos colegas Simone, Tiago, Elvys, Fernando, Paulo e Virginia, do Projeto CIn –
Motorola, que me incentivaram a ingressar no mestrado e me forneceram todo o apoio
necessário para iniciar este trabalho.
Aos colegas Mônica Falcão, Nielso, Bruno Abreu e Márcia Falcão, do SERPRO, pelo
incentivo para que eu pudesse dedicar-me ao mestrado.
Aos colegas Tiago, Humberto, Adélia, Denílson, Rodrigo e Jarley, do SINPA, pela
enorme ajuda e paciência, quando a minha mente já estava esgotada.
À Ana Claudia, por cuidar de Gabriel sempre com muito zelo e carinho, deixando-me
tranqüila para estudar.
Aos demais amigos, que felizmente não são poucos, pelas contribuições, incentivo,
conforto e compreensão pela a minha ausência nestes últimos dois anos.
vi
Resumo
Neste trabalho, é apresentado o RBTProcess, um Modelo de Processo de Teste de Software
baseado em Riscos, constituído de atividades da gerência de riscos e de processos de teste de
software, papéis, guias, artefatos e um conjunto de métricas, fornecido com o propósito de
medir e controlar os casos de teste e atividades do processo.
O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso e é
apoiado pela RBTTool, ferramenta de apoio ao Teste de Software baseado em Riscos, também
apresentada neste trabalho.
Teste baseado em risco ou Risk-based Testing (RBT) consiste em um conjunto de atividades
que favorece a identificação 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 e os casos de teste, por sua vez, são projetados com base nas estratégias para
tratamento destes riscos.
A motivação principal para este trabalho deve-se ao fato de que a atividade de Teste de
Software requer esforço considerável, normalmente dentro de restrições de custo e prazo, e a
abordagem RBT permite justamente priorizar esforços e alocar recursos para os requisitos do
software que necessitam ser testados prioritariamente, otimizando o processo de teste.
Entretanto, os engenheiros de teste, ainda encontram dificuldade em aplicar a abordagem na
prática pela ausência de conhecimentos sólidos sobre as atividades da Gerência de Riscos de
Software e, principalmente, pela ausência de ferramenta de apoio.
A contribuição principal deste trabalho é demonstrar que a abordagem RBT, através do
RBTProcess, permite concentrar os esforços de teste nos requisitos de software que possuem
maior probabilidade de apresentar falhas. Outras contribuições são: (i) mostrar que os
defeitos, com maior severidade, podem ser descobertos mais cedo, tendo em vista que os
requisitos mais problemáticos serão testados prioritariamente; (ii) mostrar que a qualidade do
produto final é melhorada, como conseqüência de uma atividade de testes bem planejada e,
por fim, (iii) mostrar que as atividades da gerência de riscos de software, incluídas no
processo de teste de software, não exigem muitos recursos e tempo para execução.
Palavras-chave: Teste de Software baseado em Riscos, Modelo de Processo, Engenharia de
Software, Gerência de Riscos de Software.
vii
Abstract
This work presents the RBTProcess, a Risk-based Software Testing Process Model that
contains activities from risk management and software testing, roles, guidelines, artifacts and
a set of metrics to measure and control risk-based test cases and activities.
The RBTProcess was evaluated through simulations of process use and case study. It is
supported by the RBTTool, a tool for Risk-based Software Testing, also presented in this
work.
Risk-based Testing (RBT) consists of a set of activities regarding risks identification related
to software requirements. Once identified, the risks are prioritized according to their
likelihood and impact and test cases are projected based on the strategies for treatment of the
identified risks.
The main motivation of this work is that testing process requires significant effort, besides
costs and resources constraints and RBT allows prioritize limited efforts for the software
components that need to be tested carefully, improving, in this way, the test activities.
However, testers continually encounter difficulties in effectively applying risk-based in
practice, because they normally do not have risk management knowledge and there is no
software tool to support the approach.
The main contribution of this work is to confirm that RBT, through RBTProcess, allows
focusing on the software requirements that are more likely to failure.
Other contributions are: (i) to demonstrate that defects with high severity are discovered
earlier as a result of requirement prioritization; (ii) to show that the software product quality is
improved as consequence of well planned test activities and (iii) to show that software risk
management activities, included in the software test process, are not time and resource
consuming.
Keywords:
Risk-based Software Testing, Process Model, Software Engineering, Software Risk
Management.
viii
Sumário
Índice de Figuras x
Índice de Tabelas xi
Tabela de Siglas e Símbolos xiii
SIGLAS xiii
SÍMBOLOS xv
1 Introdução 1
1.1 Motivação 2
1.2 Objetivos 3
1.2.1 Objetivo Geral 3
1.2.2 Objetivos Específicos 3
1.3 Metodologia 4
1.4 Organização da Dissertação 6
2 Riscos e Testes de Software: Conceitos Básicos, Modelos e Processos 7
2.1 Teste de Software 7
2.1.1 Conceitos Básicos 8
2.1.2 Processo de Teste de Software segundo o Processo Unificado da Rational (RUP) 12
2.1.3 Modelo de Maturidade de Teste de Software (TMM) 17
2.1.4 Padrão IEEE 1012-1998 para Verificação e Validação de Software 19
2.1.5 Padrão IEEE 829-1998 para Documentação de Teste de Software 22
2.2 Riscos na Engenharia de Software 25
2.2.1 Conceitos Básicos 25
2.2.2 Processo de Gerência de Riscos segundo o Guia PMBOK 28
2.2.3 Processo de Gerência de Riscos segundo o Processo Unificado da Rational (RUP) 29
2.2.4 Atividades da Área de Processo do Gerenciamento de Riscos do Modelo CMMI 30
2.2.5 Atividades da Gerência de Riscos do Instituto de Engenharia de Software (SEI) 32
2.3 Resumo do Capítulo 34
3 Teste de Software baseado em Riscos 35
3.1 Atividades 36
3.2 Principais Abordagens 37
3.2.1 Abordagem baseada em Heurística 37
3.2.2 Abordagem baseada em Métricas 39
3.2.3 Abordagem baseada em Código-fonte Orientado a Objetos 42
3.2.4 Abordagem para Teste de Regressão 43
3.2.5 Abordagem baseada em Uso 44
3.2.6 Abordagem baseada em Modelos 46
3.3 Análise Comparativa 48
3.4 Resumo do Capítulo 51
4 RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos 52
4.1 Documentação do Modelo 52
ix
4.2 Visão Geral 54
4.2.1 Fases 54
4.2.2 Papéis 56
4.3 Disciplinas ou Conjuntos de Trabalho 57
4.3.1 Identificar Riscos 57
4.3.2 Analisar Riscos 59
4.3.3 Planejar Testes 62
4.3.4 Projetar Testes 63
4.3.5 Executar Testes 65
4.3.6 Avaliar Testes 66
4.3.7 Controlar Riscos 67
4.4 Relacionamento dos Artefatos 68
4.5 Métricas 68
4.5.1 Métricas para Controle e Medição de Casos de Teste baseado em Riscos 70
4.5.2 Métricas para Controle e Medição das Atividades do Processo de Teste de Software baseado em
Riscos 70
4.6 Avaliação do Modelo de Processo 72
4.6.1 Simulações Realizadas pela Autora 73
4.6.2 Simulações Realizadas por Engenheiro de Teste com Experiência em Teste de Software 75
4.6.3 Simulações Realizadas para Avaliar Métricas e Coletar Tempo de Atividades de Identificação e
Análise de Riscos 76
4.6.4 Estudo de Caso 79
4.7 Resumo do Capítulo 90
5 RBTTool: Ferramenta de apoio ao Teste de Software baseado em Riscos 91
5.1 Requisitos 92
5.2 Material e Método 93
5.2.1 Tecnologias 94
5.2.2 Ambiente de Desenvolvimento e Frameworks 94
5.2.3 Processos de Desenvolvimento e Gerência de Riscos 96
5.3 Estágio Atual de Desenvolvimento 97
5.4 Resumo do Capítulo 97
6 Conclusões 99
6.1 Contribuições e Resultados Alcançados 99
6.2 Limitações Encontradas 100
6.3 Trabalhos Relacionados 101
6.4 Trabalhos Futuros 101
Bibliografia 103
Pesquisa sobre a Abordagem de Teste baseado em Riscos 107
RBTTool: Telas 111
RBTProcess: Papéis 116
RBTProcess: Atividades 119
x
Índice de Figuras
Figura 2.1 Classificação para os termos erro, defeito e falha [Graham et al 2007]. 9
Figura 2.2 Estágios do teste de software. 10
Figura 2.3 Arquitetura geral do RUP (2003). 13
Figura 2.4 Atividades de teste do processo unificado da Rational [RUP 2003]. 14
Figura 2.5 Estrutura do TMM [Burnstein 1999]. 17
Figura 2.7 Relacionamento entre os artefatos e atividades de teste [IEEE 829 1998]. 24
Figura 2.8 Taxonomia de riscos proposta pelo SEI e adaptada por [Gusmão 2005]. 27
Figura 3.1 Atividades relevantes para RBT [Amland 1999]. 36
Figura 3.2 Esforço necessário para reduzir em 50% os riscos. 45
Figura 3.3 Amostra de um modelo de teste com informações de riscos. 47
Figura 4.1 Níveis de modelagem do SPEM. 53
Figura 4.2 Composição do Eclipse Process Framework [EPF 2007]. 54
Figura 4.3 Página do modelo de processo criada pelo EPFComposer [RBTProcess 2008]. 55
Figura 4.4 Fases do RBTProcess. 55
Figura 4.5 RBTProcess: Disciplina Identificar Riscos. 58
Figura 4.6 RBTProcess: Disciplina Analisar Riscos. 60
Figura 4.7 Métricas para cálculo de exposição ao risco dos requisitos. 60
Figura 4.8 RBTProcess: Disciplina Planejar Testes. 62
Figura 4.9 RBTProcess: Disciplina Projetar Testes. 64
Figura 4.10 Questionário baseado em taxonomia para a funcionalidade Group Tasks. 65
Figura 4.11 RBTProcess: Disciplina Executar Testes. 65
Figura 4.12 RBTProcess: Disciplina Avaliar Testes. 66
Figura 4.13 RBTProcess: Disciplina Controlar Riscos. 67
Figura 4.14 RBTProcess: Relacionamento dos artefatos. 69
Figura 4.16 Visão geral do fluxo de execução do estudo de caso. 80
Figura 5.1 Diagrama de caso de uso da RBTTool. 92
Figura 5.2 Componentes da Arquitetura RCP (2008). 95
xi
Índice de Tabelas
Tabela 1.1 Metodologia do Trabalho. 5
Tabela 2.1 Tipos de testes de software [RUP 2003]. 11
Tabela 2.2 Objetivos e atividades dos níveis do TMM. 19
Tabela 2.3 Conteúdo dos documentos de teste de software [IEEE 829 1998]. 23
Tabela 2.4 Matriz de impacto e probabilidade. 26
Tabela 2.5 Questões de “estabilidade” e “completude” para o elemento “requisito”. 28
Tabela 2.6 Objetivos e práticas da área de processo de gerenciamento de riscos. 31
Tabela 3.1 Etapas do teste baseado em riscos [Bach 1999]. 36
Tabela 3.2 Lista de categorias de critérios de qualidade [Bach 1999]. 37
Tabela 3.3 Lista genérica de riscos [Bach 1999]. 38
Tabela 3.4 Catálogo de riscos para um instalador [Bach 1999] 38
Tabela 3.5 Exposição ao risco calculado para a função “fechar contas” [Amland 1999]. 40
Tabela 3.6 Valores limites para métricas individuais. 42
Tabela 3.7 Métricas coletadas de um projeto Java. 43
Tabela 3.8 Possíveis casos de teste e risco associado. 47
Tabela 3.9 Análise comparativa das principais abordagens RBT. 50
Tabela 4.1 Estereótipos disponíveis no SPEM. 53
Tabela 4.2 Exemplo de indicadores para a métrica de qualidade da funcionalidade. 61
Tabela 4.3 Lista de priorização dos requisitos. 61
Tabela 4.4 Definição do escopo dos teste. 63
Tabela 4.5. Métrica para casos de teste baseado em riscos. 71
Tabela 4.6 Métricas para atividade de teste baseado em riscos. 72
Tabela 4.7 Métricas da atividade de identificação de riscos. 77
Tabela 4.8 Cálculo de exposição ao risco para o sistema Health-Watcher. 77
Tabela 4.9 Métricas da atividade de análise de riscos. 77
Tabela 4.10 Número de casos de teste por funcionalidade. 78
Tabela 4.11 Resultado da execução dos casos teste baseado em riscos. 78
xii
Tabela 4.12 Métricas da atividade de análise de riscos. 79
Tabela 4.13 Atividades de preparação para realização do estudo de caso. 83
Tabela 4.14 Atividades do RBTProcess. 83
Tabela 4.15 Tempo gasto na atividade de identificação de riscos. 85
Tabela 4.16 Características dos riscos identificados. 85
Tabela 4.17 Tempo gasto para análise dos riscos. 86
Tabela 4.18 Valores de exposição ao risco das funcionalidades do MPhyScaS. 86
Tabela 4.19 Número e severidade dos defeitos encontrados por abordagem. 88
Tabela 4.20 Concentração dos defeitos por caso de teste. 88
Tabela 4.21 Concentração dos defeitos por tempo de execução. 88
Tabela 4.22 Concentração dos defeitos por funcionalidade. 89
Tabela 5.1 Cronograma de atividades do ano de 2008. 97
xiii
Tabela de Siglas e Símbolos
SIGLAS
ADS – Ambiente de Desenvolvimento de Software
ARSP – Additional Risk Score Prioritization
CASE – Computer-Aided Software Engineering
CBO – Coupling Between Objects
CMM – Capability Maturity Model
CMMI – Capability Maturity Model Integration
DIT – Depth in Tree
DSC – Departamento de Sistemas e Computação
EPF – Eclipse Process Framework
FEM – Finite Element Method
GARA – Processo Ágil de Gestão de Riscos
GQM – Goal Question Metric
IDE – Integrated Development Environment
IEEE – The institute of Electrical and Electronics Engineers
IIT – Illinois Institute of Technology
ISO – International Organization for Standardization
ISTQB – International Software Testing Qualifications Board
JUDE – Java and UML Developer Environment
MPhyScaS – Multi-Physics and Multi-Scales Solver Environment
NASA – National Aeronautics and Space Administration
NOC – Number of Children
xiv
NOM – Number of Methods
OMG – Object Management Group
PMBOK – Project Management Body of Knowledge
PMI – Project Management Institute
OP – Optimum Prioritization
OpenUP – Open Unified Process
RBT – Risk-based Testing
RCP – Rich Cliente Plataform
RE – Risk Exposure
REM – Requirement Management
RFC – The Response for a Class
RiteDAP – Risk-based test case Derivation And Prioritization
RP – Randomic Prioritization
RUP – Rational Unified Process
SATC – Software Assurance Technology Center
SEI – Software Engineering Institute
SG – Specific Goals
SP – Specific Practices
SPEM – Software Process Engineering Metamodel
SQA – Software Quality Assurance
TBQ – Taxonomy-Based Questionnaire
TCMM – Testing Capability Maturity Model
TIM – Test Improvement Model
TMM – Test Maturity Model
TPI – Test Process Improvement
TOM – Test Organization Maturity
xv
TRSP – Total Risk Score Prioritization
UFPE – Universidade Federal de Pernambuco
UMA – Unified Method Architecture
UML – Unified Modeling Language
UPE – Universidade de Pernambuco
V&V – Verificação e Validação
WMC – The Weighted Methods per Class
SÍMBOLOS
)(vC – Custo para Vendedor
)(cC
– Custo para Cliente
)( fER
– Exposição ao Risco da Função f
)( fP
– Probabilidade da Função f
)( fI
– Impacto da Função f
1
1
Introdução
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 produtos de
software produzidos tem crescido, tornando-se indispensável a utilização de processos,
métodos, técnicas e ferramentas que permitam a realização de teste de software de maneira
sistemática e com fundamentação teórica, com o propósito de aumentar a qualidade do
software, com o menor custo possível [Delamaro et al 2007]. Assim, o processo de testes
exerce um importante papel dentro da garantia de qualidade de software ou Software Quality
Assurance (SQA) assegurando que os requisitos satisfaçam as necessidades das partes
envolvidas.
Da mesma forma, a gerência de riscos de software tem sido fortemente debatida,
estudada e utilizada em ambientes de desenvolvimento de software com o propósito de
administrar oportunidades [Gusmão 2007], aumentando a probabilidade de atingir os
objetivos do projeto, ou seja, entregar o produto de software com o menor custo, no menor
tempo possível e com maior qualidade.
O Teste baseado em Riscos ou Risk-based Testing (RBT), 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
associados aos requisitos, reduzindo o tempo e esforço necessários para testar um produto.
O objetivo deste capítulo introdutório é apresentar a importância do tema abordado, as
motivações, objetivos e os passos realizados para construção deste trabalho.
Capítulo
2
1.1 Motivação
A atividade de teste de software tem se mostrado fundamental no desenvolvimento de
software, buscando evitar, principalmente, que falhas cheguem aos clientes, deixando-os
insatisfeitos e causando prejuízos. Esta atividade, no entanto, é 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, a atividade de teste é bastante cara, chegando a custar até 45% do valor inicial de um
produto em desenvolvimento [Kaner et al 1999].
Segundo estudos [Graham et al 2007], quanto mais tarde um erro é encontrado, maior
é o custo para corrigi-lo que cresce de forma exponencial como mostrado na Figura 1.1. A
mudança em um documento de requisito durante uma revisão ou inspeção de requitos tem
baixo custo, entretanto, se realizada após a codificação do requisito, torna-se mais cara, uma
vez que, além da atualização do documento, o código necessita ser reescrito.
Outro problema relatado na literatura [Goldsmith 2006] é que, infelizmente, o
processo de teste de software ainda é visto, por alguns, como um processo que tem início ao
final do processo de desenvolvimento. Nestes casos, os problemas enfrentados em estágios
anteriores têm sido resolvidos fazendo-se uso do tempo e dinheiro - normalmente bastante
limitados - reservados para o teste, não sobrando recurso suficiente para se testar
adequadamente o produto de software. Assim, o teste se torna bastante curto, e os sistemas
produzidos tornam-se menos confiáveis.
Além disso, a fase de testes também tem sido utilizada como buffer para compensar
atrasos no projeto comprometendo, também, o tempo destinado aos testes e a qualidade do
software [Goldsmith 2006].
Figura 1.1 Custo para encontrar e corrigir defeitos em um software.
custo para encontrar e corrigir
defeitos aumenta ao longo do tempo
C
U
S
T
O
TEMPO
Requisitos Projeto Construção Teste Uso
3
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 [Rios 2005].
A técnica de teste baseada em análise de riscos surgiu como uma abordagem para
minimizar alguns dos problemas relacionados ao esforço da atividade de teste e da gerência
de riscos. Assim, a atividade de testes é melhorada a partir da gerência dos riscos técnicos de
software que podem ser tratados através da realização de atividades de teste de software.
Apesar da abordagem RBT mostrar-se simples, os 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 [SEI 2006].
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.
Visando diminuir esta dificuldade de utilização da abordagem RBT, este trabalho
apresenta um Modelo de Processo de Teste de Software baseado em Riscos com guias,
artefatos, atividades, papéis, métricas e apoiado por protótipo que forneça apoio às principais
atividades da abordagem.
1.2 Objetivos
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é definir um Modelo de Processo de Teste de Software
baseado em Riscos, formado por atividades presentes nos processos de gerência de riscos e de
testes de software, bem como, métodos e técnicas presentes nas abordagens de teste baseado
em riscos disponíveis na literatura, com o propósito de facilitar e disseminar o uso da
abordagem RBT.
1.2.2 Objetivos Específicos
O conjunto de objetivos específicos necessários para a realização do objetivo geral é:
Pesquisar abordagens, métodos, processos e ferramentas de teste baseado em riscos,
identificando atividades em comum, formas de utilização, pontos fortes e fracos,
elaborando um estudo comparativo.
4
Pesquisar conceitos básicos e processos para gerência de riscos e testes de software,
identificando atividades que podem ser utilizadas na definição do modelo de processo.
Propor um modelo de processo que integre atividades de gerência de riscos e testes de
software, levando em consideração as técnicas e métodos de teste baseado em riscos
identificados na literatura.
Construir uma ferramenta que apóie a utilização da abordagem RBT através da
implementação de funcionalidades que atendam às principais atividades da
abordagem.
Avaliar o modelo através de simulações e estudos de caso.
Divulgar a abordagem RBT, modelo de processo e protótipo, através da escrita de
artigos científicos.
Propor novas linhas de pesquisas como forma de continuação deste trabalho.
1.3 Metodologia
Para a obtenção dos objetivos definidos na Seção anterior, um conjunto de etapas foi definido
contendo atividades e metodologia utilizada. A pesquisa pode ser divida em quatro fases
distintas e contínuas como apresentado na Tabela 1.1.
A primeira fase teve uma característica exploratória e possibilitou elencar os requisitos
necessários para construção do modelo e do protótipo.
A segunda fase constituiu na definição e construção do modelo de processo em si,
através da compilação do material identificado na fase anterior.
Na terceira fase, o foco foi na construção do protótipo de apoio à abordagem RBT,
independente de processo, pois a finalidade era a avaliação dos requisitos do modelo de
processo.
Na quarta fase, o modelo de processo e o protótipo foram avaliados. No decorrer desta
fase, mais precisamente após as simulações do modelo de processo, o modelo e dados
coletados resultaram nas seguintes publicações:
1. SOUZA, E.; GUSMÃO C.; RBTProcess - Modelo de Processo de Teste de Software
baseado em Riscos. In: 13º WTES - Workshop de Teses e Dissertações em Engenharia de
Software, 2008.
2. SOUZA, E.; GUSMÃO C.; ROCHA, H. RBTProcess - Proposta de Modelo de Processo de
Teste de Software baseado em Riscos. In: III EBTS – Encontro Brasileiro de Teste de
Software, 2008.
5
Tabela 1.1 Metodologia do Trabalho.
FASES ATIVIDADES METODOLOGIA
Fase 1
Estudo sobre o tema
abordado
Estudo inicial sobre testes, riscos de
software e teste baseado em riscos;
Levantamento das formas de
utilização e dificuldades da
abordagem RBT.
Revisão bibliográfica;
Aplicação de questionário.
Fase 2
Definição do
RBTProcess
Estudo aprofundado sobre testes,
riscos de software e teste baseado
em riscos;
Definição do modelo de processo
contendo as principais atividades da
abordagem.
Identificação das principais
atividades, elaboração de estudo
comparativo as abordagens RBT;
Seleção das principais atividades
encontradas nos principais processos
de gerência de riscos e testes de
software.
Fase 3
Construção da
RBTTool
Levantamento dos requisitos
necessários para utilização da
abordagem RBT;
Implementação das funcionalidades
identificadas.
Revisão das principais abordagens
RBT identificando atividades em
comum;
Definição de ambiente de
desenvolvimento, processo e
tecnologias utilizadas para
construção da ferramenta.
Fase 4
Avaliação do
RBTProcess
Instanciação do modelo de processo
e definição do plano de aplicação do
modelo de processo;
Simulação do modelo de processo;
Aplicação do modelo de processo;
Coleta e avaliação dos resultados;
Refinamento do modelo de
processo.
Divulgação da abordagem, modelo
de processo
Entrevista com os participantes do
estudo de caso, estudo da
documentação do software;
Execução das atividades do processo
utilizando documentos de projetos
de desenvolvimento de software;
Definição dos papéis e realização
das atividades definidas no modelo
de processo em um projeto de
desenvolvimento de software;
Coleta do resultado dos testes e
aplicação de questionário com os
integrantes da equipe de
desenvolvimento e com o cliente do
software;
Coleta do tempo de realização das
atividades, grau de dificuldade e
oportunidades de melhorias através
da realização de questionário e
avaliação dos resultados.
Publicação de artigos em eventos
nacionais e internacionais. Escrita e
defesa da dissertação.
6
1.4 Organização da Dissertação
Após este capítulo introdutório, este trabalho é apresentado como segue:
Capítulo 2 - Riscos e Testes de Software: Conceitos Básicos, Modelos e Processos:
apresenta os conceitos básicos da área de teste e de riscos de software, processos e modelos
estudados e utilizados como base para definição do RBTProcess. O objetivo deste capítulo é
listar a terminologia e as principais atividades da gerência de riscos e do processo de teste de
software.
Capítulo 3 - Teste de Software baseado em Riscos: apresenta a revisão bibliográfica
sobre a abordagem de teste baseado em riscos, histórico, principais atividades e análise
comparativa. O objetivo deste capítulo é apresentar as diferentes abordagens, destacando seus
pontos fortes e identificando oportunidades de melhorias, que foram aproveitadas para
definição do RBTProcess.
Capítulo 4 - RBTProcess: Modelo de Processo de Teste de Software baseado em
Riscos: apresenta o RBTProcess, descrevendo como o mesmo foi construído, modelado e
documentado, suas fases, papéis, atividades e artefatos. Também são apresentadas métricas
para acompanhamento do progresso das atividades RBT e resultado das avaliações do
modelo.
Capítulo 5 - RBTTool: Ferramenta de apoio ao Teste de Software baseado em
Riscos: apresenta os requisitos necessários para construção de ferramenta de apoio à
abordagem RBT, tecnologias utilizadas, processos e ambiente de desenvolvimento, estágio
atual de desenvolvimento e avaliação da ferramenta.
Capítulo 6 - Conclusões: contém as conclusões, contribuições, limitações encontradas
e propostas de continuação deste trabalho.
Apêndice A: apresenta o questionário utilizado na pesquisa sobre conhecimento e
formas de utilização da abordagem RBT, bem como os resultados coletados.
Apêndice B: apresenta as telas da RBTTool através de um exemplo de utilização da
ferramenta.
Apêndice C: apresenta os papéis do RBTProcess documentados na página do
processo.
Apêndice D: apresenta as atividades do RBTProcess documentadas na página do
processo.
7
2
Riscos e Testes de Software:
Conceitos Básicos, Modelos e
Processos
Processos de teste têm se mostrado fundamentais na garantia da qualidade dos produtos de
software, buscando evitar, principalmente, que falhas cheguem até os clientes, deixando-os
insatisfeitos e causando prejuízos. A gerência de riscos de software, por sua vez, é essencial
para o aumento contínuo da qualidade e produtividade exigido pelo mercado, cada vez mais
competitivo [Gusmão 2007].
Este capítulo tem como objetivos destacar a importância das atividades de teste –
Seção 2.1 – e riscos na Engenharia de Software – Seção 2.2, apresentar conceitos chave,
processos, abordagens e modelos que serviram como base para construção do Modelo de
Processo proposto neste trabalho.
2.1 Teste de Software
De acordo com Myers [Meyers 1979], teste é o processo de executar um programa com o
intuito de encontrar defeitos. No entanto, atividades do processo de teste de software podem
ser realizadas já nas fases iniciais do desenvolvimento, antes mesmo da codificação, através
do planejamento e projeto de casos de teste, por exemplo.
Uma definição mais completa é fornecida por Sommerville (2003), segundo o qual, as
atividades de verificação e validação (V&V) destinam-se a mostrar, respectivamente, que um
produto de software está de acordo com suas especificações e que ele atende às expectativas
Capítulo
8
de todas as partes envolvidas no sistema. Dentro do processo de V&V, encontra-se o teste de
software, uma técnica dinâmica, que envolve executar uma implementação de software com
os dados de teste e examinar suas saídas e comportamento operacional, a fim de verificar se
ele está funcionando conforme o esperado.
Segundo o International Software Testing Qualifications Board (ISTQB) [Graham et
al 2007] a palavra qualidade é definida como o “grau até o qual um componente, sistema ou
processo atende aos requisitos especificados e às necessidades e expectativas dos usuários”.
A qualidade de um produto de software está fortemente relacionada à satisfação do
cliente, e o teste de software é uma das formas de validar se o produto desenvolvido atende às
necessidades de seus usuários [Kaner et al 1999].
A execução de casos de teste é utilizada, também, para avaliar, de forma quantitativa,
a qualidade de um produto de software. Através dos relatórios de resultado da execução dos
casos de testes e rastreamento de requisitos funcionais e não funcionais, é possível obter
percentuais de testes que estão passando, falhando ou que não puderam ser executados para
um conjunto de requisitos, em uma determinada versão, como forma de mensurar a cobertura
dos testes.
O resultado da execução dos testes pode representar confiança na qualidade do
software caso sejam encontrados poucos ou nenhum defeito. Um teste projetado
adequadamente e cuja execução não encontre defeitos reduz o nível de riscos em um produto
de software. Por outro lado, quando os testes encontram defeitos, a qualidade do sistema
aumenta quando estes são corrigidos. É importante destacar que testes mal projetados, ou
executados de forma incorreta, podem encontrar poucos defeitos, deixando uma falsa
impressão de qualidade [Graham et al 2007].
2.1.1 Conceitos Básicos
Antes de apresentar os principais conceitos de testes, vale ressaltar a diferença entre os termos
erro, defeito e falha, normalmente utilizados com o mesmo significado. O erro consiste em
uma ação, geralmente humana, que pode produzir um defeito no código ou em qualquer outro
artefato do software. Se um defeito é executado em um código, por exemplo, o software pode
vir a apresentar falha. A Figura 2.1 apresenta uma classificação para esses termos. Abaixo,
segue definição extraída do glossário do ISTQB [Graham et al 2007].
9
Erro (engano): Uma ação humana ou do sistema que produz um resultado
incorreto. Estas ações podem surgir por falta de experiência, informação,
entendimento ou até mesmo por falta de atenção.
Defeito (bug ou falta): Brecha em um componente ou sistema que pode fazer com
que este falhe ao desempenhar sua função. Por erro ou engano, podemos inicializar
vaiáveis de informar incorreta, acessar valores inexistentes em estruturas de dados,
realizar conversões entre tipos de dados incompatíveis, dentre outras, introduzindo
assim, defeitos no código-fonte. Pensando na etapa de elicitação de requisitos, os
defeitos são funcionalidades especificadas de forma incorreta ou incompleta, por
exemplo.
Falha: Desvio, em um componente ou sistema, do seu resultado ou serviço
esperado. A falha ocorre justamente quando a parte do sistema defeituoso é
executada. Caso o código defeituoso não seja executado, o sistema pode nunca
falhar e o defeito jamais ser descoberto. Com relação aos requisitos de software,
funcionalidades especificadas de forma incorreta ou incompleta resultam em
resultado diferente do esperado pelo cliente e/ou usuário.
Figura 2.1 Classificação para os termos erro, defeito e falha [Graham et al 2007].
Abordagens
Para criação ou projeto dos casos de teste, duas principais abordagens podem ser utilizadas:
Funcional ou “caixa preta”: os casos de testes são criados a partir de uma análise
dos relacionamentos entre os dados de entrada e saída, com base nos requisitos
levantados com os usuários. Essa abordagem é aplicada durante as últimas etapas
do processo de teste de software.
Estrutural ou “caixa branca”: os testes são criados a partir de uma análise dos
caminhos lógicos possíveis de serem executados, de modo que é necessário o
conhecimento do funcionamento interno dos componentes do software. É aplicado
durante a codificação do software.
10
Estágios
Os estágios definem o momento do ciclo de vida do software em que os testes são realizados.
Em cada estágio do processo de software, desde o levantamento dos requisitos até o
desenvolvimento do programa, testes estáticos ou dinâmicos podem ser realizados. A Figura
2.2 apresenta os principais níveis ou estágios do teste de software.
Módulo
Subsistema
Sistema
Figura 2.2 Estágios do teste de software.
Teste de Unidade: componentes individuais (ex: métodos e classes) são testados.
Tem por objetivo testar a estrutura interna e comportamento do módulo e é
geralmente realizado pelo desenvolvedor durante a implementação do software.
Teste de Integração: as unidades testadas independentemente agora são testadas
de forma integrada. É recomendada a integração das unidades de forma
incremental e este teste é realizado geralmente por um desenvolvedor.
Teste de Sistema: o software integrado com o ambiente operacional, similar ao de
produção, é testado. Geralmente, é um teste “caixa preta”, executado por um
testador de sistemas após a liberação de um executável do software. É
recomendado que o testador seja membro de um grupo independente de testes.
Teste de Aceitação: o software é testado pelo usuário final. É realizado um teste
“caixa preta” a fim de demonstrar a conformidade com os requisitos de software.
Tipos de Testes
Diferentes tipos de testes são projetados e executados com o intuito de avaliar um objetivo
específico. Na Tabela 2.1, é apresentada uma lista dos principais tipos de testes extraída do
Processo Unificado da Rational [RUP 2003]. A dimensão de qualidade que aparece na
primeira coluna da tabela representa as categorias de qualidade presentes no modelo FURPS
1
e detalhadas a seguir:
1
FURPS é um modelo de referência criado por Robert Grady na Hewlett Packard, que define as cinco principais
dimensões de qualidade para um software: Functionality, Usability, Reliability, Performance e Supportability
Teste de U
nidade
Teste de Integração
Teste de Sistema
Teste de Aceitação
11
Funcionalidade: possibilita verificar se a aplicação está em conformidade com os
seus requisitos.
Usabilidade: testa a aplicação da perspectiva da conveniência do usuário final.
Confiabilidade: verifica se a aplicação se comporta de maneira consistente e
previsível.
Performance: verifica o comportamento da aplicação numa condição de carga.
Suportabilidade: testa a habilidade da aplicação suportar várias plataformas,
configurações e ambientes diferentes.
Tabela 2.1 Tipos de testes de software [RUP 2003].
DIMENSÃO DE
QUALIDADE
TIPO DE TESTE
Funcionalidade funcionais: têm por objetivo testar as funcionalidades do sistema em termos de regras de
negócio.
segurança: verifica se os mecanismos de proteção de acesso estão funcionando
satisfatoriamente.
volume: submete grandes quantidades de dados ao sistema para determinar se limites que
causam a falha do software são alcançados.
Usabilidade usabilidade: verifica aparência e comportamento da interface, navegação, consistência,
aderência a padrões, tempo para aprender como usar uma funcionalidade
Confiabilidade integridade: testa a corretude dos métodos de acesso à base de dados e as informações
armazenadas.
estresse: verifica o funcionamento do sistema em situações limite ou fora da tolerância
esperada.
Performance desempenho: verifica o tempo de resposta e processamento (para diferentes configurações,
diferentes cargas de trabalho, número de usuários, tamanho da base de dados, etc.)
Suportabilidade configuração: verifica o funcionamento adequado do sistema em diferentes configurações
de hardware/software.
instalação/desinstalação: verifica a correta instalação e desinstalação do sistema para
diferentes plataformas de hardware/software e opções de instalação.
Atividades
O processo de teste de software define como os testes serão planejados, projetados,
implementados, executados e avaliados através de um conjunto de atividades, artefatos e
papéis. A seguir são apresentadas as principais atividades de um processo de testes extraídas
de [Graham et al 2007] e descritas seqüencialmente.
Planejar e Controlar: durante esta etapa, os objetivos dos clientes, satekholders e
projetos devem ser totalmente entendidos e os riscos relacionados às atividades de
teste devem ser endereçados, com o propósito de estabelecer metas e objetivos
para o teste de software. O planejamento determina e acompanha, de forma geral,
escopo e objetivos dos testes, a abordagem utilizada para construção dos casos de
teste, os recursos físicos e humanos, cronograma de planejamento, projeto,
execução e acompanhamento dos testes, além de definir os critérios de saída e a
cobertura dos testes, ou seja, o momento em que a atividade de teste será
12
finalizada. O resultado das atividades de teste é continuamente monitorado através
de métricas para acompanhamento do progresso, critério de saída e cobertura dos
testes.
Análise e projeto: nesta atividade, objetivos gerais de teste são transformados em
cenários e condições de testes tangíveis. Para isto, são revisados as análises de
riscos, requisitos funcionais e não funcionais, arquiteturas, modelos de análise e
projeto e interface do software.
Implementação e execução: os cenários de testes são transformados em casos e
procedimentos de teste utilizando a abordagem e estratégias definidas durante o
planejamento e validadas durante a análise. O ambiente é criado, incluindo os
dados para execução dos testes, bem como os casos de teste implementados. Suítes
de teste são criadas para execução, através da priorização dos requisitos do
software. Os casos de teste são finalmente executados e um log de teste é gerado
como resultado. No caso em que defeitos são encontrados no software ou mesmo
nos casos de teste, solicitações de mudança são abertas e designadas para os
responsáveis para que, posteriormente, esses defeitos sejam corrigidos e retestados.
Avaliação do critério de saída e resultado: a execução dos testes é avaliada de
acordo com o que foi definido na atividade de planejamento. Relatórios de
acompanhamento para os diversos stakeholders são criados através de análise do
resultado dos logs de teste e do status das solicitações de mudança. Além disso, é
verificado o critério de saída, que determina quando uma dada atividade de teste é
concluída.
Atividades de encerramento dos testes: nesta etapa, dados são coletados com o
intuito de consolidar experiência, isto inclui: analisar ambiente, dados de teste,
fatos, números e procedimentos de testes.
2.1.2 Processo de Teste de Software segundo o Processo Unificado da
Rational (RUP)
O RUP [RUP 2003] é um processo da Engenharia de Software que oferece as melhores
práticas relacionadas ao desenvolvimento de produtos de software através da definição de
atividades, responsabilidade, artefatos boas práticas e diretrizes.
O RUP foi criado pela Rational Software Corporation, que hoje pertence a IBM, e está
organizado em duas dimensões como mostra a Figura 2.3. A dimensão dinâmica representa o
13
tempo e é expressa em termos de fases, iterações e marcos. A dimensão estática representa os
componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.
O RUP é considerado um processo pesado e preferencialmente aplicável a grandes
equipes de projetos de desenvolvimento, porém o fato de ser amplamente customizável torna
possível que seja adaptado para projetos de qualquer escala [RUP 2008]. Para a disciplina de
teste de software, o RUP provê conceitos básicos, fluxo de trabalho, atividades, artefatos e
diretrizes, além de um conjunto de ferramentas.
Figura 2.3 Arquitetura geral do RUP (2003).
Na dimensão estática, encontram-se as disciplinas ou fluxos do processo. O fluxo de
requisitos produz o primeiro subsídio para a identificação dos testes de sistemas que serão
executados. O fluxo de análise e projeto descreve como desenvolver um projeto que é entrada
para a definição dos testes de integração da arquitetura. No fluxo de planejamento e
gerenciamento, os testes são planejados para cada iteração. Finalmente, o código produzido
no fluxo de implementação é testado no fluxo de teste.
Com relação à dimensão dinâmica, o processo de desenvolvimento do RUP é dividido
quatro fases, onde cada fase possui uma ou mais iterações, bem como seus marcos. A seguir,
são apresentados os objetivos do fluxo ou disciplina de teste de software para cada uma das
fases do processo.
Concepção: o foco é no planejamento inicial dos testes durante o planejamento do
projeto.
Elaboração: foco principal é o projeto e execução de testes de integração, de
forma a validar e estabelecer uma arquitetura estável para o sistema.
14
Construção: o foco principal das atividades de teste é o projeto e execução de
testes de sistema para os requisitos implementados.
Transição: o foco dos testes muda para a homologação e avaliação da correção
das mudanças efetuadas devido a defeitos encontrados.
A Figura 2.4 apresenta os papéis, atividades e artefatos definidos para a atividade de
teste do processo unificado da Rational explicadas a seguir.
Figura 2.4 Atividades de teste do processo unificado da Rational [RUP 2003].
Gerente de Testes
É responsável pelo planejamento e gerenciamento de recursos e resolução de problemas que
representam um obstáculo para o esforço de teste. Estão sob sua responsabilidade as
atividades:
Combinar Missão: negociar a forma mais eficaz de usar os recursos de teste para
cada iteração. Acordar sobre os objetivos e os produtos a serem liberados na
iteração através da compreensão inicial do escopo, objetivo e expectativa dos
envolvidos.
Identificar Motivadores de Teste: identificar a lista específica de itens, incluindo
eventos e artefatos, que servirão para motivar o teste na iteração.
15
Obter Confirmação de Testabilidade: promover a criação de um software
testável que apoie as necessidades do esforço de teste, através do entendimento das
necessidades de implementação e avaliação do teste. Promover e apoiar o uso de
técnicas e ferramentas apropriadas de automação.
Avaliar e Defender Qualidade: identificar e assegurar a resolução dos defeitos
que exercem um impacto prejudicial grave sobre a qualidade do software.
Monitorar e apoiar mudanças que forneçam qualidade para o software.
Avaliar e Aprimorar Esforço de Teste: avaliar a produtividade, a eficácia e a
abrangência do esforço de teste, realizando ajustes quando necessário para
alcanças os objetivos.
Analista de Teste
É responsável por identificar e definir os testes necessários, monitorar a abrangência dos
testes e avaliar a qualidade geral obtida ao testar o produto de software. Estão sob sua
responsabilidade as atividades:
Identificar Objetivos do Teste: identificar os elementos de sistema individuais,
tanto de hardware quanto de software, que precisem ser testados. Criar uma lista
com estes itens de teste para estimativa de esforço e construção do plano de teste.
Identificar Idéias de Teste: identificar as idéias de teste que devem ser exploradas
para avaliar a qualidade aceitável do produto de software, através da realização de
um brainstorm de idéias.
Definir Detalhes do Teste: definir as condições individuais necessárias para
realizar uma idéia de teste em um contexto específico.
Definir Necessidades de Avaliação e Rastreabilidade: definir a estratégia de
avaliação para o esforço de teste, bem como os requisitos de rastreabilidade e
cobertura dos testes.
Determinar Resultados do Teste: fazer avaliações resumidas contínuas da
qualidade do produto, com o propósito de fornecer resultados e propor ações
corretivas apropriadas para resolver falhas identificadas durante os testes.
Verificar Mudanças no Build: confirmar a conclusão de uma solicitação de
mudança, normalmente, realizando um subconjunto de testes em uma ou mais
versões.
16
Designer ou Projetista de Teste
É responsável por definir a abordagem de teste e assegurar sua correta implementação.
Envolve identificar as técnicas, ferramentas e diretrizes apropriadas para implementar os
testes necessários. Estão sob sua responsabilidade as seguintes atividades:
Definir Abordagem do Teste: identificar cada técnica específica a ser empregada
para realização do teste desejado.
Definir Configurações do Ambiente de Teste: definir os requisitos dos
ambientes de avaliação necessários para apoiar o esforço de teste.
Identificar Mecanismos de Testabilidade: identificar os possíveis mecanismos
de teste necessários para a abordagem de teste selecionada.
Estruturar a Implementação de Testes: atribuir responsabilidades às áreas de
implementação do conjunto de testes e seus conteúdos, além de descrever os
conjuntos de testes a serem impementados.
Definir Elementos de Testabilidade: identificar os elementos físicos da infra-
estrutura de implementação de teste necessária para permitir testes em cada
configuração de ambiente de teste.
Desenvolver Guia de Teste: efetuar ajustes na maneira como o processo é
desempenhado e registrar essas decisões, com o propósito de desenvolver o
conhecimento sobre os pontos fortes e fracos do processo de teste.
O Testador
É responsável pelas atividades centrais do esforço de teste, que envolve conduzir os testes
necessários e registrar os resultados. O detalhamento das atividades é apresentado a seguir:
Implementar Testes: implementar testes significativos que forneçam a
validação necessária do produto.
Implementar Conjunto de Testes: organizar ou montar coleções de testes
para serem executados juntos de uma maneira significativa.
Executar Conjunto de Testes: executar os conjuntos de testes apropriados
necessários para validar a qualidade do produto.
Analisar Falha de Teste: investigar os resultados dos testes, analisar as falhas
que ocorreram durante a implementação e execução do teste e registrar
solicitações de mudança.
17
2.1.3 Modelo de Maturidade de Teste de Software (TMM)
Os modelos de maturidade são utilizados para avaliar e melhorar a qualidade dos processos
em uma organização [Vasconcelos 2007]. Modelos como o Capability Maturity Model
Integration (CMMI) abrangem todas as fases do desenvolvimento de software, e o teste de
software aparece como uma destas fases. No entanto existem também modelos específicos
para melhoria de processo de teste de software que foram criados com a finalidade de cobrir
deficiências nas atividades de teste dos modelos genéricos [Reffson et al 2006].
O Test Maturity Model (TMM) é um modelo voltado para teste de software que avalia
atividades e métodos, além de definir papéis, responsabilidades e boas práticas. Foi criado em
1996, pelo Illinois Institute of Technology (IIT). É o modelo de maturidade de teste de
software mais conhecido e é inspirado em outro modelo também bastante conhecido, como o
CMMI [Vasconcelos 2007]. O TMM é um modelo de validação baseado em um questionário,
no qual é verificado o nível de maturidade da área de TI em relação ao teste.
A partir do TMM, foram desenvolvidos outros modelos de melhoria do Processo de
teste como o Testing Capability Maturity Model (TCMM), o Test Improvement Model (TIM),
o Test Process Improvement (TPI) e o Test Organization Maturity (TOM) [Reffson et al
2006].
O TMM possui cinco níveis de maturidade com objetivos, áreas de processo e boas
práticas. A Figura 2.5 mostra a arquitetura do TMM, onde cada nível é composto por um
conjunto de objetivos que indicam o nível de maturidade do processo de teste.
Figura 2.5 Estrutura do TMM [Burnstein 1999].
18
Nível 1 – Inicial
Neste nível, o processo é caótico e não há distinção entre as atividades de teste e
depuração. Os testes são realizados de forma ad hoc após a codificação do sistema.
Normalmente não há qualquer treinamento e o objetivo do teste é mostrar que o sistema e o
software funcionam.
Nível 2 – Gerenciado
As funções do teste e da depuração são claramente definidas. O teste é visto como uma
fase seguindo a codificação. Os processos são padronizados, contendo técnicas e métodos de
testes. O objetivo do teste, neste nível, é mostrar que o software atende às especificações.
Nível 3 – Definido
O teste está integrado no ciclo de vida do produto de software. A atividade de teste é
estabelecida formalmente na organização com treinamento, controle e monitoramento do
processo de teste. O objetivo do teste é mostrar que o software não funciona, tomando como
base os requisitos.
Nível 4 – Quantitativamente Gerenciado
A atividade de teste é um processo medido e quantificado. Os produtos de software
são testados para atributos de qualidade como usabilidade, manutenibilidade, confiabilidade e
outros. Casos de teste são coletados e registrados em uma base de dados para reuso em testes
de regressão. Os defeitos são registrados com nível de severidade atribuídos para correção de
acordo com a prioridade.
Nível 5 – Em Otimização
A atividade de teste é institucionalizada. O processo de teste é bem definido e
gerenciado. O custo e a eficiência dos testes são monitorados. Ferramentas para automação
fazem parte do processo de teste e existem procedimentos estabelecidos para seleção e
avaliação de ferramentas de teste.
A Tabela 2.2 apresenta os objetivos e principais subobjetivos para cada nível do TMM
extraídos de [Reffson et al 2006, Sartori 2005 e Veenendaal 2006].
19
Tabela 2.2 Objetivos e atividades dos níveis do TMM.
NÍVEL OBJETIVOS / SUBOBJETIVOS
1 O teste é realizado de forma ad hoc, normalmente, pela própria equipe de desenvolvimento.
1. Desenvolver metas e políticas de teste e depuração:
− Equipe de teste deve desenvolver e registrar objetivos do teste;
− Objetivos do teste devem ser refletidos nos planos de teste.
2. Iniciar um processo de planejamento de testes:
− Gerência deve definir políticas de planejamento de teste;
− Definição de template do Plano de Teste aprovado pela gerência contendo cronograma de
atividades, alocação de recursos, critérios de aceitação para todos os níveis de teste;
2
3. Institucionalizar técnicas e métodos básicos de teste:
− Definição de abordagens e estratégias de testes adotadas pela equipe. Ex. abordagem funcional,
estrutural, níveis e tipos de testes.
1. Estabelecer uma organização de teste de software:
− Estabelecer um grupo de teste amplo, da organização, com liderança, suporte, e financiamento da
gerência superior.
2. Integrar o teste no ciclo de vida do software:
− A fase de teste dever ser dividida e organizada para integrar-se ao ciclo de vida do software.
3. Controlar e monitorar o processo de teste:
− Definição e utilização de conjunto de métricas para acompanhamento do processo de teste.
3
4. Estabelecer um programa de treinamento:
− Definir um plano de treinamento;
− Estabelecer um grupo de treinamento com ferramentas, facilidades e materiais.
1. Estabelecer um programa amplo de revisão:
− Os grupos de teste e da garantia de qualidade do software devem desenvolver e documentar
objetivos, procedimentos de continuação e mecanismos de gravação para revisões.
2. Estabelecer um programa de medições de teste:
− Desenvolver plano de medição do teste com mecanismos para levantamento, análise, e aplicação
dos dados;
− Documentar planos de ação que aplicam resultados de medições às melhorias do Processo de
Teste.
4
3. Avaliação da qualidade de software:
− A gerência superior e os grupos da garantia da qualidade do teste de software devem definir
políticas, objetivos da qualidade, e atributos de qualidade para produtos de software.
1. Prevenção de defeitos:
− Dever ser definida uma equipe para prevenção de defeitos com suporte da gerência;
2. Controle de qualidade:
− Os grupos do teste e de garantia da qualidade devem estabelecer objetivos para produtos de
qualidade;
− Os gerentes de teste devem incorporar estes objetivos da qualidade em planos de teste.
5
3. Otimização do processo de teste:
− A organização deve desenvolver, documentar e apoiar procedimentos e políticas para otimização
do Processo de Teste;
2.1.4 Padrão IEEE 1012-1998 para Verificação e Validação de
Software
A verificação e validação (V&V) de software é uma disciplina da Engenharia de Software que
tem como propósito determinar se o produto desenvolvido em uma dada atividade está em
conformidade com os requisitos definidos para a mesma e, principalmente, se o software
construído satisfaz suas intenções de uso e as necessidades dos usuários.
20
O padrão IEEE 1012-1998 define o processo de verificação e validação de software
em termos de atividades específicas e tarefas relacionadas. Este padrão é uma revisão do
padrão IEEE 1012-1986 e introduz conceitos chave como níveis de integridade de software,
atividade mínima de V&V para cada nível, intensidade, rigor e critérios para as atividades de
V&V. Tem como propósito, estabelecer uma estrutura comum para processos, atividades e
tarefas de V&V, além de definir o conteúdo do plano de V&V de software.
Este padrão aplica-se a produtos de software que estão em desenvolvimento ou
sofrendo manutenções corretivas ou evolutivas. São definidas atividades de V&V não
somente para o processo de desenvolvimento, mas também para processos de gerenciamento,
aquisição, fornecimento, operação e manutenção. A Figura 2.6 apresenta a estrutura do
processo do padrão IEEE 1012-1998, em que são definidas atividades para cada processo e
um conjunto mínimo de tarefas de V&V para cada atividade.
Para este trabalho, foram estudadas as tarefas de V&V presentes nas atividades do
processo de desenvolvimento do software como gerenciamento, concepção, análise de
requisitos, projeto, codificação, integração, teste e outras.
IEEE Std 1012-1998 Processo de Verificação e Validação (V&V)
Aquisição
V&V
Fornecimento
V&V
Desenvolvimento
V&V
Operação
V&V
Manutenção
V&V
Atividade de Gerenciamento de V&V
Esta atividade é realizada durante todo o ciclo de desenvolvimento. Tem como objetivo
acompanhar, revisar e controlar continuamente o cronograma do projeto, as tarefas e os
recursos de acordo com o plano de teste. Algumas tarefas de V&V para esta atividade são:
criação do plano de verificação e validação, gerenciamento das revisões de V&V e avaliação
de mudanças na baseline.
Atividades
V&V
Atividades
V&V
Atividades
V&V
Atividades
V&V
Atividades
V&V
Atividades
V&V
Atividades
V&V
Atividades
V&V
Ativi
dades
V&V
Atividades
V&V
Atividades
V&V
Tarefas
V&V
Atividades
V&V
Tarefas
V&V
Atividades
V&V
Tarefas
V&V
Atividades
V&V
Tarefas
V&V
Atividades
V&V
Tarefas
V&V
Framework
Processo
V&V
Atividades
V&V
Tarefas
V&V
Figura 2.6 Estrutura do processo de V&V [IEEE 1012 1998].
21
Atividade de Concepção de V&V
Esta atividade representa a separação entre o problema que o usuário deseja resolver e a
implementação para solucionar este problema. Tem como objetivo verificar os requisitos do
sistema, validando a solução selecionada para resolver o problema do usuário. As tarefas
mínimas de V&V para esta atividade são: avaliação do documento de concepção; análise de
criticidade e rastreabilidade; análise de problemas e riscos.
Atividade de Requisito V&V
A atividade de requisito define os requisitos funcionais e não funcionais do software. O
objetivo desta atividade é garantir a corretude, a completude, a exatidão, a testabilidade e a
consistência dos requisitos. Algumas tarefas de V&V para esta atividade são: análise de
rastreabilidade, interfaces e criticidade; avaliação dos requisitos do software; criação e
verificação do plano de V&V de sistema; criação e verificação do plano de V&V de
aceitação.
Atividade de Projeto V&V
Nesta atividade, os requisitos do software são transformados em arquitetura e projetos
detalhados de componentes. O projeto inclui banco de dados, bem como definição de
interfaces de comunicação. O objetivo desta atividade é demonstrar que o projeto é uma
transformação correta, precisa e completa dos requisitos do software. Para isto, as seguintes
atividades de V&V precisam ser realizadas: avaliação do projeto de software; criação e
verificação do plano de V&V de componente; criação e verificação do plano de V&V de
integração; criação e verificação do projeto de teste de V&V.
Atividade de Implementação V&V
A implementação transforma o projeto dos requisitos em código, estrutura de banco de dados
e executáveis. O objetivo desta atividade é verificar e validar se as transformações para
código ocorrem de forma correta, precisa e completa. As tarefas de V&V realizadas nesta
atividade são: avaliação do código fonte e de sua documentação; criação e verificação de
casos de teste de V&V; criação e verificação de procedimentos de teste de V&V; verificação
e execução de testes de componente de V&V.
22
Atividade de Teste V&V
O objetivo desta atividade é garantir que o software construído atenda às especificações dos
requisitos através da execução de testes de integração, sistemas e aceitação. Tarefas de V&V
para esta atividade são: criação e verificação de procedimentos de teste de V&V; execução e
verificação de testes de integração de V&V; execução e verificação de testes de sistema de
V&V; execução e verificação de testes de aceitação de V&V.
Atividade de Instalação V&V
O objetivo desta atividade é assegurar a correta instalação e configuração do software no
ambiente alvo. Tarefas de V&V para esta atividade são: auditoria de configuração e
instalação; geração de relatório final de V&V.
2.1.5 Padrão IEEE 829-1998 para Documentação de Teste de
Software
O Padrão IEEE 829-1998 foi criado com o propósito de padronizar um conjunto básico de
documentos ou artefatos produzidos pelas atividades de teste de software. Esta padronização
facilita a comunicação entre clientes e fornecedores através de uma referência comum para os
documentos de teste. Também, auxilia na definição e avaliação de completude do processo de
teste. Em muitas organizações, a utilização da documentação definida neste padrão aumenta a
capacidade de gerenciamento dos testes [IEEE 829 1998].
Este padrão cobre os documentos de planejamento, especificação e relatório de testes.
O planejamento dos testes define o escopo, as abordagens, as estratégias, os recursos e o
cronograma das atividades de teste. A especificação corresponde ao projeto, identificação de
casos de teste e detalhamento dos procedimentos de teste. Os relatórios de teste definem os
itens de teste, registros de execuções, registro de incidentes e resumo dos resultados. A Tabela
2.3 apresenta o conteúdo de cada documento e seus responsáveis. A Figura 2.7 apresenta o
relacionamento entre os artefatos produzidos nas atividades de teste. Os documentos de
projeto como Plano de Projeto, Documento de Requisitos e Cronograma são essenciais para a
construção do Plano de Teste. A partir das funcionalidades a serem testadas, definidas no
Plano de Teste, o Projeto de Teste é definido com a abordagem adotada para cada caso de
teste. O documento de Especificação de Caso de Teste é opcional, e os casos de teste podem
ser diretamente detalhados no Procedimento de Teste. Após a execução, evidências do teste
devem ser registradas (Log de Teste) e, quando necessário, solicitações de mudança
(Relatório de Incidente) são abertas.
23
Tabela 2.3 Conteúdo dos documentos de teste de software [IEEE 829 1998].
DOCUMENTOS CAMPOS BÁSICOS RESPONSÁVEIS
Plano de Teste
Identificador; Introdução; Itens de teste; Funcionalidades a serem
testados; Funcionalidades não testadas; Abordagem do teste;
Critérios de liberação/falha dos itens; Requisitos de suspensão e
retomada; Entregas do teste; Tarefas do teste; Necessidades de
ambientes; Responsabilidades, Necessidades da equipe e
treinamento; Cronograma; Riscos; Aprovações;
Líder de Projeto
Especificação de
Caso de Teste
Identificador; Itens de teste; Entrada necessária e saída esperada;
Ambiente necessário; Requisitos para execução do teste;
Dependência com outros casos de teste;
Projeto de Teste Identificador; Funcionalidades a serem testadas; Abordagem
refinada; Casos de teste; Critérios de passagem e falha por
Funcionalidades.
Casos de Teste
Identificador; Itens de teste; Especificação de entrada;
Especificação de saída; Necessidades do ambiente; Requisitos ou
procedimentos especiais; Dependências entre casos de teste;
Procedimentos
de Teste
Identificador; Propósito; Requisitos especiais; Passos do
procedimento;
Relatório de
Itens de Teste
Identificador; Itens passados; Localização; Estado; Aprovações;
Líder de Projeto e
Analistas de Teste
Relatório de
Incidentes
Identificador; Sumário; Descrição do incidente; Impacto;
Severidade;
Relatório de
Resultado
de Teste
Identificador; Descrição; Entradas das atividades de evento;
Descrição da execução; Resultados; informações sobre o
ambiente; Eventos anormais (conexão com relatório de
incidentes);
Testadores
Relatório de
Sumário
dos Testes
Identificador; Sumário; Variações; Avaliação Funcional;
Sumário de resultados; Avaliação dos testes; Sumário de
atividades; Aprovações;
Equipe de Teste
24
Figura 2.7 Relacionamento entre os artefatos e atividades de teste [IEEE 829 1998].
Documento especificado por este
padrão
Documento NÃO
especificado por este padrão
Item de Teste NÃO
especificado por este
padrão
Processo NÃO especificado por
este padrão
Documento do
Projeto
Documento de
Itens
Plano de Teste
Projeto de Teste Projeto de Teste Projeto de Teste
Especificação de
Caso de Teste
Procedimento de
Teste
Relatório de Itens
de Teste
Execução de Teste
Log de Teste
Relatório de
Incidente
Relatório de
Incidente
Itens de Teste
Relatório de
Sumário do
Teste
Log de Teste
25
2.2 Riscos na Engenharia de Software
Mesmo com a adoção de novas tecnologias, modelos de processos, técnicas, métodos e
ferramentas disponíveis, a maioria dos sistemas desenvolvidos ainda apresenta atrasos no
desenvolvimento, custos acima do planejado e funcionalidades aquém das expectativas devido
a riscos inesperados, não planejados ou simplesmente ignorados [Rios 2005]. A gerência de
projetos, em especial, a gerência de riscos, procura monitorar todo o processo de
desenvolvimento do software identificando riscos, suas probabilidades de manifestação,
estimando os prejuízos e orientando quanto aos procedimentos a serem adotados.
De acordo com Guia PMBOK - Project Management Body of Knowledge [PMI
2004], um risco de projeto é um evento ou condição incerta que, se ocorrer, terá um efeito
positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou
qualidade. O objetivo da gerencia de riscos do projeto é aumentar a probabilidade e o impacto
dos eventos positivos e diminuir a probabilidade e o impacto dos eventos negativos no
projeto.
O Instituto de Engenharia de Software (SEI) define risco como a possibilidade de
sofrer perdas nos objetivos do projeto, como impactar na qualidade do produto final, atrasar
cronograma, aumentar custos ou mesmo falhar o projeto [SEI 2006].
Neste trabalho, é utilizada a definição de riscos de software fornecida pelo SEI, onde o
risco para o teste de software é a possibilidade de uma funcionalidade apresentar falhas,
quando em uso pelo usuário, resultando em um produto de software de baixa qualidade.
2.2.1 Conceitos Básicos
Antes de apresentar os conceitos básicos sobre riscos de software, vale ressaltar a diferença
entre risco e problema. Os riscos são incertezas de que um evento futuro poderá afetar de
forma negativa os objetivos do projeto, enquanto um problema é algo que existe naquele
momento e ameaça diretamente os objetivos do projeto. Ou seja, o problema é um risco já
materializado. A diferença é muito importante, pois ações para gerenciar riscos serão muito
diferentes das ações para gerenciar problemas. Como existe apenas a probabilidade de que o
risco venha a ocorrer, ações podem ser tomadas para minimizar, transferir ou até eliminá-lo,
ou seja, ações são realizadas preventivamente para que o risco não venha a se tornar um
problema.
26
Exposição ao risco
A gravidade de um risco é avaliada a partir da combinação da probabilidade ou freqüência de
ocorrência e da magnitude das conseqüências dessa ocorrência. Uma das métricas mais
conhecidas e utilizadas [Boehm 1991] para calcular a exposição ao risco é apresentada na
Equação 2.1, onde P(f) representa a probabilidade de ocorrência do risco em uma função e I(f)
o impacto desta ocorrência na função. Os valores de P e I são números definidos dentro de
uma escala.
)(*)()( fIfPfER
=
Equação 2.1 Cálculo de exposição ao risco.
A Tabela 2.4 apresenta um exemplo da matriz de probabilidade e impacto com escala
de 1 (um) a 3 (três) para a probabilidade e 1 (um) a 5 (cinco) para o impacto. Neste exemplo,
as escalas de impacto e probabilidade são diferentes, porém não há nenhuma regra para a
definição das escalas, podendo estas, inclusive, possuírem o mesmo valor.
Tabela 2.4 Matriz de impacto e probabilidade.
Alto (3) Médio (2) Baixo (1)
Muito Alto (5) Alto (ER = 15) Alto (ER =10) Médio (ER = 5)
Alto (4) Alto (ER = 12) Médio (ER = 8) Baixo (ER = 4)
Médio (3) Médio (ER = 9) Médio (ER = 6) Baixo (ER = 3)
Baixo (2) Médio (ER = 6) Baixo (ER = 4) Baixo (ER = 2)
Muito Baixo (1)
Baixo (ER = 3) Baixo (ER = 2) Baixo (ER = 1)
Classificação
Os riscos de software podem ser classificados de diversas formas. Neste trabalho, é utilizada a
classificação definida pelo SEI [Carr et al 1993], que fornece uma taxonomia para os riscos
de acordo com a sua origem:
Engenharia de Produto: problemas no produto relacionados a ações técnicas,
também conhecidos como riscos técnicos. Os riscos de produto afetam a qualidade
ou o desempenho do software que está sendo desenvolvido e são os riscos tratados
neste trabalho.
Ambiente de Desenvolvimento: problemas no processo (desenvolvimento)
produtivo do software. Estes riscos são também conhecidos como riscos de
projeto, pois afetam, dentre outros, o cronograma ou os recursos do projeto.
Probabilidade
Impacto
27
Restrições dos Programas: problemas que acontecem no projeto e no processo
devido a ações da gerência. São comumente chamados de riscos de negócio e
afetam a organização que desenvolve ou adquire o software.
A taxonomia organiza os riscos de software em classes, cada classe está subdividida
em elementos que, por sua vez, são divididos em atributos, como mostrado na Figura 2.8. Na
classe Engenharia de Produto, temos o elemento Requisitos, que contém os atributos
Estabilidade, Completude, Claridade, Validade, Viabilidade, Precedente e Escala.
Figura 2.8 Taxonomia de riscos proposta pelo SEI e adaptada por [Gusmão 2005].
Além da taxonomia, o SEI fornece um questionário baseado em taxonomia de riscos, o
Taxonomy-Based Questionnaire (TBQ) para a etapa de identificação dos riscos. O TBQ
conduz os entrevistados através da taxonomia, sugerindo áreas para discussão adicional. A
Tabela 2.5 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.
28
Tabela 2.5 Questões de “estabilidade” e “completude” para o elemento “requisito”.
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?
Estratégias para Tratamento dos Riscos
Quatro estratégias lidam, normalmente, com ameaças ou riscos com impacto negativo nos
objetivos do projeto:
Prevenir: definição de ações para eliminar o risco;
Transferir: repassa para outra parte a responsabilidade pelo gerenciamento de um
risco;
Mitigar: redução da probabilidade e/ou impacto de um risco até um limite
aceitável;
Aceitar: o plano de gerenciamento do projeto não é alterado para tratar um risco
ou não se consegue identificar uma estratégia de resposta adequada;
2.2.2 Processo de Gerência de Riscos segundo o Guia PMBOK
O Instituto de Gerência de Projeto Project Management Institute (PMI) criou em 1986 a
primeira versão do Guia PMBOK - Project Management Body of Knowledge Guide [PMI
2004], guia que descreve o conhecimento e as melhores práticas em gerenciamento de
projetos. De acordo com o Guia PMBOK, o conhecimento necessário para gerenciar projetos
está dividido em nove áreas: Gerência de Integração, Gerência de Escopo, Gerência de
Tempo, Gerência de Custo, Gerência de Qualidade, Gerência de Recursos Humanos, Gerência
de Comunicação, Gerência de Riscos e Gerência de Aquisições.
A gerência de riscos do projeto inclui os processos referentes ao planejamento da
gerência de riscos, à identificação, à análise, ao planejamento das respostas e ao controle e à
monitoração dos riscos em um projeto. Esses processos interagem entre si e com os processos
das outras áreas de conhecimento da gerência de projetos.
Planejar a Gerência de Risco
Consiste no planejamento e execução das atividades da gerência de riscos a serem realizadas
no projeto.
29
Identificação de Riscos
Identifica e documenta os riscos que podem afetar, de alguma forma, o sucesso do projeto.
Técnicas como reuniões de brainstorm, entrevistas, listas de verificação, questionários são
comumente utilizadas nesta fase.
Análise Qualitativa de Riscos
Nesta fase, os riscos identificados são priorizados através da combinação de sua probabilidade
de ocorrência e impacto.
Análise Quantitativa de Riscos
Consiste na análise numérica do efeito dos riscos identificados nos objetivos gerais do
projeto. Técnicas mais avançadas como estatística, simulação e outras são utilizadas para a
priorização nesta análise.
Planejamento de Respostas a Riscos
Desenvolvem-se ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do
projeto.
Monitoramento e Controle de Riscos
Os riscos identificados são acompanhados e há o monitoramento dos riscos residuais e
identificação de novos riscos, execução de planos de respostas a riscos e avaliação da sua
eficácia durante todo o ciclo de vida do projeto.
2.2.3 Processo de Gerência de Riscos segundo o Processo Unificado
da Rational (RUP)
Como descrito na Seção 2.1.2, o RUP é um processo da Engenharia de Software baseado em
melhores práticas de desenvolvimento e em princípios fundamentais, dentre os quais ser
direcionado a riscos. De acordo com o processo, é essencial identificar e combater os itens de
risco mais alto no início do projeto. Juntamente com cada risco, deve haver um plano para
tratamento, que é entrada para o planejamento das atividades do projeto e das iterações.
O foco das fases do RUP com relação aos riscos de software é:
Concepção: foco no tratamento dos riscos relacionados a restrições dos
programas, também conhecidos como riscos de negócio.
30
Elaboração: foco principalmente nos riscos técnicos, examinando os riscos de
arquitetura e, se necessário, revisando-se o escopo do projeto à medida que seus
requisitos tornam-se mais bem compreendidos.
Construção: foco nos riscos técnicos associados ao desenvolvimento e ao teste,
que podem impedir a conclusão do desenvolvimento do produto de software.
Transição: foco nos riscos associados com a logística de entrega do produto ao
usuário.
O Gerente de Projeto é responsável pela execução das atividades: Desenvolver o Plano
de Gerenciamento de Riscos e Identificar e Avaliar Riscos, que têm como entrada ou saída os
artefatos: Documento de Visão, Plano de Gerenciamento de Riscos e Lista de Riscos.
Identificar e Avaliar Riscos
O Gerente identifica, analisa e prioriza os possíveis riscos. Identifica estratégias de prevenção,
diminuição e contingência e reavalia os riscos durante e ao final de cada iteração.
Desenvolver o Plano de Gerenciamento de Riscos
O Gerente define procedimentos e ferramentas para gerenciamento de riscos, cria lista inicial
de riscos, define equipe de gerenciamento de riscos, define estratégias para gerenciar os dez
maiores riscos e define a programação para elaboração de relatórios e revisões de riscos.
2.2.4 Atividades da Área de Processo do Gerenciamento de Riscos do
Modelo CMMI
O modelo Capability Maturity Model Integration (CMMI) foi criado em agosto de 2000 para
integrar os diversos modelos do CMM que atendem às várias atividades relacionadas ao
desenvolvimento de software [CMMI 2006]. O CMMI tem como objetivo guiar a avaliação
de melhorias nos processos das organizações e contém duas formas de representação:
Representação Contínua: possibilita à organização utilizar a ordem de melhoria
que melhor atende aos objetivos de negócio da empresa. É caracterizado pelos
níveis de capacidade: incompleto, executado, gerenciado, definido,
quantitativamente gerenciado e em otimização.
Representação por Estágios: disponibiliza uma seqüência pré-determinada para
melhoria baseada em estágios, onde cada estágio serve de base para o próximo. É
caracterizado pelos níveis de maturidade: inicial, gerenciado, definido,
quantitativamente gerenciado e em otimização.
31
Cada nível é constituído por um conjunto de áreas de processos, compostas por
objetivos específicos e objetivos genéricos. Cada objetivo específico (SG) pode ser composto
por um conjunto de práticas específicas (SP) como mostrado na Tabela 2.6.
Tabela 2.6 Objetivos e práticas da área de processo de gerenciamento de riscos.
SG1 Preparar-se para a Gerência de Riscos
SP 1.1 Determinar Fontes e Categorias de Riscos
SP 1.2 Definir Parâmetros de Riscos
SP 1.3 Estabelecer uma Estratégia para a Gerência de Riscos
SG2 Identificar e Analisar Riscos
SP 2.1 Identificar Riscos
SP 2.2 Avaliar, Categorizar e Priorizar Riscos
SG3 Mitigar Riscos
SP 3.1 Desenvolver Planos de Mitigação de Riscos
SP 3.2 Implementar Planos de Mitigação de Riscos
O gerenciamento de riscos em projetos é tratado inicialmente pelo CMMI no segundo
nível de maturidade pelas SGs Desenvolvimento do Plano do Projeto e Monitorar o Projeto de
Acordo com o Plano. Esta atuação, entretanto, é feita de uma forma reativa, ou seja, com foco
apenas na identificação dos riscos para conscientização e reação à medida que eles ocorram.
O gerenciamento de riscos é efetivamente tratado no terceiro nível de maturidade
através da área de processo de Gerenciamento de Riscos. Esta área de processo atua de uma
forma proativa no sentido de minimizar os impactos dos riscos nos objetivos do projeto.
A seguir, é fornecida uma breve descrição para as práticas específicas da área de
processo de gerenciamento de riscos apresentadas na Tabela 2.6.
Determinar Fontes e Categorias de Riscos
A identificação prematura das fontes de riscos internas ou externas possibilita a identificação
prematura dos riscos. Estabelecer categorias para os riscos provê um mecanismo para coletar
e organizar os riscos e gerenciar as atenções para aqueles riscos que podem ter conseqüências
mais sérias.
Definir Parâmetros de Riscos
Os parâmetros são usados para analisar e categorizar os riscos e para controlar a tarefa de
gerência de riscos. Eles Servem para avaliar e quantificar a probabilidade dos riscos e os
níveis de severidade dos mesmos.
32
Estabelecer uma Estratégia para a Gerência de Riscos
Fazem parte da estratégia, a definição do escopo para gerência de riscos, os métodos e
ferramentas que serão utilizados, as fontes e categorias de riscos, parâmetros e técnicas de
mitigação.
Identificar Riscos
Os riscos identificados são documentados, incluindo o contexto, condições e conseqüências
de sua ocorrência.
Avaliar, Categorizar e Priorizar Riscos
Cada risco é avaliado e recebe valores de acordo com os parâmetros de risco, que incluem
probabilidade, severidade ou impacto e limites. Para o tratamento, é interessante agrupar os
riscos em níveis ou categorias.
Desenvolver Planos de Mitigação de Riscos
Inclui técnicas e métodos usados para evitar, reduzir e controlar a probabilidade de ocorrência
do risco e a contingência caso o risco ocorra.
Implementar Planos de Mitigação de Riscos
Planos de mitigação de riscos são desenvolvidos e implementados quando necessário para
reduzir os riscos antes que eles se tornem problemas.
2.2.5 Atividades da Gerência de Riscos do Instituto de Engenharia de
Software (SEI)
A gerência de riscos, de acordo com o SEI - Software Engineering Institute, é uma prática
com processos, métodos e ferramentas para gerenciar riscos em um projeto [SEI 2006]. Ela
fornece um ambiente disciplinado para a tomada de decisão, a fim de avaliar continuamente o
que pode dar errado (os riscos), determinar quais riscos são importantes de tratar e
implementar estratégias para tratamentos dos riscos identificados.
O paradigma de riscos definido pelo SEI [SEI 2006] apresentado na Figura 2.9 mostra
as diferentes atividades que compõem a gerência de riscos. A definição é apresentada na
forma de um círculo para enfatizar que o processo é contínuo. A comunicação está localizada
ao centro porque as informações precisam fluir entre as atividades e porque a comunicação é,
normalmente, um grande obstáculo para a gerência de riscos. O framework define seis
33
atividades, estruturadas da forma que melhor se encaixam na gerência de projeto. A seguir, é
apresentado um breve resumo das atividades do paradigma de gerência de riscos:
Identificar
Localiza os riscos antes que estes se tornem problemas. Para a identificação de riscos, o SEI
propõe o questionário baseado em taxonomia de riscos [Carr et al 1993] apresentado na Seção
2.2.1.
Analisar
Transforma os dados dos riscos em informação para tomada de decisão. Avalia o impacto, a
probabilidade, classifica os riscos e os prioriza.
Planejar
Traduz as informações dos riscos em decisões e ações para o presente e futuro e implementa
estas ações. Formas de tratamento para os riscos foram apresentadas na Seção 2.2.1.
Acompanhar
Monitora os indicadores de riscos e ações de mitigação. Métricas apropriadas de riscos são
utilizadas para monitoramento e controle.
Controlar
Corrige desvios dos planos de mitigação de riscos.
IDENTIFICAR
ANALISAR
PLANEJAR
RASTREA
R
CONTROLAR
COMUNICAR
Figura 2.9 Paradigma da gerência de riscos [SEI 2006].
34
Comunicar
Provê informações internas e externas do projeto nas atividades de riscos. A comunicação
acontece entre todas as atividades da gerência de riscos.
2.3 Resumo do Capítulo
Nos dias atuais, práticas de teste e gerência de riscos estão sendo bastante demandadas pelas
organizações com o propósito de produzirem software com qualidade e com o menor esforço
possível. O teste de software assegura que os requisitos corretos foram implementados,
enquanto que a gerência de riscos possibilita o conhecimento e tratamento dos fatores de
riscos antes que esses se tornem problemas e impactem nos objetivos do projeto.
Este Capítulo apresentou um resumo dos conceitos, características, modelos e
processos da área de testes e riscos de software. Ele é fundamental para o entendimento dos
conceitos, atividades, práticas e papéis do RBTProcess, que foi concebido a partir das
informações apresentadas. Os modelos de teste e riscos de software, bem como os processos
apresentados neste Capítulo são completos, bem definidos, largamente conhecidos e
utilizados na indústria e academia. Além de serem referências para a construção de outros
modelos e processos.
35
3
Teste de Software baseado em Riscos
O consultor James Bach é considerado o pai da abordagem de teste baseado em riscos
[Goldsmith 2006]. Ele descreveu a idéia em seu artigo intitulado: The Challenge of Good
Enough Software em outubro de 1995 na revista American Programmer [Bach 1995].
O teste baseado em risco consiste em um 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 teste, por sua vez, são projetados com base nas estratégias para
tratamento dos fatores de riscos identificados. O controle da execução dos testes permite uma
mitigação dos fatores de riscos associados. A avaliação e o controle desses fatores de riscos
não são atividades triviais e requerem bastante experiência e conhecimento do negócio [Bach
2003]. Vale ressaltar que os riscos tratados nesta abordagem são os riscos relacionados à
engenharia de produto ou riscos técnicos, que podem ser mitigados através do teste de
software.
Focar em teste baseado em risco significa fazer julgamento sobre cobertura de teste;
seleção do número de testes a ser conduzido; escolhas dos tipos de testes e de revisões; o uso
e balanceamento entre teste dinâmico e análise estática, dentre outros problemas [Redmill
2004].
A abordagem RBT é utilizada, mais fortemente, no planejamento e na estratégia de
execução dos casos de teste [Bach 2003]. Seu uso, entretanto, é recomendado também na de
fase construção ou projeto dos casos de teste, como forma de otimizar o processo de teste,
projetando casos de teste apenas para os requisitos prioritários.
Capítulo
36
Bach (1999) divide a abordagem RBT em três etapas, conforme mostra a Tabela 3.1.
Essas são as etapas essenciais da abordagem RBT, onde os riscos técnicos associados aos
requisitos de software são identificados, analisados e controlados.
Tabela 3.1 Etapas do teste baseado em riscos [Bach 1999].
1. Elaboração de lista de
riscos priorizada
Esta etapa consiste na identificação e análise dos riscos técnicos associados aos
requisitos do software.
2. Realização de testes
que exploram cada
risco
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
metodologia para a atividade de criação dos casos de teste. No entanto, para a
execução, diversas estratégias foram encontradas e vão desde listas de execução
ordenadas por exposição ao risco [Chen 2002] a listas ordenadas por tempo de
execução de cada caso de teste [Schaefer 2002].
3. Acompanhamento e
controle dos riscos
Assim que um risco for eliminado, um novo risco surge e os esforços de teste
devem ser ajustados para que foquem sempre nos riscos mais importantes.
3.1 Atividades
A Figura 3.1 apresenta o modelo de atividades do processo de gerência de riscos definido por
Karolak e alterado por Amland [Amland 1999] para incluir elementos relevantes aos testes
baseado em risco dentro de um processo de teste. As caixas ovais representam as alterações
realizadas por Amland e são artefatos produzidos ou atividades realizadas a partir das
atividades (retângulos) do processo de gerenciamento 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.
Figura 3.1 Atividades relevantes para RBT [Amland 1999].
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
Identificação
dos Riscos
Estratégia
dos Riscos
Avaliação
dos Riscos
Mitigação
dos Riscos
Comunicação
dos Riscos
Previsão dos
Riscos
Plano de
Testes
Matriz: Custo e
Probabilidade
Inspeção e
Execução dos
Testes
Métricas
de Testes
Árvore de
itens de testes
37
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 através da descoberta de workarounds 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.
3.2 Principais Abordagens
Nesta seção, são apresentadas a principais abordagens RBT disponíveis na literatura,
esboçando suas características, pontos fortes e oportunidades de melhoria.
3.2.1 Abordagem baseada em Heurística
Bach define duas abordagens distintas, 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 [Bach 1999]. Para cada
risco, é identificado se este se aplica ou não a um determinado componente.
Bach sugere três tipos de listas para auxiliar a identificação dos riscos:
Lista de categorias de critérios de qualidade: são categorias desenvolvidas para
atenderem a diferentes tipos de requisitos. A lista é apresentada na Tabela 3.2 e foi
desenvolvida a partir dos critérios do padrão ISO 9126 e FURPS
1
.
Tabela 3.2 Lista de categorias de critérios de qualidade [Bach 1999].
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?
Performance Quão rápido é o tempo de resposta da funcionalidade?
Instalabilidade Quão fácil é a instalação do software?
Compatibilidade Quão bem a funcionalidade trabalha com componentes externos e outras configurações?
Suportabilidade Quão econômica é a funcionalidade para fornecer suporte ao usuário?
Testabilidade Como o produto pode ser testado efetivamente?
Manutenibilidade Quão econômicas são as manutenções corretivas e evolutivas?
Portabilidade Quão econômica é a portabilidade para outra plataforma?
Localizabilidade Quão econômica é a disponibilização da funcionalidade em outra língua?
Listas genéricas de riscos: são aquelas que possuem riscos universais a qualquer
sistema. São apresentadas na Tabela 3.3.
38
Tabela 3.3 Lista genérica de riscos [Bach 1999].
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.
Dependência em
componente superior:
Qualquer coisa cuja falha causaria um efeito cascata de falhas no resto do
sistema.
Dependente de componente
inferior
Qualquer coisa que seja extremamente dependente de falhas no resto do sistema.
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.
Estratégico Qualquer coisa que tenha especial importância para o seu negócio, como uma
característica que lhe distingue da competição.
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.
Defeituoso Qualquer coisa que conhecidamente tenha problemas.
Falhou recentemente Qualquer coisa com uma história recente de falha.
Os catálogos de risco: São listas de riscos que pertencem a um domínio em
particular. A Tabela 3.4 apresenta uma versão resumida do que seria um catálogo
de riscos para um instalador.
Tabela 3.4 Catálogo de riscos para um instalador [Bach 1999]
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.
Após a identificação dos riscos utilizando uma das abordagens explicadas
anteriormente. A estes, são atribuídos valores em uma escala de interesse, e os riscos com
maior valor são testados prioritariamente. O autor também sugere formas de organização dos
riscos para facilitar o acompanhamento e controle dos mesmos.
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 de a
análise ter sido realizada de forma errada e, conseqüentemente, os “verdadeiros” riscos não
terem sido atacados da forma correta.
39
3.2.2 Abordagem baseada em Métricas
Amland desenvolveu um conjunto de métricas para a análise de risco com o objetivo de
subsidiar um processo de teste [Amland 1999]. Essas métricas foram aplicadas em estudo de
caso de uma aplicação de instituição financeira. O modelo para o cálculo da exposição ao
risco é baseado na probabilidade de uma falha ocorrer e no custo dessa falha na função
correspondente, tanto para o provedor do serviço quanto para o cliente.
Na sua metodologia, existem três fontes de análise de risco:
Qualidade da função (área) a ser testada. O autor propõe uma função, na qual são
levados em consideração aspectos como qualidade do produto de software,
esperiência dos desenvolvedores e complexidade, tamanho e maturidade das
funcionalidades. Segundo o autor, funcionalidades complexas, de má qualidade
e/ou desenvolvidas por programadores inexperientes estão mais expostas a falhas
que funções baseadas em projeto de melhor qualidade e que foram desenvolvidas
por programadores mais experientes. Essa função corresponde à probabilidade
P(f), que pode assumir valores entre 0 e 1.
As conseqüências de uma falha ponto de vista de um cliente, em uma situação de
produção podem ser representadas, dentre outras, pela probabilidade de ameaça
legal, perda de posicionamento no mercado e pelo não cumprimento de
regulamentações governamentais. Estas conseqüências representam o custo de uma
falha para o consumidor C(c).
As conseqüências de uma falha do ponto de vista do vendedor do serviço estão
relacionadas, dentre outras, à probabilidade de publicidade negativa, altos custos
de manutenção de software e perda de clientes. Estas conseqüências representam o
custo de uma falha para o vendedor C(v).
Para o autor, o custo para o consumidor é igualmente importante na análise dos riscos
em relação ao custo do vendedor. A exposição de risco é dada pela função:
2
)()(
*)()Re(
vCcC
fPf
+
=
Equação 3.1 Cálculo para exposição do risco.
Tendo em vista o grau de exposição ao risco, as áreas com risco mais alto têm maior
prioridade nos testes e, durante a execução dos testes, à medida que falhas vão aparecendo,
40
novas prioridades podem ser adicionadas ao projeto. Também, o grau de exposição ao risco
vai sendo atualizado para cada funcionalidade e a prioridade do teste pode ser modificada.
Um exemplo de grau de exposição ao risco calculado para a função Fechar Contas é
mostrado na Tabela 3.5. O grau de exposição ao risco foi calculado para todas as funções e a
lista foi ordenada para identificar quais áreas deveriam ser focadas durante o teste. A
probabilidade é calculada como a média ponderada de uma função em particular dividida pela
maior média ponderada de todas as funções, resultando em uma probabilidade na faixa entre 0
e 1.
Tabela 3.5 Exposição ao risco calculado para a função “fechar contas” [Amland 1999].
CUSTO PROBABILIDADE
Função C(v) C(c) Média
Nova
Função
(5)
Projeto/
Qualidade
(5)
Tamanho
(1)
Comple-
xidade
(3)
Média
Ponde-
rada
Proba-
bilidade
Expo-
sição
ao
Risco
Fechar
Conta
1 3 2 2 2 2 3 7,75 0,74 1,48
Além das métricas para o cálculo de exposição ao risco, Amland utiliza, em seu estudo
de caso, métricas para acompanhamento do progresso dos testes. Alguns exemplos são:
número de casos de testes planejados e executados, número de defeitos por funções, número
de horas gastas em teste por defeito encontrado e número de horas gastas para correção de
defeitos.
A abordagem utilizada por Amland realiza as atividades apresentadas na Figura 3.1 e
está dividida em seis passos apresentados a seguir:
1. Identificação e Estratégia dos Riscos
o Passo 1: Planejamento: faz parte de toda atividade de teste realizar o
planejamento, definindo as funcionalidades que serão testadas, ambiente de
teste, padrões de documentação, execução e registro. A estratégia de riscos
também é definida nesse passo.
2. Avaliação dos riscos
o Passo 2: Identificar os indicadores de riscos: os indicadores são
definidos juntamente com o grupo do projeto. É importante que os
indicadores façam sentido para o sistema e que todos tenham o mesmo
41
entendimento. Foram utilizados como indicadores, dentre outros, o número
de defeitos, número de linhas de código, número de mudanças desde a
última versão e complexidade da função.
o Passo 3: Identificar o custo de um defeito: assim como no passo 2,
indicadores são definidos para o custo de um defeito, tanto para o usuário
(cliente), quanto para o desenvolvedor (vendedor) do produto de software.
o Passo 4: Identificar elementos críticos: calcular a exposição do risco de
cada funcionalidade utilizando os valores obtidos nos passos 2 e 3.
3. Mitigação dos Riscos
Passo 5: Execução dos testes: uma vez concluída a análise do riscos, os testes
seguem a ordem de execução da lista de priorização. Deve-se acompanhar não
somente a ordem de execução, mas também a depedência entre os casos de
testes e realizar as adaptações necessárias.
4. Comunicação e Previsão dos Riscos
o Passo 6: Estimar o tempo para completar: utilizar as métricas de
progresso dos testes para reportar a situação atual dos testes e prever o
tempo necessário para completá-los.
A abordagem 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
para o cliente. Um dos maiores problemas relatados por Amland foi 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, porém o tempo gasto para concluir os testes e o número
de recursos utilizados foi menor.
O grande desafio da definição da abordagem, segundo Amland, foi a identificação dos
indicadores de custo de falha e de qualidade. Foi utilizada uma abordagem simples, mas,
segundo o autor, satisfatória. Assim, como na maioria das abordagens, o autor mantém foco
somente na atividade de análise dos riscos, não fornecendo subsídios para a identificação dos
riscos associados aos requisitos, fundamental para a criação dos casos de teste baseado em
riscos.
42
3.2.3 Abordagem baseada em Código-fonte Orientado a Objetos
[Rosenberg et al 1999] fornecem uma metodologia 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. Segundo os autores foi comprovado que o código mais complexo tem
uma maior incidência de erros ou problemas. Seis métricas de medição de projetos orientadas
a objeto são utilizadas, identificadas e aplicadas pelo Software Assurance Technology Center
(SATC) da Goddard Space Flight Center na NASA. São elas:
Número de Métodos ou Number of Methods (NOM): é uma contagem dos
diferentes métodos existentes em uma classe.
Número Ponderado de Métodos Por Classe ou The Weighted Methods per Class
(WMC): é uma soma ponderada dos métodos em uma classe. Se os pesos forem
iguais, equivale à métrica anterior.
Acoplamento entre objetos ou Coupling Between Objects (CBO): é uma
contagem do número de outras classes nas quais uma classe está acoplada.
A resposta a uma classe ou The Response for a Class (RFC): é a cardinalidade do
conjunto de todos os métodos que podem ser invocados em resposta à uma
mensagem para um objeto da classe.
Profundidade na árvore ou Depth in Tree (DIT): a profundidade de uma classe,
de acordo com a hierarquia, é o número de saltos saindo de uma classe até a raiz da
hierarquia de classes. É medida pelo número de ancestrais na classe. Quando existe
herança múltipla, a maior DIT é utilizada.
Número de filhos ou Number of Children (NOC): o número de filhos é o número
de subclasses que herdam diretamente da classe na hierarquia.
Por mais de três anos, o SATC coletou e analisou código orientado a objetos escritos
em C++ e em Java. Mais de 20.000 classes de mais de 15 programas foram analisadas. Os
valores limites para as métricas individuais, apresentados na Tabela 3.6, foram derivados do
estudo da distribuição das métricas coletadas.
Tabela 3.6 Valores limites para métricas individuais.
MÉTRICA VALOR LIMITE
NOM Preferencialmente menor que 20 e aceitável até 40
WMC Preferencialmente menor que 25 e aceitável até 40
CBO Aceitável até 5
RFC Aceitável até 50
DIT Aceitável até 5
NOC Não há consenso, mas, quanto maior, mais alta é a probabilidade de erro
43
Segundo os autores, uma métrica nunca deveria ser utilizada sozinha. Para avaliar os
riscos do código, são necessárias, pelo menos, duas ou três métricas para termos indicação de
um problema em potencial. O alto risco é identificado para classes que tem, ao menos, duas
métricas que excedem os limites recomendados.
A Tabela 3.7 é um exemplo de métricas de um projeto Java. As células em vermelho
representam métricas fora do limite aceitável.
Tabela 3.7 Métricas coletadas de um projeto Java.
CLASSE NO. MÉTODOS CBO RFC RFC/NOM WMC DIT NOC
1 54 8 536 9.9 175 1 0
2 7 6 168 24 71 4 0
3 33 4 240 7.2 105 2 0
7 54 8 361 6.7 117 2 2
8 62 6 378 6.1 163 2 0
10 63 7 235 3.7 156 2 0
11 81 10 285 3.5 161 2 0
12 42 5 127 3 69 3 0
14 20 17 324 16.2 139 4 4
18 46 5 186 4 238 1 3
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.
3.2.4 Abordagem para Teste de Regressão
Chen, em sua dissertação de mestrado [Chen 2002], define uma estratégia para execução de
testes de regressão baseada em especificação. A justificativa principal da autora é que teste de
regressão baseado em código é bom para teste de unidade, mas tem problemas de
escalabilidade, pois à medida que o tamanho do software cresce, torna-se difícil gerenciar a
informação do teste e criar matrizes de rastreabilidade. A autora define dois conjuntos de
testes de regressão:
Testes de regressão para os componentes que foram alterados: pelo menos um
teste é executado para cada componente inserido ou alterado.
Testes de regressão baseado 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.
Esta abordagem projeta casos de teste que focam nas áreas do software que possuem
maior risco. Como conseqüência, pode nos auxiliar a atingir um nível de confiabilidade
44
adequado na qualidade do software. Essa metodologia utiliza o modelo de risco desenvolvido
por Amland [Amland 1999] e apresentado na Seção 3.2.2.
A fase de seleção de casos de teste envolve os seguintes passos:
Passo 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.
Passo 2: derivar a severidade para cada caso de teste. Esse valor é computado a
partir do número de defeitos e da severidade destes defeitos.
Passo 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.
Passo 4: selecionar os casos de teste que têm os maiores valores de exposição ao
risco.
A seleção de cenários baseado em riscos deve obedecer duas regras:
Regra 1: selecionar os cenários para cobrir os casos de teste mais críticos
Regra 2: garantir que os cenários cubram tantos casos de teste quanto possível
A seleção de cenários baseado em riscos tem os seguintes passos:
Passo 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.
Passo 2: selecionar os cenários com maior exposição ao risco
Passo 3: atualizar a matriz de rastreabilidade, removendo os cenários selecionados
e os testes já cobertos e recalculando a exposição ao risco.
Passo 4: repetir os passos 1, 2 e 3 o quanto necessário
A abordagem se mostrou bastante eficiente de acordo com os resultados apresentados
pela autora. 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. Segundo a autora, com a ajuda de ferramentas, todo o processo foi realizado de
forma rápida. Como a abordagem toma como base, a documentação do sistema, esta, por sua
vez, deve encontrar-se sempre atualizada.
3.2.5 Abordagem baseada em Uso
Besson define uma estratégia baseada em uso, segundo a qual, qualquer atividade de teste
implica em uma diminuição dos riscos [Besson 2004]. De acordo com o autor, independente
45
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.
Na sua abordagem, o autor controla os esforços de teste baseado na 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. Seguindo o que diz a teoria de
Pareto, o autor sugere testar apenas as funcionalidades que estão incluídas nestes 20%,
aumentando assim a qualidade e reduzindo drasticamente o esforço e o custo do teste de
software.
A Figura 3.2 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.
Figura 3.2 Esforço necessário para reduzir em 50% os riscos.
A metodologia proposta por Besson é dividida em cinco passos:
Passo 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, experts 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.
Passo 2: projetar casos de testes para cada funcionalidade listada no Passo 1.
46
Passo 3: estimar tamanho (em hora ou minutos) do esforço necessário para
executar os casos de testes identificados.
Passo 4: ordenar os casos de testes em ordem ascendente de acordo com o esforço,
dessa forma, os casos de testes com menor esforço são executados primeiro.
Passo 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 o autor sugere a execução de
testes baseada em esforço, os testes que gastam menos tempo são executados primeiro até que
o tempo acabe. Essa abordagem pode ser útil em culturas organizacionais avessas ao teste,
visto que se testa somente 20% das funcionalidades disponíveis no software.
3.2.6 Abordagem baseada em Modelos
[Stallbaum et al 2008] desenvolveram uma técnica automática para priorização de casos de
testes a partir de análise de riscos e geração de casos de testes de sistema a partir de diagramas
de estados como modelos de testes.
A abordagem proposta, denominada Risk-based test case Derivation And
Prioritization (RiteDAP), acrescenta informações sobre risco a cada transição do diagrama de
estado através da definição de valores de probabilidade e impacto, permitindo que um
conjunto de casos de teste priorizado seja extraído do modelo.
A Figura 3.3 apresenta um modelo de teste (diagrama de estados) com informação
sobre risco determinada pela função R (P, D) = P*D, onde P é a probabilidade de uma
entidade conter um defeito e D o dano causado por este defeito. Vale salientar que a
abordagem gera cenários de casos de teste, ou seja, não são fornecidos procedimentos de
teste, bem como os dados de entrada e saída.
Para derivar a ordem de execução dos casos de testes, são somadas as informações de
riscos (R) de cada transição que compõe o caso de teste. A Tabela 3.8 apresenta alguns casos
de teste que podem ser derivados do modelo apresentado na Figura 3.3. Os casos de teste são
executados na seguinte ordem: S4, S2, S6, S7, S3, S5, S1. Esta ordem é chamada de Total
Risk Score Prioritization (TRSP).
47
Figura 3.3 Amostra de um modelo de teste com informações de riscos.
Outra forma de execução seria levar em consideração os riscos já cobertos pelos casos
de testes anteriores, chamada de Additional Risk Score Prioritization (ARSP), ou seja, não são
incluídos em um caminho, os cenários que já foram testados em outro caminho. Por exemplo,
na Tabela 3.8, o caminho “abghklmntlmn” poderia se possível, ser removido de S7, uma vez
que este caminho já está sendo coberto em S2. Desta forma, são testados apenas os cenários
com riscos que não foram ainda cobertos.
Tabela 3.8 Possíveis casos de teste e risco associado.
CASO DE TESTE CAMINHO
Σ
ΣΣ
Σ (R)
S1 abghklmnopef 17
S2 abghklmntlmnopqrsf 41
S3 abghijpef 27
S4 abghijpqrsf 45
S5 abcdef 19
S6 abcdqrsf 38
S7 abghklmntlmntlmnopef 29
Para validação da abordagem, os autores usaram o diagrama de máquina de estados
para calcular taxas de impostos na Alemanha. A base da validação é a hipótese de que, com a
priorização dos riscos, a abordagem deve encontrar os defeitos mais cedo. Para a comparação,
48
além das duas técnicas de priorização propostas pelos autores (TRSP e ARSP), a priorização
randômica (RP) e a priorização ótima (OP) foram utilizadas. RP é alcançada quando todos os
casos de teste são escolhidos randomicamente a partir de um conjunto de casos de teste
gerados inicialmente. A OP é alcançada quando todas as faltas são descobertas pelo conjunto
de casos de teste gerados inicialmente. Na OP, inspeções manuais também foram realizadas
para descobrir faltas.
No total, oitenta casos de testes foram executados. TRSP encontrou todos os defeitos
nos primeiros oito casos de teste. ARSP teve um resultado melhor encontrando todos os
defeitos nos quatro primeiros casos de testes.
3.3 Análise Comparativa
Após o estudo das diversas abordagens, apresentadas nas Seções 3.2.1 a 3.2.6, foi possível
realizar um estudo analítico, mostrado na Tabela 3.9. Com exceção da abordagem proposta
por [Rosenberg et al 1999], todas as outras utilizam a abordagem funcional ou caixa-preta
para construção dos casos de teste, no nível de sistema.
Bach propõe diferentes heurísticas para identificar, analisar e controlar riscos durante
o processo de teste com o propósito de melhorar a qualidade do produto, focando nas partes
do software que precisam ser mais bem testadas. No entanto, o autor não fornece nenhuma
indicação de como os casos de teste são gerados.
Amland propõe métricas para a análise dos riscos com o propósito de reduzir custos da
fase de teste do projeto de desenvolvimento de software e reduzir futuros custos de produção
pela otimização do processo de teste. As métricas propostas pelo autor levam em
consideração que funcionalidades complexas, novas, construídas com pouca qualidade e com
tamanho grande possuem probabilidade maior de apresentar falhas. O autor, também, não
fornece nenhuma orientação sobre a criação dos casos de teste.
Para Chen, o crescimento contínuo das suítes de teste e a evolução das funcionalidades
de um produto de software tornam inviável ou extremamente custosa a execução de um teste
de regressão completo. Por este motivo, uma abordagem baseada em riscos reduz o volume de
teste de regressão a ser executado, possibilitando que as áreas mais críticas sejam testadas
prioritariamente. A autora não realiza a atividade de identificação de riscos e assume que os
casos de teste já estão prontos. Dependendo da quantidade de casos de teste, esta abordagem
pode ser inviável, uma vez que a análise de riscos é feita a partir dos casos de teste e não a
49
partir dos requisitos, como acontece nas demais abordagens, visto que um requisito pode ter n
casos de teste associados.
Rosenberg e demais autores fornecem uma abordagem para identificação de classes
que estejam mais propensas a falhas, através da aplicação de métricas de complexidade de
software orientado a objetos. A análise pode ser realizada de forma automática. Os autores,
contudo, 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.
A abordagem apresentada por Besson utiliza a informação de percentual de uso da
funcionalidade para priorização. Isto a torna fácil de ser utilizada, porém não garante que as
funcionalidades que estão sendo tratadas estejam mais propensas a apresentar falhas ou
precisam ser mais bem testadas.
Stallbaum e demais autores desenvolveram uma técnica automática para priorização e
geração de casos de teste, utilizando diagramas de estados como modelos de testes. A análise
de risco é bastante subjetiva, levando em consideração apenas a probabilidade de ocorrência e
o dano. Dependendo do tamanho dos modelos e do número de funcionalidade do software, a
análise de cada transição do diagrama pode levar muito tempo ou mesmo tornar-se inviável.
A Tabela 3.9 apresenta uma análise comparativa das principais abordagens
apresentadas com o modelo de processo proposto neste trabalho. Para a comparação foram
elencadas atividades da gerência de riscos de software, que são úteis para o teste de software e
atividades mínimas de teste de software existentes em qualquer processo. O RBTProcess está
incluído na Tabela 3.9 apenas para efeito de comparação, uma vez este será explicado no
Capítulo 4.
50
Tabela 3.9 Análise comparativa das principais abordagens RBT.
ABORDAGEM/
PROCESSO
IDENTIFICAR
RISCOS
ANALISAR RISCOS
PLANEJAR
TESTES
PROJETAR
TESTES
EXECUTAR
TESTES
AVALIAR TESTES
CONTROLAR
RISCOS
Baseada em
Heurística
Listas de
critérios de
qualidade,
genéricas e
catálogo de
riscos
Equação de
Barry Boehm
v
Matriz de
rastreabilidade
v
Baseada em
Métricas
Métricas
específicas
para Teste de
Software
Ordem de
exposição ao
risco
Fornece
um
conjunto
de
métricas
para
controle
de
progresso
dos testes
Baseada em
Uso
Utiliza a
informação de
percentual de
uso
Percentual de
uso da
funcionalidade
e tempo de
execução do
caso de teste
v
Testes de
Regressão
Métrica
proposta por
Amland
v
Leva em
consideração
que os casos
de teste estão
prontos
Ordem de
exposição ao
risco
v
Código
Fonte
Orientado a
Objetos
Métrica para
código fonte
OO
Baseada em
Modelo
Análise de
probabilidade
e dano
Deriva testes
a partir do
modelo
Ordem de
exposição ao
risco
v
RBTProcess
Questionário,
listas e
reunião de
brainstorm
Métrica
proposta por
Amland com
adaptações
Planeja as
iterações
de acordo
com a
exposição
ao risco
Indica tipos
de casos de
teste de
acordo com a
exposição ao
risco
Ordem de
exposição ao
risco
Inclui
atividade
de
avaliação
de
processo
de teste
padrão
Fornece
um
conjunto
de
métricas
para
controle
de
progresso
dos testes
v Faz menção a esta atividade, mas não fornece detalhes
Não faz menção a esta atividade
O RBTProcess será explicado no Capítulo 4.
51
3.4 Resumo do Capítulo
Apesar das diversas abordagens encontradas na literatura, nenhuma fornece um conjunto de
atividades completo que auxilie os engenheiros de teste em todo o processo de teste de
software. A grande maioria tem como características focar em testes funcionais ou “caixa-
preta” e fornecer atividades para análise dos riscos e/ou execução dos casos de teste.
Apenas Bach, fornece abordagem baseada em heurística para identificação de riscos,
que é essencial para criação dos casos de teste, uma vez que estes são projetados para tratar os
riscos identificados.
Existe um consenso entre os autores das abordagens apresentadas neste Capítulo de
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.
52
4
RBTProcess: Modelo de Processo de
Teste de Software baseado em Riscos
Segundo Sommerville (2003), um modelo de processo é uma descrição simplificada de um
processo de software, que é apresentada a partir de uma perspectiva específica. Neste
Capítulo, é descrito o RBTProcess, um Modelo de Processo de Teste de Software baseado em
Riscos.
O RBTProcess foi construído a partir de atividades presentes no gerenciamento de
riscos e nos processos de teste de software disponíveis na literatura e apresentados nos
Capítulos 2 e 3.
O RBTProcess é apresentando com seus respectivos fluxos de trabalho, papéis, fases e
artefatos. Além disso, são apresentados a forma como o modelo foi documentado e o
resultado das simulações de uso do processo e do estudo de caso realizados.
4.1 Documentação do Modelo
O modelo de processo está documentado graficamente através do Software Process
Engineering Metamodel (SPEM) [SPEM 2005]. O SPEM é um metamodelo que define
estereótipos da Unified Modeling Language (UML) para a modelagem de processos de
software padrão do Object Management Group (OMG) [SPEM 2005]. A Figura 4.1 apresenta
os níveis de modelagem do SPEM. O RBTProcess está modelado no nível M1.
Capítulo
53
Figura 4.1 Níveis de modelagem do SPEM.
A Tabela 4.1 apresenta uma breve descrição dos estereótipos disponíveis no SPEM e
utilizados neste trabalho.
Tabela 4.1 Estereótipos disponíveis no SPEM.
NOTAÇÃO ESTEREÓTIPO DESCRIÇÃO
Papel
(ProcessRole)
Descreve os papéis, responsabilidades e competências de
determinado indivíduo dentro do processo.
Artefato
(WorkProduct)
Descreve algo que contém informação ou é uma entidade física
produzida ou usada por atividades do processo. Ex. modelos,
códigos, executáveis, planos e documentos.
Documento
(Document)
Representa um documento criado, visualizado ou modificado através
de um processo.
Conjunto de Trabalho
(WorkDefinition)
Descreve a execução, operações realizadas e transformações feitas
nos artefatos. Representa um conjunto de atividades.
Atividade
(Activity)
Descreve os passos que um papel realiza para concluir uma única
atividade.
Guias
(Guidance)
Elemento do modelo que se associa ao outros elementos e pode
conter descrições adicionais, tais como: técnicas, guias e padrões.
Disciplina
(Discipline)
Agrupamento de elementos do processo (artefatos, papéis,
atividades) cujas atividades são organizadas segundo algum ponto de
vista em comum. Ex. teste, análise, requisito, projeto e etc.
Fase
(Phase)
Representa um conjunto de trabalho de alto nível e que é limitado
por um milestone.
Para criação, documentação e publicação do processo, foi utilizado o Eclipse Process
Framework (EPF) [EPF 2007]. O projeto EPF é composto por uma ferramenta de autoria
baseada no Eclipse [Eclipse 2008], que descreve o processo, chamada de EPFComposer, além
de alguns processos já prontos para serem customizados. A EPFComposer fornece uma
terminologia comum, padronizada e reusável através da UMA –Unified Method Architecture
para definição de métodos e processos. Além de ser facilmente customizável para os diversos
tipos de projeto. A Figura 4.2 apresenta uma visão das partes que compõem o projeto EPF e
onde o RBTProcess está localizado.
54
Figura 4.2 Composição do Eclipse Process Framework [EPF 2007].
No Apêndice A, é apresentado o resultado de uma pesquisa que fornece uma visão
sobre a área de teste de toftware, mais especificamente sobre o teste baseado em riscos, em
Pernambuco e no Brasil. Nesta pesquisa, pudemos confirmar que a maioria (noventa por
cento) das empresas realiza testes funcionais ou “caixa-preta” e que um número bastante
pequeno de entrevistados possui conhecimento avançado sobre riscos de software. Essas
informações foram decisivas para, respectivamente, manter o foco do processo em testes
funcionais e para criar o papel do Analista de Riscos.
Também, identificamos, na pesquisa, que as pessoas que conhecem ou utilizam a
abordagem possuem dificuldade em identificar riscos de software. Com isso, propomos, no
RBTProcess, o questionário baseado em taxonomia, onde a identificação dos riscos técnicos
associados aos requisitos do software é realizada de forma intuitiva, não necessitando de
conhecimento prévio sobre a gerência de riscos.
4.2 Visão Geral
O RBTProcess é iterativo, orientado a riscos e possui quatro fases distintas juntamente com
seus marcos, atividades e responsáveis, como mostrado da Figura 4.3.
4.2.1 Fases
O RBTProcess possui quatro fases distintas juntamente com seus marcos e atividades como
mostrado na Figura 4.4.
55
Figura 4.3 Página do modelo de processo criada pelo EPFComposer [RBTProcess 2008].
Figura 4.4 Fases do RBTProcess.
Planejamento
O foco desta fase é o planejamento inicial dos testes com base na análise dos riscos e tem
como marco a priorização dos requisitos a serem testados. Compreende as disciplinas
Identificar Riscos, Analisar Riscos e Planejar Testes.
56
Projeto
Nesta fase, os casos de testes planejados são projetados, com base nos riscos identificados.
Compreende a disciplina Projetar Testes. O marco desta fase é a criação de casos de teste que
verificam a existência ou não dos riscos identificados.
Execução
Os casos de testes planejados e projetados são executados. Compreende a disciplina Executar
Testes. O marco desta fase é a execução de casos de teste que verificam se riscos associados
aos requisitos foram mitigados.
Controle
Os resultados das execuções dos testes são coletados, analisados e acompanhados. Na
disciplina Avaliar Testes, os números, estratégias, tempo de execução e solicitações de
mudança são verificados. Na disciplina Controlar Riscos, é realizado o acompanhamento dos
riscos. Os riscos mitigados são eliminados da lista de riscos identificados que é entrada para o
planejamento da próxima iteração. O marco desta fase é o controle dos riscos mitigados
4.2.2 Papéis
Os papéis identificados são os mesmos encontrados em diversos processos de teste de
software como o Gerente de Testes, o Projetista de Testes e o Testador. Apenas o Analista de
Riscos é um papel do processo de gerenciamento de riscos, essencial para identificação,
análise e controle dos riscos associados aos requisitos do software. O Apêndice C fornece
mais detalhes sobre os papéis do RBTProcess.
Analista de Riscos
É responsável pelas atividades da Gerência de Riscos como identificação, análise e controle
de riscos. O analista pode, inclusive, ser membro da equipe de teste. Ele deve possuir
conhecimentos sobre teste de software, identificação e análise dos riscos, além de
conhecimento sobre os requisitos do software a ser testado.
Gerente de Testes
É responsável pela condução e controle das atividades do processo. Alguns dos
conhecimentos necessários para o Gerente de Testes referem-se a processos, projeto e
planejamento dos testes.
57
Projetista de Testes
É responsável pela criação dos casos de teste para mitigar os riscos identificados. O projetista
necessita de um conhecimento sobre os requisitos do sistema e tecnologia adotada,
ferramentas, técnicas para construção de casos de teste, estratégias e tipos de teste.
Testador
Realiza a execução dos testes projetados e registra solicitações de mudança, quando
necessário. O testador necessita de conhecimento sobre o processo de teste, ferramentas
utilizadas para execução, configuração do ambiente de execução e solicitação de mudança,
além do conhecimento sobre os requisitos do sistema.
4.3 Disciplinas ou Conjuntos de Trabalho
Como apresentado no início deste Capítulo, o modelo de processo proposto é constituído de
atividades presentes no gerenciamento de riscos e atividades do processo de teste de software.
As atividades do processo de teste de software sofreram algumas adaptações, uma vez que
essas, agora, são guiadas por riscos.
As disciplinas Identificar, Analisar e Controlar Riscos são provenientes do
gerenciamento de riscos e baseadas no RUP [RUP 2003], Guia PMBOK [PMI 2004] e CMMI
[CMMI 2006].
As disciplinas Planejar, Projetar, Executar e Avaliar Testes são provenientes de
processos de teste, baseadas no IEEE Std. 829-1998: Standard for Software Test
Documentation [IEEE 829 1998], IEEE Std. 1012-1998: Standard for Software Verification
and Validation [IEEE 1012 1998], TMM [Veenendaal 2006] e RUP [RUP 2003].
Nas subseções a seguir, são apresentadas as disciplinas do modelo de processo. Um
maior detalhamento será fornecido às atividades de gerenciamento de riscos e ao impacto das
mesmas nas atividades do processo de teste de software. O modelo de processo completo está
disponível em [RBTProcess 2008]. O Apêndice D fornece mais detalhes sobre as Disciplinas
do RBTProcess.
4.3.1 Identificar Riscos
Tem como objetivo identificar os riscos técnicos associados aos requisitos do software que
podem afetar, de alguma forma, o sucesso do projeto e que também podem ser mitigados
através da execução de testes.
58
Além do Analista de Riscos que é responsável por esta atividade, o Analista de
Requisito, Gerente e Projetista de Teste e Arquiteto ou Desenvolvedor do Software participam
da identificação dos riscos. A Figura 4.5 apresenta as atividades, responsáveis e principais
artefatos produzidos e/ou consumidos.
Figura 4.5 RBTProcess: Disciplina Identificar Riscos.
Revisar Fontes e Categoria de Riscos
Tem como objetivos avaliar e adaptar as listas de riscos e o questionário baseado em
taxonomia para o software que será testado. Os artefatos disponíveis no processo são
genéricos e podem ser utilizados em qualquer projeto de desenvolvimento. As listas de riscos
fornecidas no RBTProcess são sugeridas por Bach [Bach 1999], em sua abordagem baseada
em heurística, como forma de auxiliar os engenheiros de testes na identificação dos riscos
técnicos ou de produtos.
Além das listas, o questionário baseado em taxonomia de riscos ou Taxonomy Based
Questionnaire (TBQ) [Carr et al 1993], apresentado na Seção 2.2, é utilizado, com algumas
adaptações, para auxiliar a atividade de identificação dos riscos. O questionário completo é
composto por 20 questões que indicam ou não a presença de riscos associados aos requisitos
do software. O Analista de Riscos seleciona as questões que serão utilizadas no questionário,
levando em consideração o domínio do software a ser testado. São avaliados riscos
relacionados à estabilidade, completude, claridade, viabilidade, usabilidade e outros.
Idealmente, esta atividade deve ser realizada logo após a definição dos requisitos ou
funcionalidades a serem desenvolvidos, alterados ou evoluídos.
59
Responder Questionário (TBQ)
É a primeira etapa da identificação dos riscos. Para cada requisito, os participantes respondem
as perguntas e, de acordo com a resposta, é indicada a existência ou não do risco. Os
participantes não precisam ter qualquer conhecimento sobre riscos de software. Um
representante de cada etapa do processo de desenvolvimento de software (requisito, análise,
projeto, implementação, teste) deve participar desta atividade. Quando possível, o usuário
final também pode responder o questionário. O SEI recomenda cinco participantes para esta
atividade [Carr et al 1993].
Quando todos tiverem respondido, o Analista de Riscos consolida todas as respostas,
extraindo os riscos associados às perguntas, elimina os riscos duplicados e produz uma lista
com os riscos identificados para cada requisito ou funcionalidade.
Esta atividade deve ocorrer logo após a revisão dos requisitos, uma vez que os
requisitos estão sendo estudados naquele momento e existe uma probabilidade maior de todos
se lembrarem do propósito e detalhes de cada requisito ou funcionalidade.
Realizar Reunião de Brainstorm
Esta reunião tem como objetivos validar os riscos levantados na atividade anterior e
identificar riscos associados ao domínio do produto de software. Além disso, os participantes
podem fornecer mais detalhes sobre os riscos identificados que possam auxiliar no projeto dos
casos de teste.
As listas de riscos podem ser utilizadas para guiar a reunião de brainstorm, visando
torná-la mais eficiente. O produto dessa atividade é o refinamento da lista de riscos
identificados para cada requisito ou funcionalidade.
4.3.2 Analisar Riscos
Tem como objetivo a priorização dos requisitos ou funcionalidades do software a ser testado
com base na análise dos riscos técnicos identificados na disciplina Identificar Riscos.
Além do Analista de Riscos, que é responsável por esta atividade, o Analista de
Requisito, Gerente e Projetista de Teste e Arquiteto ou Desenvolvedor do Software participam
da priorização dos riscos. A Figura 4.6 apresenta as atividades, responsáveis e principais
artefatos produzidos e/ou consumidos.
60
Figura 4.6 RBTProcess: Disciplina Analisar Riscos.
Calcular Exposição ao Risco
As fórmulas utilizadas neste processo para a priorização dos riscos foram propostas por
Amland [Amland 1999] e posteriormente utilizadas por Chen [Chen 2002], em sua estratégia
para execução de testes de regressão baseada em riscos, com algumas adaptações. A fórmula
de Amland foi explicada no Capítulo 3.
As métricas e pesos definidos por Amland foram utilizados nas primeiras versões
deste processo da forma como foram sugeridos pelo autor. No entanto, com a avaliação do
processo através de simulações, algumas adaptações foram necessárias, além da inclusão de
nova métrica (Dependência) à fórmula para que o cálculo de exposição ao risco alcançasse
maior confiabilidade. A Figura 4.7 apresenta as métricas propostas por Amland, com seus
respectivos pesos, além da métrica proposta neste trabalho. A primeira coluna desta tabela
representa o identificador de cada uma das funcionalidades testadas. O nome das
funcionalidades aparece na Tabela 4.3.
Figura 4.7 Métricas para cálculo de exposição ao risco dos requisitos.
61
Os participantes desta atividade são os mesmos que realizaram a identificação dos
riscos. A escala sugerida pelo RBTProcess para os indicadores de custo e probabilidade vai de
1 até 3. Um guia é fornecido para atribuição desses indicadores de acordo com a atividade
realizada pelo participante. Para a métrica de qualidade, por exemplo, são sugeridos os
valores para os indicadores apresentados na Tabela 4.2.
Tabela 4.2 Exemplo de indicadores para a métrica de qualidade da funcionalidade.
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
Priorizar Riscos
Os riscos analisados na etapa anterior são consolidados pelo Analista de Riscos, gerando a
lista de priorização dos riscos. É calculada a média dos valores de exposição ao risco
atribuídas, pelos participantes, a cada funcionalidade. Além disso, o Analista de Riscos
classifica os requisitos, definindo intervalos para o valor de exposição ao risco como
apresentado na Tabela 4.3. No RBTProcess, as funcionalidades com maior exposição ao risco
são testadas primeiro. Em seguida, são testadas as funcionalidades com prioridade média. As
funcionalidades com prioridade baixa somente são testadas se houver tempo disponível.
Tabela 4.3 Lista de priorização dos requisitos.
ID. FUNCIONALIDADE REQ. DESENV. TESTE MÉDIA
PRIORIDADE
FUNC01 Simulator Properties
0.35 0.64 0.96 0.65
FUNC06 Local States
0.52 0.64 1.08 0.75
FUNC08 Phenomenon-State Relation
0.68 0.78 0.96 0.81
FUNC09 Quantity Tasks
0.60 0.64 1.28 0.84
BAIXA
FUNC03 Global States
0.60 1.44 1.08 1.04
FUNC04 Blocks
0.68 1.36 1.25 1.10
FUNC05 Create Group
0.60 1.44 1.25 1.10
MÉDIA
FUNC07 Create Phenomenon
1.30 1.05 1.28 1.21
FUNC11 Search
1.30 1.72 1.30 1.44
FUNC02 Kernel Configuration
1.50 1.92 1.50 1.64
FUNC10 Group Tasks
1.92 1.65 1.64 1.74
ALTA
62
4.3.3 Planejar Testes
Tem como objetivo direcionar e controlar as atividades de teste com base na avaliação de
riscos. O Gerente de Testes é o responsável pela atividade, mas ele conta com a participação
do Projetista ou Arquiteto de Testes. As atividades de planejamento são as mesmas de
qualquer processo de teste de software, porém o Gerente de Teste possui a informação de
riscos identificados e exposição ao risco para cada funcionalidade como principal entrada para
definição de escopo, recursos, cronogramas e outros. A Figura 4.8 apresenta as atividades,
responsáveis e principais artefatos produzidos e/ou consumidos.
Figura 4.8 RBTProcess: Disciplina Planejar Testes.
Definir Escopo dos Testes
Consiste na definição dos requisitos que serão testados ou não, tomando, como base, a análise
dos risco. A priorização dos requisitos é realizada a partir dos valores de exposição ao riscos.
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. A Tabela 4.4 apresenta um
exemplo de definição do escopo, utilizando a informação dos riscos da Tabela 4.3 e supondo
que o Gerente tem apenas duas iterações para projetar e executar todos os testes. O Gerente
definiu que, na primeira iteração, serão testados os requisitos com alta prioridade, na segunda,
os requisitos com média prioridade e os requisitos com baixa prioridade são testados se
63
houver tempo disponível. A cada iteração, esse planejamento é revisto de acordo com o
controle dos riscos.
Tabela 4.4 Definição do escopo dos teste.
ESCOPO DA ITERAÇÃO NÚMERO DE RISCOS IDENTIFICADOS
FUNC10 8
FUNC02 5
FUNC11 1
Iteração I
FUNC07 1
FUNC05 7
FUNC04 0
Iteração II
FUNC03 1
FUNC09 1
FUNC08 0
FUNC06 3
Caso sobre tempo
FUNC01 3
Definir Estratégia
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.
Definir Cronograma
Também com base na análise dos riscos, os requisitos com prioridade alta serão planejados,
projetados e executados nas primeiras iterações. Os requisitos com baixa prioridade só serão
planejados, projetados e executados se houver tempo disponível.
4.3.4 Projetar Testes
Tem como objetivo identificar e descrever os casos de teste para os requisitos e riscos a serem
testados com base na análise de riscos. É nesta atividade que está o grande diferencial da
abordagem RBT, pois, além do documento de requisitos e do planejamento dos testes, o
Projetista de Teste recebe o documento de identificação dos riscos para criação dos cenários
de teste que visam mitigar os riscos identificados. Assim, como na disciplina de Planejamento
de Testes, as atividades são as mesmas, o que muda é a forma como estas serão conduzidas e
realizadas. O Analista de Riscos também participa desta atividade. A Figura 4.9 apresenta as
atividades, responsáveis e principais artefatos produzidos e/ou consumidos.
64
Figura 4.9 RBTProcess: Disciplina Projetar Testes.
Definir Estratégia de Casos de Teste
Consiste na identificação dos cenários a serem testados, além da definição da abordagem e
tipo de testes que serão utilizados. Considerando a idéia do principle of diverse half-measures
explicada por Bach [Bach 2003], onde ele enfatiza que não é indicado utilizar apenas uma
abordagem de teste, ou seja, não se deve executar somente teste baseado em riscos,
principalmente, porque existe o risco de os requisitos não terem sido analisados corretamente.
Assim, o processo sugere diferentes coberturas para os requisitos, de acordo com sua
importância:
Requisitos com baixa prioridade: testar somente os casos de teste relacionados
aos riscos, se houver tempo disponível;
Requisitos com média prioridade: testar os casos de teste relacionados aos
riscos, testar o cenário do fluxo principal e testar possíveis fluxos alterados ou
incluídos durante a iteração;
Requisitos com alta prioridade: testar os casos de teste relacionados aos riscos e
todos os fluxos do requisito (principal, exceção e alternativo).
Um exemplo de caso de teste criado com base na identificação e análise dos riscos
para os dados apresentados na Figura 4.10, seria criar um caso de teste para a funcionalidade
Group Tasks, incluindo e alterando Group Tasks to tipo Custom, já que este foi identificado
como um requisito incompleto ou mal especificado.
65
Figura 4.10 Questionário baseado em taxonomia para a funcionalidade Group Tasks.
Especificar Caso de Teste e Descrever Procedimento de Teste
Os casos de teste que foram identificados são agora detalhados seguindo as estratégias
definidas. 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 teste para execução recomendado pelo
processo é o independente, de forma que estes possam ser executados em qualquer ordem.
Criar Pacotes de Execução
Criar pacotes para a execução contendo os casos de teste baseado em riscos, ordenados de
acordo com a priorização realizada na atividade Analisar Riscos.
4.3.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 pelo
Projetista de Teste. A Figura 4.11 apresenta as atividades, responsáveis e principais artefatos
produzidos e/ou consumidos.
Figura 4.11 RBTProcess: Disciplina Executar Testes.
66
Configurar Ambiente de Teste
Antes do início da execução dos casos teste, deve-se configurar o ambiente para a realização
dos testes que podem necessitar, dentre outros recursos, de ferramentas específicas e de base
de dados de teste.
Executar Testes e Reportar Resultados
A principal entrada para esta atividade é a planilha de execução criada pelo Projetista de
Testes. Ao executar os testes, o testador gera os logs com o resultado, como evidência das
execuções e, quando falhas são encontradas, solicitações de mudanças são criadas. Quando
um caso de teste é executado e não apresenta nenhuma falha, para a abordagem RBT significa
que o risco associado ao requisito foi mitigado. Similarmente, um risco é mitigado quando um
caso de teste falha e o defeito encontrado é corrigido e validado.
4.3.6 Avaliar Testes
Tem como objetivo medir quantitativa e qualitativamente o progresso dos testes e produzir
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 o processo de teste baseado em riscos, uma vez que todo o controle a acompanhamento
dos riscos foi definido na disciplina Controlar Riscos, sob a responsabilidade do Analista de
Riscos. A Figura 4.12 apresenta as atividades, responsáveis e principais artefatos produzidos
e/ou consumidos.
Figura 4.12 RBTProcess: Disciplina Avaliar Testes.
Avaliar Estratégias
Nesta atividade, o Projetista de Testes, de acordo com os resultados, verifica se as abordagens
utilizadas foram satisfatórias.
67
Avaliar Cobertura
O projetista verifica se os casos de teste executados e seus respectivos resultados alcançaram
a cobertura determinada no plano de teste.
Avaliar Resultado Geral
O Projetista de testes avalia os resultados gerados na atividade Executar Testes e cria o
relatório de resultado dos testes com número de casos de teste planejados, executados e seus
resultados. Além disso, o projetista avalia as estratégias utilizadas e a cobertura dos casos de
testes.
4.3.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 é
responsável pela atualização do Documento de Identificação e Análise dos riscos, principal
entrada para a atividade de planejamento dos testes. O principal artefato de entrada para esta
atividade é o Relatório de Avaliação dos Testes. A Figura 4.13 apresenta as atividades,
responsáveis e principais artefatos produzidos e/ou consumidos.
Figura 4.13 RBTProcess: Disciplina Controlar Riscos.
Identificar Riscos Mitigados
Através do relatório de resultado dos testes e das solicitações de mudanças criadas, o Analista
de Riscos identifica os riscos mitigados e atualiza o documento de riscos. Além disso, o
68
analista gera um relatório informando todos os riscos mitigados ou o percentual de mitigação,
criando uma nova lista de priorização dos riscos.
Avaliar Status dos Riscos e Avaliar Resultado Geral dos Riscos
O Analista de Riscos acompanha a evolução e os status dos riscos, reportando o resultado e
atualizando a lista de priorização a cada iteração.
4.4 Relacionamento dos Artefatos
Os artefatos com borda pontilhada na Figura 4.14 são originados do processo de teste baseado
em riscos. Os artefatos com sombra fazem parte de processos de teste de software [IEEE 829
1998]. Os demais são alguns dos artefatos criados durante o processo de desenvolvimento de
software, de uma forma geral.
Os documentos de identificação e análise dos riscos são criados pelo Analista de
Riscos na fase de planejamento e atualizados após a execução dos testes, na fase de controle.
O plano de teste é criado, pelo Gerente, levando em consideração os riscos identificados e
analisados e o cronograma do projeto. Os procedimentos de teste contêm os passos
necessários para verificar a existência dos riscos identificados. Os testes são executados na
ordem em que aparecem na planilha de execução, ou seja, na ordem de prioridade dos
requisitos. Solicitações de mudanças são criadas para os defeitos encontrados que, quando
corrigidos, mitigam os riscos associados.
4.5 Métricas
As métricas possibilitam quantificar características do processo ou do software e apóiam
atividades importantes do gerenciamento de projeto como planejamento, organização,
controle e melhorias [SMG 2001]. Assim, métricas para teste de software servem como
indicadores para o progresso das atividades de teste e podem também ser utilizadas para
melhorar práticas e atividades.
Nesta Seção, são apresentadas métricas para acompanhamento do progresso, esforço,
custo, estabilidade, qualidade e outras categorias do teste baseado em riscos utilizadas nas
atividades Avaliar Testes e Controlar Riscos do RBTProcess. As métricas estão divididas em
duas categorias:
69
Métricas para controle e medição dos casos de teste baseado em riscos,
apresentadas na Seção 4.5.1.
Métricas para controle e medição das atividades do processo de teste de software
baseado em riscos, apresentadas na Seção 4.5.2.
Figura 4.14 RBTProcess: Relacionamento dos artefatos.
A abordagem Goal Question Metric (GQM), desenvolvida por Victor Basili [GQM
2008], foi utilizada para definição das métricas propostas no RBTProcess. GQM define um
modelo de medição em três níveis como apresentado na Figura 4.15.
Busi
ness
Goals
Measurement
G
oals
Q
uestion
M
etric
Quais são os objetivos do negócio?
O que é necessário para atingir esses
objetivos?
Que questões ajudam no planejamento e controle
do progresso para alcançar estes objetivos
Que medidas
/métricas
são necessárias
para responder estas perguntas?
Nível Conceitual
Nível Operacional
Nível Quantitativo
Figura 4.15 Níveis do GQM [GQM 2008].
70
No nível conceitual estão os objetivos da medição que são definidos em termos da
entidade, propósito, atributos de qualidade, ponto de vista e ambiente. No nível operacional,
cada objetivo é refinado em um conjunto de perguntas que representam uma definição
operacional desse objetivo. No nível quantitativo, para cada pergunta, métricas relevantes são
definidas.
4.5.1 Métricas para Controle e Medição de Casos de Teste baseado
em Riscos
Para cada requisito ou funcionalidade do produto de software, riscos são identificados e
analisados. Depois, casos de teste são projetados para avaliar as ocorrências dos fatores de
riscos. Quando estes casos de teste são executados e falhas são observadas, os testadores
reportam o defeito para que possa ser corrigido e o risco, relacionado a esse caso de teste,
mitigado.
Amland [Amland 1999] propõe algumas métricas para o teste baseado em riscos em
seu estudo de caso de uma instituição financeira, como: número de testes planejados,
executados e completos; número de defeitos por função; número de horas utilizadas para se
testar por defeito encontrado; número de horas para corrigir um defeito, dentre outras. Além
disso, Konda [Konda 2008] apresenta um conjunto de métricas com o objetivo de medir
precisamente a remoção de defeitos que também pode ser aplicado ao teste baseado em riscos.
A Tabela 4.5 enumera métricas recomendadas para o controle e medição de casos de
teste baseado em riscos. A linha Gn contém o objetivo da medição, que é a informação que
nós queremos adquirir. A linha Qn.m é a pergunta que nos ajuda a planejar, controlar e medir
o progresso dos objetivos. Finalmente, Mn.m é a métrica que temos que coletar para
responder às questões. Exemplos de utilização das métricas são fornecidos na Seção 4.6.
4.5.2 Métricas para Controle e Medição das Atividades do Processo
de Teste de Software baseado em Riscos
Esta Seção apresenta métricas que podem ser utilizadas para monitorar a situação
(progresso) das atividades de teste de software baseado em riscos. Elas são utilizadas
principalmente para encontrar gargalos e/ou problemas e melhorar as atividades. Estão
enumeradas na Tabela 4.6.
71
Tabela 4.5. Métrica para casos de teste baseado em riscos.
G1. Verificar se um nível aceitável de mitigação dos riscos foi atingido.
Verificar se um nível aceitável de mitigação dos riscos por funcionalidade ou requisito foi atingido.
Q1.1. Quantos riscos foram mitigados? M1.1 100*(Número de casos de Teste baseado em Riscos que
passaram/ Número de casos de Teste baseado em Riscos planejados)
Q1.2. Quantos riscos foram mitigados
por requisito ou funcionalidade?
M1.2 100*(Número de casos de Teste baseado em Riscos que
passaram por requisito/Número de casos de Teste baseado em Riscos
planejados por requisito)
Q1.3 Quantos riscos foram mitigados
por importância?
M1.3 100*(Número de casos de Teste baseado em Riscos que
passaram por importância/Número de casos de Teste baseado em
Riscos planejados por importância)
G2. Verificar os requisitos mais importantes ou prioritários. Um intervalo pode ser definido a partir do
valor de exposição ao risco para identificar requisitos com alta, média ou baixa prioridade.
Q2.1. Qual o percentual de requisitos
com prioridade alta?
M2.1 100*(Número de requisitos com exposição ao risco alta/
Número de requisitos)
G3. Saber quais as categorias de riscos que apresentam o maior número de riscos. Alguns exemplos de
categorias apresentadas pelo SEI para requisitos são: estabilidade, completude e claridade e outras.
Q3.1. Qual o percentual de riscos
identificados por categoria?
M3.1 100*(Número de riscos por categoria/Número total de riscos)
G4. Verificar o quanto que os riscos estão diminuindo a cada iteração ou ciclo de teste.
Q4.1. Quantos riscos foram encontrados
por reunião e questionário baseado em
taxonomia?
M4.1 100*Número de riscos identificados/Número de reuniões
G5. Verificar se o nível de redução está adequado e se justifica o uso da técnica. Caso contrário, outras
técnicas mais efetivas devem ser utilizadas.
Q5.1. O custo da técnica de redução está
de acordo com o valor de limite?
M5.1 (Cálculo de exposição riscos antes da redução - Cálculo de
exposição riscos após da redução)/Custo da redução do risco.
G6. Obter informações necessárias para o planejamento de esforços. Bastante útil, uma vez que os
funcionários são pagos por hora.
Q6.1. Quanto tempo foi gasto para identificar riscos
utilizando o TBQ por funcionalidade?
M6.1 Tempo gasto para responder o TQB/Número de
requisitos
Q6.2. Quanto tempo foi gasto para identificar riscos na
reunião de brainstorm por funcionalidade?
M6.2. Duração da reunião/Número de requisitos
Q6.3. Quanto tempo foi gasto para analisar riscos por
funcionalidade?
M6.3. Tempo gasto para analisar riscos/Número de
requisitos
G7. Obter indicativos de qualidade do Teste baseado em Riscos.
Q7.1. Qual a quantidade de defeitos encontrados por
severidade?
M7.1 Número de defeitos por severidade/Número total
de defeitos
G8. Obter informações sobre a eficiência do Teste baseado em Riscos.
Q8.1. Qual percentual de defeitos encontrados com
Teste baseado em Riscos?
M8.1 100*(Número de casos de teste que falham
(porque um defeito foi encontrado)/Número de casos
de teste executado)
Q8.2. Quantas solicitações de mudança são criadas por
requisito / riscos?
M8.2. Número de solicitações de mudança/Número de
requisitos
Número de solicitações de mudança/Número de riscos
G9. Obter informações sobre defeitos que não foram capturados com Teste baseado em Riscos.
Q9.1. Quantos defeitos foram encontrados por
cliente/usuário utilizando teste baseado em riscos?
M9.1 Número de solicitações de mudança criadas pelo
cliente/usuário por severidade
G10. Obter informações do tempo requerido para encontrar um defeito com casos de Teste baseado em
Riscos.
Q10.1. Qual o tempo gasto para encontrar um defeito
utilizando casos de Teste baseado em Riscos?
M10.1 Total de horas gasta na execução/número de
defeitos encontrados durante esse período
.
72
Tabela 4.6 Métricas para atividade de teste baseado em riscos.
G1. Obter o tempo médio gasto para identificar e analisar riscos por requisito (número de linhas).
Q1.1. Qual o tempo médio gasto para analisar
riscos por linha de requisito?
M1.1 (Soma (duração da análise de riscos de um
requisito/número linhas do requisito))/ Número de requisitos
Q1.2. Qual o tempo médio gasto para
identificar riscos por linha de requisito?
M1.1 (Soma (duração da identificação de riscos de um
requisito/número linhas do requisito))/Número de requisitos
G2. Obter Informações de produtividade das reuniões de identificação de riscos.
Q2.1. Quantos riscos são encontrados por
reunião?
M2.1 Número de riscos/Número de reuniões
Q2.2. Quantos riscos são encontrados por
reunião por funcionário?
M2.2 (Número de riscos/Número de reuniões)/Número de
funcionários
G3. Como saber se os riscos identificados no TQB são úteis para o Teste baseado em Riscos ou pertinentes
para o domínio do produto de software.
Se uma quantidade grande de riscos está sendo descartada, significa que a identificação está muito abrangente e
que ela precisa focar mais nos cenários do projeto para que os riscos relevantes sejam encontrados de forma mais
rápida
Também, se um número grande de riscos é descartado, pode indicar que os requisitos estão confusos, ambíguos
ou com informações desnecessárias.
Se certo tipo de risco é sempre descartado, este não deve ser identificado.
Q3.1. Quantos riscos foram descartados durante a
reunião de brainstorm?
M3.1 Número de riscos descartados/Número total de
riscos
Q3.2. Quantos riscos foram descartados durante a
reunião de brainstorm por tipo?
M3.2 Número de riscos descartados/Número total de
riscos por tipo
G4. Obter Informações sobre a eficiência do cálculo de exposição ao risco.
Se muitos requisitos compartilham o mesmo valor de exposição ao risco, a abordagem RBT fica sem sentido já
que os requisitos não são priorizados adequadamente. Neste caso, uma métrica diferente deve utilizada para
calcular a exposição ao risco.
Q4.1. Qual o percentual de casos de teste que
compartilham o mesmo valor de exposição aos riscos
(RE)?
M4.1 100*(Número de casos de teste com o mesmo
valor de RE/Número total de casos de teste)
G5. Avaliar se os riscos identificados são úteis para criação dos casos de testes.
Q5.1.Qual o percentual de casos de teste que foram
projetados com os riscos identificados?
M5.1 100*(Número de riscos utilizados para projetar
casos de teste/Número de riscos identificados
4.6 Avaliação do Modelo de Processo
O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso. A
simulação consiste na execução das atividades do RBTProcess e na produção dos artefatos
com dados de projetos de desenvolvimento de software já concluídos ou fictícios.
Quatro simulações foram realizadas com o objetivo de validar e ajustar atividades,
artefatos, papéis, guias e métricas do processo e também coletar o tempo gasto para as
atividades de identificação e análise dos riscos técnicos associados aos requisitos.
O estudo de caso foi realizado com o objetivo de avaliar a hipótese de que o teste
baseado em risco, através do RBTProcess, encontra os defeitos de forma mais rápida do que
outros tipos de teste apresentados no Capítulo 2.
73
4.6.1 Simulações Realizadas pela Autora
Foram utilizados documentos de dois projetos de manutenção evolutiva de uma grande
empresa de informática que possui equipe de teste independente. Cada projeto é responsável
pela manutenção de um módulo do mesmo software. Para a simulação, foram necessários os
documentos de requisitos do sistema, o plano do projeto e o número de defeitos encontrados
nas últimas duas versões do software, com o intuito de avaliar a estabilidade e qualidade das
funcionalidades.
O primeiro projeto contém o módulo formado por aproximadamente vinte requisitos,
enquanto que o segundo contém o módulo formando por apenas seis requisitos. A simulação
foi realizada somente pela autora e os projetos de manutenções evolutivas já haviam sido
concluídos.
Resultados Obtidos
A atividade de identificação dos riscos se mostrou totalmente viável para o segundo projeto,
enquanto que, para o primeiro, se mostrou um gargalo, preenchendo a maior parte do tempo,
pois foi necessária a releitura de todos os documentos de requisito para responder, com mais
confiança, o questionário baseado em taxonomia de riscos. Isso reforça a necessidade de
automação desta atividade, principalmente para grandes projetos.
A atividade de análise de riscos foi realizada sem problemas e de forma rápida para
ambos os projetos. As métricas de custo foram identificadas a partir do documento de
requisitos que continha informações sobre a importância e prioridade do requisito para o
cliente. Os valores para as métricas de probabilidade (nova funcionalidade, tamanho e
complexidade) foram extraídas do plano de projeto que informava se a funcionalidade a ser
desenvolvida era nova, seu tamanho e esforço. A empresa realiza análise por ponto de função,
que pode ser utilizada para determinar a complexidade e o tamanho das funcionalidades. A
métrica Projeto/Qualidade (Tabela 3.5) foi definida de acordo com o número de falhas
encontradas por requisito nas duas últimas versões do software.
Em projetos de manutenção evolutiva, as empresas, sempre que possível, testam,
primeiramente, as funcionalidades incluídas e alteradas e, quando há tempo disponível,
realizam testes de regressão nas demais funcionalidades. Ao concluir esta atividade, foi
identificado que a fórmula proposta por Amland [Amland 1999] e explicada na Seção 3.2.2
não se adéqua a este cenário. Quando uma funcionalidade é nova, se os valores de custo para
o cliente e o vendedor, ou seja, o impacto desta funcionalidade for baixa, esta, muito
possivelmente, não será testada no RBTProcess, pois o seu cálculo de exposição ao risco
74
resultará em um valor muito baixo. Além disso, esta fórmula não considera o impacto de
alterações em uma funcionalidade nas demais. Como exemplo, tivemos uma funcionalidade
que sofreu alteração e foi classificada como de baixa prioridade, porém uma falha nessa
funcionalidade impediria o usuário de realizar, pelo menos, cinqüenta por cento das operações
disponíveis pelo software.
Para resolver este problema, o RBTProcess sugere que, para os casos em que o
desenvolvimento é de manutenções corretivas ou evolutivas, os fluxos ou cenários do
requisitos que foram incluídos ou alterados devem ser testados nas primeiras iterações,
independente do resultado da análise dos riscos. Também, uma nova métrica foi proposta para
tratar do problema de dependência entre as funcionalidades.
A atividade de planejamento dos testes foi realizada seguindo as definições propostas
no processo e explicadas na Seção 4.3.3. Os requisitos a serem testados são os que foram
classificados como de alta e média prioridade. Os requisitos classificados como de baixa
prioridade não fizeram parte do planejamento. Foi também elaborado um cronograma
tomando como base a análise dos riscos.
Na atividade de projeto de teste, foram identificados os testes apenas para a primeira
iteração definida no plano de testes. A estratégia para identificação dos testes utilizada foi a
descrita na Seção 4.3.4 e resultou num conjunto menor de casos de teste. Os riscos
identificados no questionário baseado em taxonomia não foram muito úteis para a criação dos
casos de teste. Para alguns riscos, ficou difícil imaginar cenários que garantissem a mitigação
dos mesmos. Como possível solução, o questionário baseado em taxonomia de riscos foi
revisado e algumas perguntas foram excluídas.
A atividade de execução dos testes não foi realizada, pois não foram criados os
procedimentos de teste.
Para simulação das atividades de avaliação e controle dos testes foram utilizados
dados fictícios e foi percebido que o documento de identificação e análise dos riscos não
guardava o histórico dos riscos mitigados na iteração anterior, uma informação importante
para avaliar a qualidade e evolução do software.
Considerações e Dificuldades Encontradas
Além dos problemas relatados em cada um dos conjuntos de trabalho, não foi possível avaliar
o impacto das atividades durante o desenvolvimento das funcionalidades - onde os requisitos
podem sofrer mudanças - pois ambas as simulações foram realizadas com projetos já
concluídos. Também, como a simulação foi realizada pela autora, que tem todas as atividades
75
do processo em mente, não foi possível afirmar a qualidade dos artefatos e a descrição do
processo.
Concluímos que, antes de partir para um estudo de caso, onde seriam avaliados, por
exemplo, tempo de realização das atividades e qualidade do produto final, se faz necessária a
simulação do processo por outra pessoa, que não a autora. Também, é importante validar o
processo para projetos de desenvolvimento de software em andamento.
4.6.2 Simulações Realizadas por Engenheiro de Teste com
Experiência em Teste de Software
A versão utilizada nesta simulação inclui a correção dos problemas identificados na simulação
realizada pela autora. As características desta simulação foram similares às da simulação
realizada pela autora. O engenheiro de teste utilizou os documentos do módulo formado por
aproximadamente vinte requisitos. O processo foi instanciado e o engenheiro dividiu a
execução do processo em duas iterações: (i) a primeira contendo os requisitos novos ou
alterados e a (ii) segunda contendo os requisitos que não sofreram alterações, com o intuito de
realizar testes de regressão. A simulação também foi realizada quando o projeto de
manutenção evolutiva já havia sido concluído.
Resultados Obtidos
O engenheiro de teste apresentou dificuldades já no momento da instanciação do modelo de
processo, pois ele não sabia de onde extrair, nos documentos do software, as informações
necessárias para a identificação e análise dos riscos, indicando a necessidade de um guia para
instanciação do RBTProcess.
O engenheiro precisou estudar todos os documentos de requisitos e regras de negócio
do sistema para conhecer as funcionalidades, o que tomou um tempo considerável. Diante
dessa situação, o engenheiro sugeriu que as atividades de identificação e análise ocorressem
imediatamente após a revisão dos requisitos a serem desenvolvidos, mantidos ou evoluídos,
pois os participantes estão com praticamente todas as informações das funcionalidades em
mente.
Com relação ao questionário baseado em taxonomia fornecido pelo processo, o
engenheiro identificou que algumas perguntas não estavam claras e necessitavam ser
revisadas. Além disso, sugeriu a remoção de questões que aparentemente estavam repetidas e
questões que necessitavam da participação do cliente, por não serem viáveis para a maioria
76
dos projetos. Ele apresentou dificuldade para responder as questões não objetivas do
questionário, entretanto, estas foram essenciais para a etapa de criação dos casos de teste.
Com relação à análise dos riscos, para a primeira iteração, a métrica de nova
funcionalidade apresentou um único valor para todos os requisitos, indicando necessidade de
revisão do guia.
Considerações e Dificuldades Encontradas
Apesar de o engenheiro de testes não ter tido tempo para simular as atividades do processo de
teste de software, suas considerações se transformaram em melhorias no questionário baseado
em taxonomia, nas métricas de análise dos riscos, na forma e momento de execução das
atividades de identificação e análise e na criação de guia para instanciação do modelo de
processo.
Também não foi possível avaliar o impacto das atividades durante o desenvolvimento
das funcionalidades ou requisitos.
4.6.3 Simulações Realizadas para Avaliar Métricas e Coletar Tempo
de Atividades de Identificação e Análise de Riscos
A versão utilizada nesta simulação inclui a correção dos problemas identificados na simulação
realizada pela autora e pelo engenheiro de testes. Esta simulação foi realizada com o propósito
de avaliar as métricas propostas no processo e coletar os tempos para identificação e análise
dos riscos. Três estudantes do curso de Engenharia da Computação, com conhecimentos
básicos de teste de software participaram como voluntários, realizando as atividades do
modelo de processo e coletando o tempo gasto em cada uma delas. Eles receberam
treinamento do RBTProcess e tiveram um tempo para ler o documento de requisitos do
software, o plano de projeto fictício e o histórico de defeitos reportados por funcionalidade,
também fictícios.
O documento de requisitos utilizado foi o do sistema Health-Watcher, definido por
[Soares 2002], que é um sistema de informações disponibilizado via web que oferece aos
usuários serviços relacionados ao sistema público de saúde, como o suporte ao registro de
reclamações e guia de saúde para o usuário. O documento contém nove requisitos funcionais e
nove requisitos não funcionais. Para esta simulação foram utilizados os requisitos funcionais.
77
Resultados Obtidos
Para a identificação dos riscos, foi utilizado um questionário baseado em taxonomia de riscos
com oito perguntas relacionadas a quatro categorias de riscos de requisito. A Tabela 4.7
apresenta os valores de algumas métricas que podem ser obtidos com a realização desta
atividade. A métrica M3.1 indica que 45% dos riscos identificados referem-se à estabilidade
do sistema. M1.1 indica que os voluntários gastaram 6.35 minutos para identificar riscos de
requisitos com, aproximadamente, quarenta linhas. Vinte e quatro riscos foram identificados
na reunião de brainstorm (M2.1) e oito riscos foram identificados por participante (M2.2).
Tabela 4.7 Métricas da atividade de identificação de riscos.
CASOS DE TESTE BASEADO EM RISCOS
M3.1 Estabilidade: 11 / 24 = 45%
Completude: 7 / 24 = 29%
Claridade: 3 / 24 = 12%
Validade: 3 / 24 = 12%
ATIVIDADES DO TESTE BASEADO EM RISCOS
M1.1
6.35 minutos por requisito com ≅ 40 linhas.
M2.1 24 riscos por reunião
M2.2 24 / 3 (voluntários) = 8 riscos
Para a análise dos riscos, os voluntários forneceram valores para as métricas propostas
na equação de Amland [Amland 1999] e adaptada neste processo. A Tabela 4.8 apresenta a
exposição ao risco das funcionalidades analisadas.
Tabela 4.8 Cálculo de exposição ao risco para o sistema Health-Watcher.
REQUISITO/FUNCIONALIDADE EXPOSIÇÃO AO RISCO (RE) PRIORIDADE
FR14. Update employee 0.75 Baixa
FR13. Register new employee 0.83 Baixa
FR10. Login 1.00 Média
FR16. Change logged employee 1.00 Média
FR11. Register tables 1.07 Média
FR02. Specify complaint 1.13 Média
FR12. Update complaint 1.13 Média
FR15. Update health unit 1.19 Alta
FR01. Query information 1.40 Alta
A Tabela 4.9 apresenta os valores de algumas métricas obtidos com a realização desta
atividade. A métrica M6.3 indica que os voluntários gastaram menos que 2.5 minutos para
analisar cada funcionalidade. A métrica M4.1 indica um percentual baixo de funcionalidades
com o mesmo valor de exposição ao risco (RE), indicando que a análise realizada é suficiente
para priorização das funcionalidades.
Tabela 4.9 Métricas da atividade de análise de riscos.
CASOS DE TESTE BASEADO EM RISCOS
M6.3
< 2.5 minutos por requisito
ATIVIDADES DO TESTE BASEADO EM RISCOS
M4.1 2 / 9 = 22 %
78
As informações resultantes destas atividades são os principais insumos para o
planejamento dos testes. A definição de prioridade para as funcionalidades auxilia o Gerente
de Testes a decidir quando, quais e como as funcionalidades serão testadas. A Tabela 4.10
apresenta os resultados para o projeto de casos de teste funcionais e baseado em riscos,
utilizando a estratégia proposta pelo RBTProcess na Seção 4.3.4 e assumindo que:
Para cada risco identificado, um caso de teste baseado em riscos foi projetado;
Para cada um dos requisitos foi criado um teste funcional para o fluxo principal;
Para requisitos com baixa prioridade, foram executados apenas casos de teste
baseado em riscos;
Tabela 4.10 Número de casos de teste por funcionalidade.
FUNC. PRIORIDADE NÚMERO
DE
FLUXOS
NÚMERO DE CASOS
DE TESTE BASEADO
EM RISCOS
NÚMERO DE CASOS DE TESTE
PROPOSTOS PELO RBTProcess
FR01 Alta 5 1 5 (fluxo) + 1 (risco) = 6
FR15 Alta 6 1 6 (fluxo) + 1 (risco) = 7
FR02 Média 6 5 1(fluxo principal) + 5 (riscos) = 6
FR12 Média 6 4 1(fluxo principal) + 4 (riscos) = 5
FR11 Média 1 4 1(fluxo principal) + 4 (riscos) = 5
FR10 Média 5 4 1(fluxo principal) + 4 (riscos) = 5
FR16 Média 1 3 1(fluxo principal) + 3 (riscos) = 4
FR13 Baixa 7 0 0 (riscos)
FR14 Baixa 1 0 0 (riscos)
TOTAL 38 22 38
As Tabelas 4.11 e 4.12 apresentam valores fictícios para exemplificar o uso das
métricas extraídas das atividades de execução de casos de teste e controle dos riscos. As
métricas M1.1 e M1.2 apresentam o percentual de execução dos casos de teste baseado em
riscos. A métrica M7.1 indica um número alto de defeitos com severidade muito alta. M8.1
indica a efetividade dos testes baseado em riscos e M8.2 a concentração dos defeitos
reportados.
Tabela 4.11 Resultado da execução dos casos teste baseado em riscos.
FUNC. NÚM. DE CASOS
DE TESTE BASEADO
EM RISCOS
PLANEJADOS
NÚM. DE CASOS
DE TESTE
BASEADO EM
RISCOS
EXECUTADOS
NÚM. DE CASOS
DE TESTE
QUE PASSARAM
NÚM. DE
DEFEITOS
ENCONTRADOS
FR01 1 1 0 1
FR15 1 1 0 1
FR02 5 5 3 3
FR12 4 4 2 1
FR11 4 0 0 0
FR10 4 0 0 0
FR16 3 0 0 0
FR13 2 0 0 0
TOTAL 24 11 5 6
79
Tabela 4.12 Métricas da atividade de análise de riscos.
CASOS DE TESTE BASEADO EM RISCOS
M1.1 11 / 24 = 45 % Executado
M1.2 FR01. 100 % Executado
FR15. 100 % Executado
M7.1 Severidade:
Muito Alta. 40%,
Alta. 20%,
Média. 10%
Baixa. 25%,
Muito Baixa. 5 %
M8.1 06 / 11 = 54 %
M8.2 FR01. 1 16%
FR15. 1 16%
FR02. 2 50%
FR12. 2 16%
Resultados Obtidos
A grande maioria das métricas propostas pôde ser validada com a simulação realizada. Os
tempos coletados para atividades de identificação e análise foram relativamente baixos, como
já era esperado, indicando a viabilidade do uso do RBTProcess.
A métrica de número de casos de teste não foi considerada uma boa métrica, pois este
número dependente da forma de escrita dos casos de teste, ou seja, pode-se escrever um caso
de teste que cubra unicamente um cenário, assim como se pode escrever um caso de teste que
cobre mais de um cenário. Para o teste baseado em risco, a métrica que coleta o número de
defeitos encontrados num determinado tempo aplica-se melhor, pois a idéia da abordagem é
explorar, primeiro, as funcionalidades mais críticas, com o objetivo de encontrar defeitos,
com maior severidade, mais cedo.
4.6.4 Estudo de Caso
A versão do RBTProcess utilizada neste estudo de caso contém a correção dos problemas
identificados durante as quatro simulações apresentadas anteriormente. A Figura 4.16
apresenta uma visão geral dos passos executados para a realização do estudo de caso.
Passo 1: toda equipe do experimento participou de treinamentos sobre conceitos
básicos de teste de software e sobre o RBTProcess. Após este treinamento, o
Gerente de Teste, juntamente com o Gerente de Projeto da equipe da ferramenta
em teste (MPhyScas) fizeram a instanciação do processo, criaram o questionário
baseado em taxonomia de riscos e definiram os papéis da equipe.
80
Projeto dos Testes
Treinamento
da ferramenta
MPhyScas
(2)
Identificação
de Riscos
(3)
Análise dos
Riscos
(4)
Planejamento
dos Testes
(5)
(6)
Avaliação dos
Testes e Controle
dos Riscos
(8)
Treinamento
sobre conceitos
básicos de teste
e RBTProcess
(1)
Execução dos Testes
(7)
Casos de Teste
baseado em Riscos
Casos de Teste Não
baseado em Riscos
Baseado
Em Riscos
Não baseado
em Riscos
Abordagem
Híbrida
Cycle 1
Não baseado
em Riscos
Abordagem
Híbrida
Baseado
Em Riscos
Cycle 2
Figura 4.16 Visão geral do fluxo de execução do estudo de caso.
Passo 2: a equipe de teste particiou de um treinamento sobre a ferramenta
MPhyScas, que será explicada a seguir.
Passo 3: após a reunião de validação dos requisitos a serem desenvolvidos, a
equipe MPhyScas executou a atividade de identificação de riscos do RBTProcess.
Ao final, o Analista de Riscos sumarizou os dados de todos os participantes,
removendo insconsistênias e produzindo o documento de identificação de riscos.
Passo 4: após a identificação dos riscos, a equipe da ferramenta MPhyScas
forneceu valores para as métricas apresentadas na Seção 4.3.2, com o objetivo de
definir o valor do cálculo de exposição ao risco para cada uma das
funcionalidades.
Passo 5: a partir do valor de exposição ao risco, o Gerente de Teste definiu a
quantidade de casos teste necessária para mitigar os riscos identificados, bem
como a ordem e a suíte de execução dos testes.
Passo 6: dois tipos de casos de teste foram projetados neste estudo de caso:
81
o Teste baseado em riscos: o Projetista de Teste projetou casos de teste
baseado em riscos para cada um dos riscos identificados, de acordo com o
que foi apresentado na Seção 4.3.4.
o Teste não baseado em riscos: um membro da equipe da ferramenta
MPhyScas, com treinamento intermediário sobre teste de software,
projetou um caso de teste para cada uma das funcionalidade da ferramenta.
Passo 7: na execução, foram definidos dois ciclos de execução e três grupos de
testadores que executaram abordagens diferentes de teste em cada um dos ciclos.
Três abordagens de execução foram definidas:
o Abordagem baseada em risco (Riscos): casos de teste baseado em riscos
foram executados na ordem do valor do cálculo de exposição ao risco,
seguindo as atividades do RBTProcess.
o Abordagem não baseada em risco (Funcional): casos de teste funcional
foram executados na ordem de utilização do software definida pelo usuário.
o Abordagem híbrida (Funcional RE): casos de teste funcionais foram
executados na ordem do valor do cálculo de exposição ao risco.
Passo 8: depois da execução dos casos de teste, os Analista de Riscos e o Gerente
de Projeto analisaram os resultados, removendo inconsistências, defeitos dulicados
e falso defeitos, sumarizando o resultado.
Nas subseções a seguir, são fornecidas as características e os resultados obtidos com a
execução do estudo de caso, de forma detalhada.
Característica
O RBTProcess foi aplicado no desenvolvimento da ferramenta Multi-Physics and Multi-
Scales Solver Environment (MPhyScaS), que é um ambiente para o desenvolvimento
automático de simuladores multi-físicos baseados no Método do Elemento Finito (FEM)
[MPhyScas 2007]. A ferramenta MPhyScas tem como motivação:
Potencializar o reuso de algoritmos e componentes de software em geral já
implementados e validados.
Manter componentes de software em uma base de dados única para fácil
localização.
Automatizar tarefas repetitivas na construção de simuladores.
A ferramenta MPhyScaS está sendo desenvolvida pelo Departamento de Sistema e
Computação da Universidade de Pernambuco (UPE), em parceria com o Departamento de
82
Engenharia Mecânica da Universidade Federal de Pernambuco (UFPE) com o apoio do Finep,
Cenpes/Petrobras e CNPq. A equipe conta com sete pessoas, duas contratadas recentemente,
trabalhando no desenvolvimento da ferramenta.
O objetivo deste estudo de caso foi avaliar a hipótese de que a abordagem de teste
baseado em risco, definida no RBTProcess, encontra mais rapidamente os defeitos mais
importantes. Para isto, o processo foi instanciado para a realidade do projeto e voluntários
participaram da atividade de execução dos testes, realizando três diferentes abordagens de
teste, apresentadas na Figura 4.16.
A ferramenta MPhyScas está dividida em quatro módulos: (i) repositório de
componentes de software científicos; (ii) interface para modelagem e geração de simuladores;
(iii) interface para entrada de dados e execução de simulação; (iv) framework de simulação.
O módulo de interface para modelagem e geração de simuladores foi testado através do
RBTProcess.
Os papéis definidos e utilizados no RBTProcess foram organizados da seguinte forma:
Analista de Riscos: autora.
Gerente de Teste: autora.
Projetista de Teste: autora e um membro da equipe MPhyScaS.
Testadores: cinco voluntários, estudantes do curso de Engenharia da Computação
Gerente de Projeto: membro da equipe MPhyScaS.
Analista de Sistema: quatro membros da equipe MPhyScaS. Um dos membros da
equipe não participou, pois havia integrado o grupo há pouco tempo.
Analista de Requisito: este e outros papéis não existem na equipe MPhyScaS,
pois todos realizam todas as etapas de desenvolvimento, inclusive a de teste.
A Tabela 4.13 apresenta as atividades necessárias para a realização do estudo de caso,
destacando os participantes e o momento em que cada uma delas foi executada. Ao final de
cada atividade, os participantes responderam questionários, informando as dificuldades
encontradas e oportunidades de melhoria. Os participantes receberam treinamento sobre os
conceitos básicos de teste de software, sobre o RBTProcess e sobre a ferramenta MPhyScaS.
A Tabela 4.14 apresenta as atividades do RBTProcess realizadas no estudo de caso
com seus respectivos responsáveis e participantes. A equipe MPhyScaS participou das
atividades de identificação e análise dos riscos, que não levaram mais que duas horas para
serem concluídas. A reunião de Brainstorm não foi realizada, por falta de tempo e as dúvidas
e conflitos resultantes da identificação foram resolvidos pelo Gerente de Projeto da equipe.
83
As atividades do processo de teste foram realizadas pela autora, por falta de recurso
humano, com exceção da atividade de execução dos testes, que foi realizada pelos voluntários
e a atividade de projeto dos casos de teste funcionais que foi realizada por um membro da
equipe MPhyScaS.
Tabela 4.13 Atividades de preparação para realização do estudo de caso.
ATIVIDADES RESPON-
SÁVEL
PARTICI-
PANTES
OBSERVAÇÕES
Treinamento
RBT Process
Apresentar
RBTProcess
Apresentar
página do
RBTProcess
Gerente de
Teste
Gerente do
Projeto,
Analista de
Sistemas,
Gerente de
Testes,
Projetista de
Testes,
Testadores
Duração de 1 hora
Ocorreu antes do início da
iteração
Com exceção do Gerente, a
equipe MPhyScaS não pôde
participar desta atividade,
por conta da
incompatibilidade de
horários.
Instanciação
do Modelo de
Processo
Definir
atividades,
artefatos e papéis
do processo
Identificar
recursos
necessários
Analista de
Riscos
Gerente do
Projeto
Duração de 2 horas
Ocorreu durante o
planejamento da iteração
Treinamento
sobre o
MPhyScaS
Gerente do
Projeto
Analista de
Riscos,
Gerente de
Testes,
Projetista de
Testes,
Testadores
Duração de 1 hora
Treinamento
Teste de
Software
Registro de
resultado dos
testes
Registro de
Solicitações de
mudança
Apresentação
dos templates
Gerente de
Testes
Testadores Duração 1 hora
Tabela 4.14 Atividades do RBTProcess.
ATIVIDADES RESPON-
SÁVEL
PARTICI-
PANTES
OBSERVAÇÕES
Revisar Fontes e
Categoria dos Riscos
Analista de
Riscos
Gerente do
Projeto
Duração de 1h
Questionário foi adaptado
para o projeto de acordo
com as funcionalidades a
serem testadas
Atividade
Identificar
Riscos
Responder
Questionário
Analista de
Riscos
Gerente do
Projeto,
Analista de
Sistemas,
Gerente de
Testes,
Projetista de
Testes,
Durou menos que uma hora
por pessoas
Não ocorreu após a reunião
de revisão
O questionário foi
respondido no final do
desenvolvimento
Apenas equipe MPhyScaS
84
Testadores respondeu ao questionário
Realizar Reunião de
Brainstorm
Analista de
Riscos
Gerente do
Projeto,
Analista de
Sistemas,
Gerente de
Testes,
Projetista de
Testes,
Testadores
Não houve tempo para
realizar essa reunião, pois a
equipe estava concluindo o
desenvolvimento
Analista levou em torno de
2 horas para consolidar os
dados e remover
ambigüidades com a ajuda
do Gerente
Calcular Exposição
aos Riscos
Analista de
Riscos
Gerente do
Projeto,
Analista de
Sistemas,
Gerente de
Testes,
Projetista de
Testes,
Testadores
Durou menos que uma hora
por pessoa
Apenas equipe MPhyScaS
informou valores para as
métricas
Atividade
Analisar
Riscos
Priorizar
Riscos/Requisitos
Analista de
Riscos
Durou em torno de 2h para
consolidar os dados e criar
o relatório com as métricas
para equipe
Atividade
Planejar
Testes
Gerente de
Testes
Gerente do
Projeto
O tempo desta atividade
não foi coletado
Não houve tempo para
produzir todos os artefatos,
pois a ferramenta
MPhyScaS necessitava ser
entregue aos clientes
Atividade
Projetar
Testes
Projetista de
Testes
Gerente do
Projeto,
Gerente de
Testes,
Analista de
Riscos
O tempo desta atividade
não foi coletado
Um membro da equipe
MPhyScaS projetou os
casos de teste funcionais
Atividade
Executar
Testes
Executar Testes e
Reportar Resultados
Testadores Testadores Os testes foram executados
em dois encontros com
duração média de 1,5 horas
Cada testador executou
duas diferentes abordagens
de teste
Atividade
Avaliar
Testes
Avaliar Resultado
Geral
Projetista de
Testes
O tempo desta atividade
não foi coletado
Foi elaborado relatório com
o resultado dos testes para
cada abordagem
Atividade
Controlar
Riscos
Avaliar Resultado
Geral dos Riscos
Analista de
Riscos
O tempo desta atividade
não foi coletado
Foi atualizado o documento
de priorização dos riscos
Resultados Obtidos
Os resultados apresentados a seguir foram extraídos dos relatórios produzidos para equipe
MPhyScaS, para cada atividade do RBTProcess realizada.
85
A Tabela 4.15 apresenta os tempos gastos para identificação dos riscos utilizando o
questionário baseado em taxonomia. O tempo foi ainda menor que o do sistema Health-
Watcher e isso se deve ao fato de que os membros da equipe MPhyScaS têm bastante
conhecimento sobre os requisitos, não necessitando a leitura da documentação.
Tabela 4.15 Tempo gasto na atividade de identificação de riscos.
TEMPO PARA IDENTIFICAR RISCOS POR FUNCIONALIDADE 2.41
Tempo médio gasto para responder todas as perguntas do questionário para uma
funcionalidade em minutos
TEMPO PARA IDENTIFICAR RISCOS POR PESSOA 26.51
Tempo médio para responder todas as perguntas do questionário para todas as
funcionalidades em minutos
2.41 x 11 (número de funcionalidades)
TEMPO TOTAL PARA IDENTIFICAR RISCOS 106
Tempo gasto por todas as pessoas da equipe na identificação de riscos em minutos
26.51 x 4 (pessoas)
As Tabelas 4.16 e 4.17 apresentam, respectivamente, a concentração dos riscos por
tipo e por funcionalidade e os tempos gastos para análise dos riscos.
Tabela 4.16 Características dos riscos identificados.
QUANTIDADE DE RISCOS IDENTIFICADOS 49
Quantidade de riscos identificados por toda equipe
QUANTIDADE DE RISCOS DIFERENTES IDENTIFICADOS 30
Quantidade de riscos diferentes identificados por toda equipe 49 - 19 (riscos repetidos)
QUANTIDADE DE RISCOS DIFERENTES IDENTIFICADOS POR FUNCIONALIDADE 30
Quantidade de riscos diferentes identificados por funcionalidade
FUNC01-Simulator Properties 3
FUNC02-Kernel Configuration 3
FUNC03-Global States 0
FUNC04-Blocks 1
FUNC05-Create Group 1
FUNC06-Local States 0
FUNC07-Create Phenomenon 7
FUNC08-Phenomenon-State Relation 1
FUNC09-Quantity Tasks 1
FUNC10-Group Tasks 5
FUNC11-Search 8
QUANTIDADE DE RISCOS IDENTIFICADOS POR PESSOA 7.5
Quantidade de riscos diferentes identificados por toda equipe
QUANTIDADE DE RISCOS IDENTIFICADOS POR TIPO 30
Stability 2
Completeness 11
Validity 8
Feasibility 2
Clarity 1
Feasibility 6
. É interessante notar que nem sempre as funcionalidades que apresentam mais riscos
são as mais importantes, este comportamento foi também observado na simulação com o
sistema Health-Watcher. As funcionalidades classificadas como de alta prioridade levam em
86
conta o impacto de falhas no software em produção. Assim, apesar de uma funcionalidade ser
classificada como muito importante para software ela pode não possui um risco alto, porque
está muito bem especificada, com requisito estável ou não vem apresentado falhas durante
utilização. Este, de fato, é o objetivo do teste baseado em riscos: identificar funcionalidades
que são igualmente importantes e que possuem alta probabilidade de apresentar falhas. Além
disto, a análise indicou um problema de completude dos requisitos, que foi, posteriormente,
confirmado pela equipe, por conta da ausência de documento de requisitos. O tempo gasto
para análise dos riscos foi muito pequeno, confirmando a viabilidade de utilização desta
atividade no processo de teste de software.
Tabela 4.17 Tempo gasto para análise dos riscos.
TEMPO PARA ANALISAR RISCOS POR FUNCIONALIDADE 1.05
Tempo médio gasto para informar valores para as métricas de análise para uma
funcionalidade em minutos
TEMPO PARA ANALISAR RISCOS POR PESSOA 11.55
Tempo médio para informar valores para as métricas de análise para todas as
funcionalidades em minutos 1.05 x 11 (número de funcionalidades)
TEMPO TOTAL PARA ANALISAR 46.2
Tempo gasto por todas as pessoas da equipe na análise de riscos em minutos
11.55 x 4 (pessoas)
A Tabela 4.18 apresenta os valores de exposição ao risco para o sistema MPhyScaS.
O planejamento e o projeto seguiram as definições do RBTProcess e foram criados casos de
teste para as funcionalidades classificadas com prioridade alta e média. Para as
funcionalidades com baixa prioridade, só foram criados casos de teste para as que tiveram
algum risco identificado. Os casos de teste baseado em riscos foram executado na ordem de
exposição ao risco, do maior para o menor valor.
Tabela 4.18 Valores de exposição ao risco das funcionalidades do MPhyScaS.
CÁLCULO DE EXPOSIÇÃO AO RISCO
FUNC10-Group Tasks 1.74
FUNC02-Kernel Configuration 1.64
FUNC11-Search 1.44
FUNC07-Create Phenomenon 1.21
FUNC04-Blocks 1.10
FUNC05-Create Group 1.10
FUNC03-Global States 1.04
FUNC09-Quantity Tasks 0.84
FUNC08-Phenomenon-State Relation 0.81
FUNC06-Local States 0.75
FUNC01-Simulator Properties 0.65
87
A Tabela 4.19 apresenta o resultado da execução dos casos de teste funcionais, casos
de teste baseado em riscos e casos de teste funcionais executados seguindo a ordem de
exposição ao risco (RE).
Foram realizados dois ciclos de execução com duração média de 1,5 horas. Sendo que,
para o primeiro ciclo, os testadores gastaram trinta minutos utilizando a ferramenta
MPhyScaS e esclarecendo dúvidas. Cada testador executou uma abordagem de teste diferente
por ciclo, ou seja, um mesmo testador executou duas abordagens diferentes o que pode ter
influenciado no resultado.
Entretanto, é sabido que alguns testadores encontram mais defeitos que outros, mesmo
quando executando o mesmo conjunto de teste, o que também acaba influenciando o resultado
de uma determinada abordagem. Assim, quando um testador executa abordagens diferentes de
teste, o resultado fica melhor balanceado. Como exemplo, neste estudo de caso, um testador
reportou 8 defeitos, equanto que um outro testador, que executou o mesmo conjunto de casos
de teste, reportou apenas 1 defeito. Se o primeiro testador tivesse executado apenas uma
abordagem de teste, esta abordagem acabaria tendo um resultado melhor, por conta da
habilidade do testeador.
Pode-se perceber um número considerável de defeitos encontrados utilizando a
abordagem baseada em riscos. Um ponto que merece destaque é que, apenas mudando a
ordem de execução, os testes funcionais (RE) encontraram o dobro de defeitos da abordagem
Funcional, onde os testes foram executados na ordem de utilização definida pelo usuário.
Além disso, a abordagem baseada em riscos encontrou um maior número de defeitos
com alta severidade que as demais abordagens.
A Tabela 4.20 apresenta a concentração de defeitos por caso de teste executado. A
abordagem Funcional concentrou a maioria dos defeitos nos últimos casos de teste, enquanto
que nas demais, os defeitos se concentraram nos primeiros casos de teste. É interessante
destacar que o caso de teste funcional número 11 explora a mesma funcionalidade do caso de
baseado em risco número 1.
A Tabela 4.21 complementa a informação da Tabela 4.20, onde a abordagem
funcional concentrou a maioria dos defeitos após 30 minutos de execução dos testes. A
abordagem baseada em riscos concentrou um maior número de defeitos antes dos 30 minutos
de execução.
88
Tabela 4.19 Número e severidade dos defeitos encontrados por abordagem.
SEVERI-
DADE
TESTADOR
CICLO
ABORDAGEM QTD. CASOS
DE TESTE
EXECUTADOS
QTD.
DEFEITOS
REPORTADOS
A M B
Testador 1 Ciclo 1 Funcional 7 2 2
Testador 3 Ciclo 2 Funcional 11 4 4
Testador 4 Ciclo 1 Funcional 11 1 1
TOTAL 29 7 1 6
Testador 2 Ciclo 1 Riscos 1 4 2 1 1
Testador 3 Ciclo 1 Riscos 2 4 1 2 1
Testador 5 Ciclo 2 Riscos 4 10 4 4 2
TOTAL 7 18 7 7 4
Testador 5 Ciclo 1 Funcional (RE) 4 8 2 5 1
Testador 1 Ciclo 2 Funcional (RE) 10 1 1
Testador 4 Ciclo 2 Funcional (RE) 10 4 2 2
TOTAL 24 13 4 7 2
Tabela 4.20 Concentração dos defeitos por caso de teste.
TESTADOR CICLO ABORDAGEM 1
3
4
5
6
7
8
9
10
11
Testador 3 Ciclo 2 Funcional 1
1 1 1
Testador 1 Ciclo 1 Funcional 1 1
Testador 4 Ciclo 1 Funcional 1
TOTAL 7 1 1 1 1 1 2
Testador 5 Ciclo 2 Riscos 8
2
Testador 2 Ciclo 1 Riscos 4
Testador 3 Ciclo 1 Riscos 4
TOTAL 18 16 2
Testador 4 Ciclo 2 Funcional (RE) 2
1 1
Testador 5 Ciclo 1 Funcional (RE) 2
3 3
Testador 1 Ciclo 2 Funcional (RE) 1
TOTAL 13 4 3 1 3 1 1
Tabela 4.21 Concentração dos defeitos por tempo de execução.
TESTADOR CICLO ABORDAGEM
10min
20min
30min
40min
50min
Testador 3 Ciclo 2 Funcional 1 1 2
Testador 1 Ciclo 1 Funcional 1 1
Testador 4 Ciclo 1 Funcional 1
TOTAL 7 3 2 2
Testador 2 Ciclo 1 Riscos 2 1 1
Testador 3 Ciclo 1 Riscos 1 2 1
Testador 5 Ciclo 2 Riscos 3 3 2 2
TOTAL 18 6 6 3 1 2
Testador 5 Ciclo 1 Funcional (RE) 2 3 3
Testador 1 Ciclo 2 Funcional (RE) 1
Testador 4 Ciclo 2 Funcional (RE) 1 1 1 1
TOTAL 13 2 4 4 1 2
89
A Tabela 4.22 apresenta a concentração dos defeitos por funcionalidade. Independente
da abordagem utilizada, a maioria dos defeitos estão concentrados nas funcionalidades com
maior exposição ao risco apresentadas na Tabela 4.18.
Tabela 4.22 Concentração dos defeitos por funcionalidade.
TESTADOR CICLO
ABORDAGEM
LOCAL
STATES
CREATE
PHENOMENON
PHENOMENON
STATERELATION
QUANTITY
TAKS
GROUP
TASK
SEARCH
Testador 1 Ciclo 1 Funcional 1 1
Testador 3 Ciclo 2 Funcional 1
1
1
1
Testador 4 Ciclo 1 Funcional 1
TOTAL 7 1 1 1
1
1
2
Testador 5 Ciclo 2 Riscos 8
2
Testador 2 Ciclo 1 Riscos 4
Testador 3 Ciclo 1 Riscos 4
TOTAL 18 0 0 0
0
16
2
Testador 5 Ciclo 1 Funcional (RE) 3 2
3
Testador 1 Ciclo 2 Funcional (RE) 1
Testador 4 Ciclo 2 Funcional (RE) 1 1 2
TOTAL 13 1 4 0
1
4
3
Considerações e Dificuldades Encontradas
Neste estudo de caso, praticamente todas as atividades do RBTProcess puderam ser
executadas, porém, algumas delas ainda foram executadas pela autora, tendo em vista a
dificuldade de encontrar estudos de caso que a equipe pudesse assimilar e realizar o processo
como um todo. Como foi apresentado, o tempo gasto nas atividades de gerência de riscos é
relativamente baixo não gerando uma sobrecarga no processo de teste.
Com relação aos resultados, ainda não é possível afirmar que a abordagem baseada em
riscos, representada pelo RBTProcess, é melhor que a abordagem funcional, que não
considera riscos, pois são necessários mais estudos de caso, para diferentes domínios de
software. O que podemos afirmar é que, para este estudo de caso, a abordagem baseada em
riscos se mostrou mais eficiente, confirmando que encontra os defeitos mais rápido que as
demais, tendo em vista a priorização das funcionalidades.
De acordo com a equipe MPhyScaS, as atividades realizadas não foram difíceis de
serem realizadas, auxiliaram no conhecimento do software e os testes focaram em
90
funcionalidade realmente importantes. A equipe demonstrou interesse em adotar o
RBTProcess e indica o uso do modelo de processo, inclusive para grandes projetos.
Como melhoria do modelo de processo, a equipe sugeriu revisão do guia para
atribuição de valores das métricas do cálculo de exposição ao risco.
4.7 Resumo do Capítulo
Neste Capítulo, foi apresentado o RBTProcess, um Modelo de Processo de Teste de Software
baseado em Riscos com atividade, artefatos e guias. O detalhes de cada atividade do
RBTProcess, bem como os templates estão disponíveis em [RBTProcess 2008] e no Apêndice
C.
Além do modelo, métricas são propostas com o objetivo de medir e controlar a
execução dos casos de teste baseado em riscos, bem como o esforço gasto em cada atividade
do processo, o progresso da execução dos testes e a eficiência das atividades de identificação
e análise dos riscos.
O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso.
As simulações serviram para refinar as atividades e artefatos do modelo de processo,
enquanto que o estudo de caso possibilitou avaliar o RBTProcess com relação ao número e
severidade dos defeitos encontrado, tempo gasto para encontrar cada defeito e concentração
dos defeitos por funcionalidade.
Vale destacar que, no planejamento inicial deste estudo de caso, estava previsto o uso
da RBTTool, ferramenta de apoio ao teste de software baseado em riscos. No entanto, a
ferramenta não foi concluída a tempo e a consolidação dos dados das atividades de
identificação e análise e todos os artefatos foram produzidos manualmente.
91
5
RBTTool: Ferramenta de apoio ao
Teste de Software baseado em Riscos
Com a necessidade de aumentar a produtividade e qualidade, ferramentas de apoio a
Engenharia de Software ou Computer-Aided Software Engineering (CASE) estão se tornando
imprescindíveis nos ambientes de desenvolvimento de software (ADS). Uma ferramenta
CASE é qualquer software que auxilia as pessoas que trabalham em um ADS (análise,
projeto, implementação e teste) [Loh 1996].
Nesse contexto, apresentamos a RBTTool, uma ferramenta CASE para o teste de
software baseado em riscos. Assim como as demais ferramentas CASE, a RBTTool tem como
objetivo fornecer uma maior qualidade e produtividade nas atividade do teste baseado em
riscos, através da automação de tarefas repetitivas, diminuindo a possibilidade de erros e
inconsistência nos resultados.
Vale salientar que não foram encontradas referências sobre ferramentas de apoio a
abordagem RBT. Apenas [Jorgensen 2004], em seu trabalho de graduação, levantou os
requisitos necessários para a construção de uma ferramenta de apoio à abordagem e construiu
protótipos de interface gráfica para cada funcionalidade, mas, segundo o autor, não houve
tempo suficiente para implementá-las. Além disso, o autor não contemplou, em seu
documento de requisitos, atividades como identificação de riscos, cadastro de diferentes
cálculos de exposição ao risco, planejamento e projeto de teste. Atividades estas que são de
suma importância para o processo de teste de software baseado em riscos.
Os requisitos necessários para a construção da RBTTool foram levantados a partir de
estudo detalhado das principais abordagens RBT, apresentadas no Capítulo 3. É importante
destacar que a RBTTool pode ser utilizada independente do RBTProcess.
Capítulo
92
5.1 Requisitos
A RBTTool está dividia em dois grandes módulos: O módulo de apoio às atividades da
gerência de riscos, que compreende as atividade de identificação, análise e controle dos
riscos, e o módulo de apoio ao processo de teste de software que compreende as atividades de
planejamento, projeto, execução e avaliação dos testes.
O módulo de apoio à gerência de riscos foi priorizado e está em desenvolvimento para
a primeira versão da ferramenta. Este módulo é o que fornece um maior ganho para atividade
RBT, pois contempla atividades que não são de domínio dos engenheiros de teste e que não
são apoiadas pelas ferramentas de teste de software. A Figura 5.1 apresenta os principais
casos de uso para cada um dos módulos apresentados. O Analista de Riscos é ator principal
das atividades de Gerência de Riscos, porém participam também destas atividades, o Gerente
de Teste, Projetista, Testador e membros da equipe do software que será testado.
Figura 5.1 Diagrama de caso de uso da RBTTool.
93
A seguir, será apresentada uma breve descrição dos casos de uso em desenvolvimento
para a primeira versão. Os detalhes e descrição dos demais casos de uso estão disponíveis na
página da ferramenta em [RBTTool 2008].
Manter Projetos RBT: permite ao Gerente de Teste incluir, excluir e alterar
projetos de teste de software baseado em riscos. Dentre outras informações, o
Gerente informa os requisitos que fazem parte do projeto, a versão do software que
será testado, os recursos necessários e datas de início e fim da atividade de teste.
Manter Requisitos: o Gerente de Teste cadastra os requisitos que estão no escopo
dos testes. É possível cadastrar os fluxos de cada requisito informando, inclusive, o
seu tipo (principal, alternativo e de exceção). Nas próximas versões, será possível
importar requisitos de ferramentas de gerenciamento de requisitos disponíveis no
mercado.
Manter Riscos: o Analista de Riscos inclui na ferramenta riscos que podem ser
identificados no produto de software. O sistema permite que os riscos cadastrados
sejam classificados.
Manter Questionário: o Analista de Riscos cadastra questionários que podem ser
utilizados na etapa de identificação. Ele cadastra uma ou mais perguntas no
questionário e associa estas perguntas a um risco cadastrado na ferramenta.
Identificar Riscos: o Analista de Riscos cadastra o questionário utilizando a
ferramenta, exporta para um documento e envia para os participantes da
identificação. Após respondidos, os questionários são importados pela ferramenta,
os dados são processados e sumarizados, resultando em uma lista de riscos
identificados para cada requisito do software em teste.
Analisar Riscos: o Analista de Riscos define as métricas que serão utilizadas no
cálculo de exposição ao risco, exporta para documento e envia para os
participantes da análise. Quando concluídas, os valores das métricas são
processados e sumarizados, resultando na lista de priorização dos requisitos.
5.2 Material e Método
Nesta seção, são descritas as tecnologias, ambiente de desenvolvimento e processos utilizados
no desenvolvimento da RBTTool.
94
5.2.1 Tecnologias
A seguir, apresentamos uma breve descrição das principais tecnologias utilizadas para
construção da RBTTool.
Java
Java é uma linguagem de programação orientada a objetos, desenvolvida pela Sun
Microsystems. Inicialmente, elaborada para ser a linguagem-base de projetos de software para
produtos eletrônicos, Java teve seu grande reconhecimento em 1995, com o crescimento da
web [Cornell et al 2000]. Java foi escolhida para desenvolvimento da RBTTool por ser livre,
amplamente utilizada, multiplataforma e apoiada por diversas ferramentas, também livres.
XML
XML - eXtensible Markup Language é uma recomendação da World Wide Web Consortium
(W3C) [XML 2008] para gerar linguagens de marcação para diferentes necessidades. É um
subtipo da Standard Generalized Markup Language (SGML) ou Linguagem Padronizada de
Marcação Genérica capaz de descrever diversos tipos de dados.
Seu propósito principal é a facilidade de compartilhamento de informações. O formato
XML foi escolhido para persistência dos dados da RBTTool por ser um padrão, de fácil
manipulação, evitando a necessidade de bibliotecas, instalação de ferramentas, necessários
para os bancos de dados.
5.2.2 Ambiente de Desenvolvimento e Frameworks
Nesta Seção, apresentamos o ambiente de desenvolvimento da RBTTool e os frameworks
utilizados.
Eclipse
Eclipse é uma plataforma IDE - Integrated Development Environment focada no
desenvolvimento de ferramentas e aplicações de software. É a IDE Java mais utilizada no
mundo [Eclipse 2008], possui orientação ao desenvolvimento baseado em plug-ins e amplo
suporte ao desenvolvedor com centenas de plug-ins desenvolvidos que procuram atender às
diferentes necessidades. A Eclipse Foundation [Eclipse 2008] mantém vários projetos
envolvendo a sua IDE Eclipse, tornando-a extremamente adaptável às necessidades de cada
cliente.
95
RCP
RCP - Rich Cliente Plataform [RCP 2008] é uma poderosa plataforma de desenvolvimento
que fornece suporte para criação de aplicações com interfaces gráficas, beneficiando-se de
todas as vantagens do Eclipse. A RCP permite aos programadores desenvolver aplicações sem
reescrever as classes do framework, criando, assim, aplicações com rápido desenvolvimento e
integração, utilizando a linguagem Java. A Figura 5.2 apresenta os componentes da
arquitetura da plataforma RCP, onde a RBTTool aparece como um plug-ins que se integra ao
Eclipse.
Figura 5.2 Componentes da Arquitetura RCP (2008).
XStream
O framework XStream [Xstream 2008] está sendo utilizado para persistência dos dados da
RBTTool. Ele nada mais é que uma biblioteca para serialização de objetos através de XML, de
fácil utilização, pois não necessita de mapeamento para serialização dos objetos.
Ferramentas CASE
A ferramenta REM - Requirement Management, desenvolvida por [Duran 2000], foi utilizada
para documentação, gerenciamento e publicação dos casos de uso. O Jude - Java and UML
Developer Environment [JUDE 2008] foi utilizada para criação dos diagramas de casos de uso
e os modelos de análise e projeto da RBTTool. A ferramenta SVN (SubVersioN) [SNV 2008]
foi utilizada para controle de versão dos artefatos.
96
5.2.3 Processos de Desenvolvimento e Gerência de Riscos
O processo de desenvolvimento adotado é uma instância do RUP (2003), já apresentado no
Capítulo 2. O desenvolvimento da RBTTool é iterativo, incremental e orientado por casos de
uso. A cada iteração, os requisitos são detalhados e revisados, são criados diagramas de
análise e projeto e os casos de uso são implementados e testados.
Para a gerência de riscos, adotamos o processo Ágil de Gestão de Riscos em
Ambientes de Múltiplos Projetos (GARA) proposto por [Ribeiro e Gusmão 2008]. Esse
processo está sendo desenvolvido, em um trabalho de mestrado do DSC (Departamento de
Sistemas e Computação) da Universidade de Pernambuco, pelo aluno Lúcio Ribeiro. O
processo consiste em apenas quatro etapas, como apresenta a Figura 5.3 produz um único
artefato, a Matriz de Impedimento.
Visão: consiste na apresentação dos conceitos e objetivos da gerência de riscos.
Realizada apenas uma vez, no início do projeto.
Especulação: consiste em reuniões de brainstorm, onde a equipe levanta riscos
que podem impedir o andamento das atividades e os prioriza. Também são
estabelecidas estratégias de tratamento de resposta aos riscos. O resultado desta
atividade é a matriz de impedimentos.
Exploração: consiste na implemetação de ações para os riscos identificados.
Adaptação: consiste no acompanhamento dos riscos, revendo tratamento de
repostas e comunicando lições aprendidas.
Figura 5.3 Processo Ágil de Gestão de Riscos GARA.
97
5.3 Estágio Atual de Desenvolvimento
Encontra-se em desenvolvimento a primeira versão da RBTTool que contemplará o módulo de
gerenciamento de riscos. Na primeira iteração, foram implementados e testados os casos de
uso Manter Projeto RBT e Manter Requisito. Na segunda iteração, foram desenvolvidos os
casos de uso relacionados à atividade de Identificação de Riscos. Nesta terceira iteração, estão
em desenvolvimento os casos de uso relacionados à atividade de Análise de Riscos.
O Apêndice B apresenta as telas da RBTTool, com um exemplo de utilização.
A equipe RBTTool é composta, atualmente, por quatros membros do DSC da
Universidade de Pernambuco:
A orientadora desta dissertação, responsável pela coordenação da equipe.
A mestranda que apresenta este trabalho, responsável pela definição dos requisitos
e testes da RBTTool.
Um estudante de graduação em fase de conclusão de curso, responsável pelo
estudo e implementação das atividades de identificaçao de riscos.
Um bolsista de iniciação científica, responsável pelo estudo e implementação das
atividades de análise de riscos e processo de teste. Nas primeiras iterações,
trabalhou junto com estudante de graduação em fase de conclusão de curso no
desenvolvimento da ferramenta.
A Tabela 5.1 apresenta o cronograma de atividades realizadas e a concluir neste ano.
Tabela 5.1 Cronograma de atividades do ano de 2008.
Mês/Atividade
Julho
Agosto
Setembro
Outubro
Novembro
Dezembro
Estudo das principais Abordagens RBT
Levantamento dos Requisitos para Construção da RBTTool
Definição e Estudo das Tecnologias e Ferramentas CASE
Configuração do Ambiente de Desenvolvimento
Definição da Arquitetura da RBTTool
Desenvolvimento 1ª Iteração
Desenvolvimento 2ª Iteração
Desenvolvimento 3ª Iteração
5.4 Resumo do Capítulo
Este capítulo forneceu uma visão da RBTTool, uma ferramenta de apoio à abordagem de teste
baseado em riscos. Para a definição dos requisitos necessários para a construção da RBTTool,
98
foram estudadas diversas abordagens RBT, não restringindo o seu escopo apenas a atividades
do RBTProcess.
A primeira versão da ferramenta contempla atividades da gerência de riscos como
identificação e análise de riscos, considerando que estas são essenciais para a abordagem RBT
e, em geral, desconhecidas para os engenheiros de teste.
Os grandes desafios enfrentados pela equipe foram (i) identificar os requisitos que
atendessem às principais abordagens disponíveis na literatura e (ii) definir arquitetura,
levando em consideração a plataforma RCP, que possui uma curva de aprendizado inicial
bastante alta.
99
6
Conclusões
Este Capítulo relata as conclusões obtidas através da realização deste trabalho. A Seção 6.1
destaca as principais contribuições e resultados alcançados fornecidos para a área de teste de
software. A Seção 6.2 apresenta algumas dificuldades e limitações encontradas no decorrer
deste trabalho. A Seção 6.3 fornece uma comparação do RBTProcess com os trabalhos
apresentados no Capítulo 3. Por fim, a Seção 6.4 apresenta trabalhos futuros e em andamento.
6.1 Contribuições e Resultados Alcançados
O RBTProcess é um modelo de processo iterativo, orientado a riscos, modelado no nível
“M1” do SPEM - Software Process Engineering Metamodel e descrito utilizando o EPF -
Eclipse Process Framework.
As disciplinas Identificar, Analisar e Controlar Riscos são provenientes do
gerenciamento de riscos e baseadas no RUP [RUP 2003], Guia PMBOK [PMI 2004] e CMMI
[CMMI 2006].
As disciplinas Planejar, Projetar, Executar e Avaliar Testes são provenientes de
processos de teste, baseadas no IEEE Std. 829-1998: Standard for Software Test
Documentation [IEEE 829 1998], IEEE Std. 1012-1998: Standard for Software Verification
and Validation [IEEE 1012 1998], TMM [Veenendaal 2006] e RUP [RUP 2003].
Apesar das diversas abordagens de teste baseado em riscos apresentadas no Capítulo
3, os engenheiros de teste ainda encontram dificuldade em aplicar RBT na prática.
A finalidade do RBTProcess é fornecer conhecimento e recursos necessários para que
os engenheiros de teste possam utilizar a abordagem RBT, beneficiando-se de todas as
vantagens que ela fornece, apresentadas no Capítulo 3.
Capítulo
100
Além da definição do RBTProcess, outra grande contribuição é a RBTTool, ferramenta
de apoio ao teste de Software baseada em riscos. A RBTTool é independente de processo ou
abordagem, uma vez que ela permite realizar diversas formas de identificação e análise de
riscos disponíveis na literatura.
As simulações de uso de processo e o estudo de caso serviram, respectivamente, para
refinar os componentes do RBTProcess e mostrar que a abordagem RBT, através do
RBTProcess, concentra os esforços de teste nos requisitos de software que possuem maior
probabilidade de apresentar falhas.
Os resultados obtidos no estudo de caso fornecem 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;
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;
Mostrar que a qualidade do produto final é melhorada, como conseqüência de uma
atividade de testes bem planejada;
Mostrar que as atividades da gerência de riscos de software, incluídas no processo
de teste de software, não exigem muitos recursos e tempo para execução e, por
fim,
Fornecer ao gerente de testes subsidios para tomada de decisão.
No entanto, mais estudos de casos, para diferentes domínios de software, necessitam
ser realizados para que os benefícios constatados possam ser generalizados.
6.2 Limitações Encontradas
O modelo de processo proposto neste trabalho, RBTProcess, possui algumas limitações que se
espera reduzir com trabalhos futuros.
A atividade de implementação de casos de teste, ou seja, a automatização de casos de
teste não foi tratada em nenhuma versão do RBTProcess.
Sabemos que os riscos técnicos podem aparecer tanto nos requisitos funcionais, como
nos requisitos não funcionais. O RBTProcess considera apenas atividades para os requisitos
funcionais, não fornecendo formas de tratamento para os requisitos não funcionais que, em
geral, são mais difíceis de testar.
101
Por fim, diversas limitações foram identificadas no estudo de caso. (i) algumas
atividades importantes do processo não puderam ser executadas por falta de disponibilidade
da equipe; (ii) muitas das atividades do processo ainda foram realizadas pela autora; (iii) o
estudo de caso realizado, considerou apenas os requisitos funcionais para a execução das
atividades do processo e (iv) o tempo para realização da atividade de projeto de casos de teste
baseado em riscos e casos de teste funcionais não foram coletadas para comparação.
6.3 Trabalhos Relacionados
Comparando o modelo de processo proposto, o RBTProcess, com as demais abordagens
apresentadas no Capítulo 3, tem-se:
Descrição completa das atividades necessárias para execução de testes funcionais
baseados em riscos, fornecendo uma separação clara das atividades de teste e de
riscos de software, de forma a facilitar a adoção por empresas que ainda não
possuem um processo de teste de software definido, como também para aquelas
que já possuem e estão em constante evolução;
Utilização e adaptação de questionário baseado em taxonomia de riscos, proposto
pelo SEI [Carr et al 1993], com o propósito de auxiliar a identificação dos riscos
associados aos requisitos do produdo de software e fornecer subsídio para o
projeto dos casos de teste;
Adaptação e validação do cálculo de exposição a risco, proposto por [Amland
1999], para considerar o impacto de alterações em uma funcionalidade nas demais;
Fornecimento de guias, templates e métricas para as atividades do processo de
teste de software baseado em riscos;
Documentação e publicação do modelo de processo na web, utilizando ferramenta
open source que permite instanciação e criação de novos processo.
6.4 Trabalhos Futuros
Abaixo segue uma lista de trabalhos futuros, dentre os quais, alguns já estão em
desenvolvimento.
Com relação ao RBTProcess podemos citar como trabalhos futuros:
102
Realização de estudos de caso, sem a participação da autora, para diferentes
domínios de software utilizando a RBTTool. A equipe MPhyScas, inclusive,
demonstrou interesse em utilizar novamente o processo.
Definição de métricas para controle e medição do impacto da adoção do
RBTProcess em uma organização. Essas, apesar de serem muito importantes, não
foram tratadas neste trabalho.
Fornecer questionário baseado em taxonomia para os diferentes domínios de
software, ou seja, criar um banco de dados de questionários baseado em
taxonomia.
Realização de estudos sobre padrões de teste de software com o objetivo de
pesquisar os padrões existentes e identificar novos padrões para alguns domínios
de software, verificando a possibilidade da utilização de padrões para projeto de
testes baseados em riscos.
Com relação à RBTTool podemos citar como trabalhos futuros:
Conclusão da implementação das atividades de Análise de Riscos. Atividade em
andamento.
Implementação das atividades do processo de teste de software.
Implementação de arquitetura distribuída para que as atividades sejam realizadas
online pelos participantes e os resultados contabilizados automaticamente pela
ferramenta.
Implementar técnicas de inteligência artificial para automatizar atividades do
processo de teste baseado em riscos, especialmente as atividades pertencentes ao
gerenciamento de riscos.
103
Bibliografia
[Amland 1999] Amland, S. Risk Based Testing and Metrics: Risk analysis fundamentals and
metrics for software testing including a financial application case study. In: 5o
International Conference EuroSTAR’99, 1999.
[Bach 1995] Bach, J. The Challenge of Good Enough Software. In: American Programmer,
1995.
[Bach 1999] Bach, J. James Bach on Risk-Based Testing: How to conduct heuristic risk
analysis. In: Software Testing & Quality Engineering Magazine, p.23-28, 1999.
[Bach 2003] Bach, J. Troubleshooting Risk-Based testing. In: Software Testing & Quality
Engineering Magazine, 2003.
[Besson 2004] Besson, S. A Strategy for Risk-Based Testing. Disponível em
<StickyMinds.com>. Acesso em agosto de 2007.
[Boehm 1991] Boehm, B. W. Software Risk Management: Principles and Practices. In: IEEE
Software, v.8, p.32-40, 1991.
[Burnstein et al 1999] Burnstein, I.; Homyen, A.; Suwanassart, T.; Saxena, G.; Grom, R. A
Testing Maturity Model for Software Test Process Assessment and Improvement. In:
Software Quality Professional Magazine, v.1, n.4, 1999.
[Carr et al 1993] Carr, M. J.; Konda, S.L.; Monarch, I.; Ulrich, F. C.; Walker, C. Taxonomy
Based Risk Identification. Technical Report CMU/SEI-93-TR-6. Software Engineering
Institute, Carnegie Mellon University/USA, 1993.
[Chen 2002] Chen, Y. Specification-based Regression Testing Measurement with Risk
Analysis. Dissertação de Mestrado, University of Ottawa/Canada, 2002.
[CMMI 2006] CMMI for Development, Version 1.2. Disponível em
<www.sei.cmu.edu/publications/documents/06.reports/06tr008.html>. Acesso em Janeiro
de 2008.
[Cornell et al 2000] Cornell, G.; horstman, S.; Core Java 2: Fundamentos. 1a edição, Makron
Books, 2000.
104
[Delamaro et al 2007] Delamaro, M.; Maldonado, J.; Jino M. Introdução ao Teste de
Software. 1a edição, Elsevier, 2007.
[Duran 2000] Duran, A. A Methodological Framework for Requirements Engineering of
Information Systems. Tese de Doutorado, University of Serville/Spain, 2000.
[Eclipse 2008] Projeto Eclipse. Disponível em <http://www.eclipse.org/>. Acesso em Julho
de 2008.
[EPF 2007] Eclipse Process Framework. Disponível em <www.eclipse.org/epf/>. Acesso em
Agosto de 2007.
[Fontoura et al 2004] Fontoura, L.; Price, R. Usando GQM para Gerenciar Riscos em Projetos
de Software. In: 18º Simpósio Brasileiro de Engenharia de Software, 2004.
[Graig e Jaskiel 2005] Graig, R. D.; Jaskiel S. P. Systematic software testing. Artech House
Publishers, 2005.
[Goldsmith 2006] Goldsmith, R. Early and Effective: The Perks of Risk-based Testing. In:
Software Test and Performance Magazine, v.3, p.24-30, 2006.
[GQM 2008] Goal Question Metric Approach (GQM), Disponível em
<https://www.goldpractices.com/practices/gqm/> Acesso em Maio de 2008.
[Graham et al 2007] Graham, D.; van Veenendaal, E.; Evans, I.; Black, R. Foundations of
Software Testing: ISTQB Certification. Thomson Learning, 2007.
[Gusmão 2007] Gusmão, C. Um Modelo de Processo de Gestão de Riscos para Ambientes de
Múltiplos Projetos de Desenvolvimento de Software. Teste de Doutorado, Universidade
Federal de Pernambuco/Brasil, 2007.
[IEEE 829 1998] IEEE Std. 829, Standard for Software Test Documentation, 1998.
[IEEE 1012 1998] IEEE Std. 1012, Standard for Software Verification and Validation, 1998.
[Jorgensen 2004] Jørgensen, L. A Software Tool for Risk-Based Testing. Trabalho de
Graduação, Norwegian University of Science and Technology/Norway, 2004.
[JUDE 2008] Java and UML Developer Environment. Disponível em <http://jude.change-
vision.com/jude-web/product/community.html>. Acesso em Janeiro de 2008.
[Kaner et al 1999] Kaner, C.; Falk, J.; Nguyen, H. Q. Testing computer software. 2a edição,
Wiley, 1999.
[Konda 2008] Konda, R. Measuring Defect Removal Accurately. Disponível em
<http://www.stpmag.com/downloads/stp-0507_testmetrics.htm>. Acesso em Setembro de
2008.
105
[Lins 2007] Lins, F. Modelagem da mPRIME Ontology em Lógica Descritiva e
Implementação. Trabalho de Graduação, Universidade Federal de Pernambuco/Brasil,
2007.
[Loh 1996] Loh, S. Ambientes de Desenvolvimento de Software e Ferramentas CASE.
Disponível em <http://atlas.ucpel.tche.br/~loh/ads.htm>. Acesso em Julho de 2008.
[Meyers 1979] Meyers, G. J. The Art of Software Testing. John Wiley and Sons, 1979.
[MPhyScas 2007] Multi-Physics and Multi-Scales Solver Environment. Disponível em
<http://www.dsc.upe.br/~mphyscas/MPhyScaS/project.html>. Acesso em Setembro de
2008.
[PMI 2004] PMI – Project Management Institute. A Guide to the Project Management Body
of Knowledge. ANSI/PMI 99-01-2004. Project Management Institute, 2004.
[RBTProcess 2008] RBTProcess – Modelo de Processo de Teste de Software baseado em
Riscos. Disponível em < http://www.dsc.upe.br/~eprs/rbt/process/> Acesso em Outubro
de 2008.
[RBTTool 2008] RBTTool – Ferramenta de Apoio ao Teste de Software baseado em Riscos.
Disponível em <http://www.dsc.upe.br/~eprs/rbt/tool/>. Acesso em Novembro de 2008.
[RCP 2008] Rich Client Platform Wikipedia. Disponível em
<http://wiki.eclipse.org/index.php/Rich_Client_Platform>. Acesso em Junho de 2008.
[Redmill 2004] Redmill, F. Exploring risk-based testing and its implications. In: Software
Testing, Verification and Reliability, v.14, p.3-15, 2004.
[Reffson et al 2006] Reffson, A.; Bezerra, C.; Coutinho, E,; Façanha, F. Análise da Aderência
de um Processo de Teste ao TMM. In: 1o Simpósio Brasileiro de Testes de Software,
SBTS, 2006.
[Ribeiro e Gusmão 2008] Ribeiro, L.; Gusmão, C.; Definição de um Processo Ágil de Gestão
de Riscos em Ambientes de Múltiplos Projetos. In: Hífen Magazine (Uruguaiana), 2008.
[Rios 2005] Rios, E. Análise de Riscos em Projetos de Teste de Software. Alta books, 2005.
[Rosenberg et al 1999] Rosenberg, L. H.; Stapko, R.; Gallo, A. Risk-based Object Oriented
Testing. In: 24o Annual Software Engineering Workshop, NASA SEW24, 1999.
[RUP 2003] Rational Unified Process. Versão 2003. Disponível em
<http://www.wthreex.com/rup/>. Acesso em Janeiro de 2008.
[RUP 2008] IBM Rational Unified Process Wikipedia. Disponível em
<http://pt.wikipedia.org/wiki/Rational_Unified_Process>. Acesso em Janeiro de 2008.
106
[Sartori 2005] Sartori, L. Melhoria de Processo para Pequenas Empresas. Dissertação de
Mestrado, Universidade de Marília/Brasil, 2005.
[Schaefer 2002] Schaefer H. Strategies for Prioritizing Tests Against Deadlines – Risk Based
Testing. Disponível em <http://home.c2i.net/schaefer/testing/risktest.doc>. Acesso em
Agosto de 2007.
[SEI 2006] Risk Management. Disponível em <http://www.sei.cmu.edu/risk/>. Acesso em
janeiro de 2008.
[SMG 2001] Software Metrics Guide, Disponível em
<http://sunset.usc.edu/classes/cs577b_2001/metricsguide/metrics.html#p31>. Acesso em
Janeiro de 2008.
[SPEM 2005] Software Process Engineering Metamodel. Versão 1.1, 2005.
[Stallbaum et al 2008] Stallbaum, H.; Metzger, A.; Pohl, K. An Automated Technique for
Risk-based Test Case Generation and Prioritization. In: 3rd Workshop on Automation of
Software Test, AST, 2008.
[Soares et al 2002] Soares, S.; Laureano, E.; Borba, P. Implementing Distribution and
Persistence Aspects with AspectJ. In: 17o ACM conference on OOPSLA’ 02, ACM Press,
p.174–190, 2002.
[Sommerville 2003] Sommerville, I. Engenharia de Software, Addison Wesley, 2003.
[SVN 2008] Subversion. Disponível em <http://subversion.tigris.org/>. Acesso em Agosto de
2008.
[Vasconcelos 2007] Modelos de Maturidade para Teste de Software. Disponível em
<www.qualiti.com.br/arquivos/institucional/apresentacaoAlexandreVasconcelos_AMCH
AM.pdf>. Acesso em Janeiro de 2008.
[Veenendaal 2006] van Veenendaal, E. Guidelines for Testing Maturity, STEN Journal, v.4,
2006.
[XML 2008] Extensible Markup Language. Disponível em <http://www.w3.org/XML/>.
Acesso em Julho de 2008.
[Xstream 2008] Xstream. Disponível em <http://xstream.codehaus.org/>. Acesso em Janeiro
de 2008.
107
Pesquisa sobre a Abordagem de Teste
baseado em Riscos
Tem como objetivo principal, investigar o conhecimento dos engenheiros de teste sobre a
abordagem de teste baseado em riscos. Também, identificar possíveis utilizações da
abordagem e o grau de satisfação das pessoas que a estão utilizando.
O Questionário foi respondido por profissionais de tecnologia da informação que trabalham
com teste de software, como, por exemplo, Gerentes de Testes, Analistas de Testes,
Arquitetos de Testes, Projetistas de Testes e Testadores.
Questionário
1. Como você classifica o seu conhecimento sobre a abordagem de Teste Baseado em Riscos
(RBT - Risk-based Testing)? (selecione apenas uma opção)
Desconheço.
Já li ou ouvi falar, mas não conheço sua aplicação.
Conheço e entendo sua aplicação.
Conheço e já utilizei a abordagem.
1.1 Caso conheça ou já tenha utilizado a abordagem, como você a classifica? (selecione
apenas uma opção)
Ruim.
Razoável.
Boa.
Ótima.
Apêndice A
108
Justifique sua resposta da Questão 1.1
2. Qual o seu conhecimento sobre Identificação e Análise de Riscos de Software? (mais de
uma opção pode ser selecionada)
Não tenho conhecimento.
Conhecimento acadêmico.
Conhecimento adquirido através de cursos de aperfeiçoamento.
Conhecimento adquirido através de prática (no trabalho).
2.1 Como você classifica o seu conhecimento sobre Identificação e Análise de Riscos de
Software? (selecione apenas uma opção)
Básico.
Intermediário.
Avançado.
3. Como você classifica a equipe de teste da empresa onde você trabalha? (selecione apenas
uma opção)
A empresa não possui equipe de teste independente.
A empresa possui equipe de teste independente.
Para alguns projetos, a empresa possui equipe de teste independente.
4. Qual o tamanho da equipe de teste da empresa onde você trabalha? (selecione apenas uma
opção)
Até 5 pessoas.
Entre 5 e 10 pessoas.
Entre 10 e 20 pessoas.
Mais que 20 pessoas.
5. Qual a localização da empresa onde você trabalha? (selecione apenas uma opção)
Recife - Porto Digital.
Recife - RMR.
Outro Estado.
6. Qual a principal abordagem utilizada na empresa onde você trabalha? (selecione apenas
uma opção)
Funcional ou Caixa preta
Estrutural ou Caixa branca
7. Você possui alguma certificação da área de teste? (selecione apenas uma opção)
Sim.
109
Não.
7.1 Se possui certificação, informe o(s) nome(s)?
8. Selecione abaixo a sua última formação completa: (selecione apenas uma opção)
Graduação.
Especialização.
Metrado.
Doutorado.
9. Informe quanto tempo você trabalha com testes de software: (em anos)
Resultados
Perfil dos participantes
No total, 80 pessoas participaram da pesquisa. Com relação a localização geográfica, 39% dos
entrevistados estão localizados no estado de Pernambuco, sendo que destes, 15% estão
localizados no Porto Digital. Os outros 61% estão localizados nos demais estados do país.
Com relação à formação, 53% dos entrevistados possuem graduação, 26%
especialização, 16% mestrado e 5% doutorado.
Organizações que realizam Atividade de Teste de Software
Apenas 17% dos entrevistados afirmaram que a empresa, na qual trabalham, não possui
equipe independe de teste de software. 47% afirmaram que a empresa possui, normalmente,
equipe de teste independe e 13% afirmaram que, para alguns projetos, a empresa possui
equipe independente. Essa informação é bastante relevante, pois o RBTProcess necessita de
uma equipe de teste independente e bem estruturada.
De acordo com os entrevistados, a maioria das empresas (39%) possui equipes
pequenas para a atividade de teste, com até cinco pessoas. No entanto, quase 30% das
empresas possuem equipes grandes, com mais de 20 pessoas. 31% possuem equipes medianas
entre 5 e 20 pessoas.
Além disto, 90% dos entrevistados afirmaram que as empresas, na qual trabalham,
realizam teste caixa-preta. Apenas 10% informaram a realização de teste caixa-branca.
Conhecimento sobre Riscos de Software
Sobre a gerência de riscos, 24% dos entrevistados informaram não possuir conhecimento
sobre esta área. 28% possuem conhecimento acadêmico, enquanto que 10% fizeram cursos de
110
aperfeiçoamento na área e 38% adquiriam conhecimento no trabalho. Isto indica que, nos
cursos de graduação, o investimento na área de gerência de riscos deixa a desejar.
Com relação ao nível de conhecimento sobre riscos de software, 10%, 40% e 50%, dos
entrevistados classificam, respectivamente, os seus conhecimentos como avançado,
intermediário e básico. Ou seja, um número muito grande de engenheiros de teste tem
conhecimento básico sobre riscos de software.
Conhecimento sobre Teste de Software
A maioria dos entrevistados (49%) possui entre 2 e 5 anos de experiência na área. Outros 42%
possuem até 2 anos de experiência na área. O restante (9%) possui experiência de mais de 5
anos na área.
Apenas 15% dos entrevistados informaram possuir certificações na área de teste de
software. Sendo a certificação do ISTQB, e sua versão em português (BSTQB), as mais
comuns.
Conhecimento sobre Teste de Software baseado em Riscos
Sobre a abordagem RBT, um número bastante alto (40%) de entrevistados afirmou não
conhecer e nem ter ouvido falar sobre a abordagem. Apenas 8.5% dos entrevistados
afirmaram ter utilizado a abordagem RBT. Destes, 30% e 50% a classificaram,
respectivamente, como boa e ótima. A principal justificativa dos que a classificaram como
razoável (15%) é a falta de conhecimento das atividades da gerência de riscos, que
compromete a precisão dos resultados da identificação e análise dos riscos associados aos
requisitos. Uma característica encontrada nas pessoas que já utilizaram a abordagem é o
conhecimento intermediário ou avançado sobre atividades de gerência de riscos de software.
21.5% dos entrevistados afirmaram conhecer a abordagem e entender a sua aplicação na área.
Destes, 13% e 67% a classificaram, respectivamente, como boa e ótima.
111
RBTTool: Telas
Tela de Criação de Projeto RBT
Apêndice B
112
Tela de Inclusão de Requisitos
Tela de Visualização dos Requisitos adicionados a um Projeto RBT
113
Tela de Inclusão de Questionário em um Projeto RBT
Tela de Inclusão de Perguntas em um Questionário
Tela de Visualização das Perguntas do Questionário
114
Tela de Identificação de Riscos através de Questionário
.
115
Tela de Relatório de Resultado da Identificação de Riscos
116
RBTProcess: Papéis
Role: Analista de Riscos
Responsável pela identificação, análise e controle dos riscos de técnicos de software.
Role Sets: Papéis RBT Process
Relationships
Modifies
• Lista de Riscos de Critérios de Qualidade
• Lista de Riscos Específica
• Lista de Riscos Genérica
• Questionário Baseado em Taxonomia
• Documento de Identificação dos Riscos
• Lista de Priorização dos Riscos
• Documento de Análise dos Riscos
• Relatório de Avaliação dos Riscos
Staffing
Skills
Conhecimento sobre teste de software, identificação e análise dos riscos, além de profundo
conhecimento sobre os requisitos do software.
Role: Gerente de Testes
Responsável pela planejamento e acompanhamento das atividades e recursos de testes.
Role Sets: Papéis RBT Process
Relationships
Apêndice C
117
Additionally
Performs
• Responder Questionário TQB
• Realizar Reunião de Brainstorm
• Calcular Exposição ao Risco
Modifies
• Plano de Testes de Software
Staffing
Skills
Processo e conceitos de testes de software, gerência de projeto e recursos e outros.
Assignment
Approaches
Em alguns processos, o Arquiteto ou Projetista de Testes é responsável pelo planejamento e
acompanhamento dos testes.
Role: Projetista de Testes
Responsável pela identificação, criação e avaliação dos casos e procedimentos de testes.
Synonyms: Em alguns processos, essa atividade é realizada pelo Arquiteto de Testes.
Role Sets: Papéis RBT Process
Relationships
Additionally
Performs
• Responder Questionário TQB
• Realizar Reunião de Brainstorm
• Calcular Exposição ao Risco
• Definir Escopo do Testes
• Definir Estratégias
Modifies
• Projeto de Casos de Testes
• Especificação de Casos de Testes
• Procedimento de Casos de Testes
• Planilha de Execução de Testes
• Relatório de Avaliação dos Testes
118
• Plano de Testes de Software
Staffing
Skills
O projetista necessita de um conhecimento aprofundado sobre os requisitos do sistema e tecnologia
adotada, sobre os riscos, ferramentas, técnicas para construção, estratégias e tipos de testes.
Synonyms
Em alguns processos, essa atividade é realizada pelo Arquiteto de Testes.
Role: Testador
Responsável pela execução dos casos de testes e criação das solicitações de mudança.
Role Sets: Papéis RBT Process
Relationships
Additionally
Performs
• Responder Questionário TQB
• Realizar Reunião de Brainstorm
• Calcular Exposição ao Risco
Modifies
• Planilha de Execução de Testes
• Log de Testes
• Solicitação de Mudança
Staffing
Skills
O testador necessita de conhecimento sobre o processo de teste, ferramentas utilizadas para
execução, configuração do ambiente de execução e solicitação de mudança, além do conhecimento
sobre os requisitos do sistema.
119
RBTProcess: Atividades
Identificar Riscos
Task: Revisar Fontes e Categorias de Riscos
O objetivo dessa atividade é avaliar e adaptar as listas de riscos e o questionário baseado em taxonomia para o
software que será testado. Os artefatos disponíveis no processo são genéricos e podem ser utilizados em qualquer
projeto de desenvolvimento.
Disciplines: Identificar Riscos
Relationships
Roles Primary Performer:
• Analista de Riscos
Additional Performers:
Inputs
Mandatory:
• Lista de Riscos de Critérios de
Qualidade
• Lista de Riscos Específica
• Lista de Riscos Genérica
• Questionário Baseado em Taxonomia
Optional:
• Documento de Requisitos
• Documento de Riscos do Projeto
Outputs
• Lista de Riscos de Critérios de Qualidade
• Lista de Riscos Específica
• Lista de Riscos Genérica
• Questionário Baseado em Taxonomia
Steps
Revisar lista de riscos genérica
Revisar listas de riscos de critérios de qualidade
Revisar listas de riscos específica
Revisar questionário baseado em taxonomia
More Information
Concepts
• Riscos de Software
Apêndice D
120
Task: Responder Questionário TQB
Identificar os riscos técnicos de software associados aos requisitos através da utilização do questionário baseado em
taxonomia.
Disciplines: Identificar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
• Analista de Requisitos
• Desenvolvedores de Software
• Gerente de Testes
• Projetista de Testes
• Testador
Inputs
Mandatory:
• Documento de Requisitos
• Questionário Baseado em Taxonomia
Optional:
• None
Outputs
• Documento de Identificação dos Riscos
Steps
Responder questionário
Consolidar resultados
Key Considerations
• Os participantes não precisam ter qualquer conhecimento sobre os riscos.
• O SEI recomenda cinco participantes para esta atividade.
More Information
Concepts
• TQB
• Riscos de Software
Guidelines
• Questionário Baseado em Taxonomia
Task: Realizar Reunião de Brainstorm
Validar os riscos identificados através do questionário baseado em taxonomia.
Disciplines: Identificar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
• Analista de Requisitos
• Desenvolvedores de Software
• Gerente de Testes
• Projetista de Testes
• Testador
Inputs
Mandatory:
• Documento de Identificação dos Riscos
• Lista de Riscos de Critérios de
Qualidade
• Lista de Riscos Específica
Optional:
• Documento de Requisitos
• Documento de Riscos do Projeto
121
• Lista de Riscos Genérica
• Questionário Baseado em Taxonomia
Outputs
• Documento de Identificação dos Riscos
Steps
Validar riscos identificados no questionário
Identificar possíveis riscos através do uso de listas
Identificar possíveis riscos que não estão em listas ou questionário
Classificar os riscos identificados
Key Considerations
• São utilizadas as listas de riscos para guiar a reunião.
• As reuniões de brainstorm com listas de riscos visam tornar a reunião mais eficiente.
More Information
Concepts
• Riscos de Software
• TQB
Guidelines
• Reunião de Brainstorm
• Classificação dos Riscos
Analisar Riscos
Task: Calcular Exposição ao Risco
Para cada requisito, é calculada a sua exposição ao riscos.
Disciplines: Analisar Riscos
Purpose
Priorizar os requisitos de acordo com o risco.
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
• Analista de Requisitos
• Desenvolvedores de Software
• Gerente de Testes
• Projetista de Testes
• Testador
Inputs
Mandatory:
• Documento de Identificação dos Riscos
Optional:
• None
Outputs
• Documento de Análise dos Riscos
Main Description
• Três fontes de análise de risco são utilizadas:
i. qualidade da função (área) a ser testada P(f).
ii. conseqüências de uma falha em uma função do ponto de vista de um cliente em uma situação de produção C(c) e
iii. conseqüências de uma falha em uma função do ponto de vista do vendedor do serviço C(v) como mostrado na
equação abaixo.
122
Steps
Calcular probabilidade
Calcular custo
Calcular exposição ao risco
More Information
Guidelines
• Cálculo de Exposição ao Risco
Task: Priorizar Requisitos
Priorização dos Requisitios de acordo com a análise de riscos realizada.
Disciplines: Analisar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
• Analista de Requisitos
Inputs
Mandatory:
• Documento de Análise dos Riscos
Optional:
• Documento de Requisitos
Outputs
• Lista de Priorização dos Riscos
Steps
Identificar requisitos com alto Risco
Identificar requisitos com médio Risco
Identificar requisitos com baixo Risco
Planejar Testes
Task: Definir Escopo do Testes
Definir os requisitos que serão testados e os qua não serão testados para cada iteração com base na análise dos riscos,
Disciplines: Planejar Testes
Relationships
Roles
Primary Performer:
• Gerente de Testes
Additional Performers:
• Analista de Requisitos
• Projetista de Testes
Inputs
Mandatory:
• Cronograma do Projeto
• Lista de Priorização dos Riscos
• Plano de Projeto
Optional:
• None
Outputs
• Plano de Testes de Software
123
Steps
Identificar requisitos que serão Testados
Identificar requisitos que NÃO serão Testados
Task: Definir Critérios de Sucesso e Falha dos Testes
Definir critérios de parada e aceitação dos casos de testes.
Disciplines: Planejar Testes
Relationships
Roles
Primary Performer:
• Gerente de Testes
Additional Performers:
Outputs
• Plano de Testes de Software
Task: Definir Cronograma
Definir o cronograma para planejamento, projeto e execução dos testes para cada iteração.
Disciplines: Planejar Testes
Relationships
Roles
Primary Performer:
• Gerente de Testes
Additional Performers:
Inputs Mandatory:
• Cronograma do Projeto
• Lista de Priorização dos Riscos
• Plano de Projeto
Optional:
• None
Outputs
• Plano de Testes de Software
Task: Definir Estratégias
Definir estratégias para planejamento, projeto, execução e avaliação dos testes com base na análise dos riscos.
Disciplines: Planejar Testes
Relationships
Roles
Primary Performer:
• Gerente de Testes
Additional Performers:
• Projetista de Testes
Inputs
Mandatory:
• Cronograma do Projeto
• Lista de Priorização dos Riscos
• Plano de Projeto
Optional:
• None
Outputs
• Plano de Testes de Software
Steps
124
Definir estratégia para requisitos com alto risco
Definir estratégia para requisitos com médio risco
Definir estratégia para requisitos com baixo risco
More Information
Concepts
• Estágios dos Testes
Task: Definir Itens e Artefatos de Testes
Identificar itens de testes e definir baselines para cada um deles.
Disciplines: Planejar Testes
Relationships
Roles
Primary Performer:
• Gerente de Testes
Additional Performers:
Inputs
Mandatory:
• Plano de Projeto
Optional:
• None
Outputs
• Plano de Testes de Software
Steps
Identificar itens de testes (testware)
Definir os basealines dos itens de testes
Projetar Testes
Task: Projetar Casos de Testes
Especificar o projeto dos casos de testes definindo cenários, abordagens, tipos de testes e critérios de sucesso e falha
para o caso de teste.
Disciplines: Projetar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Documento de Requisitos
• Lista de Priorização dos Riscos
• Plano de Testes de Software
Optional:
• None
Outputs
• Projeto de Casos de Testes
Steps
Identificar caso de teste
Definir cenários
Definir abordagem
Definir tipo de teste
125
Definir Critérios de sucesso e falhas do caso de teste
More Information
Concepts
• Abordagem de Testes
• Cenários de Testes
• Tipo de Testes
Guidelines
• Tipos de Testes para Riscos Identificados
Task Especificar Casos de Testes
Identificar itens de testes, definir entradas e saídas para o casos de testes e critérios de sucesso e falha.
Disciplines: Projetar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Especificação de Casos de Testes
Optional:
• None
Outputs
• Especificação de Casos de Testes
Steps
Identificar itens de teste
Definir entradas e saídas do casos de testes
Definir pré e pós condições do casos de testes
Dependência dos casos testes
Task: Descrever Procedimento de Testes
Descrever os passos necessários para realização do caso de teste.
Disciplines: Projetar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Especificação de Casos de Testes
Optional:
• None
Outputs
• Procedimento de Casos de Testes
Steps
Task: Criar Pacotes de Execução de Testes
Criar planilhas para execução de acordo com o planejamento dos testes baseado em riscos.
Disciplines: Projetar Testes
Relationships
Roles
Primary Performer: Additional Performers:
126
• Projetista de Testes
Inputs
Mandatory:
• Especificação de Casos de Testes
• Procedimento de Casos de Testes
• Projeto de Casos de Testes
Optional:
• None
Outputs
• Planilha de Execução de Testes
Executar Testes
Task: Configurar Ambiente de Testes
Configurar o ambiente necessário para realização dos testes, respeitando os baselines definidos no plano de testes.
Disciplines: Executar Testes
Relationships
Roles
Primary Performer:
• Testador
Additional Performers:
Inputs
Mandatory:
• Planilha de Execução de Testes
• Plano de Testes de Software
Optional:
• None
Steps
Identificar itens de testes
Configurar ambiente
Task: Executar Testes
Executar os testes, seguindo os precedimentos detalhados e na ordem definida na planilha de execução dos
testes.
Disciplines: Executar Testes
Relationships
Roles
Primary Performer:
• Testador
Additional Performers:
Inputs
Mandatory:
• Planilha de Execução de Testes
• Procedimento de Casos de Testes
Optional:
• None
Outputs
• Planilha de Execução de Testes
Task: Reportar Resultados
Registra resultado da execução através de logs e solicitações de mudanças.
Disciplines: Executar Testes
Relationships
127
Roles
Primary Performer:
• Testador
Additional Performers:
Inputs
Mandatory:
• Planilha de Execução de Testes
Optional:
• None
Outputs
• Log de Testes
• Solicitação de Mudança
Steps
Manter log de testes
Registrar solicitação de mudança
More Information
Concepts
• Classificação dos Defeitos
Avaliar Testes
Task: Avaliar Cobertura
Avaliar a cobertura dos testes com relação aos requisitos do software.
Disciplines: Avaliar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Log de Testes
• Planilha de Execução de Testes
• Plano de Testes de Software
• Projeto de Casos de Testes
• Solicitação de Mudança
Optional:
• None
Outputs
• Relatório de Avaliação dos Testes
Task: Avaliar Estratégias
Avaliar as estratégias dos testes com relação aos requisitos do software.
Disciplines: Avaliar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Log de Testes
• Planilha de Execução de Testes
• Plano de Testes de Software
• Projeto de Casos de Testes
• Solicitação de Mudança
Optional:
• None
128
Outputs
• Relatório de Avaliação dos Testes
Task: Avaliar Resultado Geral dos Testes
Avaliar o resultado final dos testes, gerando relatório com percentual de testes executado para os requisitos do software.
Disciplines: Avaliar Testes
Relationships
Roles
Primary Performer:
• Projetista de Testes
Additional Performers:
Inputs
Mandatory:
• Log de Testes
• Planilha de Execução de Testes
• Solicitação de Mudança
Optional:
• None
Outputs
• Relatório de Avaliação dos Testes
Controlar Riscos
Task: Identificar Riscos Mitigados
Identificar, através dos logs de testes e solicitações de mudanças, quais riscos foram mitigados.
Disciplines: Controlar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
Inputs
Mandatory:
• Documento de Análise dos Riscos
• Lista de Priorização dos Riscos
• Log de Testes
• Relatório de Avaliação dos Testes
• Solicitação de Mudança
Optional:
• None
Outputs
• Relatório de Avaliação dos Riscos
Task: Atualizar Status dos Riscos
Documentar o percentual dos riscos mitigados após bateria de execução dos testes.
Disciplines: Controlar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
129
Inputs
Mandatory:
• Documento de Análise dos Riscos
• Lista de Priorização dos Riscos
• Log de Testes
• Relatório de Avaliação dos Testes
• Solicitação de Mudança
Optional:
• None
Outputs
• Relatório de Avaliação dos Riscos
Task: Avaliar Resultado Geral dos Riscos
Avaliar o resultado geral, informando o percentual de riscos mitigados por requisito.
Disciplines: Controlar Riscos
Relationships
Roles
Primary Performer:
• Analista de Riscos
Additional Performers:
Inputs
Mandatory:
• Documento de Análise dos Riscos
• Lista de Priorização dos Riscos
• Log de Testes
• Relatório de Avaliação dos Testes
• Solicitação de Mudança
Optional:
• None
Outputs
• Relatório de Avaliação dos Riscos
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
