módulo vi - teste de software

Copyright 2011, ESAB Escola Superior Aberta do Brasil

1

MDULO DE:

TESTE DE SOFTWARE

AUTORIA:

Me. PEDRO HENRIQUE MANNATO COUTINHO



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



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,


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.


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


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


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


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


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.


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


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.


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


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


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


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


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.


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.


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.


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


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.


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


Custo da Correo 0 35.000 50.000

Suporte ao usurio


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


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.


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:


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


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


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?


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.


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


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?


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


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?


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


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


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


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.


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.


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?").


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


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,


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


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


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


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.


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.


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


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.


47


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


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


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


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.


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


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

módulo vi - teste de software

Documents