teste de software baseado em risco

Fernando Schiavo Cardoso
RA 0502032 – 8º Semestre
TESTE DE SOFTWARE BASEADO EM RISCO
Jaguariúna
2008
Fernando Schiavo Cardoso
RA 0502032 – 8º Semestre
TESTE DE SOFTWARE BASEADO EM RISCO
Monografia apresentada à disciplina Trabalho
de Graduação III, do curso de Ciências da
Computação da Faculdade de Jaguariúna, sob
orientação do Prof. Ms. FERNANDO AUGUSTO
ZANCHETA como exigência para conclusão do
curso de graduação.
Jaguariúna
2008
2
CARDOSO, Fernando Schiavo. Teste de Software Baseado em Risco. Monografia
defendida e aprovada na FAJ em 20 de novembro de 2008 pela banca examinadora
constituída pelos professores:
__________________________________________________________________________
Prof. Fernando Augusto Zancheta –
FAJ – orientador
__________________________________________________________________________
Prof.
FAJ
__________________________________________________________________________
Prof.
FAJ
3
AGRADECIMENTOS
Antes de tudo, agradeço a Deus por me fortalecer nas horas em que eu mais
precisava.
A toda a minha família, especialmente aos meus pais Natércia e Hermínio e aos
meus avós Jatenete e Antonio por terem sido tão maravilhosamente dedicados e amorosos,
sempre me guiando pelos melhores caminhos da vida.
Agradecimentos especiais devem ser feitos também ao professor Fernando Augusto
Zancheta, que, nos momentos em que se ausentou como orientador foi para se apresentar
como amigo. A todos os demais que contribuíram para este trabalho, muito obrigado!
4
CARDOSO, Fernando Schiavo. Teste de Software Baseado em Risco. 2008. Monografia
(Bacharelado em Ciências da Computação) – Curso de Ciências da Computação da
Faculdade de Jaguariúna, Jaguariúna.
RESUMO
Este trabalho apresenta um estudo acadêmico sobre um método de teste de
software que está constantemente sendo alvo de estudos por parte dos profissionais da
área de teste. O teste de software baseado em risco é aplicado no planejamento dos testes
associados aos requisitos do produto de software. Conhecido pelo termo em inglês risk –
based testing, esse método consiste em identificar, priorizar e criar casos de teste que
exploram os riscos. O objetivo desse trabalho é abordar as principais vantagens e limitações
defendidas pelos autores aqui citados.
Palavra chave: Teste de Software, Risco.
5
ABSTRACT
This body of work presents an academic study of a software testing method which is
constantly being the target of studies by professionals who specialise in this area of testing.
the software test based on risk, is applied in the planning of tests associated with the
requirements of a software product. known by the english term "risk based testing", this
method consists of identifying, prioritising and creating tests cases that explore risk.
The objetive of this study is to tackle the principal advantages and limitations which are
defended by the authors stated within.
Keywords: Test Software, Risk.
6
SUMÁRIO
LISTA DE FIGURAS.................................................................................................. 09
LISTA DE TABELAS...................................................................................................10
LISTA DE ABREVIATURAS E SILGAS......................................................................11
1. INTRODUÇÃO........................................................................................................12
2. QUALIDADE DE SOFTWARE ...............................................................................13
3. TESTE DE SOFTWARE.........................................................................................14
3.1 Validação e verificação.............................................................................15
3.1.1 Verificação..................................................................................16
3.1.2 Validação....................................................................................16
3.2 Classificação; Erro, Defeito e Falha..........................................................17
3.3 Técnicas de teste de software...................................................................17
3.1.1 Teste estrutural ou teste de caixa – branca...............................17
3.1.2 Teste funcional ou teste de caixa – preta...................................18
3.4 Caso de teste............................................................................................18
4. PROCESSO DE TESTE DE SOFTWARE..............................................................19
4.1 Definição...................................................................................................19
4.2 Ciclo de vida do processo de teste de software........................................21
4.3 Modelo de teste de software.....................................................................22
5. RISCOS DE SOFTWARE.......................................................................................26
5.1 Análise de risco.........................................................................................27
5.2 Classificação.............................................................................................28
6. TESTE DE SOFTWARE BASEADO EM RISCO...................................................28
6.1 Definição de teste de software baseado em risco.....................................29
7
7. ANÁLISE DE RISCO BASEADO EM HEURÍSTICA..............................................31
7.1 De fora para dentro...................................................................................31
7.1.1 Lista de observação de risco......................................................33
7.1.2 Matriz risco/tarefa.......................................................................33
7.2 De dentro para fora...................................................................................33
7.2.1 Aplicação da abordagem “de fora para dentro”......................................33
8. VANTAGENS E RESTRIÇÕES DO TESTE DE SOFTWARE BASEADO EM
RISCOS......................................................................................................................41
8.1 Vantagens.................................................................................................41
8.2 Restrições.................................................................................................41
8.3 Conclusão.................................................................................................41
9. BIBLIOGRAFIA.....................................................................................................43
8
LISTA DE FIGURAS
Figura 1 –
Conceito 3P3E.
Figura 2 -
Integração entre os processos de desenvolvimento e teste.
Figura 3 -
Modelo de Karolak
Figura 4 -
Os 11 passos do Processo de Teste de Software.
Figura 5 –
Fluxo Funcional da aplicação: (Manutenção na Faixa Salarial).
Figura 6 –
Página 1 Exibição das Faixas Cadastradas.
Figura 7 –
Página 3 Alteração das Faixas Salariais.
Figura 8 –
Página 4 Exclusão das Faixas Salariais.
Figura 9 -
Matriz de Componente x Risco Bach(1999).
9
LISTA DE TABELAS
Tabela 1 –
Testes que exploram os riscos analisados.
Tabela 2 –
Testes que exploram os riscos analisados.
10
LISTA DE ABREVIATURAS E SILGAS
(V&V) –
Validação e Verificação.
MPS.BR –
Melhora de Processo do Software Brasileiro.
11
1
INTRODUÇÃO
Quando os sistemas informatizados começaram a ganhar âmbito comercial, os
testes eram executados dentro do processo de desenvolvimento de software, ministrados
apenas pelos próprios desenvolvedores e em alguns casos os próprios usuários eram
envolvidos no processo para ajudar a criar os dados de teste e a aprovação do sistema final.
Porém, esse teste tinha uma cobertura muito restrita, e conseqüentemente gerava
uma grande incidência de defeitos, que geralmente eram corrigidos em outras versões do
sistema.
Segundo Rios (2008, p.91) no final da década de 1990 e início do ano 2000, “houve
a explosão da internet e o surgimento de novas tecnologias, isso passou a expor a imagem
das empresas em um cenário de grande veiculação no mercado”, fato que levou as
organizações a investirem em testes mais elaborados a fim de garantir que os seus
negócios não fossem prejudicados, transformando o teste de software em um processo
independente e fundamental na garantia de qualidade dos sistemas.
Para atender esse cenário, segundo Rios e Moreira (2008, p. 45) “o processo de
teste de software passou a ser executado em paralelo ao processo de desenvolvimento,
onde ganhou planejamento e organização sendo conduzido por técnicos treinados e
qualificados.” Os resultados foram imediatos, as empresas preocupadas com a sua imagem
no mercado e na redução dos custos de desenvolvimento, passaram a investir
continuamente em teste de software, porém junto com essa demanda, veio também à
necessidade de investimento, que agregava custos e tempo para a realização do processo
de teste, onde muitas vezes o tempo de teste era maior que o tempo de planejamento e
codificação do próprio software.
Devido à grande concorrência e aos prazos cada vez mais escassos na produção
dos softwares, não há tempo o suficiente para uma perfeita execução do processo de teste,
em muitos casos, o sistema acaba saindo para produção com pouca cobertura de teste,
deixando passar erros graves e conseqüentemente prejudicando a empresa e os
respectivos clientes.
Nesse cenário, o teste de software baseado em riscos tem se mostrado de grande
utilidade, aproveitando melhor os recursos e o tempo do teste, perfazendo um processo que
aborde as áreas de maior risco do sistema e garantindo que o negócio não saía prejudicado.
12
Este trabalho tem o objetivo de apresentar um estudo acadêmico sobre o teste de
software baseado em riscos, focando os ganhos e restrições da utilização dessa técnica,
com base nas obras literárias e artigos disponíveis no meio eletrônico.
2
QUALIDADE DE SOFTWARE
A busca pela qualidade não é uma novidade entre diversas empresas de diversos
seguimentos. Quando alguns fatos são considerados, fica evidente a grande necessidade
da busca desse conceito. No caso dos softwares o surgimento da internet expondo a
imagem das empresas para um grande público, a grande concorrência no mercado de
desenvolvimento de software, a demanda e a crescente complexidade das aplicações são
fatores que levaram as organizações a melhorarem a qualidade dos softwares
desenvolvidos. Rios (2007, p.17).
Porém a busca desse conceito não é tão fácil como aparenta, muito pelo contrário,
qualidade não é um termo tão trivial e de acordo com Koscianski e Soares (2007, p.17):
A idéia de qualidade é aparentemente indutiva; contudo,
quando examinamos mais longamente, o conceito se revela
complexo. Definir qualidade para estabelecer objetivos é,
assim, uma tarefa menos trivial do que aparenta a principio.
O software é construído por pessoas, e cada uma delas tem um conceito de
qualidade diferente, e por esse fato, qualidade de software deve ser buscada principalmente
com o correto emprego de boas metodologias pelo grupo de desenvolvimento. Pressman
(2007, p.724), define a garantia de qualidade de software da seguinte maneira:
Conformidade a requisitos funcionais e de desempenho
explicitamente declarados, a padrões de desenvolvimento
claramente documentados e a características implícitas que
são esperadas de todo software profissionalmente
desenvolvido.
Para Pressman (2007, p.724) qualidade em software pode ser definida objetivamente
da seguinte forma:
•
Qualidade é estar em conformidade com os requisitos do cliente;
•
Qualidade é antecipar e satisfazer os requisitos dos clientes;
•
Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito.
13
O conceito de qualidade de software pode ser resumido como uma série de
atividades que tem o objetivo de garantir que o software seja construído de forma correta,
eficiente e que seu resultado atenda as expectativas do cliente.
Para o início dos testes, segundo Rios (2007, p.11), há três dimensões de qualidade
que precisam ser consideradas:
•
Confiança: o sistema é resistente a falhas;
•
Funcionalidade: suas funcionalidades seguem os requisitos;
•
Performance: o sistema quando submetido a um volume de processamento próximo
ao real, tem um tempo de resposta aceitável.
O sistema tem que realizar o objetivo pretendido pelo usuário, ou seja, o sistema tem
que estar livre de falhas durante a sua execução, as regras de negócio tem que estar de perfeita
conformidade com os requisitos e por fim o sistema tem que ter um tempo de resposta
aceitável.
3
TESTE DE SOFTWARE
Diversas definições sobre teste de software são encontradas na literatura
especializada, abaixo segue alguns exemplos:
•
Para Rios (2007, p. 109) testar é:
Verificar se o software está fazendo o que deveria fazer, de
acordo com seus requisitos, e se na está fazendo o que não
deveria fazer.
•
A norma ANSI/IEEE Standard (1983, p. 729), refere-se a teste como:
... o processo de avaliar um sistema ou um componente de
um sistema por meios manuais ou automáticos para verificar
se ele satisfaz os requisitos especificados ou identificar
diferenças entre resultados esperados e obtidos.
•
Para Myers (2004), teste de software é o:
...processo de executar um programa com o objetivo de
encontrar erros...
14
Um bom caso de teste é aquele que tem uma elevada
probabilidade de revelar um erro ainda não descoberto.
Um teste bem sucedido é aquele que revela um erro ainda
não descoberto.
De modo geral, teste de software se caracteriza como:
•
Atividade de encontrar erros e defeitos ainda não descobertos antes da fase
de homologação;
•
Assegurar que os requisitos especificados na fase de requisitos foram
realmente atendidos;
•
Garantir que os riscos para o negócio foram minimizados;
•
Certificar que as necessidades do cliente foram atendidas.
Segundo Delamaro, Maldonado e Jino (2007, p. 1) “a construção de software não é
uma tarefa simples. Pelo contrário, pode se tornar bastante complexa dependendo das
características e dimensões do sistema a ser criado.” Devido a esse fato, está sujeita a
diversos tipos de problemas que acabam resultando na obtenção de um produto diferente
daquele que se esperava.
Para que esses problemas possam ser descobertos antes que o software chegue ao
cliente, é de suma importância que ele passe por um processo de revisão, a fim de garantir
que os requisitos estejam conforme especificados pelo cliente. Esse processo de revisão é
representado pela atividade de teste de software, onde segundo Pressman(2007, p. 786)
essa atividade é um elemento crítico da garantia da qualidade final do sistema.
3.1 Validação e verificação
A atividade de teste é dividida em duas grandes áreas chamadas de verificação e
validação (V&V). Essas áreas são responsáveis por assegurar que o software cumpra com
suas especificações e atenda às necessidades dos usuários. Para Koscianski e Soares
(2007, p.332) essas áreas constituem em uma serie de atividades que tem início com as
revisões dos requisitos, passando pelas revisões das análises e do projeto de software e as
inspeções do código até chegar aos testes. Pressman (2007, pg. 836) coloca duas questões
para expor a diferença entre (V&V):
15
•
Verificação: “Estamos construindo certo o produto?”
•
Validação: “Estamos construindo o produto certo?”
3.1.1
Verificação
É um conjunto de atividades que determinam se os requisitos especificados foram
efetivamente atendidos no sistema, ou seja, certificar-se que software cumpre com as suas
especificações.
3.1.2
Validação
É um conjunto de atividades que confirmam se a especificação de uma fase ou do
sistema completo é apropriada e consiste com os requisitos do cliente. O software deve
estar de acordo com o que os usuários desejam.
Para citar alguns exemplos das atividades de (V&V) segundo Rios (2007, p.30):
•
Atividades de Verificação: revisões de requisitos, revisões de modelos, revisões
de código e inspeções técnicas em geral.
•
Atividades de Validação; teste unitário, teste integração, teste de sistemas, teste
de aceitação e teste de homologação.
As atividades de (V&V) estão distribuídas por todas as etapas do processo de teste,
cada atividade apresenta duas características distintas: “testes estáticos” e “testes
dinâmicos”.
A atividade de verificação é executada antes da atividade de validação, os
documentos são verificados antes da execução dos testes, por essa razão suas atividades
têm a característica de testes estáticos já que nessa atividade o software não é executado.
Por outro lado, a atividade de validação é realizada depois da atividade de verificação, as
técnicas utilizadas nessa fase utilizam à execução do software e são caracterizadas como
testes dinâmicos.
16
3.2 Classificações: Erro, Defeito e Falha.
Para que se possa ter um perfeito entendimento sobre a área de teste de software, é
muito importante que os três conceitos relacionados abaixo estejam bem esclarecidos.
Segundo a terminologia padrão para Engenharia de Software do IEEE – Institute of
Electrical and Electronics Engineers – (1990, p. 610),
•
Erro: engano, alguma coisa feita por humanos. Como por exemplo, um
desenvolvedor que entendeu mal os requisitos de uma aplicação.
•
Defeito: o resultado de um erro. O desenvolvedor criou uma aplicação com os
requisitos diferentes do especificado.
•
Falha: diferença indesejável entre o observado e o esperado, software diferente
do esperado pelo usuário. (Defeito encontrado). O usuário ao executar a
aplicação, percebeu que os resultados esperados não batem com os resultados
retornados.
3.3 Técnicas de teste de software
Os resultados dos testes de software devem refletir as ações tomadas para descobrir
erros introduzidos no planejamento das funcionalidades definidas nas especificações dos
programas e outros erros inseridos durante a codificação do programa. Segundo Rios (2007,
p. 48) os tipos e técnicas de testes podem ser classificados em:
3.3.1
Teste estrutural ou teste de caixa-branca
Essa técnica avalia o comportamento interno do componente de software, ou seja,
trabalha diretamente sobre o código-fonte. Seu objetivo é garantir que a estrutura do
sistema esteja sólida e que funcione corretamente. Os tipos de testes utilizados por essa
técnica buscam determinar se a tecnologia foi utilizada corretamente e se os componentes
do sistema estão funcionando de forma coesa.
A escolha dessa técnica depende de uma análise dos requisitos e o nível de
complexidade do sistema já que geralmente essa técnica tendem a tomar muito tempo do
projeto de teste, por isso, o momento para que essas decisões sejam tomadas é no
momento da criação dos requisitos de teste e do planejamento.
17
Essa técnica é recomendada para as fases de Teste da Unidade e Teste da
Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software,
que por sua vez conhecem bem o código-fonte produzido.
Um exemplo prático desta técnica de teste é o uso de ferramenta de teste livre como
o JUnit para desenvolvimento de casos de teste (test cases) para testar classes ou métodos
desenvolvidos em linguagem Java. Também se enquadram nessa técnica testes manuais
ou testes efetuados com apoio de ferramentas para verificação de aderência a boas
práticas.
3.3.2
Teste funcional ou teste de caixa-preta
Essa técnica de teste foca as regras de negócio do sistema através dos requisitos e
funcionalidades do software. Ao contrário dos testes estruturais descritos a cima, essa
técnica não avalia a parte interna do sistema e sim a saída das informações do mesmo.
Segundo Pressman (2007, p. 816) ”os testes de caixa-preta procuram descobrir erros
nas seguintes categorias: (1) funções incorretas ou ausentes; (2) erros de interface; (3) erros
nas estruturas de dados ou acesso a banco de dados externos; (4) erros de desempenho; e (5)
erros de inicialização e término.”
Para Rios (2007, p. 31) os testes funcionais são executados nas últimas etapas do
processo da atividade. Para realizar esses testes, o sistema tem que estar codificado e
logicamente desenvolvido.
3.4 Caso de Teste
A aplicação dessa técnica é realizada através de um conjunto de dados de teste bem
planejados que têm o objetivo de avaliar as saídas do sistema para cada dado inserido.
Após o término da listagem de requisitos de teste, casos de teste são elaborados
procurando dar cobertura aos requisitos do sistema listados nos requisitos de teste.
Para Rios (2007, p.110) existem algumas técnicas principais que são utilizadas nos
testes funcionais, abaixo segue dois exemplos:
18
•
Classe de Equivalência: é grupo de valores de entrada que representam o
universo de teste. Por exemplo, para um intervalo de (x) os valores limites estão
especificados como: (10 <= x => 20). Nesse caso a classe de teste de
equivalência contém três valores ou situações: (9), (15) e (21). O primeiro e o
último valor nesse caso estão fora do intervalo, ou seja, geraria um caso de
defeito, e o segundo valor que está dentro do intervalo, geraria um caso de
sucesso.
•
Análise de Valor Limite: é um grupo de valores de entrada que toma como
base os limites de cada campo. No caso do exemplo da classe de equivalência
acima, os valores ou situações seriam: (9) e (11) para testar o limite inferior, (10)
e (20) para testar o limite igual e (19) e (21) para testar o limite superior.
Além desses dois exemplos acima, Rio (2007) também descreve com algumas das
técnicas de teste funcional as técnicas de: Combinação de dados, tabela de decisão, teste
de interface entre outros.
4
PROCESSO DE TESTE DE SOFTWARE
Conforme já comentado na introdução de trabalho, os resultados mais expressivos
das atividades de testes só começaram a aparecer depois que a atividade de teste começou
a ser tratada como um processo.
4.1 Definição do processo de teste
Para Molinari (2008, p. 74) um processo de engenharia de software é definido como
um conjunto de passos parcialmente ordenados, cujo o objetivo é atingir uma meta para
entregar um produto de software de maneira eficiente, previsível e que vá ao encontro das
necessidades de negócio.
Para a MPS.BR (2007) um processo de teste tem o objetivo de alcançar as seguintes
definições:
•
Aumento da qualidade do produto;
•
Diminuição do retrabalho;
19
•
Maior produtividade;
•
Redução do tempo para atender o mercado;
•
Maior competitividade;
•
Maior precisão nas estimativas;
•
Acompanhamento da satisfação do cliente.
Os testes passaram a ser tratados não como uma atividade dentro do processo de
desenvolvimento mais sim como um processo próprio. Os testes passaram a ter uma
metodologia própria a ser executados junto com o início do processo de desenvolvimento.
Quanto antes os testes comecem a ser executados, mais barato fica a correção dos defeitos
encontrados.
Figura 1 - Integração entre os processos de desenvolvimento e teste
Fonte: Rios,Emerson; Análise de Risco em Projeto de Teste, 2007. Pág.102.
20
•
Desenho lógico é físico: Nessa fase os testes de verificação asseguram que o
desenho do sistema esteja de acordo com os requisitos especificados.
•
Construção: Os testes unitários são executados em paralelo a codificação do
sistema. Os componentes desenvolvidos podem ser testados através dos testes
unitários.
•
Implementação: Nessa fase o sistema já está codificado e suas funcionalidades
lógicas já estão funcionando. Os testes de sistema e de integração são
executados.
•
Entrega: Os testes de aceitação são planejados e executados em conjunto com
o cliente.
4.2 Ciclo de vida do processo de teste
O ciclo de vida do processo de testes, conforme mostrado na Figura 1.2, é composto
por diversas etapas ou fases, sendo quatro delas seqüenciais ou em cascata e duas
paralelas.
Planejamento
Procedimentos
Iniciais
Especificação
Execução
Entrega
Preparação
Figura 2 – Conceito 3P3E
Fonte: Rios, Emerson; Moreira, T. Testes de Software, 2003. Pág. 9.
21
•
Procedimentos iniciais: Os objetivos do processo de software são definidos;
Requisitos do negócio, Atividades a serem executadas, Recursos humanos
e Recursos de ambiente.
•
Planejamento: Criação e revisão da estratégia e plano de testes.
•
Preparação: Preparação do ambiente de testes, rede, equipamentos,
pessoal, software, ferramentas.
•
Especificação: Criação dos Casos de testes e roteiros de testes.
•
Execução: Executar os casos de teste.
•
Entrega: Finalização do processo de testes com a entrega do sistema.
4.3 Modelo de teste
Um modelo de teste é um conjunto de técnicas que representam as dimensões do
teste, ou seja, em que fase do desenvolvimento se aplica um determinado teste.
Para Rios (2007, p. 146) as principais técnicas de teste são:
•
Teste de Unidade: essa técnica de teste costuma ser executada pelos
próprios desenvolvedores a fim de testar os componentes do software
visando garantir que as unidades de código atendam especificações do
sistema.
•
Teste de Integração: vida garantir que um ou mais componentes do sistema
funcionam corretamente.
•
Teste de Sistema: execução do sistema como um todo, teste voltado para
validar a exatidão e a perfeição na execução das funções do sistema.
•
Teste de aceitação: última ação de teste antes da implementação do
software, sua execução é de responsabilidade do cliente. O objetivo desse
teste é verificar se o sistema está conforme o cliente solicitou.
O modelo de teste em “V” segundo Molinari (2008, p. 68) “é o mais popular entre
todos existentes, pois se trata de um conceito simples e muito prático.” Do lado esquerdo do
“V” fica o ciclo de desenvolvimento do software e ao lado direito fica a parte do processo de
teste que segundo Bastos e Rios (2006) são:
22
•
Acesso ao Plano de Desenvolvimento: Pré-requisito para a construção do Plano de
Testes. Nessa fase é feita uma verificação do plano de desenvolvimento e é possível
estimar os recursos necessários para a realização dos testes.
•
Desenvolvimento do Plano de Testes: segue os mesmos padrões do plano de
desenvolvimento, sua estrutura varia conforme os riscos associados com o software
que está sendo desenvolvido.
•
Inspeção ou Teste dos Requisitos do Software: Através da técnica de verificação, os
requisitos do software são avaliados. Essa fase dos testes é de grande importância.
Requisitos
mal
analisados
representam
a
maioria
dos
insucessos
do
desenvolvimento do software.
•
Inspeção ou Teste do Desenho do Software: Através da técnica de verificação, o
desenho do software é verificado a fim de garantir que o objetivo dos requisitos foi
alcançado no desenho do software.
•
Inspeção ou Teste da Construção do Software: A partir do desenho do sistema é
determinado o tipo e a extensão dos testes que serão necessários. Quanto mais a
construção se torna automatizada, menos testes serão requeridos durante esta fase.
•
Execução dos testes: O código do sistema é testado dinamicamente, as abordagens
e ferramentas especificadas no plano de teste serão usadas para validar se os
requisitos do desenho do sistema foi realmente implementados.
•
Teste de Aceitação: fase de validação do software pelos usuários. Além dos
requisitos documentados, os usuários geralmente testam outras funções não
documentadas. Nessa fase, é necessário analisar os possíveis erros encontrados
pelo usuário já que esses erros podem ser tratados como mudanças e não como
erro.
•
Informação dos Resultados dos Testes: Os resultados do teste devem ser
armazenados em um documento ou relatório de teste que contenha os defeitos
encontrados no processo. Esse documento deve ser informado aos setores
envolvidos o mais rápido possível, de forma que as correções sejam feitas com o
menor custo possível.
•
Teste da Instalação do Software: Visam verificar a compatibilidade do sistema
operacional com os procedimentos operacionais do software. O resultado vai
23
determinar se o software está em condições de ser implantado no ambiente de
produção ou não.
•
Teste das Mudanças no Software: Essa fase cobre as mudanças durante o processo
de implementação e aquelas que irão ocorrer após o software estar implantado.
•
Avaliação da Eficácia dos Testes: Após o término dos testes, deve ser feito uma
avaliação da eficácia dos mesmos. Esse processo tem que ser realizado pelos
testadores, porém os desenvolvedores, usuários e outros profissionais podem ser
envolvidos.
24
PASSO 1
Acesso ao Plano de
Desenvolvimento e
Situação
DEFINIÇÃO DOS
REQUERIMENTOS
DE SOFTWARE
PASSO 2
Desenvolvimento do
Plano de Testes
PASSO 3
Testes dos Requisitos
do Software
CONSTRUÇÃO DO
SOFTWARE
PASSO 4
Teste do Desenho do
Software
PASSO 5
Teste de Construção
do Software
PASSO 6
Execução e Registro
dos Testes
INSTALAÇÃO DO
SOFTWARE
PASSO 7
Teste de Aceitação
PASSO 8
Informação dos
Resultados dos
Testes
OPERAÇÃO E
MANUTENÇÃO
DO SOFTWARE
PASSO 9
Instalação do
Software
PASSO 10
Teste das Mudanças
do Software
PASSO 11
Avaliação da Eficácia
dos Testes
Figura 3 – Os 11 passos do Processo de Teste de Software
Fonte: Bastos, Anderson; Rios, Emerson; Cristalli, Ricardo; Moreira, Trayahu. Base de
conhecimento em teste de software, 2006. Pág. 66.
25
5
RISCOS DE SOFTWARE
Segundo o “Aurélio”: Risco “1. Perigo ou possibilidade de perigo. 2. Possibilidade
de perda ou de responsabilidade por danos”.
Risco é a possibilidade de sofrer uma perda, um impacto na qualidade do produto
final, um atraso do cronograma, um aumento nos custos ou falha do projeto. (SEI – Software
Engineering Institute).
Um risco nunca é uma certeza de ocorrência. Se alguma coisa vai realmente
ocorrer com probabilidade de 100%, então isso é um problema e não um risco. Um risco
pode ser tratado preventivamente, o que não o corre com um problema.
Rios. Emerson (2007, p.37) define o risco como;
Risco é um evento no futuro cuja ocorrência poderá causar
algum tipo de problema, no caso, o projeto, o produto ou o
negócio.
Não há uma certeza de que o evento vai ocorrer, porém, caso ocorra, uma perda
poderá trazer sérios problemas. Para o teste de software, um problema seria deixar passar
um erro no software por não ter testado um módulo importante.
Para citar um exemplo, um avião sempre corre o risco de cair, mais a perda só
existirá se isso ocorrer! É dever das empresas aéreas, realizarem todas as manutenções
necessárias em suas aeronaves, para que o risco de que um problema venha causar a
queda de um avião seja sempre o mais baixo possível.
No caso do software, ao realizar um processo de análise de risco, os esforços de
teste vão ser priorizados nas áreas em que um erro possa representar um grande impacto
para o cliente ou para o negócio, dessa forma, como citado no exemplo do avião, acima, o
objetivo é reduzir ao máximo possível a ocorrência de um erro que possa causar um grave
impacto ao negócio.
26
5.1 Análise de risco
A atividade de teste de software está bastante ligada ao risco. Quando um testador
por motivo de tempo ou por qualquer outro motivo, deixa de testar uma parte do sistema, ele
está assumindo um risco já que uma parte do sistema não será testada. Se esse risco vier a
se materializar, ou seja, essa parte do sistema que não foi testada conter um erro, a
empresa poderá sofrer uma grave perda financeira.
O gerenciamento de risco é um processo que tem o intuito de reduzir a
probabilidade da ocorrência de eventos que poderiam ter um impacto negativo no produto
final.
Segundo Rios (2007. p. 93) o risco é um dos elementos mais importantes a ser
trabalhado no momento de elaborar um projeto de teste de uma aplicação.
Para fazer uma análise de risco segundo Rios(2007. p 94) é preciso avaliar o
seguinte:
•
Probabilidade da ocorrência do risco;
•
O impacto se houver uma perda associada ao risco.
Ao planejar os testes, esses dois elementos devem ser levados em conta,
Risco
=
Probabilidade
(possibilidade de falha)
X
Impacto
(prejuízo causado pela falha)
Risco para teste de software é definido como a possibilidade de um erro em uma
aplicação vezes o prejuízo caso esse erro se materialize como uma falha.
Os riscos têm que ser analisados principalmente pelos seguintes motivos abaixo:
•
Para avaliar as conseqüências em caso de falha do produto;
•
Para decidir as ações certas e necessárias antes e depois de o risco se materializar;
•
Prevenir os impactos negativos;
•
Proteger as vítimas (clientes e usuários);
•
Para priorizar os riscos;
•
Para ter critério e direção (bússola) antes e durante a execução dos testes;
27
•
Para fazer o melhor uso dos recursos investidos (materiais, humanos e tempo);
•
Conhecer as áreas que precisam de maior atenção;
•
Conhecer com antecedência o que pode dar errado (Testes pró-ativos).
De um modo geral, ao analisar os riscos no software, é possível obter um
embasamento importante sobre as áreas e recursos que serão suficientes para conduzir um
bom teste no software, evitando desperdício de recursos dando mais ênfase na parte do
sistema mais crítico para o sucesso do sistema.
5.2 Classificação
Os principais riscos em um projeto de teste de software segundo Rios (2008, p. 92) são:
•
Riscos de projeto: são riscos ligados diretamente ao projeto. Exemplo:
problemas com orçamento, cronograma, pessoal, recursos, cliente e requisitos.
•
Riscos técnicos: são riscos relacionados à qualidade do software a ser
desenvolvido Exemplo: defeitos no software, problemas com implementação,
interface, ambigüidade de especificação.
•
Riscos para o negócio do cliente: afetam as organizações envolvidas no negócio
seja por mudanças no orçamento, prazo de desenvolvimento ou problemas de
mercado.
Nesse trabalho de monografia, será abordado somente os “Riscos Técnicos”, ou
seja, riscos que podem se materializar como falha no software.
6
TESTE DE SOFTWARE BASEADO EM RISCOS
James Bach em 1995 publicou um artigo chamado: The Challenge of Good Enough
na revista American Programmer. Nesse artigo, Bach apresentou uma nova abordagem de
teste, que foi intitulada de teste baseado em risco (risk-based testing). Essa abordagem
28
consiste em um conjunto de atividades que favorecem a identificação de fatores de riscos
associados aos requisitos do produto de software.
Para materializar o conceito de (risk-based testing) segundo Molinari (2008, p. 79) é
importante levar em conta três situações:
•
É impossível ou inviável testar todas as funcionalidades de um sistema; Para essa
situação é muito importante que o teste seja bem planejado, ou seja, criar um plano
de teste que contenha a cobertura que será explorada no teste e as condições de
início e final do processo de teste.
•
Na grande maioria das vezes, os prazos para o desenvolvimento dos softwares não
são cumpridos; Para essa situação é necessário que as partes mais importantes do
sistema sejam priorizadas.
•
Para o sucesso na execução dessa abordagem é muito importante que o testador
tenha um bom conhecimento da aplicação; A análise de risco não é algo trivial, muito
pelo contrário, é algo bem abstrato. Para ser bem feito, é muito importante que o
profissional de teste, tenha um bom conhecimento sobre o sistema a ser testado.
A partir do momento em que os riscos são priorizados, são gerados os casos de
testes baseados nas estratégias de tratamento e acompanhamento dos fatores de riscos
que foram previamente identificados.
A abordagem dos testes baseados em riscos segundo Bach(1999) foca fazer
julgamento sobre:
•
Cobertura de teste;
•
O número de testes a ser conduzido;
•
Escolhas dos tipos de testes e de revisões;
•
Uso e balanceamento entre testes, revisões e inspeções, dentre outros
problemas;
•
Priorização dos testes (planejamento e execução).
6.1 Definições de teste de software baseado em risco
Em Bach(1999) é utilizada a definição das etapas e atividades do processo de teste
baseado em risco da seguinte forma:
29
1 – Elaborar uma lista de riscos com suas prioridades: Identificação e análise dos riscos do
software.
2 - Realizar testes que explora cada risco: Criação e execução dos testes que verificam a
existência dos riscos identificados.
3 – Gerenciar os riscos: Assim que um risco for eliminado, um novo risco surge e os
esforços de testes devem ser reajustados para que foquem sempre nos riscos mais
importantes.
Apesar de simples, essa definição consegue abordar a idéia principal da
abordagem de teste de software baseada em risco.
Essa abordagem se concentra em analisar software e criar um plano teste baseado
nas áreas que possuam a maior probabilidade de apresentarem problemas que teriam o
maior impacto sobre o mesmo. (MCMAHOM,1998 apud ROSENBERG;STAPKO;GALLO
,1999).
Ao avaliar os riscos de um projeto, o analista de teste busca aqueles fatos cujas
ocorrências poderão acarretar em perdas para a empresa. Nesta abordagem um produto é
analisado utilizando-se as seguintes perdas:
•
Vulnerabilidade: Quais franquezas ou possíveis falhas existentes neste
componente?
•
Ameaça: Que entradas ou situações poderiam existir que podem explorar uma
vulnerabilidade e disparar uma falha neste componente?
•
Vítimas: Quem ou o quê poderia ser impactado por uma possível falha e quão
ruim isto seria?
Após o levantamento dessas informações, o analista de teste tem os subsídios
necessários para criar os casos de testes específicos que ira abordar o sistema em sua
parte mais vulnerável. Assim é possível concluir se será necessário escrever um caso de
teste para determinada situação.
De forma geral o processo de teste de software baseado em riscos seria descrito de
tal maneira; “processo de identificar os riscos de um sistema, analisar esses riscos, priorizálos, criar casos de teste que mitiga os riscos identificados e gerenciar sua execução.”
30
7. ANÁLISE DE RISCO BASEADO EM HEURÍSTICA
Bach (1999) descreve dois métodos de análise para identificar os riscos;
7.1 De fora para dentro
É feito uma análise geral e predefine riscos baseados na experiência em sistemas
semelhantes. Em geral usa-se para essa abordagem fontes como: riscos de qualidade, listas
gerais de risco e até mesmo catálogo de riscos conhecidos e pré-documentados.
Bach (1999) sugere o uso de três tipos de listas;
1.
Lista de critérios e categorias de qualidade desenvolvida a partir dos critérios
da norma ISO/IEC 9126:
•
Capacitação; Ele pode desempenhar as funções necessárias?
•
Confiabilidade; Será que vai funcionar bem e resistir aos defeitos em todas as
situações exigidas?
•
Usabilidade; O usuário conseguirá realizar com sucesso as tarefas pretendidas
pelo sistema?
•
Performance; O sistema terá uma resposta aceitável pelo usuário nas
realizações de suas funções?
•
Instalabilidade; O sistema pode ser instalado facilmente nas principais
plataformas existentes no mercado?
•
Compatibilidade; O sistema é compatível com componentes externos ou
outras configurações?
•
Suportabilidade; O suporte aos usuários do sistema está dentro do
orçamento do projeto?
•
Testabilidade; Como o produto pode efetivamente ser testado?
•
Manutenibilidade; a tarefa de construir, corrigir ou melhorar o produto não
será mais onerosa que o planejado?
•
Portabilidade; a tecnologia utilizada para a elaboração do sistema poderá
ser utilizada para outros produtos?
•
Localizabilidade; a tarefa de publicar o sistema para outras línguas não será
uma tarefa mais onerosa que o planejado?
31
2.
Na lista de riscos genéricos, são relacionados os riscos universais para
qualquer sistema. Para Rios (2008, p. 34) os maiores riscos de encontrar um
defeito são:
•
Funções muito complexas;
•
Funções completamente novos;
•
Funções freqüentemente alteradas;
•
Funções onde uma determinada ferramenta foi usada pela primeira vez no seu
desenvolvimento;
•
Funções que forem transferidas de um desenvolvedor para outro durante o
desenvolvimento do software;
3.
•
Funções que foram construídas sob pressão;
•
Funções que sofrem muita otimização – mais do que a média;
•
Funções onde muitos defeitos foram encontrados;
•
Funções com muitas interfaces.
Lista de catalogo de risco é caracterizada como um esboço de riscos que
pertencem a um determinado domínio. Segue abaixo uma versão resumida do
que seria um catálogo de riscos:
• Escolher qual o componente ou função se pretende analisar;
• Determinar a escala de preocupação;
• Recolher informações sobre as coisas que vão ser analisadas;
•
Analise cada área de risco de cada lista e determine a sua importância;
•
Caso ocorra algum risco que não está listado, refaça a lista e re agrupe os
riscos;
•
Confira a distribuição dos riscos.
32
7 .1.1 Lista de observação de risco
Segundo Bach(1999) esta é a maneira mais simples de organizar os riscos. É uma
lista de riscos que o testador periodicamente a revisa e pergunta a si mesmo, o que a
atividade de teste revelou sobre os riscos.
7.1.2 Matriz Risco/Tarefa
A relação matriz risco/tarefa segundo Bach(1999) consiste de uma tabela com duas
colunas. À esquerda está uma lista de riscos, a direita está uma lista de tarefas de redução
dos riscos associados a cada risco. Ordene os riscos por sua importância no topo da tabela.
Componente
Risco
Heurística
Impressão
Normal
Distribuído, popular
Geração de relatórios
Alto
Novo,
estratégico,
terceirizado e critico.
Instalação
Baixo
Popular,
Usabilidade
e
modificado.
Bibliotecas de imagens
Baixo
Complexo
Tabela 1 - Matriz de Componente x Risco Bach(1999).
7.2 De dentro para fora
Após um estudo das principais funcionalidades do produto, é feita uma pergunta; O
que pode dar errado aqui? Mais especificamente, para cada parte do produto é avaliado as
vulnerabilidades do sistema, as ameaças e as vitimas.
A abordagem de teste “de dentro para fora” será aplicada no sistema abaixo.
Inicialmente será apresentado um fluxo funcional da aplicação bem como uma
listagem com os requisitos desse sistema.
7.2.1 Aplicação da abordagem de fora para dentro
Para o melhor entendimento da abordagem “de dentro para fora”, as técnicas e
fases desse teste serão aplicadas em uma aplicação real.
33
A aplicação abaixo faz parte do sistema de informação da empresa Cheque-pre.com
Tecnologia da Informação / ProScore no site www.proscore.com.br. Todos os seus direitos
são reservados a empresa citada que gentilmente cedeu para fins de estudo e pesquisa a
utilização de sua imagem.
•
Objetivo do sistema: O sistema “Manutenção na Faixa Salarial” tem o
objetivo de possibilitar que o usuário tenha acesso a manutenção e cadastro da
faixa salarial.
•
Requisitos
Os requisitos listados abaixo têm o objetivo de auxiliar no entendimento das
funcionalidades do sistema, ficando livre de normas ou outros artifícios técnicos de
modelagem de dados.
Página 1:
1. Conter os botões de navegação (Serviço e Abandonar).
2. Layout padrão do sistema ProScore (Nome do Serviço em fonte azul,
Rodapé contendo o texto de versão do sistema, direitos autorais e nome
do responsável pelo acesso).
3. Exibir as faixas salariais cadastradas para o contrato do usuário, dividida
pelos campos; (código, Valor Inicial, Valor Final e Descrição da Faixa).
4. Conter os botões de navegação (Serviço e Abandonar).
5. Layout padrão do sistema ProScore (Nome do Serviço em fonte azul,
Rodapé contendo o texto de versão do sistema, direitos autorais e nome
do responsável pelo acesso).
6. Conter as opções (Incluir, alterar e excluir).
7. Caso não tenha nenhuma faixa salarial cadastrada para o contrato do
usuário, exibir uma mensagem na cor azul descrevendo que não há faixas
cadastradas.
Página 2:
1. Conter os botões de navegação (Serviço e Abandonar).
2. Layout padrão do sistema ProScore (Nome do Serviço em fonte azul,
Rodapé contendo o texto de versão do sistema, direitos autorais e nome
do responsável pelo acesso).
3. Exibir as opções de cadastro:
34
3.1 Código; apenas valores numéricos.
3.2 Descrição da Faixa; apenas valores alfa decimal.
3.3 Última faixa; Opção sim ou não.
3.4 Valor Inicial; apenas valores numéricos.
3.5 Valor Final; apenas valores numéricos.
3.6 Todos os campos são obrigatórios.
4. O valor do campo Valor Inicial não pode ser menor que o Valor Final.
5. Botões:
5.1 Cadastrar; enviar os dados do formulário para o banco de dados.
5.2 Desfazer; limpar o campo de cadastro do formulário.
Página 3:
1. Exibir os dados já cadastrados no banco para a faixa a ser alterada.
2. Conter os botões de navegação (Serviço e Abandonar).
3. Layout padrão do sistema ProScore (Nome do Serviço em fonte azul,
Rodapé contendo o texto de versão do sistema, direitos autorais e nome
do responsável pelo acesso).
4. Exibir as opções de cadastro:
4.1 – Código; apenas valores numéricos.
4.2 - Descrição da Faixa; apenas valores alfa decimal.
4.3 - Última faixa; Opção sim ou não.
4.4 - Valor Inicial; apenas valores numéricos.
4.5 - Valor Final; apenas valores numéricos.
4.6– Todos os campos são obrigatórios.
5 - O valor do campo Valor Inicial não pode ser menor que o Valor Final.
6 - Botões:
6.1 Cadastrar; enviar os dados do formulário para o banco de dados.
6.2 Desfazer; limpar o campo de cadastro do formulário.
Página 4:
1. Exibir uma mensagem de validação no final do processo de exclusão da faixa
salarial.
a.
Se a exclusão da faixa salarial for realizada com sucesso, exibir uma
mensagem na cor verde descrevendo o sucesso da operação.
b.
Se a exclusão da faixa não for concluída com sucesso, exibir uma
mensagem de validação na cor vermelha descrevendo problema
encontrado.
35
Fluxo Funcional
Esse fluxo mostra de forma macro o processo funcional do sistema.
Figura 5 – Fluxo Funcional da aplicação: (Manutenção na Faixa Salarial).
36
Figura 6 – Página 1 Exibição das Faixas Cadastradas
Figura 7 – Página 2 Cadastro das Faixas Salariais
37
Figura 8 – Página 3 Alteração das Faixas Salariais
Figura 9 – Página 4 Exclusão das Faixas Salariais
38
Após analisados os requisitos do sistema, é iniciado o processo de identificação
dos riscos pertinentes as ameaças, vulnerabilidade e vítimas.
Vulnerabilidades:
1
- Interface do sistema não funciona para os principais navegadores do
mercado.
2
– Layout da aplicação não está em conformidade com os padrões do
sistema da ProScore.
3
– Dificuldade de interação do usuário com o sistema.
4
– Desempenho entre às entradas e saídas de informações.
5
– Validação dos campos de cadastro.
6
– Inserção das informações de cadastro no banco de dados.
7
– Recuperação das informações inseridas no banco de dados.
8
– Os links podem levar a páginas erradas.
Ameaça:
1 - O usuário pode estar utilizando um navegador de internet em uma versão
muito antiga, ou qualquer outro navegador diferente do utilizado para o teste
da aplicação (Essa ameaça dispara a situação 1 e 2).
2 - O sistema pode estar com o layout fora dos padrões da empresa (Essa
ameaça dispara a situação 2 e 3).
3 – O Sistema está lento (Essa ameaça dispara a situação 3, 4, 5, 6 e 7).
4 - O usuário tem dificuldades em entender as mensagens de validação do
sistema (Essa ameaça dispara a situação 1, 2, 3, 5 e 6).
5 – Existe um erro na validação dos dados de cadastro. (Essa ameaça
dispara a situação 3, 5 e 6).
6 - Existe um erro na inserção dos dados de cadastro no banco de dados
(Essa ameaça dispara a situação 3 e 6).
7 – Existe um erro na seleção dos dados cadastrados no banco de dados
(Essa ameaça dispara a situação 3 e 7).
8 – Os links das páginas do sistema estão desconexos (Essa ameaça dispara
a situação 3, 4, 6, 7 e 8).
Vítimas:
1 - O usuário não consegue cadastrar um faixa salarial.
2 – O usuário não consegue ver as faixas cadastradas para o seu contrato.
39
3 – Informações não validadas são inseridas no banco de dados. A empresa
perde com dados inválidos em sua base.
4 – Com o layout fora dos padrões, a empresa pode perder credibilidade
perante os seus usuários.
Após a identificação das vulnerabilidades do sistema, é possível partir para a
criação dos casos de teste que exploram as situações listadas acima. Na tabela abaixo
estão listados os casos de teste baseados nas vulnerabilidades, ameaças e vitimas.
Situação
1
2
Teste
Testar a aplicação nos navegadores mais usados no mercado. Exemplo:
Internet Explorer, Firefox e Flock
Verificar o layout da página do sistema através do documento de padrões do
sistema da empresa.
3
Realizar os testes funcionais.
4
Realizar os testes de performance
5
Realizar os testes funcionais e estruturais com as fases de classe de
equivalência, valores limítrofes e Erro imaginário
Após a inserção dos dados de cadastro, verificar as informações inseridas no
6
banco de dados para certificar que o cadastro foi realmente realizado com
sucesso.
7
8
Verificar a condição de seleção do banco de dados na exibição das faixas
cadastradas para o contrato do usuário.
Com posse no fluxo funcional da aplicação, explorar as iterações do sistema
com outras páginas e certificar que todos os links levam a pagina correta.
Tabela 2 – Testes que exploram os riscos analisados.
40
8. VANTAGENS E RESTRIÇÕES DO TESTE DE SOFTWARE BASEADO EM RISCOS
8.1 Vantagens
Agilidade no processo de teste; com o conhecimento dos riscos do
•
sistema, é possível distribuir os esforços de teste nas áreas de maior nível
crítico, perfazendo um processo de teste mais ágil.
Proteger as vítimas; ao mitigar os riscos do sistema, estamos também
•
protegendo as vítimas de possíveis erros.
Priorizar os esforços de teste; direcionar os esforços de teste para as áreas
•
mais criticas.
Fazer melhor uso dos recursos de teste; otimizar o processo de teste.
•
8.2 Restrições
•
Processo de análise de risco não é uma tarefa trivial: o processo de
análise dos riscos depende do nível de complexidade e do conhecimento do
profissional de teste em relação ao sistema. Tratando-se de sistemas muito
complexos, esse processo se torna muito difícil e pouco viável, nesses
casos, abordagens mais formais de teste, se encaixam melhor.
8.3 Conclusão
A abordagem de teste de software baseada em risco tem fatores positivos e fatores
restritivos. Sua grande vantagem sem dúvida está relacionada ao ganho de custo e prazo no
processo de teste.
Outro ponto positivo nessa abordagem é o fato que ao conhecer os riscos de um
sistema e priorizá-lo através de seu nível crítico, as possíveis vítimas de possíveis erros no
sistema estão sendo protegidas.
As partes restritivas dessa abordagem se da ao fato que o processo de análise de
risco não é uma tarefa simples, o sucesso desse processo depende do conhecimento do
analista em relação ao sistema e ao nível de complexidade que esta embutida no mesmo.
41
Essa abordagem de teste segundo o seu criador James Bach tem mais sucesso em
aplicações de nível de complexidade mais baixa, e em sistemas em que as possíveis
vítimas a erros não tenham grande perda tanto financeira como risco à vida humana.
Para exemplificar esse contexto, no caso de um software que controle um avião ou
um banco de sangue, essa abordagem não é a mais indica já que um erro poderia causar
sérios prejuízos, tanto financeiros como de vida humana.
42
9. REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, ROGER S. “Engenharia de Software”. São Paulo: Pearson Makron Books,
2007. 1056p.
KOSCIANSKI, ANDRÉ., SOARES, MICHEL DOS SANTOS. “Qualidade de Software”. 2ª
São Paulo: Novatec, 2007. 395p.
DELAMARO, MARCIO EDUARDO,. MALDONADO, JOSÉ CARLOS,. JINO, MARIO.
“Introdução ao Teste de Software”. Rio de Janeiro, 2007. 394p.
BASTOS. ADERSON,. RIOS EMERSON., CIRSTALLI, RICARDO,. MOREIRA TRAYAHÚ.
“Base de Conhecimento de Teste de Software”. 2ª Ed. São Paulo: Martins, 2007. 263p.
RIOS, EMERSON. “Análise de Riscos em Projetos de Teste de Software”. Castelo Rio de
Janeiro: Alta Books, 2008, 131p.
MOLINARI, LEONARDO. ”Testes Funcionais de Software”. Santa Catarina: Visual Books,
2008. 214p.
RICK D. CRAIG,. STEFAN P. JASKIEL. “Systematic Software Testing”. Artech House,
2002, 536p.
BACH, JAMES; James Bach on Risk-Based Testing: How to conduct heuristic risk
analysis; Software Testing & Quality Engineering Magazine; p. 23-28, nov. de 1999.
Disponível via URL em: http://www.cswit/htm/literatura. Acesso em: 20 de novembro. de
2008.
AMLAND, S. Risk Based Testing and Metrics: Risk analysis fundamentals and metrics
for software testing including a financial application case study. (1995)
BACH J. James Bach on Risk-Based Testing: How to conduct heuristic risk analysis
(1999).
MPS.BR “Melhoria do Processo de Software Brasileiro”. Disponível em:
www.heurys.com.br/gxpsites/agxppdwn.aspx?2,9,265,O,P,0,211%3BP%3B1%3B53-. Acesso
em 20 de novembro de 2008.
43