módulo vi - teste de software
TRANSCRIPT
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
1
MDULO DE:
TESTE DE SOFTWARE
AUTORIA:
Me. PEDRO HENRIQUE MANNATO COUTINHO
Copyright 2011, ESAB Escola Superior Aberta do Brasil
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
2
Mdulo de: Teste de Software
Autoria: Pedro Henrique Mannato Coutinho
Primeira edio: 2011
CITAO DE MARCAS NOTRIAS
Vrias marcas registradas so citadas no contedo deste Mdulo. Mais do que simplesmente listar esses
nomes e informar quem possui seus direitos de explorao ou ainda imprimir logotipos, o autor declara estar
utilizando tais nomes apenas para fins editoriais acadmicos.
Declara ainda, que sua utilizao tem como objetivo, exclusivamente na aplicao didtica, beneficiando e
divulgando a marca do detentor, sem a inteno de infringir as regras bsicas de autenticidade de sua
utilizao e direitos autorais.
Todos os direitos desta edio reservados
ESAB ESCOLA SUPERIOR ABERTA DO BRASIL LTDA
http://www.esab.edu.br
Av. Santa Leopoldina, n 840/07
Bairro Itaparica Vila Velha, ES
CEP: 29102-040
Copyright 2011, ESAB Escola Superior Aberta do Brasil
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
3
Apresentao O software passou a ser pea chave na competitividade de muitas empresas, fazendo
com que suas falhas provocassem diversos tipos de prejuzos. Nesse cenrio, para
garantir a qualidade dos softwares rea de teste vem ganhando cada vez mais
importncia e notoriedade.
Para obter a ateno necessria, os testes devem ser tratados com uma abordagem mais
sistemtica, deixando de ser uma atividade dentro do processo de desenvolvimento, e
passando a ter um processo prprio, com etapas, atividades, artefatos, tcnicas, equipe,
ambiente e ferramentas.
Objetivo Apresentar de forma dinmica e agradvel os conceitos relacionados aos testes de
software e a sua importncia, em conjunto com demonstraes prticas. Proporcionar ao
aluno o aprendizado necessrio para colocar em prtica os principais aspectos dos testes
de software.
Para atingir esse objetivo, foram intercaladas unidades de conceituao e
recomendaes, com outras de demonstrao de ferramentas gratuitas e ricas em
funcionalidades, para apoiar diferentes atividades e etapas do processo de Teste do
Software.
Ementa Apresentao dos seguintes temas: testes estticos, dinmicos, funcionais (caixa-preta),
estruturais (caixa-branca), tipos e nveis de testes, investimento em teste, custo da falha e
da correo, o processo de teste, planejamento, ambiente, equipe, casos de teste,
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
4
execuo, gesto dos defeitos, reviso e inspeo, desenvolvimento orientado a testes
(TDD) e integrao contnua. So apresentadas tambm 8 ferramentas gratuitas para:
cobertura de cdigo, teste unitrio, objetos "substitutos" (mock objects), gesto de
defeitos, gesto do processo de teste, teste de estresse e de performance, testes de
aplicaes web e integrao contnua.
Sobre o Autor Mestre em Informtica (UFES -2007), Graduado em Cincia da Computao (UFES-
2004).
A Dissertao de Mestrado rendeu o terceiro lugar no prmio de dissertaes do SBIE
2008 (Simpsio Brasileiro de Informtica na Educao).
Diretor Executivo e scio fundador da empresa Projeta Sistemas de Informao. J foi
Vice-Presidente de Associativismo e Financeiro da ASSESPRO-ES.
Professor de Ps-Graduao Lato-Sensu em disciplinas presenciais e on-line. Faz parte
do corpo de consultores de tecnologia do SEBRAE-ES. Possui experincia atuando como
Gerente de Projeto, Analista de Sistema, Analista de Processos de Negcio (BPM),
Desenvolvedor, Pesquisador de Novas Tecnologias, Analista de Testes, dentre outros.
Atuou em projetos que tinham como clientes: Arcelor Mittal, Receita Federal, IBGE,
Sebrae, Grupo Coimex, ESAB, dentre outros. Atuou como analista e desenvolvedor do
software para o gerenciamento de empresas do mercado rent a car, ganhador do 1
Prmio do Plo de Software do Esprito Santo e um dos quatro finalistas do 6 Encontro
Nacional de Tecnologia e Negcios - Rio Info.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
5
SUMRIO UNIDADE 1 ......................................................................................................................... 7
Introduo ....................................................................................................................... 7
UNIDADE 2 ....................................................................................................................... 10
Conceitos de Testes I .................................................................................................... 10
UNIDADE 3 ....................................................................................................................... 13
Conceitos de Testes II.....................................................................................................13
UNIDADE 4 ....................................................................................................................... 17
Custos de Testar, da Correo e o Retorno de Investimento em Testes ...................... 17
UNIDADE 5 ....................................................................................................................... 23
Custos das Falhas ......................................................................................................... 23
UNIDADE 6 ....................................................................................................................... 26
O Processo de Teste ..................................................................................................... 27
UNIDADE 7 ....................................................................................................................... 32
Planejamento dos Testes .............................................................................................. 32
UNIDADE 8 ....................................................................................................................... 38
Ambiente de Testes ....................................................................................................... 38
UNIDADE 9 ....................................................................................................................... 43
A Equipe e os Papis nos Testes .................................................................................. 43
UNIDADE 10 ..................................................................................................................... 48
Tcnicas Estticas - Reviso e Inspeo ...................................................................... 48
UNIDADE 11 ..................................................................................................................... 51
Casos de Teste ............................................................................................................. 51
UNIDADE 12 ..................................................................................................................... 56
Execuo dos Testes .................................................................................................... 56
UNIDADE 13 ..................................................................................................................... 59
Gesto de Testes - Ferramenta TestLink ...................................................................... 59
UNIDADE 14 ..................................................................................................................... 64
Gesto de Defeitos ........................................................................................................ 64
UNIDADE 15 ..................................................................................................................... 68
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
6
Gesto de Defeitos - Ferramenta Mantis I ..................................................................... 68
UNIDADE 16 ..................................................................................................................... 73
Gesto de Defeitos - Ferramenta Mantis II.....................................................................73
UNIDADE 17 ..................................................................................................................... 77
Cobertura de Cdigo - Ferramenta EclEMMA ............................................................... 77
UNIDADE 18 ..................................................................................................................... 80
Testes de Unidade e Integrao - Ferramenta JUnit ..................................................... 80
UNIDADE 19 ..................................................................................................................... 86
Testes com Objetos Substitutos ou "Falsificados" (Mock Objects) - Ferramenta Mockito ...................................................................................................................................... 86
UNIDADE 20 ..................................................................................................................... 92
Desenvolvimento Orientado a Testes (TDD - Test Driven Devlopment) ....................... 92
UNIDADE 21 ..................................................................................................................... 96
Exemplo de TDD na Prtica .......................................................................................... 96
UNIDADE 22 ................................................................................................................... 102
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers ........................ 102
UNIDADE 23 ................................................................................................................... 105
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuao) . 105
UNIDADE 24 ................................................................................................................... 109
SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuao) . 109
UNIDADE 25 ................................................................................................................... 114
Teste de Performance e Estresse - Ferramenta JMeter .............................................. 114
UNIDADE 26 ................................................................................................................... 118
Teste de Performance e Estresse - Ferramenta JMeter (Continuao) ...................... 118
UNIDADE 27 ................................................................................................................... 122
Integrao Contnua .................................................................................................... 122
UNIDADE 28 ................................................................................................................... 126
Integrao Contnua - Ferramenta Jenkins I ............................................................... 126
UNIDADE 29 ................................................................................................................... 131
Integrao Contnua - Ferramenta Jenkins II .............................................................. 131
UNIDADE 30 ................................................................................................................... 136
Consideraes Finais .................................................................................................. 136
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
7
UNIDADE 1 Objetivo: Realizar uma apresentao inicial do contedo do Mdulo de Teste de Software
Introduo
Bem vindo ao Mdulo Teste de Software!
O avano da tecnologia nas ltimas dcadas em reas que vo dos hardwares at as
linguagens de programao, proporcionaram o surgimento de milhares de software. A
utilizao da Internet potencializou ainda mais esse fato, fazendo com que diversas
aplicaes computacionais fizessem parte do nosso dia a dia. Assim, o software passou a
ser pea chave na competitividade de muitas empresas, fazendo com que suas falhas
provocassem diversos tipos de prejuzos. Nesse cenrio, para garantir a qualidade dos
softwares, a rea de teste foi ganhando cada vez mais importncia.
At a dcada de 90, os testes eram realizados na maioria das vezes pelos prprios
desenvolvedores, e eram tratados como uma atividade que tinha pouco tempo disponvel,
no cronograma do projeto de software, para ser realizada. Desde ento, diversos artigos,
ferramentas e livros sobre testes foram lanados, mas assim mesmo comum ver
empresas que no dedicam a ateno necessria a essa rea para garantia da qualidade.
Portanto, o objetivo deste Mdulo apresentar os principais pontos envolvidos com o
teste de software, com uma abordagem mais sistemtica; deixando de ser uma atividade
dentro do processo de desenvolvimento, e passando a ter um processo prprio, com
etapas, atividades, artefatos, ambiente, tcnicas, equipe e ferramentas.
Mesmo com todo avano em relao aos testes, nos ltimos anos; o teste de software
no uma "cincia exata". No entanto, teste exaustivo impossvel, e para realizar os
testes adequadamente importante realizar uma avaliao de risco.
A anlise de risco uma parte importante dos testes de software, visto que vai determinar
as reas que precisam ser mais cuidadosamente testadas e, em qual momento, se pode
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
8
considerar que os testes realizados foram suficientes para garantir uma confiana
adequada para liberar o software para produo.
Para atingir o objetivo, este Mdulo foi baseado em livros, artigos de especialistas,
revistas especializadas e manuais de ferramentas. Para fornecer uma abordagem
conceitual aliada prtica, 8 ferramentas gratuitas, relacionadas com diferentes partes do
teste de software, sero apresentadas.
O objetivo da apresentao dessas 8 ferramentas propiciar ao aluno o conhecimento
dos principais benefcios, facilidade de uso e o momento adequado para usar cada tipo de
ferramenta. Assim, o Mdulo no tem a pretenso de abranger todos os aspectos dessas
ferramentas, at porque, o manual delas extenso, impossibilitando abordar em um
mdulo.
A figura a seguir apresenta algumas das bibliografias utilizadas como base para
elaborao deste Mdulo.
Figura 1 Algumas referncias que serviram como base para este Mdulo
Um dos indicadores da importncia e aumento de notoriedade dos testes de software o
surgimento de vrias certificaes. Dentre elas, importante citar a Certificao Brasileira
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
9
em Teste de Software (CBTS) e a Qualificao Internacional de Teste de Software
(ISTQB - Internacional Software Testing Qualification), cujas referncias tambm foram
consultadas para a elaborao deste Mdulo.
Os modelos de processo de melhoria de software como CMMI (Capability Maturity Model
Integration) e o MPS.BR (Melhoria de Processos do Software Brasileiro) exigem a
implantao de testes de software. Por exemplo, para conquistar o nvel 3 do CMMI
preciso adotar uma abordagem sistemtica em relao aos testes, que se encontra nas
reas de Verificao e Validao deste modelo.
importante notar que as metodologias geis como o XP (eXtreme Programming)
contriburam com os conceitos de Integrao Contnua, Desenvolvimento Orientado a
Testes (TDD) e ferramentas de testes unitrios no modelo xUnit, que sero estudadas
neste Mdulo. Apesar de a origem ter sido em metodologias geis, qualquer metodologia
de desenvolvimento pode se beneficiar dessas prticas.
Organizao do Contedo
Nas prximas duas unidades deste Mdulo, sero abordados conceitos utilizados nas
demais unidades. Portanto, as Unidades 2 e 3 apresentam conceitos como testes
estticos, dinmicos, funcionais (caixa-preta), estruturais (caixa-branca), tipos e nveis de
testes. As unidades seguintes apresentam conceitos relacionados com o custo do teste,
custo da falha e da correo; o processo de teste; planejamento; ambiente; equipe; casos
de teste; execuo; gesto dos defeitos; reviso e inspeo; desenvolvimento orientado a
testes (TDD) e integrao contnua.
Sero apresentadas tambm 8 ferramentas gratuitas para: cobertura de cdigo, teste
unitrio, objetos "substitutos" (mock objects), gesto de defeitos, gesto do processo de
teste, teste de estresse e de performance, testes de aplicaes web e integrao
contnua.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
10
UNIDADE 2 Objetivo: Conhecer os principais conceitos sobre os testes, que sero utilizados no decorrer deste Mdulo
Conceitos de Testes I
Se os testes so to importantes, por que normalmente no se testa adequadamente?
Um dos principais fatores para responder essa pergunta entender que a presso por
menores prazos e valores negociados para desenvolver um software, dificilmente
contempla a realizao de testes de forma adequada. Os testes precisam de um
investimento inicial maior, mas como ser visto, ao longo deste mdulo, os prejuzos
provocados pelas falhas costumam justificar o investimento em um processo de testes.
Os softwares so desenvolvidos por seres humanos, que por mais dotados de
competncias, no so perfeitos, sendo passveis de cometer erros. A verdade que
infelizmente os erros estaro presentes no software, e se a equipe de desenvolvimento
no encontr-los, o cliente vai encontrar, j que cada vez que ele interage com o software,
ele est "exercitando" uma funcionalidade.
Delamaro, Maldonado e Jino citam no livro "Introduo ao Teste de Software" que o
desenvolvimento de software est sujeito a diversos tipos de influncias e problemas que
acabam por gerar um software diferente do que o cliente esperava. Dentre os diversos
fatores que podem causar esses problemas, eles identificam que a maioria ocasionado
por uma mesma origem, o erro humano.
Portanto, os testes devem ser realizados de uma maneira sistemtica, para evitar o
acontecimento de uma das "Leis de Murphy": "Se alguma coisa pode dar errado, dar. E
mais, dar errado da pior maneira, no pior momento e de modo que cause o maior dano
possvel."
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
11
Exceto em casos triviais, a execuo de testes exaustivos que testam todas as
possibilidades de combinaes, entradas, etc., no so viveis. Pode-se citar como
exemplo, uma demonstrao simples apresentada por Falbo (2008):
Suponha um programa que calcule o exponencial de nmeros inteiros x e y (xy). Para
testar todas as entradas possveis todos os nmeros inteiros de x e y combinados devem
ser testados, gerando uma cardinalidade de 2n * 2n, sendo "n" o nmero de bits usados
para representar um inteiro. Em uma arquitetura de 32 bits, a cardinalidade seria 264
(232*232). Se cada teste puder ser realizado em 1 milissegundo, seria necessrio
aproximadamente 5,85 milhes de sculos para executar todos os testes. Adicionalmente
mesmo que o teste exaustivo fosse executado, ele no garantiria que o software
corresponde sua especificao. Suponha que ao invs do xy o cliente tenha especificado
a raiz de x por y (y x), e o desenvolvedor por equvoco implementou a funo
apresentada no exemplo; esse erro no seria identificado pelo teste exaustivo, e sim pela
reviso dos requisitos ou teste de aceitao.
Portanto, como afirmou Djkistra O teste no pode nunca demonstrar a ausncia de
defeitos, apenas sua presena.
Mesmo no sendo possvel realizar testes exaustivos para provar que o software est
livre de defeitos a conduo sistemtica de testes em conjunto com as definies de
critrios, riscos e prioridades contribuem para aumentar a qualidade e confiana no
sistema.
Testes Estticos x Testes Dinmicos
As atividades relacionadas ao teste do software em si no envolvem somente a execuo
do programa, que o teste dinmico. Existem tambm os testes estticos, que no
precisam da execuo de um software (ou nem mesmo a sua existncia) para serem
realizados. Os testes estticos podem ser aplicados a diferentes artefatos como a reviso
de documentos de requisitos, anlise, do prprio cdigo fonte, etc.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
12
Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)
Os testes funcionais tambm so conhecidos como "teste caixa-preta", pelo fato do
testador no precisar conhecer os detalhes da codificao. Nesse tipo de teste o testador
informa os dados de entrada e verifica se a sada/resultado est de acordo com o que era
esperado. Portanto, esse tipo de teste no tem como objetivo saber como a
funcionalidade foi implementada, mas sim quais so os resultados apresentados.
Avaliando somente a entrada e a sada, o teste de caixa-preta visa identificar defeitos do
tipo:
Se o sistema aceita entradas incorretas;
Se a sada produzida est correta;
Se existem erros na interface;
Se alguma funcionalidade est faltando;
Dentre outros.
J os testes estruturais, ou "testes caixa-branca" levam em considerao a estrutura do
cdigo fonte para identificar a implementao e se os diferentes caminhos esto sendo
cobertos por algum tipo de teste. Assim, os testes sero elaborados para: testar as
decises lgicas (verdadeiro/falso), testar os "loops" at o limite, as variveis estticas e
dinmicas, dentre outros.
O teste de caixa-branca no substitui o teste de caixa-preta, e vice-versa. Eles so
utilizados em conjunto; cada um com um objetivo distinto.
Figura 2 Teste Caixa-preta e Teste Caixa-branca
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
13
UNIDADE 3 Objetivo: Objetivo: Conhecer os principais conceitos sobre os testes, que sero utilizados no decorrer deste Mdulo
Conceitos de Testes II
Nveis de Testes
Os nveis de testes normalmente so classificados como: teste unitrio, teste de
integrao, teste de sistema e teste de aceitao.
Os testes unitrios so realizados nas menores unidades do software, que normalmente
so os mtodos ou funes. Usualmente so os prprios desenvolvedores que realizam
os testes unitrios do prprio cdigo. O seu objetivo buscar por erros de lgica e
programao, nas unidades em separado, de forma a garantir que essas unidades
funcionem corretamente e isoladamente. A justificativa clara para realizar os testes de
unidade :, se uma unidade no funcionar isoladamente, ao ser integrada com outras
unidades, o erro ser propagado e mais tempo ser gasto para identific-lo. Os testes
unitrios podem ser realizados aps a implementao da unidade, ou at mesmo antes
de seu cdigo ser implementado, sendo essa ltima uma abordagem de metodologias
geis (Mais detalhes, a respeito de desenvolvimento orientado a testes, sero abordados
adiante).
Os testes de integrao verificam se as partes que funcionavam isoladamente continuam
a funcionar aps serem combinadas. Portanto, so verificadas as integraes entre
unidades, componentes, sistemas, camadas, etc.
As integraes podem ser do tipo "Big-Bang" ou incremental.
A integrao Big-Bang consiste da realizao do teste aps todas as unidades,
componentes, etc.; serem integrados, testando tudo de uma s vez. A integrao
incremental consiste em integrar e testar o programa gradativamente, comeando com
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
14
uma integrao pequena e testando; constituindo uma nova integrao somente quando
os testes da integrao menor forem bem sucedidos. A integrao Big-Bang mais
arriscada, porque quanto maior for a abrangncia da integrao mais difcil ser para
identificar a parte que originou a falha. Sem contar que testar a integrao, aps tudo ter
sido desenvolvido, faz com que os erros sejam encontrados tardiamente. Portanto, para
evitar esses tipos de problemas, recomenda-se o uso da Abordagem Incremental.
Testes de sistema avaliam o comportamento do sistema como um todo. Alm das
funcionalidades, as caractersticas no funcionais como: performance, segurana,
usabilidade, dentre outros, so avaliados. Esses quesitos podem ser avaliados tambm
nos outros nveis de teste, e devem ser feitos por completo nos testes de sistema. Nesse
nvel, importante que o ambiente de teste se parea, ao mximo, com o ambiente de
produo, de forma que os testes reproduzam o mximo possvel o uso real.
Testes de aceitao so realizados pelos clientes e/ou usurios do sistema com o objetivo
de verificar se o sistema est atendendo ao que era pretendido e foi especificado. Esse
nvel no tem como objetivo caar defeitos e sim verificar se o sistema est "conforme".
Engana-se quem pensa que esses testes devem ser realizados somente ao final do
desenvolvimento. Eles devem ser realizados o quanto antes, para que os desvios possam
ser corrigidos enquanto h tempo e no tenham sido propagados. Deixar os testes de
aceitao somente para o final representa um risco altssimo de reprovao do cliente,
gerando diversos tipos de prejuzos que englobam o custo do retrabalho, perda do tempo
certo para lanar o produto, dentre outros.
Tcnicas de Testes
A seguir, sero apresentadas algumas tcnicas de teste.
Teste de regresso: consiste em testar novamente o software (ou partes dele),
aps o desenvolvimento de uma mudana. Assim, o objetivo verificar se a
introduo de uma mudana, como por exemplo, novo cdigo ou at mesmo a
correo de um defeito, no provocou um novo defeito em uma parte do software
que funcionava corretamente, ou seja, verificar que no ocorreu nenhum "efeito
colateral". A reexecuo dos testes muitas vezes no realizada da forma
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
15
adequada por ser encarada como uma tarefa cansativa e repetitiva, mas preciso
avaliar o risco de uma parte que funcionava apresentar defeitos. Como os testes de
regresso so realizados muitas vezes, se tornam bons candidatos a serem
automatizados.
Teste de estresse: o objetivo do teste de estresse avaliar como o sistema se
comporta em condies extremas. Dessa forma, ele deve ser realizado para
consumir os recursos disponveis de forma anormal, testando: restries de
memria, espao em disco, CPU, dentre outros. Para isso, testa-se com
quantidade elevada de acessos simultneos, volume de dados acima da mdia
esperada, etc. Nessas condies o comportamento do sistema ser avaliado.
importante que o ambiente de testes seja o mais parecido possvel com o ambiente
de produo.
Teste de recuperao: verifica se o sistema ser restabelecido sua operao
normal e de forma ntegra aps ocorrer alguma falha, como por exemplo: queda da
rede, falha de hardware, perda de acesso ao banco de dados, dentre outros. Para
tanto, esses e outros tipos de falhas so provocadas pelo testador. O teste de
recuperao avalia no s a recuperao automtica do sistema, mas tambm os
procedimentos manuais necessrios. Dessa forma, os testes avaliam
procedimentos com respectivos checklilsts e podem envolver inclusive a
restaurao de backup. Portanto, verifica-se tambm se o backup est sendo
realizado e armazenado adequadamente. Outro ponto avaliado a quantidade de
tempo necessrio para o software se restabelecer, depois da realizao dos
procedimentos.
Teste de performance: o objetivo do teste de performance avaliar se o sistema
consegue obter um desempenho determinado em quesitos como, tempo de
resposta, utilizao do hardware, dentre outros. No deve ser confundido com o
teste de estresse, visto que, nesse caso, o objetivo verificar se a performance
est como esperada em condies normais, e no em condies extremas.
Teste de segurana: os testes de segurana so executados para garantir que os
mecanismos de segurana do software vo proteg-lo em relao integridade,
confidencialidade das informaes e proteo do software. Esse tipo de teste pode
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
16
necessitar de contratao de terceiros, visto que especialistas podero utilizar
tcnicas e conhecimentos especficos para invadir o software, sendo que esses
conhecimentos no costumam ser de conhecimento de analistas, desenvolveres e
testadores em geral.
Teste paralelo: a referncia do CBTS chama de teste paralelo a execuo da nova
verso do software em conjunto com uma verso antiga, para comparar se os
resultados apresentados so iguais.
Em relao performance de um site, a revista Exame PME, de Junho de 2011, traz uma informao interessante. Na reportagem "Quem mais rpido vende mais" so apresentados dados de uma pesquisa informando que:
Cada 1 segundo que um site demora a mais para carregar; significa perda de 7% das vendas
57% dos consumidores abandonam um site depois de esperar 3 segundos para visualizar os dados
80 % desses consumidores no voltam ao site por pelo menos 6 meses Desde 2008, a Amazon estima ter aumentado suas receitas em 1%, cada vez
que suas pginas ficaram um dcimo de segundo mais rpidas.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
17
UNIDADE 4 Objetivo: Conhecer os custos envolvidos com os testes de software, bem como o retorno de investimento proporcionado.
Custos de Testar; da Correo e o Retorno de Investimento em Testes.
Custos de Testar
O autor do livro "The Art of Software Testing" (A Arte de Testar Software), Glenford Myers
estima que 50% do custo total do projeto so gastos com as atividades relacionadas ao
teste de software. Embora outros autores apresentem estimativas diferentes importante
identificar onde esses custos esto alocados.
O teste de software consome recursos principalmente em:
Profissionais: horas gastas pelos profissionais da equipe (desenvolvedores,
analistas de teste, testadores, etc.) com atividades de testes, custos com
treinamento da equipe, dentre outros.
Equipamentos: mquinas necessrias para permitir a criao de um ambiente de
teste adequado, que permita simular o ambiente de produo.
Ferramentas: softwares necessrios para gerenciar o processo de teste e os
defeitos, preparar as bases de dados, realizar testes unitrios, de integrao,
aceitao, regresso, e demais testes.
Portanto, para implantar um processo de teste de software ser necessrio investir um
valor maior no incio. Entretanto, o retorno desse investimento tende a ser muito maior do
que se os testes no fossem realizados de forma planejada e organizada.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
18
A figura abaixo demonstra, de forma simples, o aumento do investimento inicial com a
implantao de um processo de testes bem como retorno de investimento proporcionado.
Figura 3 Economia proporcionada ao investir em testes de software
Como se pode perceber, na imagem, a parte da esquerda representa um projeto que no
possui um processo de teste formalizado. Mesmo no sendo formalizado, esse projeto
consome recursos com testes; visto que alguns testes aleatrios so realizados pelos
desenvolvedores e eventualmente por algum outro membro da equipe. J no projeto da
direita, que possui um processo de teste estabelecido, o custo com a realizao dos
testes aumenta em relao ao anterior (custo com pessoas, ferramentas, etc.) e o custo
das falhas diminui, proporcionando uma economia ao longo do tempo. O "Custo da
Falha", representado de forma resumida na figura, engloba o custo do retrabalho,
correo e prejuzos ocasionados pela falha; desde prejuzo de imagem da equipe
desenvolvedora at prejuzos financeiros, como por exemplo, processos judiciais.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
19
Custo da Correo
No processo de desenvolvimento de software com as etapas de: Especificao de
Requisitos, Anlise, Projeto, Implementao e Implantao; quanto mais tarde um defeito
for encontrado, maior ser o custo para corrigi-lo. E no difcil visualizar o motivo desse
aumento, visto que uma simples declarao errada, nos requisitos, pode gerar de duas a
trs decises equivocadas na etapa de anlise/projeto, podendo ocasionar uns vinte erros
introduzidos no desenvolvimento (Black, 2002). como se fosse uma bola de neve que
aumenta na medida em que ela desce morro abaixo.
Essa percepo de que: quanto mais cedo o defeito for encontrado mais barato ser a
sua correo antiga. Barry Boehm j abordava esse tpico em seu artigo de 1976 e
Glenford Myers em seu livro "The art of sotware testing" (A arte de testar software) de
1979. A declarao de Myers ficou famosa, sendo conhecida como a Regra 10 de
Myers, em que ele alega que o custo de corrigir um defeito aumenta 10x por cada etapa
em que o projeto de software avana.
O custo de correo aumenta ainda mais se o erro for detectado externamente (pelo
cliente), aps a entrega do software, do que internamente pela equipe
desenvolvedora/testadora. O especialista Rex Black (mais detalhes sobre ele ao final
desta unidade) estima que um defeito encontrado por um desenvolvedor, custa em mdia
$ 10 para ser corrigido, enquanto que, se for identificado por um testador custar $100 e
pelo cliente $ 1000. Para visualizar melhor esses custos importante pensar no processo.
Quando o desenvolvedor identifica o defeito, ele vai e corrige. Caso esse mesmo defeito
seja identificado por um testador, ele ter que reportar para que o desenvolvedor o
identifique e conserte. Em seguida, uma nova verso dever ser disponibilizada para o
testador verificar se o erro foi de fato corrigido e se nenhum outro foi introduzido com a
correo (realizao do teste de regresso). Portanto, pode-se perceber como mais
caro quando o defeito identificado pelo testador.
Quando o defeito identificado pelo cliente, alm dos passos descritos anteriormente,
existe o aumento do custo com o suporte tcnico que atender o cliente e de implantar a
nova verso do software, sem contar os possveis custos intangveis com processos
judiciais e impactos, na reputao da empresa desenvolvedora (Black,2010).
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
20
Adicionalmente, com o passar dos anos, os custos podem aumentar de maneira
exorbitante, visto que pode ser difcil encontrar algum desenvolvedor que trabalhou no
software (problema agravado se o software no tiver uma documentao adequada) e/ou
ento encontrar um profissional com experincia adequada em uma linguagem de
programao/plataforma que se tornou obsoleta.
Ento, se fcil perceber pelos motivos citados que quanto mais cedo o defeito for
identificado e corrigido, menor ser o seu custo, por que muitos gestores ignoram a
realizao adequada de testes? A resposta : eles no visualizam o teste como um
investimento.
Normalmente enxergam o teste como uma atividade custosa, que requer muito tempo e
investimento e que no ajudar o software ficar pronto mais cedo, em um cenrio que, na
maioria das vezes, a presso por prazo e as margens de lucro so bem pequenas.
Portanto, para visualizar que o teste deve ser visto como um investimento; importante
observar a situao descrita a seguir.
Retorno de Investimento
Para entender melhor o retorno de investimento proporcionado pelos testes, deve-se
tomar como base o seguinte estudo de caso hipottico, apresentado por Rex Black.
Um software implantando em um cliente possui uma nova verso liberada a cada 3
meses. Em mdia, cada nova verso possui 1000 novos defeitos. A equipe
desenvolvedora desse software encontra em mdia 250 erros antes de liberar a verso,
sendo que o restante (750) encontrado pelo cliente. Tendo como base a estimativa
anterior do prprio Rex Black, que um erro encontrado por um desenvolvedor custa em
mdia $10 e pelo cliente custa $ 1000, esse cenrio, que no possui um processo formal
de teste, gera um custo de $750.000 por verso, e uma insatisfao imensa no cliente.
Para tentar melhorar essa situao, o gerente do projeto consegue investir $ 70.000 por
verso em testes manuais para minimizar os impactos. Sendo assim, a equipe dedicada
para testes identifica mais 350 defeitos que so corrigidos antes de lanar a verso.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
21
Partindo da estimativa que cada defeito encontrado por um testador custa em mdia
$100, o retorno do investimento 350%, conforme apresentado na tabela a seguir.
Opes para Investimento em Testes (Adaptado de Rex Black,2010)
TESTES
Sem
Processo
Formal
Processo
Manual
Teste
Automatizado
Equipe $ 0 $ 60.000 $ 60.000
Infraestrutura $ 0 $10.000 $10.000
Ferramentas e Automatizao $ 0 $ 0 $12.500
Total $ 0 $ 70.000 $ 82.500
Desenvolvimento
Defeitos Encontrados 250 250 250
Custo da Correo 2500 2500 2500
Testes
Defeitos Encontrados 0 350 500
Custo da Correo 0 35.000 50.000
Suporte ao usurio
Defeitos Encontrados 750 400 250
Custo da Correo 750.000 400.000 250.000
Custo da Qualidade
Investimento $ 0 $ 70.000 $ 82.500
Custo da Correo $ 752.500 $ 437.500 $ 302.500
Total $ 752.500 $ 507.500 $ 385.000
Retorno do Investimento N/A 350% 445%
Tabela 1 Retorno de Investimento em Testes adaptado de (Black, 2010)
Percebendo o retorno do investimento, o gerente do projeto consegue pleitear um
investimento de mais $12.500, por verso, para investir em automatizao dos testes,
encontrando 150 defeitos a mais. Dessa forma, o retorno de investimento obtido seria de
445%.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
22
Apesar desse estudo de caso ser hipottico, o renomado especialista Rex Black afirma ter
presenciado retorno de investimento, em testes, variando de 50% a 3200%.
Entretanto, assim como qualquer outro investimento, somente disponibilizar a verba no
garantia de sucesso, visto que existem formas corretas e erradas de se investir. Se o
dinheiro no for investido com a equipe, ferramentas e tcnicas adequadas, o resultado
pode ser negativo e frustrante.
Conhea Rex Black:
Rex Black um dos especialistas mais reconhecidos em teste de software. Autor de livros relacionados aos testes, dentre eles o popular "Managing the Test Process" com mais de 25.000 cpias vendidas ao redor do mundo. Tambm palestrante e autor de vrios artigos (muitos deles podem ser encontrados em http://www.rbcs-us.com/).
Durante 4 anos foi presidente do ISTQB e um dos autores do Syllabus da certificao desse instituto.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
23
UNIDADE 5 Objetivo: Conhecer alguns prejizos causados por falhas de software, visualizando que em alguns casos os custos podem ser muito altos
Custos das Falhas
O National Institute of Standards and Technology (NIST), ou em portugus Instituto
Nacional de Tecnologia e Padres, uma agncia do Departamento de Comrcio dos
Estados Unidos. Em 2002 o NIST elaborou um estudo para estimar o custo anual
provocado por falhas de software. O estudo foi intitulado "The Economic Impacts of
Inadequate Infrastructure for Software Testing", ou em portugus, "O Impacto Econmico
da Infraestrutura Inadequada para Testes de Software".
O impacto das falhas de software alto devido ao fato de muitos empreendimentos,
desde indstrias medicina, dependerem de software. Segundo estimativas desse
estudo, as falhas de software so predominantes e prejudiciais ao ponto de custar
economia americana $59,5 bilhes de dlares anualmente. Os autores estimaram
tambm que pouco mais de um tero desse valor ($22,2 bilhes) poderiam ser eliminados
com a implantao de processos de testes que permitissem identificar (e
consequentemente corrigir) mais cedo e de maneira mais efetiva os defeitos de software.
Algumas falhas de software podem causar prejuzos imensos. Vamos ver agora alguns
exemplos de falhas de software que viraram notcias.
Erros em escalas da GOL:
Veja a seguir parte da notcia publicada no portal Terra
(http://noticias.terra.com.br/brasil/noticias/0,,OI4602632-EI306,00-
Gol+diz+a+Anac+que+falha+em+software+causou+erro+em+escala.html) sobre o
transtorno provocado por uma falha de software:
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
24
"Gol diz Anac que falha em software causou erro em escalas
A Agncia Nacional de Aviao Civil (Anac)
informou nesta tera-feira que a companhia area
Gol disse que um problema no software para
planejamento de escala da tripulao gerou dados
incorretos que resultaram no "planejamento
inadequado da malha area e da jornada de
trabalho dos tripulantes". Hoje, a Gol foi convocada
pela agncia a apresentar um plano de ao para
atender os passageiros de voos cancelados ou atrasados. A companhia operava cerca de
70% dos voos atrasados ontem em todo o Pas.
De acordo com a Anac, a Gol afirmou que o problema no sistema aconteceu em julho,
durante um upgrade no programa. "Por essa razo, foi adotada novamente a configurao
de escala do ms anterior", disse a agncia, em nota: O sistema era utilizado h trs
meses, segundo a companhia, e com o conhecimento da Anac.
Autodestruio do Foguete Ariane 501
Em junho de 1996, aproximadamente 37 segundos aps o seu lanamento o foguete
Ariane 501 explodiu em voo.
O foguete possua um sistema referencial inercial (SRI) para medir a trajetria. O SRI 2
era o principal, sendo que o SRI 1 funcionava como sistema redundante para assumir em
caso de falhas no primeiro. Ao invs de enviar os dados corretos da altitude, o SRI 2
enviou um cdigo de erro decorrente de uma falha no software. S que o SRI 1 no pode
entrar em operao, visto que 72 milissegundos antes apresentou o mesmo problema que
o SRI 2.
A falha foi provocada pela converso de um float de 64 bits para um nmero inteiro com
sinal de 16 bits, referente velocidade horizontal para a plataforma. Na tentativa da
converso, foi gerado um nmero maior do que o comportado nos 16 bits. O motivo dessa
converso estar vulnervel no foi identificada, uma vez que nenhum comentrio no
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
25
cdigo fonte justificava esse fato, sendo que existiam outras converses com a proteo
adequada.
O foguete e a carga destruda estavam avaliados em $ 500 milhes de dlares.
Destruio da sonda da NASA Mars Climate Orbiter
A NASA enviou uma sonda para Marte para poder estudar o clima deste planeta. A sonda
Mars Climate Orbiter deveria entrar na rbita do planeta ao atingir uma altitude
aproximada de 150 km. Porm, devido a um erro de converso de medidas, a sonda
entrou em uma altitude inferior, provocando a sua destruio. A converso que no foi
realizada era de medidas inglesas para o sistema mtrico.
O veculo espacial foi lanado no dia 11 de dezembro de 1998 e seu ltimo sinal foi
recebido em 23 de setembro de 1999.
Os exemplos de incidentes apresentados nesta unidade apresentam alguns prejuzos
financeiros, e de tempo, ocasionados por falhas de software. Existem outras falhas
conhecidas que infelizmente alm das perdas financeiras, provocaram a perda de vidas,
como por exemplo, o caso do Therac-25; um acelerador mdico utilizado para tratar
tumores.
Com uma breve pesquisa na Internet possvel achar vrias outras falhas de software
que ficaram famosas.
possvel inclusive assistir o vdeo de destruio do foguete Ariane 5. Um dos
endereos disponveis : http://www.youtube.com/watch?v=gp_D8r-2hwk
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
26
Voc j presenciou algum prejuzo provocado por uma falha de software? Qual
(cuidado para no descrever detalhes confidenciais)? Ele poderia ter sido evitado com
a realizao adequada dos testes? Como?
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
27
UNIDADE 6 Objetivo: Entender a importncia do teste ser abordado como um processo e no como uma atividade
O Processo de Teste
comum em projetos de software encontrar os testes sendo tratados como uma atividade
dentro do processo de desenvolvimento. Nessa abordagem, muitas vezes os testes so
iniciados aps a etapa de desenvolvimento. A figura abaixo ilustra esse caso.
Figura 4 Abordagem de Testes como uma Atividade no Processo de Desenvolvimento
Entretanto, para aumentar a qualidade do projeto, os testes precisam ter um processo
prprio no sendo mais tratado apenas como uma atividade dentro do processo de
desenvolvimento, conforme apresenta a figura abaixo.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
28
Figura 5 Abordagem de Testes com um Processo Prprio
Essa abordagem importante para dar uma nfase maior aos testes. Assim, o teste
passa a ter as etapas estruturadas possuindo atividades, artefatos, mtodos, papis e
responsabilidades. Esse processo deve ser iniciado em paralelo com o incio do projeto
de software e, normalmente, deve ser realizados dentro do prazo do processo de
desenvolvimento, ou seja, de forma geral o cronograma do projeto no ser aumentado
para realizao dos testes.
Mesmo sendo um processo e no mais uma atividade, o processo de teste e o de
desenvolvimento esto interligados (conforme demonstrado a seguir no "Modelo em V"),
mas possuem alguns indicadores distintos. Tome como exemplo o indicador "Defeitos
Encontrados": quanto maior o nmero de defeitos encontrados, mais bem sucedido
considera-se os testes, e menos o processo de desenvolvimento.
Um processo constitudo por um conjunto de tarefas e atividades, sendo que algumas
podem ser sequenciais enquanto outras so realizadas em paralelo. De forma geral, as
principais atividades do processo de teste so: planejamento, preparao, especificao,
execuo e entrega/avaliao (Rios et al.,2007).
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
29
O Modelo V
A representao grfica que mais utilizada para demonstrar a integrao entre o
desenvolvimento e os testes o Modelo V. Existem algumas variaes do Modelo V, mas
de forma geral ele representado conforme figura abaixo.
Figura 6 Forma usual de representar o Modelo V
Outras formas de representao do modelo V diferentes da figura anterior existem. O
prprio Syllabus (documentao) da certificao de testes ISTQB, cita o modelo V sem
apresentar nenhuma figura e nem mesmo informar os nomes das quatro etapas de
desenvolvimento.
Alguns autores criticam esse modelo, como por exemplo, James Christie. Christie alega
que existem tantas variaes do modelo em V que na prtica podem significar qualquer
coisa. As representaes normalmente compartilham o formato de "V" com uma seta
ligando os estgios equivalentes em cada lado.
Mas qual o significado dessas setas?
1. O teste das entregas de cada etapa do desenvolvimento?
2. O planejamento dos testes em paralelo a cada etapa do desenvolvimento?
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
30
Seguem abaixo algumas crticas dos equvocos que podem ser ocasionados por conta da
interpretao do modelo V baseados em (Christie, 2008), e aproveitando o "gancho" das
crticas, algumas recomendaes de boas prticas de testes (que na verdade
independem do modelo adotado).
1. Desencoraja a participao do usurio avaliando as funcionalidades e interface
antes da etapa de "Teste de Aceitao", que de acordo com a representao
ocorre mais tardiamente no projeto.
a. Recomendao: Idealmente, a prototipao e testes cedo devem ser
includos para identificar problemas quando so mais baratos de resolver.
No raro encontrar projetos que so submetidos para o cliente aprovar
somente ao final e o cliente no aprova o que foi entregue, gerando um
imenso prejuzo (para ambas as partes) e insatisfao. Portanto o
planejamento do projeto deve contemplar os testes de aceitao em todas
as etapas, submetendo sempre que possvel s telas (mesmo que
prottipos) e funcionalidades para aprovao do cliente.
2. Caso ocorra o atraso no tempo do desenvolvimento, sobrar pouco tempo para
realizao dos testes, visto que a interpretao pode deixar a entender que os
testes so realizados aps o desenvolvimento.
a. Recomendao: importante que os testes ocorram em paralelo durante
todo o processo
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
31
3. Comear as respectivas revises e testes, em paralelo com as etapas de
desenvolvimento, no deve significar reviso e aceite ao final de cada etapa.
a. Recomendao: Revises e testes devem ser realizados enquanto os
documentos/diagramas so elaborados. Testadores devem se envolver na
reviso de documentos o mais cedo possvel ao longo do ciclo de
desenvolvimento.
Independente da representao grfica utilizada importante visualizar que o processo
de desenvolvimento e o de testes andam juntos para proporcionar um aumento na
qualidade do projeto do software.
Como os testes so realizados na empresa que voc trabalha? Existe algum tipo de abordagem sistemtica (casos de teste, apoio por ferramentas, automatizao de testes, definio de papis e processo, etc.)? Quais?
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
32
UNIDADE 7 Objetivo: Apresentar os fatores envolvidos em um bom planejamento de testes
Planejamento dos Testes
Para elaborar um planejamento de testes, importante identificar as seguintes questes,
conforme aponta McGregor e Sykes (2001):
Quem deve realizar os testes?
Quais partes devero ser testadas e receber mais ateno?
Em qual momento os testes sero realizados?
Como os testes sero realizados?
Quanto de teste adequado?
O planejamento dos testes visa minimizar os riscos e evitar desperdcios de tempo e
dinheiro. Se os testes forem realizados ao acaso, o esforo gasto tende a ser um prejuzo
e no proporcionar um retorno do investimento, visto que muitos defeitos no sero
identificados antes do software ir para produo.
E como em qualquer planejamento, o planejamento de testes aps ter sido realizado no
incio deve ser revisado e atualizado at o trmino do projeto, para no ficar engessado e
desatualizado, permitindo corrigir o rumo na ocorrncia de imprevistos. Se o planejamento
do desenvolvimento mudar, o planejamento de testes tem que ser reavaliado.
Esse planejamento feito em um documento de "Plano de Testes" que essencialmente
deve conter: o escopo, o processo de teste definido, os profissionais, ferramentas,
ambiente/hardware, estimativas financeiras, cronograma e riscos. Esses so itens
importantes, mas a composio do documento varia de empresa para empresa, sendo um
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
33
fator limitante os recursos disponveis principalmente de tempo e dinheiro. Um exemplo
de modelo de plano de testes o padro IEE 829.
Os autores do livro referncia para a certificao brasileira CBTS citam que o Plano de
Testes deveria seguir o modelo de Plano de Projeto do PMBOK, que o conjunto de
prticas para gesto de projetos, publicado pelo PMI (a principal associao mundial de
gerenciamento de projetos). Eles identificaram que possvel fazer uma relao entre os
dois modelos.
De forma geral, um bom Plano de Testes abordar questes como: o que ser testado, as
funcionalidades que sero testadas e as que no sero testadas em conjunto com o
motivo, o processo com as principais tcnicas e ferramentas que sero utilizadas, os
critrios para considerar os testes concludos, os artefatos que sero produzidos pelo
processo de testes (casos de testes, relatrios, etc.), indicadores de qualidade
(elaborados em conjunto com o cliente), a necessidade de aquisio de suprimentos
como hardware e software, necessidade de treinamento da equipe, as responsabilidades,
riscos do projeto de teste (ex: risco de determinado profissional ficar ausente, ou de ter
que utilizar uma ferramenta nova que ningum tem experincia), risco do negcio e das
funcionalidades do software, custo e cronograma previstos.
Abordando esses itens, o planejamento visa proporcionar aes preventivas ao invs de
reativas, de forma que os riscos sejam minimizados e as medidas (como por exemplo,
compra de hardware/software) sejam realizadas no momento certo para evitar atrasos.
Anlise dos Riscos
O planejamento est fortemente relacionado com a avaliao dos riscos que
fundamental para definir o que ser testado e em qual momento os testes podem ser
considerados terminados. Esse ponto bem importante porque no tem como realizar
testes exaustivos para garantir que o sistema est livre de defeitos ento preciso
garantir que as partes mais crticas do sistema foram testadas.
So avaliados os riscos, ou seja, potenciais situaes que se acontecerem podem gerar
diversos tipos de prejuzos e perdas para a organizao. Dessa forma, as ameaas e
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
34
vulnerabilidades so analisadas para identificar potenciais formas de controle que podem
prevenir, ou minimizar os prejuzos.
A anlise do risco avalia a probabilidade de ocorrncia com gravidade do impacto do dano
causado. Essa anlise deve ser feita ao longo de todo o projeto, uma vez que a gravidade
e o impacto podem mudar com o decorrer do tempo. Por exemplo, no incio do projeto a
probabilidade de invaso ao software quando estiver pronto pode ser alto, mas no
decorrer do desenvolvimento o surgimento de um componente de segurana que pode
ser acoplado ao software diminui os riscos.
A avaliao deve contemplar tanto os riscos referentes ao projeto e processo de teste em
si, quanto os riscos inerentes ao negcio, como por exemplo, as funcionalidades que
contemplam reas mais crticas.
Quanto ao projeto de teste os riscos j comeam no oramento e no cronograma. Se a
verba e/ou o tempo disponvel para os testes forem poucos, os testes sero realizados
inadequadamente, aumentando muito a probabilidade dos defeitos serem encontrados no
software j implantado, potencializando assim os prejuzos. Muitas vezes, a empresa que
est orando o desenvolvimento do software no contempla na proposta comercial o
custo e tempo para os testes, percebendo que tomou prejuzo somente no momento dos
testes de aceitao quando o cliente no aprova o que lhe foi apresentado. Portanto, no
fechamento do contrato fundamental negociar prazos e custos adequados que
contemplem a realizao dos testes. Outros riscos envolvem a qualificao da equipe,
utilizao de uma ferramenta nova para realizao dos testes, ambiente de teste pouco
parecido com o ambiente de produo, inadequao de metodologias, processo e
controle dos artefatos de teste.
A realizao dos testes custa dinheiro e o investimento necessrio aumenta na medida
em que a cobertura dos testes aumenta. A anlise de riscos bem realizada proporciona
uma destinao coerente dos esforos, priorizando as partes que apresentam maior
probabilidade de ocorrncia x impacto de perda (risco) de forma que o teste tenha o maior
nvel possvel de confiabilidade no tempo disponvel (Rios et al., 2007).
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
35
Portanto, necessrio realizar uma anlise de custo x benefcio para avaliar at que
ponto vale a pena investir em testes, respondendo perguntas como: "O custo da
ocorrncia do defeito muito maior do que o custo da sua preveno?".
Uma forma de se estabelecer a prioridade definir quantitativamente a probabilidade e
severidade (impacto) da ocorrncia. A tabela a seguir apresenta um exemplo simples de
anlise quantitativa de risco utilizando escalas como 1, 5, 10, 15; sendo que quanto maior
o nmero maior a prioridade.
Funcionalidade Probabilidade Severidade
(Impacto)
Prioridade
(P.x S.)
Realizar Depsito em Conta 15 15 225
Encerrar Conta 5 10 50
Cadastrar Fornecedor 1 1 1
Tabela 2 Exemplo simples de clculo de prioridade de funcionalidade a ser testada
Algumas das formas de determinar o risco so: intuio baseada na experincia de
profissionais, consenso da equipe e estimativas. Essa ltima se baseia em dados para o
clculo, como por exemplo: "Quanto custa cada hora que essa mquina fica parada sem
produzir?", "Quanto se perder, por minuto, se o site ficar fora do ar?".
Adicionalmente, pode-se utilizar tambm o Princpio de Pareto adaptado, em que 20% do
software so responsveis por 80% das funcionalidades mais utilizadas. Para determinar
quais so essas funcionalidades mais utilizadas, se o software j estiver em produo
(vale lembrar que as manutenes tambm devem ser testadas), pode-se monitorar as
estatsticas de uso, e caso o software no esteja implantado, perguntar aos usurios.
Porm, importante perceber que o Princpio de Pareto, por si s, pode no ser
suficiente, visto que uma funcionalidade pode ser muito importante e raramente utilizada,
mas se falhar pode causar um grande prejuzo. Portanto, deve-se avaliar quando essa
informao ser til, atrelada a outras estimativas.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
36
Trmino dos Testes
Um ponto muito importante relacionado ao projeto de testes o momento de identificar o
seu fim, para no acontecer: testes de menos, com uma interrupo, muito antes de
atingir a cobertura adequada (essa situao mais comum, principalmente por causa das
presses por prazos, ou inadequao em definir a cobertura apropriada); ou testes de
mais, implicando em custos, acima do necessrio, com o excesso de testes, pois o custo
adicional, com os testes, no compensa o custo que seria provocado pela falha.
Figura 7 Custo do teste comparado com nmero de defeitos que faltam ser corrigidos (Rios et al.,2007)
Portanto, importante identificar o ponto de equilbrio. Esse ponto de equilbrio est
relacionando com aspectos de criticidade: quanto mais crtico o negcio, mais testes
devem ser realizados. Por exemplo, os testes de um software para controle de rota de
espaonaves muito mais crtico do que um software para gesto financeira pessoal, de
forma que o primeiro requer muito mais testes, visto que, o prejuzo ocasionado por uma
possvel falha pode ser muito alto.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
37
Mas como se pode identificar esse ponto de interrupo? Rios e colaboradores (2007)
apontam algumas sugestes que podem ser utilizadas em conjunto para definir o
momento de trmino:
Quando intervalo de ocorrncia e identificao de defeitos aumenta muito de
horas para dias;
Quando a nova realizao de um ciclo de teste acha menos do que um nmero
determinado de "bugs";
Quando atinge determinado valor de cobertura sem descobrir novos defeitos;
De acordo com o nmero de defeitos encontrados e ainda no corrigidos,
considerando a respectiva severidade (ex: "existem defeitos, de alto ou mdio
risco, que ainda no foram corrigidos?").
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
38
UNIDADE 8 Objetivo: Entender os aspectos envolvidos com a preparao do ambiente de teste
Ambiente de Testes
preciso planejar tambm o ambiente em que os testes devem ser realizados. Engana-
se quem pensa que o ambiente se refere apenas ao hardware necessrio; ele engloba
toda a estrutura envolvida com a execuo dos testes, como por exemplo: sistemas
operacionais, browsers compatveis, a massa de dados a ser utilizada, e assim por diante.
As caractersticas do ambiente vo depender de alguns fatores. Quanto mais crtico o
software, mais o ambiente de teste deve ser parecido com o ambiente de produo. E em
alguns casos, o ambiente de produo pode ser o mais variado possvel. Por exemplo,
um grande site de vendas precisa rodar perfeitamente em diferentes browsers (e em
diferentes verses do mesmo) combinados com diferentes sistemas operacionais. Se uma
atualizao do site no rodar em um determinado browser padro, o prejuzo pode ser
grande; visto que seus clientes em um segundo podem acessar o site do concorrente.
Assim, a preparao do ambiente deve levar em considerao as caractersticas de cada
projeto. Um software com arquitetura cliente-servidor deve permitir a realizao adequada
de testes em ambientes que simulem bem a parte do cliente e tambm em ambientes que
simulem a parte do servidor.
Um software que precise ser testado com diferentes sistemas operacionais e
configuraes; pode utilizar as mquinas virtuais (ou "Virtual Machines"). Um mesmo
computador pode ser utilizado com diferentes mquinas virtuais. Cada mquina virtual
pode receber um sistema operacional diferente, reduzindo os custos. Assim, um nico
computador com um Windows 7 (ou qualquer outro sistema operacional) instalado, pode
ter uma mquina virtual com o Linux Ubuntu 10.10, outra com o Windows XP, outra com
Mac O.S, etc. A referncia do CBTS lembra um ponto importante; normalmente esses
ambientes no so recomendados para teste de performance, uma vez que a mquina
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
39
virtual pode no ter a quantidade suficiente de recursos alocados (ex: memria e
processamento) por estar sendo compartilhada com o sistema operacional do
computador.
Existem casos em que determinadas condies so proibitivas para a reproduo do
ambiente no local do desenvolvimento. Pode-se citar como exemplo fictcio, mas provvel,
uma indstria que contrata uma empresa para desenvolver um software. Essa indstria
pode ter uma estrutura de hardware muito cara que pode custar muito mais do que o
software que est sendo desenvolvido. Nesse caso, a empresa desenvolvedora tem que
realizar alguns tipos de testes no ambiente de testes da indstria, enviando alguns
participantes de sua equipe para l. importante perceber, que essa situao deve ser
prevista no planejamento dos testes.
Massa de Dados
A necessidade dos dados que sero utilizados nos testes varia de acordo com a
necessidade de cada tipo de teste. Os testes de unidades e integrao normalmente no
precisam de muitos dados, enquanto os testes de performance precisam, e para os testes
de homologao e aceitao interessante que tenha uma quantidade representativa.
Em alguns casos, ter dados reais de uma base j em produo relevante. Mas nem
sempre possvel obt-los seja porque no existe uma base de dados de produo
(sistema novo) ou porque a poltica de privacidade da empresa contratante no permite
que esses dados sejam acessados por terceiros. Caso seja possvel obter os dados reais
importante ter cuidado para camuflar dados confidenciais, substituindo-os ou
convertendo-os no momento da importao. Tambm preciso, avaliar se necessrio
utilizar todos os dados, ou se apenas uma parte deles seria mais adequada, filtrando o
que for relevante para reduzir a base. Em alguns casos, como nos testes de performance
e estresse, os dados geralmente no precisam ser reais, ou seja, em muitos casos podem
ser gerados aleatoriamente.
Outro ponto importante a se observar, na realizao de testes com dados reais, em
relao ao disparo de e-mails. Se a aplicao possui funcionalidades que disparam e-
mails, na base de teste fundamental adotar uma poltica que tratem os mesmo,
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
40
adotando medidas como substituir os e-mails originais por e-mails de teste, por exemplo.
Essa poltica visa evitar problemas maiores com as pessoas cadastradas no sistema.
Alm de ser incmodo para pessoa receber e-mails desse tipo, uma informao falsa
pode ser enviada causando confuso e problema. Por exemplo, se estiver sendo
realizado um teste em um sistema bancrio e um cliente que possua uma fortuna recebe
um e-mail disparado pelo ambiente de testes informando que sua conta foi zerada,
certamente seria gerado um transtorno. Outro ponto que deve ser observado, que a
aplicao no ambiente de testes deve estar apontando para um banco de dados de
testes, pois em alguns casos, por descuido, eles podem estar apontando para o banco de
produo, ocasionando a perda de dados importantes.
Quando no for possvel, ou no for necessrio obter dados reais, de acordo com o
objetivo e necessidade de volume dos testes, os mesmos podem ser gerados
manualmente ou ento automaticamente; sendo gerado de forma aleatria por alguma
ferramenta.
Como diferentes tipos de testes demandam de diferentes tipos de dados, vrias bases
com propsitos distintos so criadas. Aps essa criao, interessante fazer o backup
dessas bases, armazenando-os de forma adequada e categorizada, para futura
reutilizao em testes de regresso ou outros. Por exemplo, suponha um sistema que
gerencia planos de sade que de acordo com a idade do cliente cadastrado o valor e os
benefcios mudam. Os casos de testes vo ser elaborados para exercitar essa situao
de forma que um determinado cliente seja "envelhecido" nos testes, passando por
diferentes idades. Assim, um teste pode comear com "Joo da Silva" com 5 anos de
idade e no final dos testes, ele estar com 75 anos. Aps a realizao de alteraes no
sistema os testes de regresso vo precisar que "Joo da Silva" tenha 5 anos novamente,
bastando para isso restaurar a base previamente criada com essas condies.
Ferramentas
Faz parte de preparao, e utilizao do ambiente, o uso de ferramentas. As ferramentas
visam apoiar diversos aspectos relacionados aos testes, desde a gesto do processo de
teste em si at a execuo dos mesmos. Portanto, existem ferramentas para gerenciar os
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
41
testes, controle de defeitos, cobertura de cdigo e ainda, realizar testes de estresse,
facilitar os testes unitrios, comparar os resultados dos testes, dentre outros. Existem
ferramentas que atuam sobre uma atividade especfica enquanto outras contemplam mais
do que uma.
Apenas a aquisio da ferramenta no condio suficiente para obter o sucesso na
atividade que ela suporta. Portanto, existem os benefcios que podem ser conquistados e
tambm existem os riscos que so apresentados abaixo, baseados na referncia da
certificao do ISTQB:
Alguns possveis benefcios:
o Reduo de trabalhos repetitivos (ex: execuo de testes de regresso)
o Avaliao dos objetivos (ex: nmero de defeitos, cobertura de cdigo)
o Maior consistncia e possibilidade de repeties (ex: testes realizados por
uma ferramenta)
o Facilidade de acessar as informaes sobre os testes (ex: estatsticas e
grficos referentes ao progresso do teste, como nmero de defeitos graves
que faltam ser corrigidos)
Alguns riscos potenciais:
o Criar expectativas falsas sobre a ferramenta, como por exemplo,
funcionalidades oferecidas e facilidade de uso;
o Subestimar o tempo necessrio para iniciar o uso da ferramenta, assim
como, custo e esforo necessrio para conseguir utilizar a mesma;
o Subestimar o esforo necessrio para manter atualizados os artefatos
gerados pelas ferramentas;
o Tentar utilizar a ferramenta para tudo, mesmo quando a realizao manual
seria mais adequada.
Ao longo deste Mdulo, sero apresentadas algumas ferramentas gratuitas, que se forem
bem empregadas podem auxiliar bastante nos testes. Essas ferramentas servem para
demonstrar conceitos para voc saber escolher qual tipo de ferramenta ser adequada ao
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
42
seu projeto. Entretanto, o Mdulo no tem a pretenso de abranger todos os aspectos
dessas ferramentas, at mesmo porque o manual delas extenso. Assim, problemas com
instalao e utilizao das ferramentas no devem ser retiradas na sala de aula, e sim
nos manuais encontrados em fruns de discusso da internet, dentre outros meios
adequadamente disponveis na web para essa finalidade.
Algumas ferramentas demonstradas so especficas para linguagem de programao
Java. Uma vez entendido os benefcios oferecidos por determinado tipo de ferramenta,
independente da linguagem de programao, basta pesquisar na internet por uma
ferramenta similar para a sua linguagem de programao preferida.
Existem ferramentas que facilitam a gerao, extrao e manipulao de dados, como por exemplo a ferramenta gratuira Kettle da suite Pentaho, disponvel em http://kettle.pentaho.com/.
Para crirar as "Virtual Machines" uma opo gratuita o Virtual Box - http://www.virtualbox.org/.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
43
UNIDADE 9 Objetivo: Apresentar as abordagens para montar a equipe de testes, bem como os papis existentes
A Equipe e os Papis nos Testes
Conforme visto anteriormente, as atividades relacionadas com os testes devem ser
iniciadas junto com projeto de software. Dessa forma, a equipe de testes inicia sua
participao no incio do projeto para detectar defeitos o mais cedo possvel, visando
evitar a propagao dos mesmos e tentar corrigi-los enquanto os custos so menores.
A equipe de testes utilizar os artefatos gerados pela equipe de desenvolvimento para
test-los ou planejar testes de outros artefatos.
Para montar a equipe de testes, existem algumas abordagens que vo desde utilizar os
prprios desenvolvedores at terceirizar os testes para equipe externa. A estratgia
utilizada depende muito das condies do projeto, como custo, prazo, dentre outros. O
ideal uma equipe de testes dedicada (seja ela interna ou terceirizada), mas muitas
vezes esse objetivo difcil de alcanar por restries financeiras. Mas importante ter
em mente que: dificilmente se obtm resultados satisfatrios quando o desenvolvedor
testa o prprio cdigo. Alguns motivos so:
O testador precisa trabalhar de maneira isenta e independente e os seres humanos
tendem (mesmo que de forma inconsciente) a encobrir os seus prprios enganos.
difcil ter motivao psicolgica para elaborar casos de testes que mostram que
seu cdigo possui defeitos
Ao desenvolver utilizou-se uma lgica de raciocnio que precisa ser modificada,
para tentar identificar os possveis defeitos.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
44
O desenvolvedor possui uma lista de atividades para desenvolver e normalmente
fica ansioso. Quando termina uma atividade, tem a inteno de logo comear outra
e no parar e ficar testando o que j fez.
Essas dificuldades no so exclusivas de desenvolvedores de software, por isso, esto
presentes em qualquer tipo de construo intelectual. Voc j tentou revisar um texto
depois que escreveu? E revisar novamente aps outra pessoa ter feito uma reviso
seguida de correes? Muitas pessoas consideram essa atividade torturante.
Abordagens para montar a equipe
A seguir, algumas vantagens e desvantagens de montar a equipe de testes com os
desenvolvedores e outra com profissionais designados somente para essa funo, com
base na referncia da certificao CBTS (Rios et al., 2007).
1. Alocar equipe de desenvolvimento para realizar os testes
Nesse caso, um desenvolvedor (ou analista) deve testar a funcionalidade do outro, de
forma que o responsvel nunca deve testar o que ele mesmo produziu (com exceo dos
testes unitrios e alguns tipos de integrao).
Para isso, importante que os desenvolvedores passem por treinamentos que permitam
desempenhar melhor a funo de testador, adquirindo conhecimentos com tcnicas,
documentos e ferramentas de testes.
Apesar dessa abordagem envolver menores investimentos iniciais e permitir alcanar
resultados positivos, o gerenciamento passa ser mais trabalhoso, uma vez que
necessrio organizar o tempo e sincronizar cronogramas de forma a no atrapalhar o
trabalho do outro desenvolvedor (seja por interrupo ou espera da realizao dos testes
para poder prosseguir).
Alm da dificuldade de sincronizar cronogramas, outros riscos envolvidos so: os
desenvolvedores tero uma tendncia a realizar os testes de maneira mais informal.
Assim, dificilmente mantero os documentos de testes atualizados, portanto, no tero
conhecimento a respeito do negcio.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
45
2. Alocar equipe independente para realizar os testes
A equipe independente pode ser da prpria empresa desenvolvedora ou ento uma
equipe externa, terceirizada. Essa abordagem tem um custo inicial maior, visto que mais
pessoas estaro envolvidas e alocadas no projeto. Porm, tende a proporcionar um
retorno financeiro maior ao longo do tempo, principalmente se for contabilizado o custo de
corrigir os defeitos encontrados no software em produo.
A qualidade final maior devido : dedicao de tempo maior, conhecimento mais
especializado nas tcnicas, ferramentas e metodologias de teste.
Para funcionar bem, preciso gerenciar alguns pontos, como por exemplo: a equipe de
desenvolvimento pode achar que a responsabilidade sobre a qualidade somente da
equipe de testes, diminuindo o seu padro de qualidade e existe uma tendncia de
desentendimento entre as duas equipes, que pode ser ocasionado principalmente se os
testadores reportarem os erros com linguagem inapropriada (ex: deboche, agressividade,
etc.).
Beizer j dizia, em 1990: "Testadores, quebrem o software como de sua
responsabilidade, e teste com fora, mas no sinta prazer com a dor do programador"
(traduo livre).
Papis no Processo de Teste
A equipe de desenvolvimento responsvel por realizar os testes unitrios e de
integrao. Em relao equipe de testes, normalmente os papis existentes so:
Gerente de Teste: esse papel semelhante ao gerente de projetos, e normalmente
encontrado apenas em equipes maiores.
Lder do Projeto de Teste: lidera um projeto de teste especfico
Arquiteto de Teste: tem como responsabilidade preparar o ambiente de testes e
escolher as ferramentas que sero utilizadas
Analista de Teste: elabora os casos de teste
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
46
Testador: executa os casos de teste
Pode ser que profissionais acumulem alguns papis (tanto de teste como de
desenvolvimento), de acordo com a necessidade e porte da equipe e projeto. Em relao
automatizao dos testes e aos testes de performance, essa atribuio, dependendo da
equipe, fica sob responsabilidade do testador ou do analista de teste.
Certificaes para Profissionais de Testes
Existem no mercado vrias certificaes para os profissionais de testes. Abaixo so
relacionadas trs delas (2 delas j citadas neste mdulo) que so bem aceitas no Brasil,
juntamente com algumas informaes adicionais. Vale ressaltar que essas informaes
servem apenas para dar uma pequena noo, visto que os valores, tempo, nmero de
questes podem mudar.
CBTS - Certificao Brasileira de Teste de Software
o ALATS (Associao Latino-Americana de Teste de Software)
o Material de apoio para a certificao: Livro Base de Conhecimento em Teste de Software, 2 edio.
o Valor: R$ 300 reais.
o Nmero de Questes: 100 questes.
o Percentual de Acerto para aprovao: 75%
o Durao: 3 horas.
o Formato: Mltipla escolha.
o Site: http://www.alats.org.br
CTFL Foundation - Certified Tester, Foundation Level
o ISTQB(International Software Testing Qualifications Board)
o Material de apoio para a certificao: "Foundation Level Syllabus" e "Glossary of Terms" (ambos possuem traduo para portugus).
o Valor: R$ 350 reais.
o Nmero de Questes: 40 questes.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
47
o Percentual de Acerto para aprovao: 60%
o Durao: 1 hora.
o Formato: Mltipla escolha.
o Site: http://www.bstqb.org.br/
CSTE - Certified Software Tester
o QAI - Quality Assurance Institute
o Material de apoio para a certificao: Common Body of Knowledge(CBOK).
o Valor: U$ 350 dlares.
o Nmero de Questes: 100 mltipla-escolha e 20 dissertativas curtas
o Percentual de Acerto para aprovao: 75%
o Durao: 4 horas e meia.
o Formato: Mltipla escolha e dissertativa.
o Site: http://www.softwarecertifications.org/qai_cste.htm
Uma alternativa de terceirizao da equipe de testes que vem ganhando popularidade, principalmente no exterior o "CrowdTest" (algo como"teste da multido").
Tarefa Dissertativa
Acesse a sua sala de aula para realizar a seguinte tarefa dissertativa:
Pesquise em artigos e sites e faa uma sntese, com suas prprias palavras, sobre "CrowdTest".
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
48
UNIDADE 10 Objetivo: Entender a importncia de realizar revises e inspees nos artefatos do processo de desenvolvimento
Tcnicas Estticas - Reviso e Inspeo
As tcnicas de Teste Dinmico necessitam da execuo do cdigo fonte para serem
realizadas. Portanto pode-se citar como exemplo, a execuo dos testes unitrios e dos
testes de performance como tcnicas de Teste Dinmico.
J as tcnicas de Teste Esttico no esto relacionadas execuo do cdigo fonte, que
pode muitas vezes nem existir ainda. So exemplos de testes estticos, as revises de
artefatos como especificao de requisitos, diagrama de classes, inspeo do cdigo
fonte, dentre outros. Portanto, muitas das tcnicas de Teste Esttico so realizadas
"manualmente", como a leitura de documentos para identificar inconsistncias.
Como estudado anteriormente, quanto mais cedo um defeito for identificado, menor o
custo da sua correo. Para evitar que defeitos introduzidos nos artefatos, como
especificao de requisitos, diagramas de classe, etc., se propaguem para os demais
artefatos, importante realizar a reviso desses documentos.
Para facilitar a leitura, os defeitos dos artefatos citados nesta Unidade, so mais
abrangentes do que o conceito de defeito que ser estudado, abstraindo o conceito para
qualquer tipo de problema. Ao revisar os requisitos e diagramas os tipos de problema
procurados so (Kalinowski,2008):
Omisso: falta de informaes relevantes a respeito do sistema, como por
exemplo, parte importante no definida, ausncia de classes, diagramas, etc.
Ambiguidade: a descrio do texto ou diagramas permite que a mesma informao
seja interpretada de diferentes formas
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
49
Inconsistncia: informaes no mesmo artefato ou em artefatos distintos so
conflitantes entre si
Fato Incorreto: a informao textual ou diagramtica no condiz com a verdade
Informao Estranha: informaes que no so necessrias ou no so utilizadas
Outros: os demais tipos de defeito, como posicionamento errado de informaes
em determinada seo.
A realizao da reviso deve iniciar o quanto antes e no somente ao trmino de uma
fase. As revises podem seguir processos informais ou formais. Segundo o Syllabus do
ISTQB, a reviso formal normalmente contempla as etapas de planejamento, kick-off,
preparao individual, reunio de reviso, correo e acompanhamento. No planejamento
so definidas as tcnicas a serem empregadas e os revisores, dentre outros. A fase de
kick-off contempla a distribuio dos documentos, e explicao para os participantes
sobre os objetivos, documentos e processos. A preparao individual consiste na reviso
individual antes da reunio, de forma que cada revisor identifique os problemas,
comentrios e sugestes. Na reunio de reviso, os participantes discutem as anotaes
realizadas previamente e decidem com a ajuda do moderador os defeitos (e os pontos
que no so defeitos) e possveis encaminhamentos. O retrabalho (correo) a etapa de
correo dos defeitos, normalmente pelo autor do artefato. O acompanhamento consiste
em verificar se os defeitos foram devidamente corrigidos e a necessidade de uma nova
reviso.
As abordagens para leitura normalmente so: ad hoc, baseadas em checklists e tcnicas
de leitura de software. A leitura ad hoc no possui um mtodo definido, sendo sua eficcia
dependente da habilidade do revisor. A leitura baseada em checklist (ou lista de
verificao) no apresenta uma metodologia sistemtica, mas sim um conjunto de
caractersticas de defeitos conhecidos previamente, que devem ser verificados (Falbo,
2008). J a tcnica de leitura de software visa adotar uma postura mais sistemtica na
realizao da reviso. Pode-se citar como exemplo, a Tcnica de Leitura Orientada a
Objetos (OORT - Object-Oriented Reading Techniques). A OORT estabelece
procedimentos para reviso de documentos e diagramas do projeto orientados a objeto
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
50
(Mafra e Travassos; 2005). Duas dimenses so analisadas, a leitura horizontal
(verificao de consistncia de artefatos de uma mesma fase) e leitura vertical
(verificao de artefatos produzidos em fases diferentes) (Falbo, 2008). Assim, so
apresentadas tcnicas que verificam, por exemplo, a consistncia dos casos de uso com
o diagrama de classes.
Na inspeo do cdigo fonte, algumas atividades podem ser apoiadas por ferramentas.
Por exemplo, a ferramenta Checkstyle (http://checkstyle.sourceforge.net/) verifica se o
cdigo fonte dos desenvolvedores segue um padro como nomenclatura de mtodos,
cdigo duplicado, etc. J a ferramenta gratuita FindBugs (http://findbugs.sourceforge.net/),
para Java, analisa estaticamente o cdigo fonte e aponta possveis defeitos, baseados em
padres conhecidos. Dentre as inmeras anlises realizadas, aponta variveis que no
so inicializadas, possveis ocorrncias de excees de "null pointer", indicao de
problemas de performance com cdigo desnecessrio, tratamento incorreto de excees,
etc.
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
51
UNIDADE 11 Objetivo: Conhecer os conceitos e contedo dos casos de Teste
Casos de Teste
O Caso de Teste um dos artefatos do processo de teste. Seu objetivo documentar os
cenrios de teste de forma a verificar se os resultados esperados esto sendo atingidos.
Normalmente, utiliza-se os casos de uso (do processo de desenvolvimento) para elaborar
os casos de teste, sendo que cada cenrio do caso de uso pode ser coberto por um ou
mais casos de testes. Entretanto, existem alguns casos de testes que so baseados em
requisitos no funcionais, como por exemplo, desempenho, e dessa forma no utilizam os
casos de uso como base.
Como os casos de uso so utilizados como base, caso eles sejam alterados os casos de
teste precisam ser revisados. Por isso, importante manter a rastreabilidade entre a
especificao de requisitos e casos de teste. Uma boa ferramenta de gesto de teste
deve oferecer a funcionalidade para realizar essa rastreabilidade.
Contedo do Caso de Teste
O contedo do caso de teste, normalmente, composto por valores de entrada, pr-
condies de execuo, os passos/procedimentos e resultados esperados. Essas
informaes normalmente so utilizadas, mas o contedo do documento pode ser
adaptado pela equipe.
Segue abaixo uma possibilidade de campos para compor um caso de teste:
Autor: autor do caso de teste
Id: nmero que identifica o caso de teste
Ttulo: deve descrever brevemente o caso de teste
-
Copyright 2011, ESAB Escola Superior Aberta do Brasil
52
Pr-condies: condio que deve ser atendida antes do teste ser executado. Por
exemplo, pode ser necessrio ter um cliente cadastrado com um filho de 17 anos
Dados de entrada: indica os dados que sero informados durante o teste
Procedimentos: descreve os passos que devem ser realizados para executar o
teste, indicando qual passo realizado pelo testador e qual realizado pelo
sistema.
Dados de sada: dados que foram modificados ou produzidos durante a execuo
do teste.
Ps-condies: situaes que devem ser veri