RBTProcess: Modelo de Processo de Teste de Software ...livros01.livrosgratis.com.br/cp118979.pdf · baseado em Riscos, constituído de atividades da gerência de riscos e de processos

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

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


Orientador: Prof. Dra. Cristine Martins Gomes de Gusmão

Recife, Dezembro/2008.

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 - UPE

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

CUSTO

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 FURPS1

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 Unidade

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

Atividades 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

RASTREAR

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

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(

vCcCfPf

+=

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.

AB

OR

DA

GE

M/

PR

OC

ESS

O

IDE

NT

IFIC

AR

R

ISC

OS

AN

AL

ISA

R R

ISC

OS

PL

AN

EJA

R

TE

STE

S

PR

OJE

TA

R

TE

STE

S

EX

EC

UT

AR

T

EST

ES

AV

AL

IAR

TE

STE

S

CO

NT

RO

LA

R

RIS

CO

S

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


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


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


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.

Business Goals

Measurement Goals

Question

Metric

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.


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


� 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


� 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


Gerente do Projeto, Gerente de Testes, Analista de Riscos


� 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



� Foi elaborado relatório com o resultado dos testes para cada abordagem

Atividade Controlar Riscos

Avaliar Resultado Geral dos Riscos

Analista de Riscos


� 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

LO

CA

L

STA

TE

S

CR

EA

TE

P

HE

NO

ME

NO

N

PH

EN

OM

EN

ON

ST

AT

ER

EL

AT

ION

QU

AN

TIT

Y

TA

KS

GR

OU

P

TA

SK

SEA

RC

H

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


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

Julh

o

Ago

sto

Sete

mbr

o

Out

ubro

Nov

embr

o

Dez

embr

o

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.


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.


Relationships


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


Relationships


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


Relationships


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.


Relationships



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



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


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.


Relationships




Task: Definir Cronograma

Definir o cronograma para planejamento, projeto e execução dos testes para cada iteração.


Relationships




Optional: • None


Task: Definir Estratégias

Definir estratégias para planejamento, projeto, execução e avaliação dos testes com base na análise dos riscos.


Relationships


Additional Performers: • Projetista de Testes


Optional: • None


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.


Relationships



Inputs Mandatory: • Plano de Projeto

Optional: • None


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


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.


Relationships



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.


Relationships



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.


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


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.


Relationships



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.


Relationships

127



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



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.


Relationships



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


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.


Relationships



Inputs Mandatory: • Log de Testes • Planilha de Execução de Testes • Solicitação de Mudança

Optional: • None


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



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.


Relationships



129


Optional: • None


Task: Avaliar Resultado Geral dos Riscos

Avaliar o resultado geral, informando o percentual de riscos mitigados por requisito.


Relationships




Optional: • None


Livros Grátis( http://www.livrosgratis.com.br )

Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







Documents

RBTProcess: Modelo de Processo de Teste de Software ...livros01.livrosgratis.com.br/cp118979.pdf · baseado em Riscos, constituído de atividades da gerência de riscos e de processos