Visões Sobre Teste de Software

Vises sobre Teste
de Software
Diferentes perspectivas da comunidade
de teste brasileira discutidas no DFTestes
made with
Indice
1.
Sobre o eBook
Este eBook um trabalho colaborativo e aberto a comunidade de teste
de software.
2.
Introduo
3.
Autores e Revisores
4.
Captulo 1: Testar to fcil, que at a minha me

testaria!
5.
Captulo 2: Certificaes, valem a pena?
6.
Captulo 3: O Testador tambm necessita saber

programar?
7.
Captulo 4: Testar sem documentao possvel?
8.
Captulo 5: Quando documentar no preciso?
9.
Captulo 6: Utilizao de Processos geis no Teste

de Software (SCRUM, XP, TDD...)
10. Captulo 7: Teste gil, como implementar?
11. Captulo 8: Quando Automatizar?

12. Captulo 9: Estimativas de Testes (APT)
13. Captulo 10: MPT.BR Melhoria do Processo de
Teste Brasileiro
Sobre o eBook
Este eBook um trabalho colaborativo e aberto a comunidade de
teste de software.
Este ebook foi criado com o intuito de disseminar e facilitar o acesso a

informao gerada pela comunidade de teste de software possuindo diversos
autores e colaboradores que fizeram o trabalho de reviso e escrita das Mesas
Redondas no grupo de e-mail DFTestes.
Distribua este eBook a qualquer pessoa que queira receber informao sobre
a rea de teste de software.
Como este contedo surgiu?

Em 2009, em uma lista de e-mails chamada DFTestes o Fabricio Ferrari lanou
na lista um desafio colaborativo chamado de Mesa Redonda.
Depois de diversas mesas redondas e timas discusses resolvemos (como
comunidade) elencar as 10 principais e trabalha-las a fim de criar um
contedo que qualquer um possa consumir sem custo e com a viso de
diversos profissionais da rea de teste de software.
Eu (Elias Nogueira) estou chamando agora esta iniciativa criada l em 2009,
onde muitas continuam muito atuais, de Vises sobre Teste de Software. As
10 principais discusses esto tambm disponveis no site
http://dftestes.gershon.info/Conteudo.html
Este ebook foi criado a "quatro mos" por profissionais de Teste de Software
que deram seu tempo para disseminar este conhecimento. Todos eles so os
autores deste ebook e merecem todo o nosso reconhecimento!
Introduo
Shmuel Gershon
Revisor: Marcelo Andrade
(...) a terra em si de muito bons ares (...) Em tal maneira graciosa

que, querendo-a aproveitar, dar-se- nela tudo!
Em seu relatrio de viagem sobre o Brasil, Pero Vaz de Caminha demonstrou
bastante perspiccia para um turista em sua primeira visita. Caminha tambm
notou algo mais sobre esta nova 'ilha', e afirmou que apesar de todas as terras
e guas, o que o Brasil tem de melhor so seus habitantes: "o melhor fruto que
dela se pode tirar parece-me (...) esta gente."
Eram os anos Mil e Quinhentos, e nos anos Dois Mil a situao pouco mudou.
Trocam-se os 'mancebos' nativos pelos brasileiros modernos, e trocam-se os
arcos e flechas por computadores, sistemas operacionais, Internet e
aplicativos; o Brasil ainda est empenhado em avanar.
Esse avano tecnolgico cobre todas as reas da informtica moderna. Uma
boa frao da populao ainda no tem acesso a essas novidades, mas a
indstria mantm-se atualizada e oferece servios que competem no mercado
internacional.
Um desses servios, matria que viu grande crescimento no Brasil nesta ltima
dcada, o Teste de Software.
Esta importante etapa no desenvolvimento de software tem como objetivo
revelar informaes sobre os aplicativos e diminuir a incerteza sobre sua
qualidade e risco. A qualidade de um software definida pelo valor que este
tem para o cliente, e os testadores so os responsveis por estudar o valor
percebido pelo cliente e relacion-lo s necessidades da empresa.
Hoje, mais de 1500 desses testadores de software se renem no frum de

discusso DFTestes, correspondendo-se atravs de mais de 300 mensagens ao
ms. A que se deve tanto movimento?
Fruns de discusso so o habitat natural dos testadores de software, pois
"Testar questionar um produto para descobrir informaes sobre sua
qualidade", como define James Bach. Um testador passa sua jornada de
trabalho fazendo perguntas; ao diretor, ao cliente, ao programador, a um
colega, at mesmo perguntas ao aplicativo. Mas as questes mais difceis, as
"cabeludas" e filosficas, as que precisam de uma viso objetiva e
descompromissada, essas vo para o frum, para os colegas virtuais.
Para quem no conhece a indstria de testes, isso pode parecer estranho...
Que perguntas cabeludas podem haver sobre Testes de Software? Testar o
software consiste em executar um programa e seguir passos predefinidos,
no?
Essa falta de segurana na natureza do trabalho uma das grandes dvidas
de nossa rea. Algumas respostas esto disponveis no captulo "Testar to
fcil que at minha me testaria" deste livro.
Pois este um dos objetivos deste livro: expor o mundo dos Testes de
Software ao leitor de diferente rea.
Ao abordar os dilemas de forma aberta e baseando-se em comentrios da
comunidade, este livro um timo retrato do cenrio atual de Teste de
Software no Brasil. Isso , um grande auxlio para colaboradores e diretores,
pois empresas e equipes precisam dessa compreeno para posicionar seu time
de testadores de maneira eficiente. Por exemplo, todo administrador procura
as melhores solues para os problemas cobertos nos captulos "Melhoria do
Processo de Teste" e "Estimativas de Testes". E em uma transio para
metodologias geis, o papel do time de testes pode ser definido de diversas
maneiras -- de modo que os captulos "Teste gil, como implementar?" e
"Utilizao de Processos geis no Teste de Software" sao teis ao apresentar
algumas das prticas da indstria.
Mas a educao de parceiros no o nico objetivo deste livro. O principal

propsito guiar o testador irresoluto, e ajud-lo a levantar novas perguntas.
As dvidas so inmeras, sejam relacionadas a carreira (ver capitulos
"Certificaes, valem a pena?" e "O Testador tambm necessita saber
programar?"), ou relacionadas a eficcia no trabalho ("Quando automatizar?",
"Testar sem documentao possvel?" e "Quando documentar no
preciso?").
Denota-se que o livro no visa responder em definitivo a nenhuma dessas
questes, mas sim oferecer comentrios de colegas de profisso experientes e
referncias online -- na esperana que o leitor possa criar sua prpria resposta
que satisfaa seu contexto e necessidades.
Como escreve Michael Bolton, "Contrariamente ao folclore de nossa profisso,
uma boa pergunta sobre testes no tem necessariamente uma resposta
definitiva ou um resultado decisivo. Testes ou perguntas que apenas visam
confirmar uma teoria predeterminada dificilmente revelam nova informao
til."
Finalmente, por que no, fica o leitor convidado a compartilhar conosco suas
prprias respostas e opinies sobre os assuntos na lista DFTestes. dessa
contribuio que nossa comunidade deriva sua fora, e todos so bem vindos!
Autores e Revisores
Introduo
Autor: Shmuel Gershon Lder Tcnico no campus Israelense da Intel
Corporation, Shmuel Gershon tem experiencia em testes de firmware e
software, em treinamento de testadores e em ajuda a amigos. No passado ele
foi programador, mas descobriu que testar prov diverso em dobro. Shmuel
acredita que os fatores mais significativos na nossa busca pela qualidade so
as pessoas, e no funes ou tecnologias. Ele escreve sobre testes em
http://testing.gershon.info, e recentemente publicou "Rapid Reporter", um
aplicativo para tomar notas em testes exploratrios.
Captulo 1
Autora: Alice H. Tamashiro especialista em Gesto da Qualidade, Testes e
Processos. Trabalha como professora no curso de ps-graduao em
Engenharia de Software, Desenvolvimento Colaborativo - JAVA e no curso de
extenso em Qualidade e Testes de Software na Universidade da Cidade de
So Paulo - UNICID.
Revisor: Rodrigo Souza
Captulo 2
Autor: Gustavo Nascimento docente de graduao e de ps-graduao,
ministra disciplinas relacionadas a qualidade de software, a testes, a gerncia
de configurao e ao modelo MPS.BR. Trabalha com melhoria de processos
baseada no modelo MPS.BR e coordena equipes de testes, de gerncia de
configurao e de garantia da qualidade. Gustavo tambm trabalha e ministra
cursos sobre ferramentas de integrao de processo e sobre os temas citados.
Revisor: Felipe da Silva Analista de Testes da IBM, atua em contato direto
com cliente DIRECTV dos E.U.A, atua na rea de qualidade e melhoria de

processos, desenvolve e aprimora ferramentas e metodologias visando
melhoria contnua de produtividade, presta suporte ao cliente e ao time da
IBM na ndia, assim como leciona treinamentos e apoia demais membros do
projeto, ponto focal snior na aplicao corao do sistema de vendas de
seu cliente.
Captulo 3
Autora: Karine Birnfeld
Revisora: Anna Carolina Rocha
Captulo 4
Autora: Sarah Pimentel
Revisora: Keite Moraes
Captulo 5
Autor: Edwagney Luz
Captulo 6
Autora: Mara Dutra
Revisora: Patrcia Silva Corra
Captulo 7
Autor: Lucas Gonalves Nadalete
Revisora: Juliana Kryszczun
Captulo 8
Autor: Fabrcio Ferrari de Campos apaixonado pelo que faz e tenta espalhar
esse esprito para os outros profissionais, pois acredita que o trabalho uma
das formas de contribuir para o mundo e tambm para o crescimento pessoal
e profissional. Atua na Vizir, onde co-fundador, uma start-up focada em
mdias sociais que desenvolve o Vizir, uma ferramenta para monitorao nas
redes sociais, e tambm presta consultorias na rea de desenvolvimento de
software. Fabrcio tambm autor do QualidadeBR, um blog focado em Teste
e Qualidade de Software, onde ele tenta escrever semanalmente sobre essa
rea to divertida e desafiante.
Captulo 9
Autores: Fabrcio Ferrari de Campos e Karine Birnfeld
Autor: Fabrcio Ferrari de Campos apaixonado pelo que faz e tenta espalhar
esse esprito para os outros profissionais, pois acredita que o trabalho uma
das formas de contribuir para o mundo e tambm para o crescimento pessoal
e profissional. Atua na Vizir, onde co-fundador, uma start-up focada em
Captulo 10
Autor: Ueslei Aquino da Silva Analista de Testes Snior da RSI. Atuou como
lder de equipe de testes na iTeste. Ocupou a posio Gestor do Dpto de Testes
na MXM Sistemas. Ps-Graduado com MBA em Garantia da Qualidade de
Software pela COPPE-UFRJ. Atuou como membro do Conselho Tcnico do
MPT pela ALATS com tarefas de ((i)Criao e aprimoramento contnuo do
modelo MPT e seus Guias especficos;(ii)Validao das avaliaes efetuadas;
(iii) etc.). Atuou no Comit de Inovao da ALATS na frente de trabalho do
MPT para reviso e auxlio s necessidades do MPT. Certificado como
Implemetador MPT (Nvel 1 e 2) e CBTS - Certificao Brasileira de Teste de
Software. Consultor MPT.
Revisora: Carla Regina Florentino Sampaio
Diagramadores
Robson Agapito Corra
Fabrcio Ferrari de Campos apaixonado pelo que faz e tenta espalhar esse
esprito para os outros profissionais, pois acredita que o trabalho uma das
formas de contribuir para o mundo e tambm para o crescimento pessoal e
profissional. Atua na Vizir, onde co-fundador, uma start-up focada em
Facilitadores
Daniel Goettenauer Bacharel em Sistema de Informao pela Universidade
Luterana do Brasil, Tecnlogo em Desenvolvimento de Software pelo Instituto
Federal do Amazonas; Ps-graduado em Governana de TI pelo SENAC-RIO.
H 5 anos dedicando estudos a Engenharia de Software com foco em Testes.
Membro da Associao Latino Americana de Teste de Software. Colaborou
como Editor no Livro Conversando sobre Teste de Software. Atualmente
cursando MBA de Gerenciamento de Projetos na Fundao Getlio Vargas.
http://goette.com.br
Fabrcio Ferrari de Campos apaixonado pelo que faz e tenta espalhar esse
esprito para os outros profissionais, pois acredita que o trabalho uma das
formas de contribuir para o mundo e tambm para o crescimento pessoal e

profissional. Atua na Vizir, onde co-fundador, uma start-up focada em
Paulo Csar
Ricardo Franco
Editores
Andrea Cruz
Daniel Goettenauer
Elias Nogueira
Juliana Kryszczun
Captulo 1: Testar to
fcil, que at a minha me
testaria!
Alice Tamashiro
Revisor: Rodrigo Souza
Introduo
Atualmente vivemos em um mundo onde os negcios possuem uma grande
dependncia pela TI (Tecnologia da Informao) e medida que esse fator
aumenta, tambm cresce a produo de software e complexidade dos
sistemas. Um exemplo quando um risco operacional da TI se propaga para
os negcios, deixando de ser um risco da TI, passando a ser um risco do
negcio, ou seja, se uma falha ocorrer nos sistemas, consequentemente
ocorrer uma falha nos negcios. Desta forma, torna-se fundamental o
desenvolvimento de software com mais qualidade e confiabilidade. Neste
captulo ser abordado o porqu se devem ter profissionais qualificados na
elaborao e execuo de testes.
Linha de Evoluo entre TI e Testes

A tecnologia pode ser identificada em vrios momentos da evoluo humana,
as descobertas de uma poca que para a maioria da populao eram
novidades ou desconhecidas, eram consideradas como tecnologia.
A tecnologia relacionada a informaes surgiu em meados dos anos 60 com a
criao do Processamento de Dados. O Processamento de Dados era
responsvel por realizar a execuo de atividades burocrticas como gerao
de relatrios de folhas de pagamento.
Nos anos 70, iniciou-se a era dos Sistemas de Informaes onde as informaes
coletadas e reportadas pelo Processamento de Dados passaram a ser
organizadas e refinadas com o auxilio da evoluo do meio de
armazenamento e processamento destas informaes.
Nos anos 80, inseriu-se no contexto tecnolgico a era da Inovao e Vantagem
Competitiva, nessa poca as empresas descobriram que podiam utilizar as
informaes de forma organizada e refinada com o auxilio da execuo das
tarefas de escritrio e no apenas para agilizar o processo de trabalho, mas
tambm tomar decises de forma mais rpida e entender melhor os seus
clientes. Nessa poca tambm teve uma grande evoluo do hardware e das
redes de computadores, porm, ainda no havia uma boa integrao.
Nos anos 90, com a necessidade constante de obter informaes cada vez mais
rpidas, distribudas e com maior integrao entre hardware, software, redes,
surge a era da Integrao e Reestruturao do Negcio, onde passa a ter maior
flexibilidade e troca de informaes em que as empresas se vem na
necessidade de utilizar cada vez mais sugestes tecnolgicas para a tomada de
deciso.
Assim como a tecnologia, os testes tiveram evoluo ao longo do tempo. Essa
evoluo se deu devido necessidade de melhorar a qualidade do software
desenvolvido. Iniciou-se nos anos 70 devido ao aumento de informaes e
complexidade de armazenamento dos dados. No incio, os testes de software
eram realizados dentro do processo de desenvolvimento pelo prprio
desenvolvedor realizando os atualmente chamados Testes Unitrios.
A complexidade dos programas de computador dificultava muito a execuo
dos testes e como consequncia os programas eram liberados com inmeros
defeitos. No final de 1979 o Teste de Software foi conceituado por Myers
como sendo um processo no qual se executava um programa com a inteno
de encontrar erros.
Nos anos 80 e 90, iniciou-se o movimento da melhoria dos Testes deSoftware,
os resultados obtidos foram timos e empresas comearam a investir em
ferramentas de automao, houve diminuio dos custos de correo dos
defeitos, criao de rea prpria e aderente ao processo de desenvolvimento,
as atividades de Testes de Software comearam a iniciar-se paralelamente e
integradas com o desenvolvimento.
Hetzel conceituou o Teste de Software como sendo qualquer atividade que

tem como objetivo mensurar a qualidade do software e avaliar um atributo de
um programa ou sistema.
Em 2002, Graig conceituou o Teste de Software como um processo de ciclo de
vida concorrente ao projeto e mantm o testware a fim de medir e melhorar a
qualidade de software que est sendo testado.
Contudo, voc deve estar se perguntando, porque diante de todo esse avano
da tecnologia e da qualidade de software, ainda ocorrem defeitos? Segundo
Rios isso acontece devido:
As organizaes no do a devida importncia atividade, que informal,

sem metodologia, funes e responsabilidades.
Em anlise do contexto descrito, pode-se dizer que este fato ocorre
devido falta de conhecimento da empresa sobre seu prprio processo
de desenvolvimento de software. Em caso de empresas em que a TI um
processo de apoio, no conseguem entender a importncia das
atividades de teste em conjunto com as atividades de desenvolvimento.
Logo, no vem a necessidade de se ter uma pessoa especialista
responsvel por esta atividade.
Os testes so incompletos durante o desenvolvimento, implicando em
problemas que ocorrem aps sua implantao.
So incompletos devidos viso de testes que toda a equipe de
desenvolvimento possui (Gerente, Analista, Desenvolvedor e Testador,
se existir). Em geral, cada papel citado possui uma preocupao
diferente da execuo de bons testes (isso deveria ser exceo para
Testador). O Gerente de Projetos no quer ter muito custo com testes, os
Analistas no procuram especificar de forma mais detalhada o possvel
para entendimento de qualquer pessoa que leia sua documentao, o
Desenvolvedor busca testar o cenrio feliz, ou seja, se o que ele
desenvolveu est correto e o Testador acaba no possuindo base
incentivo e metodologia de trabalho. Cenrio que regride aos anos 70.
O resultado disso o alto custo para identificar e corrigir os problemas.
A abordagem dos testes no foi adequada para as novas tecnologias. Na
realidade, pouco esforo foi feito nas organizaes para adequar os

procedimentos e reciclar o pessoal tcnico de testes para tratar novas
tecnologias.
O principal motivador o custo que ter. Teste visto como algo que
no caro, que deve ser mais barato que o desenvolvimento.
A estrutura organizacional para testes no tem se modificado. Quase todos
os nveis de testes ainda so feitos pelos desenvolvedores que muitas vezes
no gostam de testar o software. Alm disso, no possui o perfil de
Testador e/ou formalizao especializada para executar tal atividade.
Novamente custo.
Pouca utilizao de ferramentas de automao de testes que so essenciais
para certos tipos de testes.
O investimento em automao muito maior que o simples
investimento em evoluo de metodologia e conhecimento. Logo,
torna-se algo ainda mais longe de se alcanar.
Concluindo, a TI era considerada armazenadora de informaes e atualmente
considerada como ferramenta de extrema importncia para a tomada de
decises de negcios. A disciplina de Testes de Software era considerada um
meio de encontrar defeitos, atualmente vista como ferramenta de melhoria
e qualidade do software. A disciplina de Testes de Software teve uma grande
evoluo devido necessidade de entregar produtos com mais qualidade e de
acordo com as necessidades dos usurios que comeou a surgir nos anos 70.
Porm, as culturas das empresas ainda no se adequaram com a viso
Melhoria e Qualidade de Software, considerando muitas vezes a disciplina de
Testes como sendo apenas um meio de encontrar defeitos.
Atualmente, as especificaes dos sistemas e regras de negcios no so
adequadamente descritas e a atividade de Testes de Software a ltima etapa
no processo de desenvolvimento. Estas duas atividades levam
disponibilizao de produtos e solues que no operam de acordo com o
especificado, levando insatisfao do cliente e/ou usurios finais.
Desta forma, podemos afirmar que a quantidade de problemas encontrados
na entrega e implantaes de software so ocasionadas muito mais por falta
de cultura que existem ainda nas organizaes do que falta de evoluo da
tecnologia e metodologia para dar qualidade.
Mito ou Realidade?
Mesmo com o surgimento de padres, modelos e metodologias reconhecidas

internacionalmente a rea de garantia da qualidade vem enfrentando
diversos tipos de obstculos o quais chamamos aqui de mitos, vejam alguns
deles:
Enquanto no tivermos um programa em funcionamento, no ser
possvel avaliarmos a sua qualidade. Isso um mito! Atualmente temos
mecanismos mais efetivos para garantir a qualidade do software, tal
mecanismo permite que seja possvel aplicar a garantia da qualidade desde
o incio do projeto. Esse mecanismo conhecido como reviso tcnica
formal.
Testar to fcil, que at a minha me testaria!, ser isso verdade? Diante
dos exemplos aqui apresentados podemos perceber que isso no
verdade. Alm disso, os softwares atuais so muito complexos e possuem
contextos diferentes, ou seja, no possvel testarmos um software de
misso crtica da mesma forma que um software de comrcio eletrnico.
Este cenrio mostra o quanto importante ter profissionais qualificados
que entendam essas diferenas e saibam aplic-la de forma que atendam
as expectativas do negcio.
No necessrio gastar tempo com testes, pois o programa j foi
testado!, quem j no se deparou com uma frase dessas? Infelizmente,
muitos programadores pensam dessa forma e aplicam testes sem critrio
algum. O intuito no criticar os programadores e muito menos provar
que 100% do que est descrito verdadeiro, mas sim mostrar que a
disciplina de testes de software existe e deve ser aplicada de forma
profissional. Isso no significa que o desenvolvedor no deva testar, muito
pelo contrrio, existem testes especficos que seguem uma tcnica que
devem ser executados pelo desenvolvedor durante o desenvolvimento, os
Testes Unitrios.
Vamos pensar nos testes, aps o desenvolvimento! O planejamento dos
testes feito tardiamente, ou seja, aps a fase de construo. Esta fase
super crtica, pois existe uma enorme presso para entregar o projeto que
muitas vezes pode estar atrasado e com custos elevados. Todos esses
fatores comprometem a qualidade do produto a ser entregue ao cliente.
Qual a realidade da disciplina de Testes de Software? Os mitos se tornaram
realidade e a nossa misso mudar a viso do prprio profissional da rea de

Testes de Software e das demais reas.
A seguir ser apresentada uma compilao da discusso da primeira mesa
redonda (Testar to fcil que at minha me testaria!) realizada no DFTestes.
A discusso contou com 19 participantes, que deram as suas opinies e
compartilharam as suas experincias na rea, gerando assim um total de 26
respostas.
Para facilitar a visualizao e compreenso foi utilizado o Diagrama de Causa e
Efeito, conhecido tambm como Diagrama de Ishikawa ou Fishbone. Este
diagrama tem como objetivo expor as relaes de um determinado efeito
(conforme figura: Defeito no Software e Qualidade no Software Entregue) e
as suas causas potenciais, estas por sua vez possuem um at dois nveis.
Figura 1.02 - Ishikawa - Qualidade no Software Entregue
Cases
A seguir sero apresentados alguns casos reais de problemas que ocorreram

recentemente, devido m qualidade do software, problemas de
desempenho e usabilidade. Embora algumas empresas aqui citadas no
tenham divulgado a perda financeira que tiveram, podemos concluir que
essas falhas causaram prejuzos diretos e indiretos organizao, alm de
comprometer a imagem da organizao e gerar impactos para futuros
negcios.
Caso 1 - Fonte IDG NOW, Symantec compensou 50 mil vtimas de atualizao
com falha na China. Publicada em 25 de junho de 2007 s 09h18
A Symantec distribuiu uma atualizao problemtica para 50 mil
computadores chineses, essa atualizao classificou equivocadamente
arquivos do sistema como malwares' e os colocou em quarentena, afetando
assim o funcionamento do computador, gerando uma onda de protestos na
web.
Para compensar os danos a companhia ofereceu uma extenso de 12 meses de
licenas do Norton e uma cpia da ferramenta Norton Save & Restore 2.0,
para os usurios em geral. Para os clientes corporativos, a empresa ofereceu
licenas da Symantec Ghost Solution Suite.
Caso 2 - Fonte IDG NOW, Bolsa de Tquio fechou mais cedo por pane em TI.
Publicada em 18 de janeiro de 2006 s 11h07.
Aumento no volume de transaes, resultante de um forte movimento de
queda nos valores, levou o sistema da bolsa de Tkio (a segunda maior no
mundo em valor de capitalizao, depois de Nova York) ao limite de
processamento. O ndice Nikkei fechou em queda de 3% (15.341 pontos), a
maior baixa em um ano.
Caso 3 Fonte IDG NOW, Site do Submarino apresentou problemas de
acessibilidade. Publicada em 25 de novembro de 2008 s 15h39.
O site de comrcio eletrnico Submarino apresentou instabilidades, tornandose inacessvel aos internautas.
Os usurios que tentavam acessar a home do site se deparam com uma pgina
incompleta com a seguinte mensagem Pgina no encontrada. Nesta
pgina tinha um link, que s vezes encaminhava para a pgina correta, outras
no.
Concluindo, os problemas citados acima poderiam ser evitados, caso a
empresa tivesse adotado um processo formal de garantia da qualidade.
A correta escolha da tcnica de testes tambm fundamental para o sucesso
dos testes, por exemplo:
1 caso a aplicao de testes funcionais;
2 caso testes de desempenho, carga e volume.
3 caso testes de navegabilidade.
Alm disso, podemos concluir a partir desses casos apresentados, que um teste
mal sucedido pode significar um caminho aberto para outros tipos de
problemas.
Concluso
A disciplina de Testes de Software evoluiu muito durante esses anos, no
entanto muitos profissionais da rea sentem-se desvalorizados devido falta
de reconhecimento e visibilidade do papel deste profissional na indstria do
software. A falta de conhecimento deste papel inicia-se:

Nas faculdades de TI onde a nfase dada mais em linguagens de
programao. Somente no ltimo ano (quando tem) o aluno aprende algo
sobre a disciplina de Testes de Software.
H mais de dez anos que tramitam no Congresso Nacional, diversos
projetos que visam regulamentao da rea da TI. Contudo alguns desses
projetos referem-se regulamentao apenas da profisso de Analista de
Sistemas, por exemplo . Em alguns desses projetos a disciplina de Testes de
Software est inserida como uma atividade do desenvolvedor.

As empresas preferem contratar desenvolvedores com vrias habilidades,
inclusive de garantia da qualidade.
A viso de um desenvolvedor diferente de um Testador, geralmente

desenvolvedores no gostam de testar e quando fazem no exercitam todas
as condies. J o Testador, tem uma viso mais crtica e detalhista.

Concluindo, a disciplina de Testes de Software essencial para o
desenvolvimento, pois fornece evidncias da confiabilidade de produtos e
solues, e garantia do atendimento aos requisitos de negcios. Alm disso,
no pode ser considerada como qualquer atividade.
Referncias Bibliogrficas
KENN, Peter G. W. Guia Gerencial para a tecnologia da informao: Conceitos
essenciais e terminologia para empresas e gerentes. Rio de Janeiro: Campus,
1996.
CRAIG, Rick D.; JASKIEL, Stefan P. Systematic Software Testing. Artech House
2002
RIOS, Emerson; MOREIRA, Filho. Testes de Software. Rio de Janeiro, Alta
Books, 2003.
COMPUTERWORLD/EUA. As seis profisses da rea de tecnologia mais
valorizadas em 2010. Disponvel em
<http://idgnow.uol.com.br/carreira/2009/12/30/as-seis-profissoes-maisvalorizadas-em-2010/>. Acesso em 30/01/2010.
CAMPOS, Fabrcio F. Testar to fcil, que at minha me testaria! Disponvel
em: <http://qualidadebr.wordpress.com/2009/11/08/testar-e-tao-facil-queate-a-minha-mae-testaria/>. Acessado em 30/01/2010.
HETZEL, Bill. The complete Guide to Software Testing. New York, John Wiley &
Sons, 1998.
MYERS, G.J. The Art of Software Testing. 2 ed. New Jersey, John Wiley & Sons,
2004.
WIKIPEDIA. Malware. Disponvel em <http://pt.wikipedia.org/wiki/Malware>.
Acesso em 30/01/2010.
LEMON, Summer. Symantec Compensa 50 mil vtimas de atualizao com
falhas na China. Disponvel em:
<http://idgnow.uol.com.br/seguranca/2007/06/25/idgnoticia.2007-0625.7174306115/>. Acesso em 30/01/2010
IDG Now!. Bolsa de Tquio fecha mais cedo por pane em TI. Disponvel em: .
Acesso em 30/01/2010.
RODRIGUES, Nando. Site do Submarino apresenta problemas de

acessibilidade. Disponvel em:
<http://idgnow.uol.com.br/seguranca/2008/11/25/site-do-submarino-estacom-problemas-de-acessibilidade/>. Acesso em 30/01/2010.
Mayer, Roberto C. Regulamentao das profisses de TI: a quem interessa?
Disponvel em:
<http://www.administradores.com.br/noticias/regulamentacao_das_profissoe
s_de_ti_a_quem_interessa/20340/>. Acesso em 30/01/2010.
Captulo 2: Certificaes,
valem a pena?
Gustavo Nascimento
Revisor: Felipe da Silva
Introduo
A indstria de software vem apostando cada dia mais na qualidade de seus
produtos. Um dos caminhos que as empresas esto seguindo a
profissionalizao da atividade de teste. Ter uma equipe de testes j uma
tendncia nas fbricas de software.
O intuito desta rea, que pode ser considerada nova no mercado brasileiro,
detectar e corrigir falhas nos softwares antes que esses sejam entregues aos
clientes. No Brasil, os compradores de servios de software (principalmente
rgos governamentais) e as empresas de software comeam a valorizar esta
rea. Isso faz com que os profissionais especializados sejam mais valorizados e,
neste caminho, as certificaes comeam a aparecer como um diferencial .
Com a rea de testes em expanso, surgem questes relacionadas a
certificaes. Afinal, elas valem a pena?
O objetivo deste captulo apresentar ao profissional alguns aspectos que
devem ser considerados na hora de traar seu plano de carreira voltado para a
rea de testes e tambm esclarecer algumas dvidas sobre o que a
comunidade pensa sobre certificaes em testes de software. O captulo
tambm traz um guia das principais certificaes existentes atualmente e
algumas orientaes ao profissional que deseja seguir este caminho.
Porque certificar
Semelhantemente outras reas da engenharia de software, existem diversas
certificaes em Teste de Software que visam garantir, s empresas
contratantes, que o profissional certificado possui determinado nvel de
conhecimento na rea. Do outro lado, o profissional ganha visibilidade no
mercado e aumenta suas chances de conseguir uma posio no mercado.
Embora as certificaes comprovem certo nvel de conhecimento e algumas
exijam algum tempo de experincia na rea de tecnologia da informao
como pr-requisito, de uma forma geral, elas no conseguem medir a
experincia do profissional na rea de teste. Quando se fala em Testes de
Software, quase que um consenso (dentro da comunidade de testes

DFTestes) que a experincia do profissional na rea agrega muito valor e que
esta experincia deve ser relevante em um processo de seleo ou em uma
promoo.
O fato que grande parte das empresas ainda enfrentam dificuldades em
avaliar o conhecimento e experincia de um profissional da rea e utilizam-se
das certificaes como instrumento de avaliao. Quando isso ocorre, muito
provvel que um profissional experiente, que supostamente traria mais
resultados positivos para a empresa contratante, seja descartado em um
processo de seleo ou em uma promoo, antes mesmo de inici-lo, por no
possuir uma certificao. Este o principal motivo das crticas direcionadas s
certificaes em Teste de Software.
Em resumo, como veremos nas prximas sees, as diversas certificaes em
Testes de Software abordam, em nveis e formas diferentes, diversos
contedos relacionados a testes. Isso faz com que uma certificao seja mais
abrangente que outra e, por sua vez, mais valorizada. Algumas certificaes
ainda tem reconhecimento internacional e outras so reconhecidas apenas no
Brasil. Portanto, importante que o profissional que deseja se certificar saiba
que a certificao no substituir a experincia e, ainda, saiba escolher a
certificao mais adequada a seus objetivos profissionais a curto, mdio e
longo prazo.
Certificaes existentes na rea de testes de

software
Diversas so as certificaes existentes em testes de software. Independente
de qual certificao for escolhida, o profissional que deseja se certificar deve
estar ciente de que s a certificao no suficiente para garantir sucesso
profissional.
As certificaes so bem vindas, desde que acompanhadas de
comprometimento, empenho e, com o passar do tempo, experincia. A
experincia o principal fator que pode resultar no sucesso profissional.
Nesta seo so apresentadas algumas das principais certificaes em testes
de software existentes atualmente.
QAI Quality Assurance Institute

A QAI a instituio que administra a Software Certifications, organizao
sem fins lucrativos, e responsvel pela criao e atualizao da base de
conhecimento de onde os exames QAI so gerados. A QAI oferece grupos
distintos de certificao, que so voltadas para as reas de Teste de Software,
de garantia da qualidade e de gerenciamento de projetos .
As certificaes do QAI foram projetadas para testar as habilidades de
profissionais que atuam em uma das reas cobertas pelo corpo comum de
conhecimento relacionado ao assunto desejado, denominado CBOK (material
base para estudo). Estas certificaes so direcionadas aos profissionais que
tenham experincia significativa e ampla para dominar os conceitos bsicos
desses assuntos .
De acordo com Fernando Scarazzato, as certificaes da rea de Testes de
Software oferecidas pela QAI para o mercado brasileiro a CSTE (Certified
Software Tester):
A CSTE voltada para especialistas em Testes deSoftware, esta certificao

demonstra o nvel de conhecimento e habilidades que o profissional possui
nos princpios, conceitos e prticas do Teste de Software. As pessoas com a
habilitao CSTE conquistam o papel de conselheiros da alta gerncia,
auxiliam outros indivduos na melhoria e evoluo dos programas de Teste
de Software da organizao, motivam o pessoal responsvel pelo Teste de
Software a manter suas habilidades sempre atualizadas e so vistos como

agentes de mudanas, algum que possa mudar a cultura e os hbitos de
trabalho dos indivduos para fazer com que a qualidade no Teste de
Software acontea.
Para estar qualificado para se candidatar ao exame de certificao cada
candidato deve ter trabalhado na rea de servios de informao,
preferencialmente com Teste de Software, nos ltimos 18 meses e possuir um
dos quatro pr-requisitos abaixo:
Formao de 4 anos em alguma instituio de nvel universitrio
reconhecida e 2 anos de experincia na rea de sistemas de informao; ou
Seis anos de experincia na rea de sistemas de informao.
A QAI oferece ainda para o mercado brasileiro as certificaes CSQA -
Certified Software Quality Analyst (voltada para especialistas em garantia da

qualidade) e CSPM - Certified Software Project Manager (voltada para
especialistas em gerenciamento de projetos).
ISTQB International Software Testing Qualifications

Board
O ISTQB um conselho internacional, sem fins lucrativos, formado em 2002,
composto por representantes de mais de 40 pases, denominados conselhos
membros. Esse conselho, que cresce a cada ano, dedica-se disciplina de
Testes de Software e promove o profissionalismo na rea atravs de um
programa de certificaes profissionais. No Brasil, o conselho membro o
BSTQB (formado em 2006).
Atualmente so mais de 120.000 certificados ISTQB no mundo e mais de 500
certificados no Brasil, sendo a maior certificadora em Testes de Software no
Brasil e no mundo .
As certificaes na rea de testes oferecidas pelo ISTQB so:
CTFL (Certified Tester Foundation Level): Esta certificao destina-se ao
profissional de Testes de Software que tem como objetivo estar apto a
comparar as prticas de testes entre diferentes pases, a trocar
conhecimentos na rea de testes, a ter uma certificao reconhecida
internacionalmente, a desenvolver um corpo comum internacional de
compreenso e conhecimento sobre Teste de Software (este corpo de
conhecimento denominado syllabus, e o material onde a certificao se
baseia). O certificado CTFL no possui pr-requisitos obrigatrios, no
expira e no precisa ser renovado.
CTAL (Certified Tester Advanced Level): O objetivo desta certificao
assegurar, em nveis avanados, a compreenso em tcnicas de teste,
gesto e melhoria do processo de teste. Esta certificao destina-se ao
especialista em Testes de Software, que tenha experincia em sua carreira
de testes. Isto inclui pessoas em papis como testador, analistas de testes,
engenheiro de testes / arquiteto de teste, lder de teste / gerente de teste /
coordenador de testes. Esta certificao tambm adequada para quem
deseja um entendimento mais profundo sobre Testes de Software, tais
como Gerentes de Projeto, Gerentes de Qualidade, Gerentes de
Desenvolvimento de Software, Analistas de Negcios, Diretores de TI e
Gestores.
O CTAL possui como pr-requisitos que o candidato tenha a certificao CTFL

e que tenha uma experincia mnima de trs anos em Testes de Software ou
sistemas, desenvolvimento, garantia da qualidade ou reas correlatas.

O CTAL dividido em CTAL-TA (Advanced Level Test Analyst), CTAL-TM
(Advanced Level Test Manager), CTAL-TTA (Advanced Level Technical Test
Analyst).
ALATS Associao Latino Americana de Testes de

Software
A ALATS uma instituio sem fins lucrativos, fundada em 2002, que tem o
objetivo de reunir profissionais das reas de teste e de qualidade de sistemas
para servir de apoio a troca constante de informaes. A participao na
ALATS aberta a todos os profissionais e empresas que tenham interesse nas
reas de teste e/ou qualidade de sistemas .
Para atender as exigncias do mercado brasileiro, a ALATS criou a seguinte
certificao:
CBTS (Certificao Brasileira em Testes de Software): o objetivo desta
certificao estabelecer padres de conhecimento na rea de Testes de
Software. Os exames de qualificao para a CBTS ocorrem duas vezes ao

ano (maio e novembro) e tem validade de 3 anos. Ao longo desse perodo,
o profissional deve acumular uma pontuao de 50 PDTS ou deve realizar
novo exame para validar sua re-certificao.
ISEB Information Systems Examination Board

O ISEB uma instituio internacional criada para padronizar a competncia e
performance de profissionais da rea de TI e suas diversas disciplinas.
As certificaes ISEB so divididas em ISEB Foundation Level (aborda uma
vasta introduo a disciplina desejada), ISEB Practitioner Level (aborda
experincia prtica para a disciplina desejada) e ISEB Higher Level (aborda um
profundo conhecimento para a disciplina desejada e voltada para
especialistas ou gerentes) .
Para a disciplina especfica de Testes de Software, a ISEB oferece as seguintes
certificaes:
ISEB Foundation Level
Foundation Certificate in Software Testing: esta certificao voltada para

o profissional que tem interesse em entender os conceitos bsicos em
Testes de Software. Esta certificao tambm acreditada pelo ISTQB,
portanto, o profissional que obtm esta certificao recebe ambas as
certificaes: ISEB Foundation Certificate in Software Testing e ISTQB
Certified Tester Foundation Level
Intermediate Certificate in Software Testing: esta certificao voltada
para o profissional que est se especializando na rea de Testes de
Software e que deseja comprovar habilidades analticas na rea e que
possui conhecimentos terico e prtico na rea. Esta certificao o
prximo nvel a ser obtido pelo profissional certificado no ISEB Foundation
Certificate in Software Testing . Esta certificao pr-requisito para a
obteno de certificaes ISEB Practitioner Level voltadas para a rea de
testes
ISEB Practitioner Level

Practitioner Certificate in Test Analysis: esta certificao voltada para o
profissional que deseja comprovar conhecimentos para se manter
ativamente envolvido com anlises da rea de testes, em qualquer aspecto.
Esta certificao estende os conhecimentos da certificao ISEB Foundation
Certificate in Software Testing e cobre os aspectos tcnicos da certificao
ISEB Intermediate Certificate in Software Testing. Um profissional com esta
certificao possui alto nvel de competncia tcnica na rea.
ISEB Practitioner Certificate in Test Management: esta certificao
voltada para o professional que trabalha com gerncia de Testes de
Software. Ela estende os conhecimentos da certificao ISEB Foundation
Certificate in Software Testing e cobre os aspectos gerenciais da
certificao ISEB Intermediate Certificate in Software Testing. Um
profissional com esta certificao possui alto nvel de competncia
gerencial na rea.
IIST International Institute of Software Testing
O IIST uma instituio formada por um conselho, formado de especialistas e

profissionais da rea de testes, que tem o intuito de direcionar os esforos
para desenvolver um plano de treinamentos baseado em certificaes. O IIST
acredita que as certificaes comprovam o conhecimento do profissional
naquele assunto especfico.
As certificaes IIST expiram em 3 anos e so divididas em:
CSTP Certified Software Test Professional: Voltado para o profissional
iniciante na rea de Testes de Software e que deseja se especializar na rea.
Os conhecimentos exigidos do profissional relaciona-se aos seguintes
tpicos: princpios de testes, projeto de testes, gerenciamento de testes,
execuo e rastreamento de defeitos, definio, refinamento e verificao
de requisitos, testes automatizados e testes estticos.
CTM - Certified Test Manager: voltado para o profissional com experincia
mnima de 3 anos na rea de Testes de Software e que pretende se tornar
gerente de testes. Os conhecimentos exigidos do profissional relaciona-se
aos seguintes tpicos: gerncia do processo de testes, gerncia de projetos
de testes, melhoria e mtricas relacionadas aos testes, gerenciamento
organizacional da rea de testes, gerncia de riscos, estratgias e
arquiteturas para automatizao de testes, garantia da qualidade de
software.
Qual o caminho a ser seguido por um

profissional da rea de testes de software?
O mercado de TI vem se tornando mais competitivo a cada dia. Participar de
um processo seletivo com chances de ficar com a posio requer que o
profissional tenha diferenciais em seu currculo. Neste contexto, as
certificaes podem representar este diferencial e, consequentemente, a
contratao.
Acredita-se que a certificao tem maior importncia para o profissional que
est em incio de carreira. As certificaes asseguram a esses profissionais,
apesar de algumas opinies controversas, um determinado nvel de
conhecimento sobre a rea e isso pode significar uma posio em uma
empresa.
A certificao um bom incio para quem deseja iniciar na rea de teste. No

entanto, o profissional no deve ficar satisfeito com essa opo. Ele precisa
adquirir experincia e conhecimento na rea se desejar alavancar a carreira.

Existem algumas opes de plano de carreira na rea de testes: testador,
analistas de testes, engenheiro de testes / arquiteto de teste, lder de teste /
gerente de teste / coordenador de testes. Este seria um possvel caminho a ser
percorrido por um profissional de testes, no entanto, este caminho no o
nico e no deve ser considerado como uma sugesto deste autor. Os cargos e
as remuneraes variam entre as empresas e entre as diversas regies do pas e
a carreira deve estar atrelada aos objetivos profissionais.
Esta variao pode ser observada atravs do resultado da pesquisa de cargos e
salrios organizada por Cristiano Caetano em 2007 . Nas Figura 1 e Figura 2
esto apresentados os resultados obtidos com a pesquisa, onde possvel
observar a variao de remunerao praticada pelas empresas para diferentes
cargos e regies do pas.
Figura 2.01 - Cargos e Salrios
Figura 2.02 - Cargos e salrios distribudos por estados

Para o profissional que deseja obter uma certificao e ingressar no mercado
de Testes de Software, seguem algumas dicas de alguns profissionais da rea:
Escolher um bom curso preparatrio. Herbert Maroni, diretor de
desenvolvimento da 4sec Brasil e autor de livros sobre C#, VB.NET, AJAX e
ASP.NET, faz um alerta: "geralmente o curso no o suficiente". Maroni
acredita que o candidato precisa se dedicar aos estudos
independentemente do curso que tenha escolhido .
Procurar o mximo de informaes sobre a prova a ser realizada. Isso
significa conhecer o contedo do exame, a durao, o custo e o local de
realizao .
Adquirir e separar material de estudo e fazer simulados podem fazer a
diferena para o candidato. Recomenda-se fazer, no mnimo, dois

simulados antes da prova e estudar as respostas das questes que se errou.
Alm de conhecimentos e experincias na rea de Testes deSoftware, pode
ser importante que o profissional adquira conhecimentos e experincias em
reas correlatas. Isso depender da rea e da carreira almejadas.
Para um profissional que deseja se especializar em automatizao de testes, a
aquisio de conhecimentos em linguagens de programao pode ser uma
boa opo. O mesmo raciocnio vale para o profissional que deseja ocupar a
posio de gerente de testes. Neste caso, uma certificao em gesto de
projetos pode ser um diferencial.
Concluso
A rea de testes vem se expandindo no Brasil e acredita-se que a existncia de
uma rea de testes nas fbricas de software j uma tendncia. Para tanto,
espera-se que os profissionais da rea acompanhem esta tendncia e
especializem-se cada dia mais.
Percebe-se ainda que h diferenas significativas de reconhecimento e
remunerao nas diversas partes do pas. Isso se deve ao fato da rea ainda
estar em expanso e das empresas ainda no estarem preparadas para
acomodar esse tipo de profissional especializado. Pode-se dizer que esta a
realidade no Brasil de hoje.
No entanto, independentemente da regio do pas, as certificaes em Teste
de Software j se tornaram um assunto corriqueiro nas discusses que
envolvem tais profissionais especializados.
Nestas horas, entra em ao sempre a mesma dvida: Certificaes, valem a
pena?
A resposta : Depende!
Vrias perguntas devem ser respondidas pelo profissional antes que se chegue
a alguma concluso. Conforme vimos neste captulo, a concluso vai depender
da expectativa e da experincia do profissional, da regio do pas onde ele
atua (ou deseja atuar), da empresa contratante, dentre diversos outros
fatores. Alm disso, a escolha pela certificao tambm pode ser um fator
determinante.
As diversas certificaes existentes exigem diferentes nveis de conhecimento e

dedicao do candidato e possuem diferentes nveis de reconhecimento
mercadolgico. Sem dvida, as certificaes agregam valor ao candidato,

porm, no espere que ela substitua a necessidade de experincia. A
experincia ainda mais relevante em uma possvel contratao.
O profissional de TI deve ter, durante sua carreira, dois objetivos bsicos:
Conhecimento e Experincia.
Quando o profissional consegue perseguir estes dois objetivos com foco e
determinao, as chances dele ser bem sucedido crescem significativamente.
Se a certificao desejada estiver alinhada aos objetivos citados, as chances de
sucesso aumentam ainda mais.
Lima, L. procura de testadores de software. Disponvel em:
<http://www.timaster.com.br/revista/materias/main_materia.asp?
codigo=1560>. Acesso em: 19 fev. 2010.
Scarazzato, F. Entrevista com Fernando Scarazzato. Disponvel em:

<http://www.testexpert.com.br/?q=node/1086>. Acesso em 18 fev. 2010.
QAI Brasil - Quality Assurance Institute. Disponvel em

<http://www.qaibrasil.com.br/>. Acesso em 16 mar. 2010.Edit this page (if you
have permission) |
BSTQB - Brasilian Software Testing Qualifications Board. Disponvel em:
<http://www.bstqb.org.br/>. Acesso em: 01 mar. 2010.
ALATS - Associao Latino-Americana de Testes de Software. Dispnvel em:
<http://alats.org.br>. Acesso em 01 mar. 2010.
THE CHARTERED INSTITUTE FOR IT. Disponvel em
<http://www.bcs.org/server.php?show=nav.5732>. Acesso em 01 mar. 2010.
Caetano, C. Cargos e Salrios: Quanto ganha o profissional de teste e

qualidade de software. Disponvel em: <http://www.testexpert.com.br>.
Acesso em: 18 fev. 2010.
Ramos, T. O. Certificaes: prepare-se para os exames das principais

plataformas. Disponvel em: <http://www.itweb.com.br>. Acesso em: 18 fev.
2010.
Ramos, T. O. Certificaes: avaliar demanda do mercado ajuda na escolha.

Disponvel em: <http://www.itweb.com.br>. Acesso em: 18 fev. 2010.Ramos,
T. O. Certificao pode fazer diferena no comeo da carreira. Disponvel em:
<http://www.itweb.com.br>. Acesso em: 18 fev. 2010.
IIST - International Institute for Software Testing. Disponvel em
<http://www.testinginstitute.com>. Acesso em 01 mar. 2010.Google Docs -Web word processing, presentations and spreadsheets.
Captulo 3: O Testador
tambm necessita saber
programar?
Karine Birnfeld e Fabrcio Ferrari de Campos
Revisora: Anna Carolina Rocha
Introduo
Uma viso comum do Teste de Software de que ele consiste apenas na
execuo do sistema, e devido a isso, existe a dvida se realmente necessrio
que um testador de software possua um conhecimento aprofundado de
programao para executar suas tarefas.
Quando procuramos na bibliografia pelas tarefas tpicas de um profissional da
rea de teste de software, encontramos atividades que vo desde o
planejamento dos testes, especificao, configurao do ambiente, criao da
massa de dados, execuo manual e automatizada at o registro dos
resultados obtidos.
Na verdade o que acontece que algumas empresas no possuem bem
definidas as diferentes especialidades existentes na rea de testes de software.
Caso um mesmo profissional seja responsvel pela execuo de todas as
atividades de testes, pode-se concluir que este profissional necessita ter bons
conhecimentos de gesto de projetos, anlise de requisitos, especificao de
testes, banco de dados e inclusive bons conhecimentos de programao.
Especialidades da rea de Teste de Software

Este tpico tem como objetivo principal apresentar as diferentes divises
(especialidades) que existem na rea de Teste de Software. Para cada
especialidade so apresentadas as principais atividades bem como os
conhecimentos necessrios.
possvel encontrar cinco especialidades diferentes na rea de Testes de
Software, conforme segue:
Lder de Teste / Gerente de Teste / Coordenador de Teste:Planejamento e
controle de teste. Deve possuir conhecimento e experincia na rea de teste
de software, qualidade de software, gerenciamento de projetos e gesto de
pessoas.
Engenheiro de Teste / Arquiteto de Teste:Organizao da infra-estrutura
de teste. Necessrio possuir conhecimento para instalar e operar o
ambiente de teste, realizando a sua administrao e suporte a rede.
Analista de Teste: Modelagem e especificao de testes. Exigido
conhecimento e experincia em tcnicas de teste para realizar a
especificao dos testes, alm de conhecimento em banco de dados, sendo
que tambm de sua responsabilidade a preparao e aquisio da massa
de dados de teste.
Automatizador de Teste: Criao e execuo de testes automatizados. Um
automatizador de teste necessita de conhecimento bsicos de testes, porm
excelentes conhecimentos e experincia em programao com ferramentas
de automao de teste.
Testador: Execuo dos casos de teste. Necessrio conhecimentos para
execuo de testes e registro de resultados.
Conhecimentos de Programao
Este tpico visa tratar especificamente da necessidade de saber programar
para cada especialista da rea de testes.
Comeando pelo lder de teste, este profissional deve ser capaz de auxiliar sua
equipe na resoluo de problemas. Para isso, fortemente recomendvel o
conhecimento de linguagens de programao para auxiliar sua equipe. Alm
disso, este profissional precisa saber utilizar ferramentas de gerenciamento de
projeto, bem como testwares e ainda ter boas habilidades na gesto de
pessoas.
O engenheiro de teste necessita saber programar, pois ele precisa ser capaz de
coletar informaes no cdigo fonte do programa para realizar as
configuraes e parametrizaes necessrias no ambiente de teste, alm disso,
ele tambm necessita de conhecimentos de programao para entender a
arquitetura do software e, com isso, conseguir disponibilizar um ambiente
mais prximo possvel do ambiente de produo.
J o analista de testes no precisa ter excelentes conhecimentos de
programao, mas necessita ter bons conhecimentos de lgica de
programao para inferir sobre os testes que devero ser realizados. Este
conhecimento em lgica de programao auxiliar o analista de testes na
identificao dos principais pontos em que uma falha pode ocorrer. Alm
disso, o analista de testes necessita saber analisar os requisitos do cliente,
visando extrair o mximo de cenrios de teste possveis.
Para o automatizador de teste, sem sombra de dvidas, exigido excelente
conhecimento em programao, visto que sua atividade gira em torno da
criao e execuo de scripts de teste em diferentes linguagens de
programao, dependendo da ferramenta de automao utilizada.
Referente ao testador, cujas atribuies incluem a execuo dos testes
manuais e registro dos resultados obtidos, no obrigatrio possuir
conhecimentos de programao. Este profissional pode tanto ser um
profissional da TI como um profissional que tenha bons conhecimentos do
negcio a ser validado no sistema. Porm, isso depende muito do nvel em
que o teste especificado e do tipo de projeto. Caso existam profissionais que
no sejam da rea da TI, ou seja, no possuam conhecimentos em lgica de
programao, banco de dados e sistemas operacionais, por exemplo, a
especificao dos testes a serem executados dever chegar ao nvel de detalhe
dos procedimentos de teste, fornecendo a este testador cada passo que ele
dever realizar para executar os testes.
Como trabalhoso realizar a especificao de teste at o nvel dos
procedimentos, mais fcil para as empresas contratarem profissionais que j
tenham essa base de conhecimento de TI, podendo ser utilizada uma
especificao de testes num nvel mais alto, visto que um profissional da rea
de TI saber realizar uma validao em banco de dados ou realizar operaes
em diferentes sistemas operacionais.
Programao a servio do Teste de Software

Como vimos, o conhecimento de programao se far necessrio dependendo
da especialidade que o profissional pretende seguir, sendo que em algumas
delas conhecimentos de programao so essenciais. Alm disso, h outros
fatores que podero influenciar na necessidade do profissional de teste saber
ou no programar, dentre os quais os principais so:
Cultura da empresa: dependendo dela, pode haver uma forte tendncia a
execuo de testes manuais, o que no demandaria conhecimentos de
programao; por outro lado, poderia haver uma forte tendncia na
automao dos testes, onde a sim, se faz necessrio possuir conhecimentos
de programao;
Metodologia adotada: hoje em dia, com o crescimento das metodologias
geis, acaba se tornando importante/diferencial o profissional de teste
saber programar, se ele desejar atuar numa equipe gil, uma vez que
metodologias geis, incentivam a automao dos testes.
Alm disso, o conhecimento de programao pode agregar muito ao
profissional e tornar o seu trabalho mais efetivo, tanto no planejamento de
um teste, uma vez que se ele tiver conhecimentos de programao, poder ter
insights mais especficos (por exemplo, fazer "injees SQL"), como tambm
poder utilizar esse conhecimento para automatizar testes de regresso ou
criar massa de dados, e assim poupar o seu tempo com tarefas repetitivas.Ou
seja, mesmo se o profissional no for usar na prtica o seu conhecimento
sobre programao, ele poder ser muito til para a execuo das tarefas
habituais de um profissional de Teste de Software, uma vez que ele ter uma
percepo mais afinada, sob uma perspectiva tcnica, quanto ao
comportamento do sistema. Deste modo, poder fazer asseres mais
pertinentes e elaborar casos de testes mais complexos.Quando falamos em
automao na rea de Teste de Software, dificilmente poderemos abdicar de
profissionais com conhecimento de programao, por mais que existam

ferramentas que sejam fceis de serem utilizadas para automatizar os testes,
como por exemplo o Selenium IDE. Isso porque, geralmente, h certos
cenrios de testes mais complexos, que demandaro um uso mais avanado
da ferramenta, o que muitas vezes, envolve o desenvolvimento de algum
script.Dentre as vantagens que podemos ter quando sabemos programar,
citadas pelo Shmuel Gershon, esto:
O testador capaz de entender os tipos de problemas que o aplicativo
pode apresentar, pois o testador pode montar seu modelo mental de como
o software funciona por dentro e testar os limites desse modelo.
O testador capaz de fazer testes automticos quando necessrio. Talvez
at mais importante, a criao de pequenas ferramentas que facilitam a
configurao rpida do sistema, ou que recolhem dados para relatrios
podem fazer do testador um jogador importante com influncia na equipe
toda.
Facilita a comunicao com os programadores.
Concluso
O Teste de Software j passou por grandes evolues e tende a continuar
evoluindo. Caso o profissional de testes no acompanhe esta evoluo, no
sentido de se interar de novas tecnologias e aprender a arte da programao,
ser sempre apenas um testador de software, visto que para todas as demais
especialidades exigido ou fortemente recomendado este conhecimento.
Spillner, A., Linz T., Schaefer H. (2007) Software Testing Foundations. Santa
Barbara, Rocky Nook, 2nd Edition.
Captulo 4: Testar sem

documentao possvel?
Sarah Pimentel
Introduo
De acordo com o RUP, caso de teste " a definio (geralmente formal) de um
conjunto especfico de inputs de teste, condies de execuo e resultados
esperados, identificados com a finalidade de avaliar um determinado aspecto
de um item de Teste-alvo". Duas disciplinas da Engenharia de Software
provem informaes para criao dos casos de teste. So elas: Engenharia de
Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos o processo de aquisio,
refinamento e verificao das necessidades do cliente. Dentro das diversas
metodologias de desenvolvimento h maneiras distintas de documentar
requisitos. No RUP, o principal documento gerado, que utilizado pela equipe
de teste, so os Modelos de Caso de Uso; j nas metodologias geis, um
documento mais comum o conjunto de User Stories. Na prtica, muitas
equipes no tm nem os Casos de Uso e nem as User Stories, mas sim,
descries em alto nvel dos requisitos, sejam elas por escrito ou no.
A disciplina de Projeto, por sua vez gera documentos complementares s
especificaes de Requisitos. Nessa etapa, a estrutura interna do software
descrita atravs de diagramas. A utilizao da linguagem UML bastante
recomendada na gerao desses diagramas. Exemplos de diagramas de
projeto so Diagramas de Estados, Diagramas de Seqncia e Diagrama de
Atividades, entre outros.
Essa documentao serve como apoio para a elaborao dos testes. Todas elas
so de grande valia para o analista no seu projeto de casos de teste. Mas e se o
analista no as tiver? possvel, mesmo assim, testar? Essa a pergunta tema
da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentao para o teste.
Primeiramente no vamos confundir necessidade com importncia.
Denotativamente o termo necessidade significa uma obrigao
imprescindvel, enquanto que importncia ou relevncia significa valor.
As participaes nessa mesa redonda so freqentemente utilizadas no texto
que segue para expressar a opinio da comunidade sobre o assunto.
Testes Exploratrios
possvel sim testar sem scripts e isso j no se pode chamar de novidade. O
termo "testes exploratrios" foi citado pela primeira vez por Cem Kaner em
seu livro Testing Computer Software (1999).Segundo James Bach, testes
exploratrios so simultaneamente um aprendizado, um projeto e uma
execuo de teste. Atravs da profunda explorao das habilidades de ouvir,
ler, pensar e reportar eficazmente, os testes exploratrios podem trazer
informaes muito importantes de maneira to ou mais produtiva que os
testes baseados em casos de teste. A falta de um script a ser seguido tende a
potencializar essas habilidades.
Escolas de Teste
Sobre a documentao em que iremos embasar a criao dos casos de teste, o
Jorge Diz disse: "no coloquemos todas as nossas fichas na documentao do
sistema. Com certeza, possvel testar sem documentao formal: pode ser
mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar
que o documento mais atualizado sempre o prprio sistema sendo testado."
O contexto! Esse o grande segredo dessa discusso. A eficcia do seu teste
pode ou no ser impactada pela falta de documentao considerando
diversos cenrios. papel do analista de testes sinalizar at que ponto ele
consegue aferir a qualidade do sistema com as ferramentas (documentao,
especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as caractersticas de

cada escola (um contexto), o tema "testar sem documentao possvel?"
tratado de maneiras diferentes.De acordo com Pettichord (2007), uma escola
definida por afinidades intelectuais, interao social e objetivos comuns. So
compostas por uma hierarquia de valores, tcnicas, padres de crtica,
instituies organizadas e vocabulrio comum.
Existem cinco escolas de teste e suas vises so:
Escola Analtica: o teste deve ser rigoroso e tcnico, com base na academia
Escola Padro: o teste uma maneira de medir o progresso com nfase no
custo e padres repetveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os
quais os clientes se importam mais
Escola gil: usa o teste para provar que o desenvolvimento est completo.
Enfatiza o teste automatizado
Sobre os testes sem documentao, so a favor:
Escola baseada em Contexto: "Faa o que puder para ser til. Faa
perguntas se necessrio. Desencave especificaes escondidas."
Escola gil: "Conversas so mais importantes que documentao"
E so contra:
Escola Analtica: " impossvel"
Escola Padro: "Algum tipo de documentao necessria"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus
cenrios, cada uma expressa uma viso diferente da possibilidade de testar

sem documentao. Na viso geral dos participantes da discusso, testar sem
documentao no impossvel, mas essa abordagem tambm no foi
defendida como a melhor prtica. A comunidade do DFTestes parece ter uma
tendncia muito prxima a da Escola baseada em Contexto, entendendo que
no devemos olhar as nossas dificuldades de documentao como muros
intransponveis, mas como empecilhos que devem ser vencidos.
Reflexes da Mesa Redonda

" medida que os sistemas se tornam mais complexos, os riscos se tornam
maiores, chegando ao ponto no qual ningum conhece o que h no sistema.
Isto ruim no s para o teste, mas tambm para todas as fases anteriores do
desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem no
tem essa documentao o de no saber o que testar. Recentemente fiz uma
anlise de cobertura de cdigo em um programa de pedidos e conclu que ao
incluir um pedido neste sistema com o mximo de opes que consegui
informar, no cobri nem 20% do cdigo. Se voc no tem nada para consultar,
como testar os outros 80% de forma eficiente? Agora imaginem se este
programa estivesse 60% documentado com casos de uso e casos de teste. J
seria uma garantia bem maior. Outro problema o de no saber o que alterar.
Recentemente em um projeto foi esquecido de alterar um programa, e s esse
programa gerou mais estresse que todas as outras alteraes juntas porque
estava dando problema l no cliente. Sem documentao, no h
rastreabilidade."
Na colocao do Ismael conclui-se que:
Falta de documentao pode prejudicar a cobertura dos testes
Falta de documentao implica em falta de rastreabilidade e aumento dos
riscos nas manutenes do sistema
A viso do Marcelo Andrade complementa o primeiro cenrio do Ismael:
"Claro que no d para testar tirando concluses sobre regras de negcio da

prpria cabea do testador. Neste caso, se a informao est disponvel (com o
cliente ou com quem quer que seja) ela que deve ser buscada."
Ento, na falta de uma documentao, caso haja alguma outra fonte de
conhecimento sobre os requisitos, ela viabiliza os testes e tambm aumenta a
sua cobertura. Essa opinio tambm foi expressa pela Andrea Cruz quando ela
fala que "testar sem documentao possvel, porm podem existir em
determinados sistemas requisitos implcitos importantes que podem no ser

cobertos pelo teste."
Existe sem dvida um risco na falta de documentao. Para ser bem sucedido,
o Analista de Teste precisa contar com alguma outra fonte de informao, ou
a sua cobertura poder ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentao s percebido
atualmente em grandes projetos, onde os testes de regresso so constantes e

existem muitas mudanas. dependendo do tamanho do projeto de teste a
documentao poderia ser tratada de forma mais simples (documentos
bsicos) ou complexa (todos os documentos). Dessa forma no teramos
projetos desenvolvidos em 16 horas e testados em 72 horas por conta do
volume de documentao."
Ter algum nvel de documentao mesmo importante, entretanto o que
define sua necessidade? Uma documentao necessria aquela que
consultada e mantida, que serve de apoio para o time ou, no se encaixando
em nenhum desses objetivos, ela se torna necessria apenas se for uma
requisio do cliente. Jeffries, 2001 expe em seu blog esse mesmo ponto
quando fala que "voc pode precisar de um UML bem formatado para o seu
projeto, ou voc pode precisar imprimir o Javadoc quando distribuir o seu

cdigo para outros, ou voc pode precisar documentar os requisitos para o
gerenciamento ou como parte de um contrato. Se e quando voc realmente
precisar dessas documentaes, voc deve realmente t-las." Se elas no forem
realmente necessrias apenas demandam tempo da equipe e nem sempre so
mantidas adequadamente.
Um sem nmero de documentos que so criados no incio do projeto e no

sofrem mais atualizaes uma realidade em muitos projetos. De acordo com
o Shmuel, "uma documentao desatualizada menos til, mas ainda pode
ser usada da mesma maneira. Mas essa ajuda no um pr-requisito

necessrio, e podemos testar mesmo sem t-la. Por meio de abstraes e
inferncias, possvel aprender sobre o programa de vrias outras maneiras,
durante os testes, durante conversas, durante as discusses sobre bugs etc.
Essa opinio est alinhada com uma pesquisa do IEEE, 2003 em que
entrevistas com engenheiros de software revelaram as seguintes opinies
sobre documentao:
Documento de arquitetura e outras documentaes abstratas so
freqentemente vlidos ou ao menos provem um guia histrico que pode
ser til para manuteno.
Documentaes de todos os tipos freqentemente esto desatualizadas
Uma frao considervel da documentao no confivel. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou
outro uso dado documentao fora o projeto de testes que o de contrato.
comum utilizarmos uma documentao e a aprovao do cliente como um
contrato ou parte dele na definio de escopo e base para cronograma.
Segundo Felipe, "na maioria dos casos alm de brigarmos para querer ter um
sistema testvel por qualquer um, em determinados processos de engenharia

de software tambm brigamos porque queremos ter um documento como
"defesa" contra a insatisfao do cliente. aquele problema que se voc no
documenta, o cliente no assina, se ele no assina, no existe um registro que
ele havia dito que era aquilo que ele queria, correndo o risco do cliente
reclamar e ter melhorias no sistema sem pagar por elas nem ajustar
cronograma e etc."
Concluso
As opinies expostas na Mesa Redonda levaram a um entendimento de que a
documentao pode no ser necessria, mas importante. O tema bastante
abrangente e a cada participao na lista foi possvel idealizar novos cenrios
para responder a mesma pergunta. E voc? A que concluso chegou aps ler o
que discutimos em mais uma edio da Mesa Redonda do DFTestes?
Much Ado About Nothing: DocumentationRon Jeffries 2001
http://www.xprogramming.com/xpmag/FussAboutDocumentation
Schools of Software Testing Bret Pettichord, 2007
http://www.io.com/~wazmo/papers/four_schools.pdf
How Software Engineers Use Documentation: The State of the PracticeTimothy
C. Lethbridge, Janice Singer, Andrew Forward, IEEE Computer Society 2003
Exploratory Testing Explained James Bach, 2003
http://www.satisfice.com/articles/et-article.pdf
Captulo 5: Quando
documentar no preciso?
Edwagney Luz
Introduo
Atualmente vivemos em um mundo onde os negcios possuem uma grande
dependncia pela TI (Tecnologia da Informao) e medida que esse fator
aumenta, tambm cresce a produo de software e complexidade dos
sistemas.
Um exemplo quando um risco operacional da TI se propaga para os
negcios, deixando de ser um risco da TI, passando a ser um risco do negcio,
ou seja, se uma falha ocorrer nos sistemas, consequentemente ocorrer uma
falha nos negcios. Desta forma, torna-se fundamental o desenvolvimento de
software com mais qualidade e confiabilidade. Neste captulo ser abordado o
porqu se devem ter profissionais qualificados na elaborao e execuo de
testes.
Mesa Redonda
Durante a discusso desse tema, diversos integrantes do grupo DFTestes
colocaram suas opinies e suas experincias, seja obtido de suas empresas ou
em participaes em projetos. Dessa discusso chegamos a alguns pontos
interessantes, que trataremos no decorrer deste captulo.
Para que serve a documentao?

No exposto por (Rezende, 2005) e descrito na introduo deste captulo,
chama a ateno o trecho onde diz que a documentao serve para orientar e
treinar o cliente na operao do sistema. Esse um enfoque interessante, visto
que sem a documentao seria um tanto quando complicado passar essa
orientao e treinamento ao cliente. Pensando em Teste de Software, para
que serve ento a documentao?
Ajuda o entendimento do sistema, quando voc cria a documentao de
Teste de Software, voc entende melhor o sistema e ainda abstrai as
informaes para o mundo do Teste de Software (Fabrcio Ferrari)
Vocs podem observar que, em outras palavras usamos a documentao de
teste com o mesmo objetivo que levamos ao cliente. Entretanto, isso vai alm.
Ela no pode e no deve ser considerada apenas um guia para orientao e
treinamento.
Ela deve ser tratada como sendo um referencial para o projeto de software,
como o compartilhamento de informaes entre os diversos times que
compe um projeto. a documentao que tem o poder de dar consistncia e
credibilidade ao projeto. (Ambler, 2002), expe um raciocnio interessante. O
software o produto principal de um projeto, e afirma que ter essesoftware

funcionando o principal objetivo desse projeto e a produo de documentos
ou artefatos gerenciais irrelevantes no o foco. A equipe de
desenvolvimento desenvolve softwares e no documentaes.
Por outro lado ela tambm tem a responsabilidade de possibilitar a execuo
de um possvel prximo trabalho. Ele chama de objetivo secundrio da equipe
de desenvolvimento. Ele afirma que para possibilitar que isso acontea, a
equipe no deve querer apenas desenvolver um software de qualidade, mas
tambm documentao suficiente para que as pessoas que jogaro a prxima
partida possam ser to ou mais eficientes do que a equipe anterior, pois
transferem habilidades para a equipe posterior, alm de motivar o pessoal j
existente a permanecer na equipe e desenvolver uma prxima verso.
Usando esse raciocnio, podemos perfeitamente transferi-lo para a equipe de
teste, que em nada difere de uma equipe de desenvolvimento. Se uma equipe
de desenvolvimento tem como principal responsabilidade desenvolver
software, de forma anloga uma equipe de teste tem como principal atividade
desenvolver testes, e como atividade secundria, no basta apenas
desenvolver testes com qualidade e que encontrem o maior nmero de
defeitos, necessrio tambm documentar esses testes para que outra equipe
possa, no futuro, garantir a mesma qualidade que foi garantida na primeira
execuo de teste no projeto.
Outro ponto levantado na discusso da mesa redonda sobre a solicitao do
cliente, onde tudo depende da solicitao dele. Se ele exige documentao de
Teste de Software, a equipe tem o conhecimento sobre o sistema e o prazo
para teste curto, documentaes so desnecessrias, e o teste a ser realizado
seriam apenas usando tcnicas de teste exploratrio. O que um assunto bem
controverso, visto que a equipe de teste a que deve ou deveria zelar pela
qualidade do produto e este inclui o software e sua documentao. Assumir
esse tipo de situao seria o extremo do extremo. Sugere-se fazer um estudo
sobre a viabilidade de documentao, documentar por documentar, pode
tornar-se perda de tempo, e consequentemente ocasionar perda de dinheiro.
Conclumos que documentar preciso, porm com muito bom senso e que a
mesma tenha uma finalidade, caso contrrio estaramos perdendo um
precioso tempo que poderia ser utilizado para a melhoria da qualidade do
produto. Mas quando preciso documentar? Abaixo listamos alguns pontos
levantados durante a discusso:
Quando existir a necessidade de arquivar evidncias;
Quando existir a necessidade de arquivar e disseminar conhecimentos
(gesto do conhecimento);
Quando alguma clusula contratual indicar que os nveis de documentao
devem ser entregues;
Quando existe uma alta rotatividade da equipe.
E quando documentar no preciso?
Quando o documento de fato no seja de nenhuma utilidade futura;
Quando o documento no for mantido ou atualizado;
Quando o documento no for compreendido pelas pessoas para quem ele
foi escrito;
Quando a equipe de desenvolvimento for gerar documentos difceis de
entender, que no atendam o propsito, ou que no sejam efetivamente
utilizados;
Quando a documentao gerada no considerada importante, que no

ir agregar valor e no for compartilhada com os stakeholders do projeto;
Se a documentao criada no for gerar uma base histrica para auxiliar
em pesquisas de projetos futuros.
Percebemos que nesse caso, todos os itens so uma consequncia do item um,
portanto, a primeira regra de utilidade a primeira coisa que deve ser
levantada no processo de deciso de se elaborar ou no um determinado
documento.
Tornando a documentao de teste eficaz

Todos concordam que esse um tremendo de um desafio, visto que antes
necessrio convencer as equipes da necessidade de se documentar. Mas
podemos simplificar essa tarefa, como algumas pessoas propuseram conforme
descrito abaixo:
Definir qual o objetivo do documento; a que se prope; para qual
finalidade ele dever ser elaborado;
Otimizar o documento eliminando tpicos irrelevantes ao projeto;
Observando o grau de manutenibilidade do documento. Se o mesmo for
difcil de manter, algo est errado e o mesmo deve ser revisto. Nesse caso
volte ao item um e observe sua finalidade;
Busca por ferramentas que agilize a produo do documento;
Definio de local de fcil armazenamento e acesso por parte da equipe de
teste e projeto;
Verificar e garantir que a documentao esteja seguindo a padronizao
exigida;
Identificar qual o pblico receptor da documentao para que a mesma
seja elaborada com a linguagem desse pblico.
Como vimos no item anterior, devemos apenas gerar uma documentao
quando temos certeza de que ser lida. Elaborar documentos apenas com o
intuito de documentar detalhadamente determinada atividade, mas que de
nada vai adiantar para o projeto ou projetos futuros, estaremos alm da perda
de tempo, consumindo recursos de armazenamento que podero fazer falta
no futuro e tempo desnecessrio de profissionais para simplesmente
organizar e manter as informaes em repositrio. Elaborar documentao
deve antes passar pelo crivo de identificar para qual necessidade vamos
armazenar tal informao.
Quais documentaes devem ser geradas?

De acordo com o Guia de Implementao Parte 10: Implementao do MRMPS em organizaes do tipo Fbrica de Teste (SOFTEX, 2009), as informaes
que devem ser armazenadas para qualquer projeto so: relatrios informais;
estudos e anlises; atas de reunies; lies aprendidas; artefatos gerados;
itens de ao; e indicadores. As informaes podem estar armazenadas nos
diversos meios de armazenamento como papeis impressos, fotografias,
desenhos, eletrnicos e multimdia.
O guia tambm prega que as informaes relevantes devem ser observadas
primariamente, ou seja, devemos sim documentar, porm o que for mais
relevante ao projeto. Vimos que essa informao compartilhada por todas
as fontes citadas nesse captulo e com base nisso chegamos ao seguinte
questionamento. Em teste, quais documentaes ento devem ser geradas
para o armazenamento das informaes?
De acordo com o discutido pelos integrantes da mesa redonda, vrias
documentaes so utilizadas, dependendo da forma em que a empresa ou o
projeto se porta em relao ao teste. Entretanto, colhendo dados durante a
discusso, encontramos comumente entre todos os integrantes os seguintes
documentos, que podemos dizer que podem seguramente serem
considerados como sendo documentaes que guardam informaes
relevantes ao teste de software. So eles:
Plano de Teste descreve o escopo, estratgia, ambientes, riscos, recursos,
referentes ao projeto de teste;
Especificao de Teste descreve os cenrios, casos, roteiros e massa de
dados para teste;
Relatrios Peridicos de Teste descreve os resultados da execuo do
teste contendo suas evidncias e toda a gesto e histrico de defeitos;

Relatrio Final de Teste descreve de forma sucinta todo o histrico da
execuo do teste contendo todos os casos de teste executados, percentual
de casos com defeito, sua severidade e etc.
Esse conjunto de artefatos em geral aplicado em projetos de teste que
possui um nvel de criticidade alto, pois necessitam de maior controle e
armazenamento de informaes. E nesse caso descrever de forma sucinta a
estratgia, riscos, ambientes, recursos, relatrios peridicos e detalhados de
execuo, so informaes extremamente relevantes, no s para o projeto
atual, mas principalmente projetos futuros.
Para projetos com menor criticidade, somente os relatrios de testes so
exigidos, principalmente para evidenciar os testes realizados. E na maioria dos
casos pelos prprios desenvolvedores. Mas tudo isso faz parte de uma
estratgia de melhoria dos processos, que devem visar sempre alcanar nveis
mais elevados de maturidade.
Sugere-se que a documentao deve ser mais simples possvel, mas que
permita o registro das informaes que a organizao considera
imprescindveis. E nessa anlise cada organizao deve definir sua
documentao bsica, mas deve tambm explicitar aos seus colaboradores os
objetivos a serem alcanados e as estratgias utilizadas, para que consiga da
equipe o comprometimento e a motivao necessrios.
Outras reflexes
No decorrer da discusso, surgiram algumas reflexes no sentido de melhoria
do processo de teste, que no poderiam ficar de fora dessa coletnea de
informaes.
Uma dessas reflexes que chamou a ateno dos componentes da mesa foi
relativa ao tratamento dos requisitos. Ao invs de criar casos de teste, basear
os testes nos requisitos ou user stories. Essa abordagem gerou controvrsia
entre os integrantes no sentido de acreditarem no ser uma boa ideia a
criao nica de documento de requisitos direcionado para teste. Alguns
acreditam que a criao dos casos de teste continua sendo necessrio, mesmo
que os requisitos sejam elaborados tendo a viso do teste. Melhorar a
elaborao e gerncia dos requisitos uma tarefa a ser considerada sempre,
mas no elaborar os casos de teste pode ser um risco para a qualidade do
projeto, visto que o documento de requisitos e casos de teste possui diferentes
significados.
Outra reflexo interessante se, ao invs, de requisitos, documentarmos
apenas os testes? Colocarmos as solicitaes do cliente no como requisitos,
mas como cenrios de teste. Ser que perderamos algo?
De acordo com os praticantes do BDD (Behaviour Driven Development),
costumam dizer que existe a possibilidade de utiliz-lo para detalhar os
requisitos funcionais e nesse caso j estaramos documentando e escrevendo
um teste. possvel que no percamos nenhuma informao no caminho,
entretanto corremos o risco de ter que detalhar muito cedo as informaes de
um projeto. Nesse momento a equipe ainda no est madura o suficiente para
realizar esse detalhamento e em alguns casos nem mesmo o cliente tem esse
nvel de maturidade no projeto.
Em relao abordagem TDD (Test-Driven Development), como ficaria a
documentao de teste? Seria dispensvel ou seria apenas em nvel de Teste
de Unidade? Possivelmente os documentos de teste continuariam sendo
gerados, principalmente se no projeto existirem papis especficos para a
atividade de teste. Continuariam sendo desenvolvidos testes manuais e que
em determinados projetos tero a necessidade da elaborao de
documentaes tradicionais em outras abordagens.
Concluso
No decorrer da discusso dessa mesa redonda, pudemos perceber vrios

pontos de vista e vrias abordagens diferentes quanto elaborao e
tratamento da documentao a ser elaborada em um projeto. Alguns optam
pela elaborao vrios tipos de documentos, outros optam por uma
quantidade menor. Isso depende do tamanho e da criticidade projeto.
Quando maior e mais crtico, maior nvel de detalhamento exigido.
Entretanto o ponto em que todos concordam e isso vem ao encontro do que
pregam as referncias usadas como base terica deste texto, foi que a
documentao s necessria quando existirem informaes relevantes e que
realmente sejam importantes de serem armazenadas. Caso contrrio no faz
muito sentido a elaborao de documentao. Analisar a informao que se
deseja armazenar e o objetivo pelo qual se destina, o primeiro passo e a
primeira reflexo a ser feita antes de se iniciar a elaborao de qualquer
documentao.
Ambler, S. W. (2002). Modelagem gil: Praticas Eficazes para a Programao
eXtrema e o Processo Unificado. Porto Alegre - RS: Bookman.

Rezende, D. A. (2005). Projeto de Documentao. In: D. A. Rezende,
Engenharia de Software e Sistemas de Informao (p. 275). Rio de Janeiro:

Brasport.
SOFTEX. (Outubro de 2009). MPS.BR - Melhoria de Processo do Software
Brasileiro - Implementao do MR-MPS em organizaes do tipo Fbrica de
Teste.
Captulo 6: Utilizao de
Processos geis no Teste de
Software (SCRUM, XP,
TDD...)
Mara M. Dutra e Patrcia Silva Corra
Processos geis? Que isso mesmo?

Processo, ou metodologia de desenvolvimento de software pode ser
enxergado como um conjunto de atividades que auxiliam a produo de
software. Essas atividades culminam em um produto que reflete a forma
como todo processo foi conduzido.
Muitas organizaes desenvolvem software sem usar nenhum processo.
Geralmente isso ocorre porque os processos tradicionais no so adequados
as suas realidades. Em particular, as pequenas e mdias organizaes no
possuem recursos suficientes para adotar o uso de metodologias pesadas, e,
por essa razo, normalmente no utilizam nenhum processo. O resultado
dessa falta de sistematizao na produo de software a baixa qualidade do
produto final, alm de dificultar a entrega do software nos prazos e cursos
predefinidos e inviabilizar a futura evoluo do software.
E na busca por solues para esses problemas, atualmente existe um interesse
cada vez maior nos mtodos geis de desenvolvimento de software. O termo
metodologias geis tornou-se popular em 2001, quando 17 especialistas em
processo de desenvolvimento de software, representando os mtodos (XP),
Scrum, DSMD, Crystal dentre outros, estabeleceram princpios comuns
compartilhados por todos esses mtodos. O resultado foi a criao da Aliana
gil e o estabelecimento do Manifesto gil.
Uma das caractersticas dos processos geis que eles no so centrados nos
artefatos (documentao). Valorizando mais software em funcionamento, do
que uma documentao abrangente, acaba-se incentivando a produo de
documentao apenas em momentos que se faz necessrio, ou seja, deixa-se
em aberto a quantidade e artefatos que sero produzidos, para que a pessoa
decida, de acordo com a sua realidade. E orientam, que deve-se valorizar mais
o software em funcionamento, do que a produo de uma documentao
extensa.
Outra forte caracterstica dos processossgeis que so adequadas para
situaes, em que a mudana de requisitos frequente. Para ser realmente
considerada gil, a metodologia deve aceitar a mudana, ao invs de tentar
prever o futuro no comeo do projeto. Alm disso, reconhecer que as pessoas
so os principais condutores e responsveis pelo sucesso do projeto.
Mas e o Teste de Software, se encaixou nesses novos

processos?
A discusso da sexta Mesa Redonda DFTestes foi sobre a Utilizao de
Processos geis no Teste de Software (SCRUM, XP, TDD), discusso que
gerou13 respostas, e teve oito participantes: Fabrcio Ferrari, Renata Eliza,
Marcelo Andrade. Juliana Kryszczun, Felipe Silva, Ronaldo Cruz, Jorge Diz e o
Vitor Machel, e buscou responder as seguintes questes:
Metodologias geis e Teste de Software, tudo a ver ou no?
Scrum e Teste de Software combinam?
O que o XP tem a ver com o Teste de Software?
Preciso seguir a risca a metodologia gil ao implant-la?
E tambm contou com as experincias dos participantes ao utilizarem
processos geis.
Dito isso, refresquemos as ideias e vamos leitura!
Metodologias geis e Teste de Software, tudo

a ver ou no?
O Marcelo Andrade transmitiu a seguinte ideia "no h como se seguir
qualquer tcnica dita gil se no se tiver uma forte disciplina em teste de
software. Teste uma das essncias do desenvolvimento gil."
Boa parte das metodologias geis surgiu da necessidade de fazer coisas
diferentes, para que resultados diferentes fossem obtidos. Uma das diferenas
percebida que Teste de Software essencial, pois ajuda a garantir a
qualidade do produto.
O renascimento do interesse em teste de software causado pela adoo de
prticas de teste integradas ao desenvolvimento gil, como formalismos (BDD,
ATDD com planilhas, DSLs), novos mecanismos de isolamento de unidades
para teste (ex: test doubles/mocks) novas ferramentas (ex: JUnit) e
principalmente uma nova forma de olhar para o teste, enxergando-o no
apenas como uma forma de especificao verificvel mecanicamente, mas
como forma de comunicao e como instrumento de gesto, como nos
mostrou o Jorge Diz, que tambm relembrou que a automao cresceu em
importncia e puxou avanos na tecnologia de testes como nunca antes na
histria da nossa rea.
Como o termo gil nos traz a idia de velocidade, de rapidez, podemos nos
apoiar na ideia do Ronaldo Cruz para enxergar a combinao entre Testes e
Metodologias geis: "uma vez que a elaborao de um produto tem de ser
feita de forma mais rpida, os teste so ainda mais necessrios, o risco de em
meio a extrema velocidade se perder ou esquecer de alguma coisa bem
alto." Porm, como nos lembrou o Vitor Machel, existe a necessidade de que o
Teste de Software se adapte aos valores da metodologia: "como qualquer
processo de desenvolvimento de sistemas, mas no se pode ficar com o mesmo
pensamento com metodologias tradicionais, tem que se enquadrar tambm."
Scrum e Teste de Software Combinam?
Existe uma ideia que o Scrum pode ser utilizado em qualquer contexto em
que uma equipe precise trabalhar junta em prol de um objetivo comum. A
partir essa ideia, a Renata Eliza nos guia "falando especificamente do Scrum,
no h quem diga que ele pode ser utilizado em qualquer rea da vida?! Por
que no no Teste de Software?" E o Fabrcio completou: "Scrum combina com
qualquer tipo de projeto, desde para organizar uma faxina na casa com a
famlia, at a construo de um foguete. Mas existe tambm que no
concorde, o Vitor Machel, nos diz que: "Se pensar risca, no porque teste de
software por equipe de teste, no entra no conceito de Scrum". Examinemos
as vises explicitadas pela mesa redonda.
Um projeto que utilize Scrum ter maior facilidade para responder as
mudanas que vierem a ocorrer durante o decorrer do processo de
Desenvolvimento. Buscando base nos princpios dos processos geis, torna-se
possvel enumerar uma srie de motivos pra implement-lo. O objetivo
principal continuar sendo a garantia da qualidade dos sistemas.
O Scrum utiliza de meios e ferramentas bem claras para comunicao, como
por exemplo, o quadro Kanban, que faz com que os objetivos e as tarefas
estejam mais claras e para todos da equipe. Alm disso, h um grande foco em
reunies de alinhamento, focadas em objetivos especficos, como por exemplo
a daily meeting, onde o objetivo alinhar como est o andamento do
trabalho da equipe.
Essa dinmica diferente, que acaba sendo mais simples e facilita a equipe ter
foco no trabalho que necessrio ser feito, pode resultar num melhor
gerenciamento dos testes e tambm num fluxo mais rpido das tarefas, em
comparao, com metodologias tradicionais.
Com a implantao do Scrum possvel
Verificar o andamento de cada projeto como um todo
Permitir a deteco e remoo de riscos e impedimentos
Oferecer uma estimativa mais apurada
Controlar conflitos de interesses e necessidades
Compartilhar o conhecimento entre a equipe
Vale lembrar tambm que um dos pontos mais importante do Scrum trazer
o cliente para perto do time.
Focando o Scrum na atividade de Teste, o Jorge Diniz nos trouxe outra

importante percepo: " O conceito de pronto, aplicado s user stories, tem
que incluir testes."
Como o Scrum um framework de prticas de gesto, necessrio que
tambm se adote em conjunto prticas tcnicas que iro permitir que as
entregas atendam sempre aos padres de qualidade. As prticas de XP vm a
se encaixar bem nesse contexto.
Para no se prender somente nas prticas de gesto e chegar a umanti-
pattern, necessrio foca-se tambm nas tcnicas usadas para entregar

software. impossvel melhorar o produto sem mudar as tcnicas de
requisitos, de desenvolvimento, de integrao e de teste. Se no houver
mudanas a equipe no conseguir dar vazo as entregas. Os post-its na
parede no possuem superpoderes, por isso nada de esperar melhorias sem
mudanas.
Para concluir, refletimos sobre as colocaes do Ronaldo Cruz:
"Todo modelo de desenvolvimento combina com teste. A questo o quanto
as pessoas e empresas esto dedicadas em fazer as coisas acontecerem. De
nada vale dizer que usa Scrum, XP, RUP, abobrinha, chuchu ou cenoura, se a
empresa e os envolvidos no esto realmente engajados em implementar o
modelo e faz-lo acontecer".
O que o XP tem a ver com o Teste de Software?

O XP - Extreme Programming, desenvolvido por Kent Back e Ward
Cunningham, conhecido como o mais popular dos mtodos geis. indicado
para equipes pequenas e mdias, que necessitam desenvolver softwares em

que os requisitos no esto totalmente especificados e que tambm se
modificam rapidamente. Os valores principais so: comunicao, simplicidade,
feedback e coragem.
Aps essa breve viso, nos resta responder a questo: "O que o XP tem com o
Teste de Software?"
Para o Jorge Diz, o "XP representou no incio uma viso bastante peculiar em
relao a teste de software".
De uma maneira bem sintetizada, pode-se dizer que o XP distribuiu o Teste de
Software em dois: os Testes do Programador e os Testes do Cliente.
No Teste do Programador, o desenvolvedor se torna responsvel por testar
seu prprio cdigo. Para cada user story, escrito um teste que atenda a
funcionalidade. Aps a escrita do teste o desenvolvedor implementa o cdigo.
Dessa forma, o teste tem um teor altamente tcnico e funciona como um
apoio ao desenvolvimento do software.
A cada novo teste construdo, necessrios que eles sejam integrados
bateria de testes existentes. A cada integrao, os novos testes no podem
causar falhar nos antigos e essa integrao contnua precisa ser rpida para
que o fluxo de trabalho de desenvolvedor no seja quebrado.
J o Teste do Cliente, funciona como testes de aceitao. Os clientes validam
cada user story e com essa validao, o requisito desta user story declarada
pronta.
Outra caracterstica do teste cliente o detalhamento dos requisitos
funcionais do sistema. Uma vez que os clientes esto mais prximos do
ambiente de operao do sistema, para eles mais fcil levantar novas regras
e requisitos sobre o software em desenvolvimento.
As atividades de inspeo tambm esto presentes no XP. Nesse processo, as

prticas de inspeo se fundem dentro da prtica de trabalho em pares ("pair
programming"). Esta inspeo contnua, mais eficaz que do que a inspeo
tradicional, uma vez que as inspees tradicionais so feitas aps o fluxo de
desenvolvimento.
Mas nem tudo so flores em relao a inspeo. Essa prtica exige uma
mudana na cultura do programador, e ela no costuma ser fcil.
Outra forte tendncia no XP a automao de testes. Essa automao
provocou uma srie de inovaes tecnolgicas, para que o tempo de teste
fosse suficiente para que o tempo do projeto no fosse quebrado, apoiando o
ritmo do desenvolvedor.
Na cultura do XP, inicialmente no era dada importncia aos testes manuais.
Atualmente, essa viso mudou devido as contribuies da escola "contextdriven testing" para testes exploratrios gerenciados.
Vale ressaltar que TDD (Test Driven Development) no considerada uma
prtica de teste, e sim uma prtica de apoio ao desenvolvimento, uma vez que
ela uma juno de duas prticas: 'test-first' (escrever o teste automatizado,
antes do cdigo) e 'refactoring' (limpeza do cdigo, sem alterar seu
comportamento funcional que j fora validado pelos testes).
Preciso seguir a risca a metodologia gil ao

implant-la?
Essa uma dvida que pode surgir na cabea dos responsveis pelo
desenvolvimento de um software. Surge um novo projeto e a oportunidade de
colocar em prtica os conhecimentos sobre os processos geis. De que forma

utilizar a metodologia gil em seu projeto? Vejamos as ideias dos
participantes da mesa para sanar essa dvida.
Como o prprio nome diz, um modelo, uma forma estruturada de executar o
trabalho. Cada empresa tem sua particularidade, seja do projeto, dos
funcionrios, do cliente, em fim, da cultura. O que o Ronaldo Cruz nos
recomenda "voc pega as prticas do modelo e as adapta ao seu ambiente."
Outro cuidado com "seguir a risca" a forma como a metodologia ensinada,
O Vitor Maciel aponta: "...ningum ensina a risca metodologia gil, incrvel o
que eu leio por a." E prossegui alertando sobre cargos: "Imagina criar
empregos especficos de Scrum como um cara especifico para ser Scrum
Master".
J alguns (o Kent Beck do XP, por exemplo), dizem que sim, que necessrio
seguir a risca a metodologia, por causa da sinergia entre as prticas. Como
citou o Jorge Diz. Mas, o prprio Jorge, acredita que necessrio manter um
jogo de cintura, sem descaracterizar as prticas que fazem a dinmica
funcionar. Sempre iro existir limitaes e ser preciso contorn-las.
No incio do processo de implantao de uma metodologia gil, o problema
a que os conceitos da metodologia ainda no foram totalmente incorporados.
S se aprende realmente fazendo, descobrindo, que importante e o que no
; onde ser preciso bater o p e onde ser possvel ceder; o que funcionar
bem num certo contexto e o que ser preciso evitar. Por isso, uma das solues
para esse problema, ter o acompanhamento de profissionais mais
experientes durante o incio de uma transio para a agilidade.
Outra prtica comum, adotada pelas organizaes que adotam uma nova
metodologia, so as adaptaes para evitar as prticas que mais mudam a
forma de trabalho qual esto acostumadas, por acomodao ou por medo
da mudana. O tal "Scrum, but ...", como disse o Jorge Diz.
Muitas organizaes saem com as mximas: "Estamos fazendo Scrum, mas

dispensamos as reunies dirias". "Estamos usando XP, mas no temos testes
unitrios". Em casos como esses, a chance de sucesso diminui drasticamente, e
a metodologia em questo paga o pato e ainda aparece mal na foto.
Para concluir, O by the book est longe de ser a melhor maneira de implantar
algo, principalmente na nossa rea, como nos contou o Fabrcio, e continuou
dizendo: "Adaptao a palavra chave, e adaptao no feita uma nica
vez, temos que est sempre evoluindo e melhorando, e para isso a adaptao
essencial."
O Testador no Processo gil

"O testador o cara que aprova.
Nada considerado pronto em um sprint, at que ele diga que est." Gustavo Quezada
Durante a Mesa Redonda surgiu um novo questionamento. A Juliana
Kryszczun levantou a seguinte dvida:
Qual a maior diferena para o analista de teste entre processos geis e
processos tradicionais de teste?
Para ajudar a sanar essa questo, o Marcelo Andrade citou o artigo do
Professor Jos Papo, "O papel do analista de Testes dentro dos processos geis
- Uma Introduo". Abaixo est uma compilao das principais colocaes do
artigo.
O professor inicia apresentando a ideia de que ainda existem muitas dvidas
no mercado, sobre qual o papel do analista de teste dentro de uma equipe
gil. Pois a definio dos papeis pode levar a confuses e a crena, de que no
existe lugar para o analista de teste em um time gil.
Outro levantamento do professor a diferena entre o processo tradicional e

o processo gil. Enquanto no processo tradicional, testes aparecem no fim do
ciclo de desenvolvimento o analista de teste mais reativo. Na prtica a
equipe de vive separada da equipe de desenvolvimento, e s se cruzam no
momento da verdade da fase de teste do modelo cascata. J nos processos
geis, o analista de teste deixa de ser reativo para se tornar um papel

fundamental na interao com os desenvolvedores, analistas de negcios e
clientes.
Para fundamentar essa mudana, o professor apoiou-se no quadrante de
testes gil, do livro de Lisa Crispin e Janet Gregory, Agile Testing.
Em seguida, citou os grandes Grupos de Teste:

Q1 - Testes que focam na arquitetura e suportam o time: So os testes
unitrios e de componentes. Estes so realizados e so de responsabilidade
dos prprios desenvolvedores. O papel do analista de testes nesse quadrante
o de apoiar, suportar e expandir conhecimentos entre os desenvolvedores
sempre que necessrio. De preferncia isso feito fazendo "pairing" com o
desenvolvedor no momento de elaborar os testes unitrios automatizados.
Q2 - Testes que focam no negcio e suportam o time: So testes funcionais
diferenciados, que idealmente utilizam a tcnica de Behaviour-Driven
Development e Acceptance Test-Driven Development. Isto , so testes e

cenrios de exemplo realizados pelos testadores em conjunto com os clientes,
usurios e analistas de negcio. Com base nesses exemplos e cenrios os
desenvolvedores tero melhores condies de desenvolver e entender os
requisitos. Alm disso, utilizando-se ferramentas adequadas (como o Fitnesse

ou o Concordion, por exemplo), uma parte desses testes ser automatizada
antes ou em paralelo com o desenvolvimento do cenrio. Portanto, o foco
desses testes no encontrar o maior nmero de defeitos e sim ajudar clientes
e desenvolvedores a se entender melhor.
Q3 - Testes que focam no negcio e criticam o produto: esses so o que chamo
de testes "clssicos". Os testes de aceitao feitos na homologao do produto
ou de suas partes, testes betas e testes exploratrios. So os testes feitos no
com o objetivo de dizer que o software funciona, mas, pelo contrrio, de
encontrar defeitos. Essa categoria s vezes negligenciada por alguns
agilistas mais radicais. Mas a verdade que bons analistas de testes possuem
tcnicas para encontrar defeitos que poucos desenvolvedores conhecem (at
porque o papel do desenvolvedor construir e o do testador, neste
quadrante, o de destruir!).
Q4 - Testes que focam na arquitetura e criticam o produto: So os testes de
performance, de carga e de segurana. Esses so de responsabilidade dos
analistas de testes e costumam ser feitos quando pedaos da aplicao j
esto prontas e, especialmente, antes da entrada de um release em produo.
E concluiu com a seguinte recomendao: "Recomendo ento a todos os
analistas de testes: estudem bastante o processo gil de testes, as novas
tcnicas de Behaviour Driven Development e as ferramentas automatizadas
que as auxiliam. Assim voc se tornar um recurso muito mais valioso para sua
equipe e para o resultado final dos projetos."
Principais Benefcios dos Mtodos geis.

Existem vrias razes pelas quais as empresas adotam os Mtodos geis ir
agregar valor a seus negcios. Dentre as principais podemos citar:
Software correto - O cliente est constantemente envolvido no projeto.
Assim assegurando que o software que esta sendo desenvolvido o que
lhe retornar o maior valor desejado, ou seja, atender todos os requisitos

funcionais, de acordo com a sua prioridade. A todo instante o cliente ir
dizer que o sistema estar desenvolvido de forma correta para a equipe de
desenvolvimento sobre o incremento de software que foi entregue. Com
esse alto grau de envolvimento do cliente em um projeto gil, no mais
difcil desenvolver um software errado e que no traga o maior valor
possvel ao cliente.
Qualidade - Mtodos geis sempre atribuem forte foco na qualidade do
que esta sendo desenvolvido. No se resumindo apenas nos testes de
aceitao do
cliente, mas sim na adoo de prticas de desenvolvimento que garantam
alta qualidade tcnica.
Prazos e custos - O fato dos projetos geis fazerem com que o software
seja desenvolvido em interaes, e propondo que essas interaes devam
ser curtas, faz com que os atrasos sejam menores, e tambm proporciona
um melhor ajuste da equipe quanto ao desenvolvimento do software, e do
cliente quanto ao software que deseja. Na verdade a grande vantagem do
mtodos geis nesse ponto, que eles incentivam a entrega constante e o
mais cedo possvel, o prazo em si tambm definido em projetos que no
usam mtodos geis. Caso o andamento do projeto no esteja seguindo o
que foi planejado, os requisitos de menor valor ou baixa prioridade podem
ser retirados do projeto. E caso o perodo definido de tempo do projeto
tenha a necessidade de ser estendido, isso ocorre com o total
consentimento do cliente e de todos envolvidos no projeto.
Alertas mais cedo - Como um projeto gil essencialmente uma srie de
mini-projetos bem definidos, os problemas podem ser identificados e
resolvidos com maior antecedncia, sem causar maiores danos ao
andamento do projeto.
Adaptao a mudana - As mudanas so inerentes aos negcios. Um
projeto gil pode se adaptar as mudanas de um mercado, uma empresa,
ou um cliente, efetivamente melhor do que os projetos tradicionais.
Experincias dos participantes ao utilizarem

processos geis
Nessa parte, sero expostas as experincias compartilhadas pelos participantes
da mesa, sobre a utilizao de processos geis. Aproveitem as vises e
absorvam o que julgarem necessrio, nunca se sabe quando ser a hora de
colocar a leitura em prtica, e ideias so sempre bem-vindas. Como disse o

Felipe da Silva: "Gosto sempre de utilizar exemplos que sendo analisados
possa-se tirar uma lio extra".
Para o Ronaldo Cruz:
"Para mim foi muito boa. Tornou o trabalho mais fcil por ter uma interao
maior com todos os envolvidos. Mas tambm exigiu uma mudana maior na
postura. Qualquer membro da equipe, seja desenvolvedor, banco ou teste,
tem de se tornar gil. Sair da cadeira e correr atrs, seja para desenvolver a
atividade de outro membro ou tirar dvidas de teste ou negcio, no importa,
cada um da equipe precisa deixar de ser acomodado e se tornar pr-ativo,
buscar a soluo e ajudar os demais a conclurem as suas atividades. Na equipe
em que trabalho, me tornei analista de teste, negocio e dou suporte ao
pessoal do desenvolvimento."
O Vitor compartilhou tambm a sua experincia dizendo:
"Totalmente satisfatrias, os documentos (no so todos) que s serviram
para ir para o lixo, nem existe mais. O conceito que estamos usando "faa
somente documentos para usar e entregue o software funcionando".
dificilmente estamos trabalhando(tanto teste quanto desenvolvimento)
depois das 18 e sbados e domingo, o que eu mais gostei. Em resumo aqui,
todos esto aprovando, cliente satisfeito tudo, o resto resto."
O Fabrcio Ferrari apresentou tambm suas concluses retiradas de suas

experincias:
A cultura das pessoas e da organizao o que mais influncia a
implantao de uma metodologia gil;
A maturidade das pessoas tambm um fator bastante influenciador,
principalmente, em relao ao tempo que a implantao vai levar e como
ela ocorrer;
A comunicao essencial, tanto interna quanto externa;
O PO o cara (no bom sentido claro), a sua participao essencial para o
sucesso do projeto;
As pessoas so o diferencial de qualquer projeto. As pessoas certas com
domnio da tecnologia, conhecimento do projeto e determinao so
capazes de resultados incrveis, e a adoo de metodologias geis
potencializa esses resultados;
A metodologia utilizada pode ter dado certo em um projeto, mas isso no
garante que ela tambm ir funcionar em outro;
Busque ter uma pessoa da rea de Teste de Software, no seu time Scrum;
Antes de implantar uma nova metodologia, d treinamentos a respeito
dela para todos;
Se algo deu errado, com certeza no culpa da metodologia, e sim sua.
O Jorge Diz a partir de suas experincias identificou os problemas enfrentados
pela disciplina de Teste de software no contexto dos processos geis. comum
as pessoas empacarem justamente por dificuldades na automao de testes no
nvel necessrio para suportar a agilidade. Alguns pontos de ateno:
Cdigo legado difcil de testar
Falta de disciplina de test-first por parte dos desenvolvedores
No domnio das tcnicas de isolamento para testes unitrios
Investimento excessivo em testes frgeis (GUI), que pode diminuir a
velocidade das atividades de teste.
Indisponibilidade de ambiente prprio para teste, onde a aplicao possa
ser testada sob controle total da equipe de desenvolvimento/ testes
Testadores ainda perdidos numa nova forma de organizar as equipes
(testador residente em vez de operrio de uma fbrica de testes)
Dificuldade para satisfazer o pronto-pronto
Resistncia programao em pares
Concluso
Voltando ao tema processos geis, nesse momento de fechar as ideias, vale
relembrar da colocao do Marcelo Andrade, que alertou para o enfoque
meramente mercadolgico para a palavra gil. De nada adianta uma empresa
dizer que usa metodologia gil se ela no possuir disciplina e seguir apenas o
modismo que a palavra gil nos traz: "Ontem usvamos metodologia prpria,
hoje usamos gil e continuamos seguindo o testa a". O indicado, seria que
empresas que querem entrar na moda, usassem um tempo para estudar e um
modelo como mesclas de metodologias geis adaptadas para seu cotidiano.
Nesse caso, essas empresas poderiam ser o destaque de um evento 'da moda' e
ainda ganhar fs e seguidores, como a globo.com que implantou um misto de
metodologias geis para desenvolvimento de seus projetos.
E seguindo a ideia de adaptar e implantar, o principal objetivo ao se implantar
uma nova metodologia, sempre melhorar e melhorar, como lembrou o
Felipe Silva e que ainda completou dizendo que pela melhoria vale a pena ir
guerra, tomando o cuidado de sempre lutar como um exrcito unido e no
um contra o outro. Lembrando que ser necessrio mudar a cultura dos
soldados, pois de nada adiantar usar, gil, abobrinha, ou chuchu, se as
pessoas da empresa, ou os nossos bravos soldados, no estiverem
comprometidas e engajadas em implementar o modelo e faz-lo acontecer.
No existe a bala de prata!
Inicie com o primeiro passo e siga passo a passo. No de uma vez, como
tentam fazer alguns, que pensam que um processo novo que cai de sem praquedas e ir funcionar. Traga o cliente para perto do time, busque ter uma
pessoa da rea de Teste de Software, no seu time. J vimos que o teste tem
muito, se no tudo a ver com essa guerra. Ele a arma secreta para deixar seu
cliente satisfeito. E principalmente, ao iniciar um novo processo gil, lembre-se
da mxima do Marcelo Andrade:
SE VOC NO TESTA, VOC NO GIL!
CRISPIN, Lisa et al. Agile Testing: A Practical Guide for Testers and Agile
Teams. Addison-Wesley Professional. 2009. 576P.
KOSCIANSKI, Andr. Qualidade de Software. So Paulo. Novatec. 2007 400p.
PAPO, Jos. O papel do analista de Testes dentro dos processos geis - Uma
Introduo. Disponvel em <

http://josepaulopapo.blogspot.com/2009/09/testes-agil-papelanalista.html> Acesso em 09/11/2010.
SOARES, Michel dos Santos. Comparao entre Metodologias geis e
Tradicionais para o Desenvolvimento de Software. Disponvel em
<http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02... > Acesso em
01/11/2010
Captulo 7: Teste gil, como

implementar?
Lucas Gonalves Nadalete
Revisora: Juliana Kryszczun
Introduo
O uso de metodologias e prticas de desenvolvimento gil tm se tornado
algo cada vez mais natural no cotidiano das empresas . Algumas dessas
empresas, apesar de no admitirem sua adeso, implicitamente acabam
aplicando algumas prticas comuns, com o objetivo de obter resultados mais
cedo.
Essas prticas tendem a estimular e valorizar a equipe e a interao constante
entre os seus membros, a colaborao constante com os clientes, o
funcionamento do software em desenvolvimento e a capacidade de resposta a
mudanas.
Poucas sabem, mas na realidade elas esto adotando os princpios geis
definidos no Manifesto gil na data de 11 13/02/2001. No entanto, o que
muitas no tem claramente definido, como controlar a qualidade do que
est sendo desenvolvido de forma gil, ou seja, como praticar teste gil.
Conforme opinio expressa pelos colaboradores e reforada por meio da
prpria literatura, aplicar teste gil exige quebra de paradigmas, mudana de
cultura, dinamismo da equipe (pr e pr-atividade), conhecimento tcnico,
testes automatizados, e muitas outras caractersticas e fatores que viabilizam a
aplicao de teste gil, quando praticadas conjuntamente.
Este captulo apresenta uma explanao sobre "teste gil e como implementlo" do ponto de vista das diversas perspectivas discutidas na Mesa Redonda
DFTestes.
O que Teste gil?'

Em se tratando de desenvolvimento gil, alguns princpios definidos por meio
do Manifesto gil so utilizados com o objetivo de nortear a linha de
produo, como:
Indivduos e interaes entre eles mais que processos e ferramentas;
Software em funcionamento mais que documentao abrangente;

Colaborao com o cliente mais que negociao de contratos;
Capacidade de responder a mudanas mais que seguir um plano.
Apesar de se valorizar muito mais os itens da esquerda, os itens da direita no
so desconsiderados, ao invs disso, os mesmos so aplicados de forma
ponderada e conforme a necessidade do processo, sem que haja impacto nas
entregas a serem realizadas, prazos estabelecidos e qualidade do produto
final gerado.
Os mesmos princpios usados para direcionar o desenvolvimento gil, devem
ser considerados quando for aplicado teste gil, ou seja, testar de forma gil
exige uma forte adaptao na rotina e dinmica da equipe de teste, em
relao ao processo de desenvolvimento adotado, com o objetivo de propiciar
um processo relativamente simples e que possa ser executado com grande
facilidade e agilidade, cobrindo o maior nmero de riscos, com um nvel de
qualidade que seja apreciada e valorizada pelo cliente ou usurio final.
Atravs da definio do processo ideal e simplificado, onde o teste gil
suportado, um conjunto de prticas que proporcionem a diminuio do
tempo entre o erro e a sua descoberta tendem a ser estabelecidos em
conjunto com uma sistemtica de trabalho que possibilite rea de teste de
software ser mais pr-ativa do que reativa.
O que muda do Teste Tradicional para o Teste
gil?
Analisemos algumas das prticas do processo de teste tradicional aplicados na
tentativa de gerenciar o "chaos", ou ao menos evitar culpados :
A rea de teste de software assumindo a postura de "ltimo Defensor da
Qualidade";
Restries no gerenciamento de mudanas;
Preparao detalhada e planejamento acima de tudo;
Conjunto de documentao pesado para a terceirizao dos esforos de
teste;
Critrios de entrada e sada rigorosos e com aprovaes;
Automatizao de testes pesada e com foco nas regresses;
Tentativas de execuo do processo.
Ao se tratar de teste gil, essas mesmas prticas no se adaptam dinmica
almejada. Em um ambiente gil de controle de qualidade deve-se considerar
os prazos e as atividades de teste do comeo ao fim da iterao. Ao contrrio
do teste tradicional, no se espera que uma nica equipe se responsabilize
pela qualidade final das entregas, mas sim que todas as equipes tenham sua
colaborao no controle dessa qualidade, desde o levantamento das
necessidades do cliente, at a implantao do produto final gerado.
Figura 7.01 Deslocamento de papis - Adaptado de
Conforme pode ser observado na Figura 1, no teste tradicional, espera-se que
os defeitos sejam identificados no ltimo nvel, pela equipe de QA, enquanto

que ao se aplicar teste gil, isso antecipado pela prpria equipe de
desenvolvimento por meio de prticas como desenvolvimento em pares,
integrao contnua, pequenas entregas, refatorao constante e padres de
codificao, de tcnicas como TDD (Test Driven Development) e ATDD
(Acceptance Test Driven Development), e atravs da automatizao dos testes
gerados.
Ao se trabalhar com testes geis, observa-se algumas mudanas de conceito
em relao ao modelo tradicional, tais como:
Mudanas so inevitveis, e com base nisso toda equipe, incluindo os
programadores, testadores e clientes, so responsveis pelo resultado final;
Todos da equipe devem estar acessveis e se comunicando ativamente
atravs do projeto;
O teste de software se torna mais preventivo, ou seja, programadores
testam mais cedo, com mais frequncia e agressivamente. Neste ponto a
prtica de TDD pode e deve ser aplicada;
Toda equipe solicita ativamente feedback das demais;
Testadores e programadores tendem a ser mais pr-ativos (participao
direta com o cliente) e tcnicos (aplicao de prticas XP e tcnicas como
TDD e ATDD);
Testadores precisam saber automatizar, com o intuito de manter o ciclo de
entregas dos testes sempre no prazo estabelecido e com teste de regresso
atualizado. S no se automatiza, o que realmente no pode ser
automatizado ou no vale a pena ser automatizado (e.g. Teste de
Usabilidade);
Os testes tonam-se uma rotina que nasce e morre junto iterao
planejada.
Como podemos implementar Teste gil no
dia-a-dia?
possvel trabalhar de forma gil nas atividades de teste desoftware com
qualquer tipo de metodologia de desenvolvimento, desde os mais tradicionais
descendentes da famlia UP (e.g. RUP, EUP, OpenUP, AUP), at as mais geis
como XP, Scrum, Cristal, Lean e outros. A questo que nenhuma dessas
metodologias garantir "agilidade" no processo. Ser gil no exige apenas
adotar uma sistemtica gil, mas pensar e agir de forma gil na plenitude do
seu conhecimento.
Figura 7.02 Fluxo gil de desenvolvimento

Em um projeto onde a sistemtica de trabalho segue os princpios do
Manifesto gil, o prazo de cada iterao tende a ser reduzido, visando
agregar valor mais rpido ao produto final que apresentado como subsdio
para se obter o feedback do cliente (Figura 2).
neste tipo de iterao que as "atividades de teste" devem assumir
caractersticas geis. A Figura 3 apresenta um processo simplificado de teste
gil que pode ser adotado a cada iterao realizada.
Figura 7.03 Representao de uma iterao de teste gil - Adaptado de

Prticas XP: A aplicao de algumas das prticas de Programao Extrema
possibilitam mitigar e minimizar os riscos de introduzir defeitos triviais na
aplicao, por meio da aplicao de programao em par, design
simplificado, testes, refatorao constante e a aplicao de padres de
codificao . Outras prticas podem ser adicionadas conforme necessidade.
Teste de Unidade Automatizado: Feito pelos prprios programadores,
geralmente com o auxlio de um framework xUnit, e frequentemente como
resultado da prtica de TDD. A bateria de testes de unidade gerada
representa um conjunto de especificaes executveis que apoia o processo
de desenvolvimento.
Teste de Aceitao Automatizado: Representa o resultado da colaborao
entre os programadores e os stakeholders de negcio, e so
frequentemente implementados com o auxlio de um FIT (Framework for
Integrated Testing). A bateria de testes de aceitao gerada representa um

conjunto de requisitos executveis.
Teste Exploratrio Manual: Alm de ser necessrio para complementar os
testes automatizados, os testes exploratrios fornecem algum feedback
adicional, cobrindo possveis lacunas que passam despercebidas pelos
testes automatizados de unidade e aceitao.
Para se aplicar teste gil, no h receita de bolo a ser seguida. preciso
conhecer o processo gil praticado muito bem, assim como a cultura da
empresa e a maturidade dos seus colaboradores em relao ao mesmo, e em
cima disso, trabalhar uma estratgia de implantao e execuo das atividades
de teste dentro do processo.
Algumas sugestes so apresentadas por profissionais e podem ser

consideradas na implementao de teste gil:
Implantao de forma gradativa, ou seja, a realizao de um projeto piloto
pode ser adotada com o intuito de iniciar a adoo, adquirir experincia,
aperfeioar, ajustar e comprovar progressivamente os ganhos;
Anlise antes de automatizar os testes, se realmente vale a pena ou no. A
automatizao na maioria das vezes proporciona diversos ganhos ao
projeto, principalmente a mdio e longo prazo, no entanto, a mesma pode
custar mais caro que os ganhos proporcionados em determinadas
situaes;
Ao se aplicar teste gil, h uma inverso na pirmide dos nveis de teste, ou
seja, ao invs de termos muitos testes a nvel de sistema e aceitao,
havero muitos testes a nvel de unidade e integrao, onde a
responsabiliade primria tende a ser dos programadores;
Atue junto ao cliente, com o objetivo de obter feedback constante sobre o
que est sendo desenvolvido, em relao ao esperado;
Criar teste de unidade e integrao para sistemas legados (cdigo
desenvolvido sem teste), algo impraticvel e pode impactar no
oramento e prazo final planejado.
ATDD e TDD, como implementar?

muito comum ouvirmos a respeito de desenvolvimento orientado a teste
(TDD) como uma "tcnica para teste" onde os testes de unidade produzidos,
guiam o desenvolvimento do cdigo fonte da aplicao. Na verdade TDD no
se trata de uma tcnica, e sim de uma "prtica de programao" que resulta
em uma sute de testes de unidade, onde tais testes so um efeito colateral e
no o objetivo em si .Na aplicao da prtica de TDD guiada por trs passos
bsicos, usados no desenvolvimento dos testes de unidade, e
consequentemente do cdigo fonte da aplicao:
Desenvolve-se um teste de unidade que falhe, para demonstrar que a base
de cdigo existente ainda no contm tal recurso implementado;
Uma vez que se tenha o teste de unidade que falhe, produz-se o cdigo de
produo para tonar o teste executvel e faz-lo passar;
Com o teste passando, refatora-se o cdigo com o objetivo de enxugar e
eliminar duplicaes para deixar o cdigo fonte legvel e melhorar o
design.
Aplicar TDD nem sempre uma tarefa fcil e muitas vezes tida como
complexa por pregar a criao dos testes antes mesmo do cdigo da
aplicao, alm de representar expectativas quanto ao comportamento do
software.Mas e o que a "prtica" de ATDD tende a oferecer alm da TDD?

ATDD visa capturar os critrios de aceitao para a funcionalidade em
desenvolvimento. Normalmente isso discutido, identificado e levantado
quando a equipe de teste interage com os responsveis pelo negcio, visando
compreender sua real necessidade. Em complemento prtica de TDD, que
visa garantir que as funcionalidades bases da aplicao sejam desenvolvidas
em conformidade com a arquitetura e projeto, a prtica de ATDD tende a
prover feedback sobre o quo perto da concluso da tarefa a equipe de
desenvolvimento se encontra, demonstrando uma clara viso do progresso.
A Figura 4 apresenta claramente o ciclo de desenvolvimento orientado a teste
de aceitao, e como a prtica de TDD pode ser inserida visando aumentar a
abrangncia dos testes.
No artigo escrito por Elisabeth Hendrickson , fonte principal deste tpico, a

autora apresenta um exemplo simples, prtico e bem completo de como
extrair o melhor de ambas as prticas de TDD e ATDD. As equipes que aplicam
as prticas, principalmente ATDD, tendem a sentir os benefcios ainda na fase
de discusso dos requisitos e estabelecimento dos critrios de aceitao, por
meio de uma melhor e mais completa compreenso das necessidades do
cliente.
Quando o ciclo proposto na Figura 4 trabalhado do comeo ao fim do
projeto, os envolvidos tendem a concordar que o sistema tende a se tornar
mais testvel, manutenvel e relativamente fcil. Com a sute de testes gerada
possvel efetuar os testes de regresso automaticamente, fornecendo um
pronto feedback sobre as expectativas relacionadas s funcionalidades bases
do sistema, e ao negcio como um todo.
Quais as dificuldades de se implementar Teste

gil?
Nem todos os ambiente so propcios para a adoo e execuo de
desenvolvimento gil. Barry Boehm e Richard Turner sugerem em seu trabalho
que a anlise de risco seja usada para escolher entre mtodos adaptativos
("geis") e preditivos ("dirigidos pelo planejamento"), destacando o ambiente
ideal para cada um destes:
Ambiente ideal para o desenvolvimento gil:
Baixa criticidade;
Desenvolvedores snior;
Mudanas frequente de requisitos;
Pequeno nmero de desenvolvedores;
Cultura que tem sucesso no caos.
Ambiente ideal para o desenvolvimento direcionado a planejamento:
Alta criticidade;
Desenvolvedores jnior;
Baixa mudana de requisitos;
Grande nmero de desenvolvedores;
Cultura que procura a ordem.
Muitas vezes as caractersticas acima apresentadas so consideradas ao se
definir qual a metodologia a ser adotada em um projeto de desenvolvimento
de software e, consequentemente na sistemtica adotada para as atividades
de teste. Dentre outros fatores que podem comprometer a adoo de uma
abordagem mais gil na dinmica de testes dentro da empresa, cita-se:
Cultura organizacional resistente;
Requer muita mudana cultural;
Pode levar a maiores dificuldades nas negociaes contratuais;
Equipe no multidisciplinar, ou seja, considerando o fato de que o time de
teste forado a cada vez mais estar pequisando e se aperfeioando em
relao novas ferramentas, alm de saber programar, pois a automao
se torna um elemento essencial, espera-se que os colaboradores sejam
multidisciplinar;
Cliente no ou prefere no ser gil, assumindo uma metodologia

direcionada a planejamento. Neste ponto, espera-se que ao optar por uma
metodologia gil, o cliente seja participativo e comprometido com o
sucesso do sistema, passando para o time de desenvolvimento suas reais
necessidades e opinies do sistema;
A rea de teste participando de forma reativa, ou seja, contando sempre
com todos os documentos mo, o que nem sempre uma realidade em
um ambiente gil.
Segundo Jos Correia, um profissional especialista da rea de teste de
software, o mesmo relata sua experincia prtica em relao resistncia do

mercado na adoo de metodologias geis:
"Nos projetos que acompanho, o uso de prticas geis elegvel apenas
quando o nmero de horas totais do projeto inferior a 1000 horas. Alguns
clientes so mais conservadores e estabelecem um teto de 640 a 800 horas.
Projetos acima so executados dentro das prticas do RUP, modelos
CMMI/MPS-Br e os testes complementados com base no Syllabus/ISTQB,
CBOK/QAI, normas ISO e IEEE."
Experincias como a citada acima, nos mostram que um ambiente gil nem
sempre elegvel para um determinado projeto, seja pelas especificaes do
projeto a ser executado, seja pela capacitao dos recursos envolvidos, seja
pelo prazo estabelecido, ou at mesmo pela resistncia organizacional ou do
cliente final. O que nos cabe analisar cada caso e avaliar qual a melhor
metodologia de desenvolvimento e teste a ser aplicada, e no simplesmente
aplic-la por aplicar.
Quais as vantagens de se implementar Teste

gil?
A aplicao de teste gil proporciona diversas melhorias, no s a nvel de
qualidade do processo, como tambm na qualidade do produto. A equipe de
desenvolvimento se apresenta mais motivada e segura em relao a qualquer
mudana que seja efetuada na aplicao. Em um ambiente gil, os bugs so
identificados, relatados e corrigidos em um curto espao de tempo, pelo fato
do foco estar na preveno e no na remediao dos mesmos. O
desenvolvimento torna-se sustentvel.Em um ambiente gil, a tendncia
que as entregas sejam feitas mais rpidas, em curtas iteraes. A gesto de
defeitos tende a ser, tambm, mais dinmica, pois passa a ser executada
diretamente pelo prprio desenvolvedor, sem o relato de inconformidades e
interveno do testador, como tambm pode ser fomalizada pela equipe de
QA equipe de desenvolvimento quando identificadas a nvel de sistema ou
aceitao.
A participao do cliente nas atividades de teste se torna mais efetiva, ou seja,
faz com que o software tenha realmente aquilo que precisa ter, e faa aquilo
que realmente precisa fazer. Em paralelo, a automatizao de testes adquire
muito mais importncia, possibilitando a realizao de ciclos enxutos e cada
vez mais rpidos, alm de garantir a validao regressiva das funcionalidades,
e de forma econmica.Ao se aderir a teste gil, o retrabalho e manuteno
executados na aplicao so bem menores, pois as validaes so realizadas
em todos os nveis da aplicao (unidade, integrao, sistema e por fim
aceitao do cliente final). Com isso, o custo e tempo atrelados ao
desenvolvimento tambm tendem a reduzir.
possvel observar que o fator "tempo" tem se tornado cada vez mais curto,
levando muitos profissionais a casarem a ideia de agilidade com qualidade.
Com base nisso, tenta-se estabelecer um equilbrio unindo o "til" (qualidade)
ao "necessrio" (agilidade), sem perder a real essncia das atividades de
controle de qualidade. Em outras palavras, "agilidade" no representa "ter
pressa", da mesma forma que no simboliza evitar a "documentao", pelo
contrrio, ser "gil" significa fazer direito, conciso e coeso, onde toda
documentao que seja efetiva e til, mais que assimilada. por esse motivo
que a documentao de teste de software esta entre uma das melhores e mais
efetivas.
Em um artigo publicado na InfoQ por Kay Johansen, a mesma questiona
diferentes especialistas da rea "Por qu voc ama teste gil?", obtendo as

mais variadas respostas, as quais so compiladas em 10 razes chaves para
isso:
No h mais teste manual de scripts!: Scripts so executados
automaticamente, disponibilizando mais tempo para o testador executar
testes exploratrios.
Desenvolvedores realmente gostam de mim!: Localizar problemas antes
do final da iterao e enquanto o cdigo est fresco na mente dos
desenvolvedores, facilita o trabalho dos mesmos.
Agora eu posso verificar os recursos antes deles serem escritos!(ambos
Kay e Philip) O testador pode evitar problemas ao iniciar o teste, antes
que os recursos sejam definidos.
Os resultados do teste automatizado podem ser visto muitas vezes ao dia
Fornecendo um feedback rpido aps qualquer alterao.
A atmosfera fortemente orientada a equipe (John Overbaugh) Cada
membro da equipe se preocupa em terminar os testes e no somente o
cdigo (Lisa Crispin).
O testador pode ocasionalmente ajustar o defeito (Lista Crispin) Cada
membro da equipe sente-se mais confortvel j que o teste
automatizado.
Fornece a oportunidade para revisar constantemente as prticas de teste
(Adam Knight) Ao invs de simplesmente repetir o que foi feito
anteriormente, as prticas so constantemente revistas. No caso de Adam
os testes que costumavam levar 5 dias para serem executados
manualmente foram reduzidos agora para 30 minutos.
Eu gasto muito, muito menos tempo debugando(Adrian Howard) Eu
tenho o feedback quase ao mesmo tempo em que cometi um erro, por isso,
geralmente trivial localizar e corrigir.
H chance de realmente impactar na qualidade ao invs de somente
document-la! (Jonh Overbaugh) Quando os defeitos so corrigidos
imediatamente ao invs de colocar numa pilha de defeitos.
Sempre existe tempo para testar, porque o teste feito primeiro- Josue
Barbosa dos Santos contou a histria de trabalhar num escritrio do

governo no Brasil onde a prtica era testar no final do projeto. O
desenvolvimento estava sempre atrasado no cronograma do projeto,
atingindo o prazo limite e sendo liberado para os usurios sem teste. Com a
introduo das tcnicas de TDD e ATDD pelo menos algum teste era
executado enquanto o software era desenvolvido.
Concluso
Os benefcios proporcionados pela aplicao de teste gil tendem a ser
extraordinrios quando explorados da forma correta, com as prticas e
tcnicas corretas, e sob a anlise correta dos recursos, infraestrutura,
ambiente, frameworks e ferramentas a serem utilizados e aplicados no ciclo
de vida de desenvolvimento do software.
A sistemtica de teste aplicada tende a ser mais ousada e dinmica,
fornecendo feedback constante a equipe de desenvolvimento, que passa a se
comprometer tambm com a qualidade do produto final, por meio da
implementao de testes de unidade (TDD).
comum ao se aplicar teste gil, confundir o conceito de "agilidade" com
"rapidez", quando na realidade est atrelado "qualidade" e "integridade"
dos artefatos finais entregues. Ao se aplicar uma abordagem gil, as iteraes
tendem a ser menores, assim como as entregas tendem a ser efetuadas em um
curto prazo de tempo, no entanto cabe a equipe de teste em conjunto com as
demais reas garantir a consistncia e qualidade final do produto gerado,
assim como a satisfao do cliente diante das suas expectativas. Isso pode ser
feito de vrias formas, inclusive atravs da adoo das prticas de TDD e
ATDD.
Em cada projeto desenvolvido, pode-se observar um conjunto de variveis que
influenciam diretamente nas decises tomadas antes, durante e aps o
projeto, muitas vezes a favor e outras vezes contra a adoo de abordagens
geis de desenvolvimento. No entanto o que se pode observar, que "teste
gil" uma realidade vivel que pode extrair o melhor da equipe e do
processo aplicado, fornecendo retorno imediato e a curto prazo diante da
sistemtica de teste adotada.
FOWLER, Martin; HIGHSMITH, Jim. The Agile Manifesto. SD Magazine. Agosto,

2001. Disponvel em: <http://andrey.hristov.com/fhtstuttgart/The_Agile_Manifesto_SDMagazine.pdf>. Acessado em: 02/02/2010.
HENDRICKSON, Elisabeth. Agile QA/Testing. Quality Tree Software, Inc.
Novembro, 2006. Disponvel em: <http://testobsessed.com/wordpress/wpcontent/uploads/2006/11/agiletesting-talk-nov2006.pdf>. Acessado em:
10/02/2010.
BECK, Kent. Test Driven Development: By Example. 1. Ed. Addisson-Wesley
Professional. Novembro, 2002. 240 p.
Extreme Programming: A Gentle Introduction. Disponvel em:
<http://www.extremeprogramming.org/>. Acessado em: 11/02/2010.
BOEHM, Barry. Balancing Agility and Discipline: A Guide for the Perplexed.
Boston, MA: Addison-Wesley, 2004. pp. 55-57.
InfoQ: Top 10 Motivos para Amar Teste gil. Disponvel em: . Acessado em:
28/02/2010.
HENDRICKSON, Elisabeth. Driven Development with Tests: ATDD and TDD.
Quality Tree Software, Inc. Agosto, 2008. Disponvel em:
<http://testobsessed.com/wordpress/wpcontent/uploads/2008/12/atddexample.pdf>. Acessado em: 08/03/2010.
Captulo 8: Quando
Automatizar?
Fabrcio Ferrari de Campos
Introduo
A automao vem desempenhando um importante papel no progresso da
sociedade, e isso tem ocorrido tanto para o bem quanto para o mal. Por
exemplo: graas automao foi possvel a produo em srie de carros, mas a
mesma fez com que houvesse demisses em massa de funcionrios em pocas
de sazonalidade baixa no mercado automobilstico, j que o volume de
produo maior do que o de venda.
No entanto, neste captulo no iremos abordar a automao no contexto
automobilstico e sim no contexto de Teste de Software, uma das principais
reas da Engenharia de Software e onde a automao costuma ser um grande
desafio, uma vez que pode contribuir para o progresso do projeto, como
tambm, se usada de forma inadequada, ter o efeito reverso e causar vrios
problemas.
Automao no Teste de Software

A automao vem aos longos dos anos ganhando um papel importante na
rea de Teste de Software. E isso se deve a uma srie de fatores, dentre os
quais podemos destacar:
Diminuio do uso de mo de obra;
Diminuio dos custos;
Aumento na velocidade do processo de Teste de Software;
Maior sustentabilidade da garantia da qualidade, perante o tringulo da
gerncia de projeto (escopo, tempo e dinheiro).
Podemos utilizar a automao em qualquer fase do Teste deSoftware, como
especificao de casos de teste, gerao de mtricas de testes, execuo de

testes, montagem do ambiente, etc.
Porm, importante salientar que a automao costuma ser um passo a ser
dado, apenas aps j termos um processo de Teste de Software bem
estruturado e uma equipe preparada, pois ela muitas vezes exige um alto
conhecimento tcnico, principalmente para alguns tipos de testes especficos
(que sero abordados mais a frente) e um esforo que precisa ser apoiado
por um processo maduro.
Em frente aos fatores citados anteriormente, tentaremos nas prximas
pginas esclarecer melhor a automao no Teste de Software, pois tais fatores
costumam ser mal interpretados, causando muitos problemas e o surgimento
de falsas expectativas e impresses.
Quando automatizar?
Atualmente existem boas ferramentas (tanto livres quanto proprietrias) que
podem nos auxiliar em diversas atividades do processo de Teste de Software,
desde a reviso de documentos, at a execuo de testes de desempenho.
Muitas vezes, sente-se a necessidade de ferramentas para automao de
testes, quando acabamos despendendo muito tempo, por exemplo: criando
ou formatando casos de teste, gerando mtricas de testes, etc.
Ao pensar na automao dos testes, no podemos esquecer da automao
dos testes unitrios e integrados, que geralmente, so feitos pelos
desenvolvedores e que j costumam ser executados de forma automatizada.
O problema que a prtica de criao de testes unitrios e integrados no
muito comum, no mbito do desenvolvimento de software, mesmo tendo
resultados bem expressivos quando implantada.
Neste caso, a automao deve iniciar logo que a primeira linha de cdigo for
escrita, ou at mesmo (de preferncia), antes mesmo da elaborao da
primeira linha de cdigo, como prope a tcnica TDD (Test-driven
development).
Ao pensar em automatizar os testes de sistema, precisamos estudar a
viabilidade da automao, quer dizer, se com a automao conseguiremos:
Ganho de tempo;
Reduo de custos;
Manter a qualidade.
A maior dificuldade est em conseguir medir a viabilidade da automao, pois
necessrio analisar vrios fatores, dentre eles:

A maturidade do time e do processo de Teste de Software;
O grau de reutilizao dos testes automatizados;
O nvel de capacitao das pessoas para operar o software, ou manter o
software, nos cenrios em que a ferramenta ouscript foi desenvolvido pelo

prprio time;
O conhecimento acerca do comportamento que se espera do sistema a ser
testado;
O tempo disponvel para automatizao dos testes. Lembre-se que a
automao um investimento a mdio e longo prazo;
O grau de frequncia de mudanas das funcionalidades a serem verificadas,
pois em alguns casos, pode no ser vivel automatizar um teste de uma
funcionalidade que ir mudar amanh (embora isso no seja uma verdade
absoluta, pois h excees);
A testabilidade do sistema. Em alguns cenrios necessrio realizar
alteraes no cdigo para que seja possvel a automao dos testes. Isto
ocorre de forma mais frequente, em sistemas legados, nos quais no houve
uma preocupao com a testabilidade do sistema e o desenvolvimento no
utilizava tcnicas que favorecem uma boa testabilidade, como por
exemplo, o TDD;
A garantia de que com a automao do teste, poderemos alcanar a
mesma qualidade da execuo manual do teste;
Aumentar a cobertura dos testes, uma vez que com os testes
automatizados, a equipe pode ganhar tempo para elaborar testes mais
complexos e assim, tornar o processo de Teste de Softwaremais eficiente,
em relao ao tempo e qualidade, j que ser possvel prover um feedback
mais rpido aos desenvolvedores e garantir uma maior qualidade do
sistema sob teste.
Quais so as razes para automao dos

testes?
No livro Agile Testing, da Lisa Crispin e da Janet Gregory, so citadas as
seguintes razes:
Teste manual demorado;
Reduzir a probabilidade de erros das tarefas de teste;
Liberar tempo para fazer o trabalho da melhor forma;
Prover uma rede de segurana ( se eu fizer uma mudana no cdigo eu
terei os testes, que iro me avisar se eu quebrei algo);
Prover feedback cedo e frequente;
Os testes que direcionaro a codificao (utilizando tcnicas como o TDD e
BDD) podem fazer mais do que isso (ex.: se tornam testes de regresso);
Os testes provem documentao, alis, so uma excelente documentao;
ROI, com o passar do tempo o esforo gasto na automao dos testes se
paga.
Um dos grandes benefcios da automao prover feedback cedo e frequente,
e isso possvel, principalmente com a automatizao dos testes unitrios e
integrados (que iremos ver com mais detalhes no prximo tpico), geralmente
realizados pelos desenvolvedores. Ou seja, quando falamos de automao de
testes, no estamos falando apenas da rea de Teste de Software, mas sim em
prticas que devem ser comum no desenvolvimento de software como um
todo.
Essa uma prtica que pode ser utilizada em qualquer metodologia e no
demanda de um grande investimento financeiro, pois boa parte das
ferramentas que auxiliam esses nveis de testes, so softwares livres, como por
exemplo: o JUnit para criao de testes unitrios em Java.
Podemos perceber pelas razes citadas que a automao dos testes pode ser
uma boa escolha, frente ao teste manual, porm como vimos anteriormente,
precisamos analisar vrios fatores, antes de partir para a automao.
Quais tipos de Testes devem ser
automatizados?
Quando tomamos a deciso de iniciar a automao na execuo dos testes,
bom avaliar quais testes sero automatizados primeiro. De acordo com o Elias
Nogueira, j h certos tipos de testes que sofrem uma tendncia a automao,
sendo eles:
Testes de regresso;
Smoke Tests;
Tarefas repetitivas;
Funcionalidades crticas do software;
Testes com clculos matemticos.
H outros testes que devido grande dificuldade de sua execuo de forma
manual, a automao torna-se praticamente essencial:
Teste de performance;
Testes unitrios e integrao.
Patrick Wilson-Welsh fez uma boa metfora usando a pirmide de Mike Cohn,
que nos ajuda a explicar, quais tipos de testes devem ser automatizados,
tendo em vista o custo de se manter os testes. No topo, temos os testes de
palha so aqueles que testam o sistema de forma caixa-preta, por meio da
interface. No meio temos os testes de madeira que no so por meio da
interface, mas tipicamente testam muito mais do sistema, do que os nossos
testes de unidade. E na ltima camada temos os testes dos programadores:
testes unitrios que verificam partes do nosso sistema, de forma isolada.
Figura 8.01 - Pirmide da Automao (patrickwilsonwelsh.com, 11 de abr.

2010)
O interessante dessa pirmide, que ela costuma ser invertida em equipes
tradicionais (no geis), pois geralmente a automao surgi como uma
necessidade da equipe de Teste de Software, por conta dos testes de
regresso.
Mas como podemos perceber com a metfora do Patrick, precisamos apoiar a
automao dos testes em uma base slida, e essa base slida, s pode ser
construda com criao de testes unitrios. E isso explica porque importante
pensar em testes sempre, testar no uma atividade que deve ser realizada s
no final, ou por apenas uma rea.
Alinhamento das expectativas

Bret Pettichord diz em seu artigo Seven Steps to Test Automation Success,
que devemos tratar a automao dos testes da mesma forma que tratamos
qualquer outro projeto. De acordo com o Bret, se iremos desenvolver um
software para auxiliar a automao ser necessrio:

Melhorar o processo de Teste de Software;
Definir os requisitos;
Realizar uma prova de conceito;
O produto deve ser o melhor em testabilidade;
Realizar a modelagem com foco na sustentabilidade;
Elaborar o plano de implantao;
Enfrentar os desafios do sucesso.
J se iremos adquirir um software para auxiliar a automao sero necessrias
outras aes, como por exemplo:
Levantar as ferramentas existentes no mercado, tanto as comerciais quanto
as gratuitas;
Avaliar qual ferramenta atende melhor s suas necessidades. Muitas
ferramentas possuem verses de demonstraes, com avaliao em
perodos determinados (p. ex.: 30 dias);
Capacitar as pessoas que iro utilizar osoftware. Infelizmente, ainda h
pessoas que pensam que iro comprar uma ferramenta e as pessoas vo
sair usando e tirando os melhores resultados, ledo engano, pois a
ferramenta pode acabar ficando na "prateleira", caso as pessoas no sejam
capacitadas;
Envolver toda a equipe de teste, desde o levantamento das ferramentas
existentes no mercado.
Mark Fewster e Dorothy Graham, lembram em seu livro "Software Test

Automation - Effective use of test execution tools", que h uma expectativa de
que os testes automatizados iro encontrar diversos novos defeitos. Porm,
mais provvel que um teste encontre um defeito, na primeira vez que ele
executado, e geralmente, a primeira execuo manual. E se o teste j foi
executado e passou, muito menos provvel que uma nova execuo do
mesmo teste encontre um defeito, ao menos que o teste execute um cdigo
que foi mudado ou poderia ser afetado por uma mudana realizada em uma
parte diferente do software, ou ainda executando o teste em um ambiente
diferente.
Portanto importante saber que vrias ferramentas de execuo de testes so
ferramentas de "repetio", ou seja, ferramentas de teste de regresso. Elas
so usadas para executar testes que j foram executados. E isto muito til,
mas o objetivo principal destes testes no encontrar novos defeitos, e sim
nos d confiana de que o software est funcionando da mesma forma de
antes.
Uma expectativa errnea, que s vezes ocorre quando iniciamos a
automatizao dos testes, a de que teremos que ter 100% dos testes
automatizados e isso faz que as pessoas busquem uma meta que muitas vezes
no coerente.
Dificilmente iremos utilizar apenas uma ferramenta para automatizar os
testes. Por exemplo: se iremos testar uma aplicao Web podemos
automatizar os testes funcionais com o Selenium, j os testes de performance
podemos automatizar com o JMeter.
importante ter em mente, que o projeto de automao no dar resultados
do dia para a noite. Alis, bem pelo contrrio, pois como j dito, a automao
um investimento a mdio e longo prazo.
Como vimos anteriormente, a automao essencial para alguns tipos de
testes, porm para outros tipos de teste, como por exemplo, testes de
usabilidade, ela no vivel.
Alm disso, a automao no deve ser medida pela quantidade de casos de

teste que foram automatizados, mas sim por quais testes foram
automatizados e quanto tempo foi ganho com a automao. Em

determinadas circunstncias, pode at ser possvel obter bons ganhos mesmo
com apenas 10% dos testes automatizados. Por isso importante saber o que
ser necessrio automatizar e o que mais prioritrio. Automatizar apenas
por automatizar costuma ser uma pssima ideia.
Automao no contexto gil

A automao dos testes est entre as principais prticas geis, uma vez que as
metodologias geis focam em entregas pequenas e curtas e que devem ter
valor para o cliente.
E como garantir a qualidade de uma entrega que feita em duas semanas,
por exemplo?Por isso que a automao dos testes uma prtica
imprescindvel no desenvolvimento gil, pois ela que ir ajudar o mesmo a se
tornar sustentvel, j que no possvel realizar ciclos curtos de entrega se
tivermos que orar um ciclo de teste manual.
necessrio poder executar os testes vontade e de forma rpida (segundo o
livro Agile Testing, 10 minutos), para obter feedback a respeito da qualidade
do cdigo. Voc precisa escrever e executar os testes junto com o sistema
sendo desenvolvido, para encurtar o ciclo de comunicao com o cliente e no
perder tempo e esforo com mal-entendidos.
Os quadrantes de Brian Marick (figura 2) ilustra a nfase da automao em
agile. Mesmo para os testes do quadrante superior direito (crtica do produto
/ voltados ao negcio) possvel ser auxiliado por ferramentas de automao.
Em outros quadrantes, no se descarta o teste manual. Na prtica, apenas os
testes de unidade (quadrante inferior esquerdo) so inviveis sem automao
e os testes do quarto quadrante so executados com o auxlio de ferramentas,
muitos deles realizados de forma automatizada, como por exemplos os testes
de desempenho.
Figura 8.02 - Quadrante do Teste gil (Agile Vancouver, 7 de mar. 2010)

bom lembrar que no modelo de Teste gil, testes so pensados no apenas
como mecanismo de deteco de defeitos, mas que tambm analisado seu
papel de especificao do comportamento do sistema e suporte equipe de
desenvolvimento. Requisitos, testes e exemplos so aspectos diferentes das
mesmas especificaes.
Indo mais a fundo no papel da automao dos testes no contexto gil, por
meio do quadrante do Marick, podemos notar os seguintes pontos a respeito
de cada quadrante:
Q1: aqui entram os testes unitrios e de integrao, geralmente so feitos
pelos desenvolvedores, mas os profissionais de Teste de Software podem
participar da elaborao deles, por exemplo: programando em par com o
desenvolvedor, quando o mesmo for criar os testes;
Q2: os testes so realizados preferencialmente de forma automatizada,

porm a automao pode no ser vivel e ento os testes podem ser
realizados de forma manual. Neste quadrante os testes tem dois objetivos:
validar o sistema com base no negcio e tambm d suporte ao time de
desenvolvimento, pois alguns testes, como os funcionais podem ser
desenvolvidos antes mesmo da funcionalidade e assim podero ajudar o
desenvolvedor na modelagem do cdigo, e futuramente, podero entrar
na sute de testes de regresso do processo de integrao contnua;
Q3: os testes so executados de forma manual, devido aos objetivos dos
testes e pessoas que esto executando-os;
Q4: abrange testes mais especficos ligados a requisitos no-funcionais, e
geralmente s podem ser realizados com o apoio de uma ferramenta,
como o caso do teste de desempenho. Alm disso, em alguns casos se faz
necessrio a participao de um especialista, para poder realizar tais testes
de forma efetiva, por exemplo, contratando um profissional da rea de
Segurana da Informao, para auxiliar nos testes de segurana.
Kent Beck, criador do XP e do TDD, tem uma postura bem radical, em relao
aos testes automatizados:
"Qualquer funcionalidade que no possui testes automatizados

simplesmente no existe."
A viso de Kent Beck pode at parecer radical demais, mas os testes tem um
papel fundamental em um ambiente gil, e os ciclos curtos exigem que eles
sejam automatizados, sempre que possvel.
Duas prticas fortemente difundidas com o surgimento de metodologias geis
o TDD e o ATDD. O primeiro que sigla para Test-Driven-Development
(Desenvolvimento Orientado a Testes), e como o prprio nome j sugere, a
ideia fazer que desenvolvedor desenvolva o sistema sendo guiado pelos
testes, ou seja, os testes no so propriamente o objetivo dessa prtica e sim o
desenvolvimento do sistema de uma forma sustentvel, que favorecer a
manutenbilidade e testabilidade do mesmo.
J o ATDD do ingls Acceptance Test Driven Development (Desenvolvimento
Orientado a Testes de Aceitao) faz com que o desenvolvedor desenvolva o

sistema focado no negcio, utilizando testes de aceitao que validem o
comportamento esperado do sistema. Esses testes de aceitao so criados,
geralmente, com a participao do cliente e do analista de teste. A gerao de
tais testes faz com que seja gerada uma "documentao viva" do sistema, uma
vez que a sua execuo costuma ser feita de forma automatizada, por meio de
ferramentas como o Fitnesse, por exemplo.
Ambas as prticas so utilizadas antes do desenvolvimento do cdigo, afinal o
objetivo que elas possam orientar e ajudar o desenvolvedor no processo de
codificao. O grande ganho de tais prticas, que utilizando elas o
desenvolvedor tem um melhor entendimento sobre o sistema, sem ter escrito
sequer uma linha de cdigo e os testes que foram criados com o propsito de
auxiliar a modelagem do sistema podero ser utilizados como testes de
regresso, garantindo assim a corretude do sistema e facilitando futuras
mudanas, uma vez que no haver o medo de quebrar algo, j que temos
uma rede de segurana, os testes automatizados.
Concluso
A automao est longe de ser a bala de prata para o Teste deSoftware, mas
pode trazer benefcios significativos para o projeto, quando utilizada
adequadamente dentro do mesmo. Precisamos execut-la de forma
incremental, sempre analisando quais testes que se automatizados traro
maior benefcio equipe.
Automatizar os testes no algo simples, e diversas premissas so necessrias
para que possamos trazer todos os benefcios da automao, pois caso
contrrio, ela ir trazer mais problemas. importante ter em mente que
quando partimos para a automao, no podemos esquecer das pessoas e do
processo, afinal como diz um velho ditado: Tolos com ferramentas ,
continuam tolos.
Quando trabalhamos com ciclos curtos de entrega, a automao de testes
torna-se essencial para conseguirmos garantir a qualidade do software que
est sendo desenvolvido. Essa necessidade fez surgir vrias ferramentas
voltadas para a automao dos testes, boa parte delas distribudas de forma
gratuita.
Por fim, a resposta para a pergunta Quando automatizar?, s pode ser
obtida por cada um, pois os fatores que podem influenciar a deciso pela
automao podem variar muito de empresa para empresa. A inteno desse

captulo foi colocar em foco os desafios, caractersticas e fatores ligados a
automao de teste, que aponta para ser uma das principais tendncias na
rea de Teste de Software nessa nova dcada.
BASSI, Dairton; CHEQUE Paulo. Testes Automatizados. Cursos de Vero 2007 IME/USP. Disponvel em: <http://ccsl.ime.usp.br/agilcoop/files/2-Testes.odp>
Acessado em: 05/02/2010
PETTICHORD , Bret. Seven Steps to Test Automation Success. Disponvel em:
<http://www.io.com/~wazmo/papers/seven_steps.html> Acessado em:
05/02/2010
WELSH, Patrick. Flipping the Automated Testing Triangle: the Upshot.
Disponvel em: < http://patrickwilsonwelsh.com/wp-includes/class-read.php?
fn=99fec55bf96d4a2bfad2f6718ab0a1e83bf11f08&sid=9&sb=wpnews>
Acessado em: 11/04/2010
Gregory, Janet. Focus Your Testing Using the Agile Testing Matrix. Disponvel
em:
<http://agilevancouver.ca/sites/agilevancouver/files/speakerslides/Vancouve
r-Quadrants.pdf> Acessado em 07/03/2010
CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and
Agile Teams. 1 ed. Addison-Wesley Professional. 2009.
FEWSTER, Mark; GRAHAM, Dorothy. Software Test Automation - Effective use
of test execution tools. Addison-Wesley Professional. 1999.
Captulo 9: Estimativas de
Testes (APT)
Fabrcio Ferrari de Campos e Karine Birnfeld
Introduo
A Anlise de Pontos de Teste (APT) uma tcnica de medio para a rea de
Teste de Software, baseada na tcnica de medio de Anlise de Pontos de
Funo (APF).
Ela utiliza como base, o tamanho do sistema em pontos de funo, oriundos
da aplicao da APF, considerando todas as suas funcionalidades.
A APT aplica-se apenas aos testes de caixa preta, visto que para as demais
tcnicas de teste (caixa branca, por exemplo), as estimativas j esto includas
na tcnica de APF.
A tcnica de APT pode ser utilizada quando existem horas de teste prdeterminadas, pois alguns riscos envolvidos podem ser identificados
comparando o tempo de testes estimados com APT com o tempo de testes
pr-determinados. Com a APT, possvel determinar ou calcular o real valor
das funes do sistema, com o objetivo de utilizar o tempo da equipe de testes
o mais eficientemente possvel .
Porm, em torno das estimativas em geral e da APT em especfico giram
algumas dvidas como, por exemplo, as dificuldades encontradas para
implantar esta tcnica de estimativa, as vantagens e custo-benefcio bem
como pr-condies e dados necessrios para sua implantao.
Importncia das Estimativas x Controle

Estimar uma atividade que pode ser de grande valia no planejamento,
gerenciamento e controle dos projetos. Porm, antes de estimar, necessrio
saber por que ser estimado, ou seja, qual a finalidade de cada estimativa e
como ela ser utilizada. Estimativas devem existir, principalmente, para
melhorar o processo de planejamento e controle e no servir como uma forma
de cobrana de profissionais, ou aplicado, apenas porque dizem que estimar
importante.
Segundo o Robson Agapito, atualmente as estimativas so extremamente
importantes para fazer previses mais certeiras, montar cronogramas, prever
recursos e custos necessrios. Caso no existam estimativas, ser mais difcil
acompanhar o andamento do projeto, no sendo possvel fazer um
acompanhamento efetivo a partir do cronograma. realmente muito difcil
planejar sem estimar, mas bom ter conscincia de que estimar no
adivinhar o futuro, ou seja, no porque existem estimativas que o
planejamento ser exato, como disse o Fabrcio Campos.
Planejar diferente de controlar. Estimativas so muito importantes para
planejar o esforo necessrio para as atividades do projeto, que
consequentemente, com um planejamento mais coerente, facilitar o controle
e acompanhamento do projeto.
No impossvel controlar algo sem medir, ou melhor, no regra, que para
controlar necessrio sempre medir. Como o prprio autor da frase (Tom
DeMarco), disse recentemente: a ideia de que controle seja talvez o mais
importante aspecto de um projeto de software. Mas no . Muitos projetos
foram realizados quase sem controle e produziram produtos maravilhosos,
como o Google Earth ou o Wikipedia. (traduo do Jos Papo).
Segundo o Fabrcio Campos, medir apenas uma das formas de controlar.
Porm, no uma tarefa to simples, e nem sempre a mais importante para
uma determinada realidade.
Anlise de Ponto de Teste (APT)

O tamanho do sistema a ser testado, medido atravs da tcnica de APF, a
base da APT. Alm do tamanho do sistema, existem outros fatores que devem
ser considerados para estimar a atividade de testes de software.
Na APT existem trs elementos relevantes: o tamanho do sistema a ser
testado, a estratgia de teste (seleo de componentes do sistema e
caractersticas de qualidade a serem testadas e a cobertura dos testes) e o nvel
de produtividade. O primeiro e o segundo elemento determinam o volume do
trabalho de teste empreendido (expresso em pontos de teste). Se o nmero de
pontos de teste for multiplicado pela produtividade (o tempo total para
realizar determinado volume de testes) possvel obter a estimativa de testes
em horas .
A importncia da utilizao de uma tcnica de medio especfica para testes
de software se deve ao fato da maioria das outras tcnicas embutirem o
esforo de testes no esforo de desenvolvimento, perdendo-se alguns detalhes
que precisam ser considerados para estimar os testes de software de forma
mais eficiente.
No livro Base de Conhecimento em Teste de Software, do Anderson Bastos,
Emerson Rios, Ricardo Cristalli e Trayah Moreira, so citados os seguintes
fatores que afetam os testes:
O grau de complexidade do processo de teste;
O nvel de qualidade que se pretende alcanar com os testes;
O grau de envolvimento dos usurios com os testes;
As interfaces que as funes testadas tm com os arquivos;
A qualidade do sistema testado (o ciclo de reincidncia de defeitos);
O nvel de cobertura esperado com os testes;
A experincia e a produtividade da equipe de testes (medidos atravs de
indicadores histricos);
O grau de automao dos testes;
A qualidade do ambiente de teste, at mesmo sua capacidade de simular o
ambiente de produo;
A qualidade da documentao do sistema e, em especial, dos requisitos;
A Figura 9.01 ilustra a viso geral do modelo de APT.
O nmero de pontos de teste necessrios para os testes dinmicos calculado

para cada funo com base no nmero de pontos de funo atribudos
funo, os fatores funes dependentes (complexidade, interfaces,
uniformidade, importncia do usurio e intensidade de uso) e a qualidade dos
requisitos relacionados ou a estratgia de teste para as caractersticas de
qualidade dinmica. A soma destes pontos de teste atribudos a cada funo
o nmero de pontos de teste dinmico.
O nmero de pontos de teste esttico para medir as caractersticas de
qualidade calculado com base no nmero total de pontos de funo para o
sistema e a qualidade dos requisitos ou estratgia de teste para as
caractersticas de qualidade estticas. Isto resulta no nmero de pontos de
teste esttico.
O total de pontos de teste a soma dos pontos de teste dinmico e esttico. O
nmero de horas de teste primrias pode ser calculado multiplicando o

nmero total de pontos de teste pelos fatores ambiente de teste e
produtividade. As horas de teste primrias representam o volume de trabalho
envolvido nas atividades de teste primrias, como por exemplo, o tempo
necessrio para as fases de Preparao, Especificao, Execuo e Concluso.
Finalmente, o total de horas de teste obtido adicionando subsdio para as
atividades de teste secundrias (Planejamento e Controle) ao total de horas
primrias. O tamanho deste subsdio, que representa o volume de trabalho
envolvido nas atividades de gerenciamento, dependem do tamanho do time
de teste e da disponibilidade de ferramentas de gerenciamento. O total de
horas de teste uma estimativa requerida para todas as atividades de teste,
excluindo a elaborao do plano de teste.
Conforme mencionado no livro Base de Conhecimento em Teste de Software ,
a transformao do tamanho em esforo precisa de um trabalho adicional de
calibragem, que demandar algum tempo at que as informaes histricas
estejam disponveis.
Utilizao da APT no Brasil

Pela discusso realizada no grupo DFTestes, a maior e mais ativa lista da
comunidade de Teste de Software brasileira, percebeu-se que a tcnica APT
pouco utilizada na realidade brasileira de Teste de Software.
Essa constatao pode levar a vrias interpretaes, mas importante
salientar que a realidade brasileira diferente da Europia, onde a tcnica
mais popular. Alm do mais, a cultura brasileira tambm, o que faz com que
os profissionais busquem outras solues para suprir a necessidade de
medio para a rea de teste.
O Robson Agapito ainda ressaltou que para projetos fechados a utilizao do
APT mais produtiva do que para projetos de manuteno de um software.
Muitos dizem tambm que o APT para projetos grandes, pois o PF inicial
para se utilizar o APT de 500 PF (o que equivale para muitas empresas em
mais de 2000 horas no projeto) e no qualquer projeto que tem este
tamanho.
Outras formas de estimar
Frente ao pouco uso da APT no Brasil, procurou-se levantar durante a mesa

redonda, como feita a estimao na prtica.
Percebeu-se que podemos estimar utilizando diversas tcnicas e de formas
diferentes, desde utilizando as reunies do mtodo Delphi at mesmo a
utilizao de tcnicas de diviso de tempo em caixas de tempo, como por
exemplo utilizando a tcnica de Pomodoro.
De acordo com Eduardo Gomes, o fato que estimar no tem muito valor se
no se constroem bases histricas. S ser possvel comprovar a efetividade
das estimativas quando tivermos bases histricas que contribuam para os
ajustes necessrios nos modelos e para a utilizao com maior segurana dos
resultados das estimativas. Antes disso, continua sendo chute. Mas talvez um
chute calibrado; um ponto de partida pelo qual temos que passar.
importante ter em mente que no h uma frmula mgica que ir te dizer
como estimar, por isso importante experimentar mtodos e tcnicas
diferentes, e ir adaptando a realidade. Lembrando-se que para uma boa
estimativa, importante possuir experincia naquilo que ser medido, seja
por meio da prpria experincia das pessoas, ou utilizando-se de bases
histricas.
Concluso
Estimar o tempo uma atividade importante para um bom planejamento e
gerenciamento do projeto de teste. A APT e uma tcnica madura e focada na
estimativa de tempo para a rea de Teste de Software.
Todavia, preciso analisar e avaliar a APT, perante a realidade do projeto no
qual ela ser aplicada, pois h pr-requisitos que caso no tenhamos, poder
ocasionar um mau uso de tal tcnica e acabar resultando em mais problemas,
do que solues com a sua aplicao.
A realidade do mercado brasileiro de Teste de Software diferente da de
outros pases, seja por questes econmicas ou culturais, portanto se faz
necessrio um esforo de adaptao, ao se optar por usar determinada tcnica
para estimar os esforos de testes.
Tcnicas acopladas fortemente a pessoas, como por exemplo o planning
poker e pomodoro, podem ser revelar um bom incio para a atividade de
estimar, principalmente, devido ao fato que estimar envolve pessoas e muitas
vezes estimamos um trabalho criativo, que possui variveis muito inconstantes

e subjetivas.
Por fim, importante buscar arquivar uma base histrica desde o primeiro dia
do projeto, pois ela costuma ser uma boa fonte para a atividade de estimar e
ao longo do projeto a estimativa acaba sendo mais efetiva, pois uma maior
experincia provoca domnio sobre estimativas de determinada realidade
Kusters R., A Cowderoy, F. Heemstra and E. van Veenendaal
(eds).Testpointanalysis: a method for test estimation. Disponvel em:
<http://www.erikvanveenendaal.nl/UK/files/Testpointanalysis a method for
test estimation.pdf> Acessado em: 04/07/2010
Bastos, A., et al. (2007) Base de Conhecimento em Teste de Software. So
Paulo, Martins Fontes, 2 Edio.
Captulo 10: MPT.BR

Melhoria do Processo de
Teste Brasileiro
Ueslei Aquino da Silva
Revisora: Carla Regina Florentino Sampaio
Introduo
Na dcada de 60, os softwares eram desenvolvidos com baixo nvel
tecnolgico e ficavam a cargo dos analistas e programadores. O foco nesse
momento era apenas demonstrar que o software estava funcional. medida
que a tecnologia evolua, softwares mais sofisticados eram desenvolvidos,
impactando diretamente na realizao dos testes que, desta vez, se
focalizavam: (1) na deteco dos defeitos; (2) nos erros e deficincias
existentes no software; (3) na definio das capacidades e limitaes e (4) no
fornecimento de informaes sobre a qualidade dos componentes, sistemas e
outros produtos. Mas, o grande problema neste momento estava em quem
realizava tais processos, pois eram realizados pelos prprios usurios e
testadores sem experincia. Apesar de desde a dcada de 70 j existirem
trabalhos mostrando que o teste precisava ser re-estruturado, (Em 1979
Glenford Myers publicou aquele que atualmente ainda considerado um dos
melhores livros de Teste de Software existentes no mercado, sob o ttulo de
The Art of Software Testing -publicado por John Wiley and Sons Inc. em
edio revisada em 2004) foi a partir da dcada de 90 que o Teste de Software,
enfim, recebe um novo olhar. Os holofotes agora esto sob a perspectiva da
preveno. Assim como comprovado por Myers, quanto mais cedo encontrar e
corrigir um defeito, mas barato se torna para empresa. Desta forma, inspees
so realizadas nos artefatos do software, possibilitando a deteco e reduo
de defeitos logo nas fases iniciais do desenvolvimento.
Com a sofisticao dos softwares, processos de maturidade no

desenvolvimento de software foram criados para se garantir cada vez mais a
qualidade do produto. Em consequncia, Processos de Teste surgiram para
atribuir uma melhoria contnua aos servios de teste. Atualmente vrios so os
processos destinados a Teste de Software. Citando alguns deles temos :
Testability Support Model (TSM);
Testing Maturity Model (TMM);
Test Process Improvment (TPI), entre outros.
Alguns desses modelos tiveram origem a partir de um modelo de processo de
software, como por exemplo o TMM, cuja base original o CMM.
Desenvolvimento
Antes mesmo de entrar no cerne da discusso da 5 mesa-redonda do
DFTestes, cujo tema foi MPT.BR (Melhoria do Processo de Teste Brasileiro) e
apresentar as opinies dos participantes da mesa, vou de forma breve
explanar o que vem a ser o MPT.BR
Tendo como fundamento toda histria em torno de Teste deSoftware e a
realidade do mercado brasileiro de desenvolvimento de software, a ALATS em
parceria com a RioSoft do incio ao desenvolvimento do modelo chamado de
MPT.BR (Melhoria do Processo de Teste Brasileiro), modelo de maturidade de
processo de teste compatvel com o MPS.BR e o CMMI. Desta forma, empresas
que implementam MPS e CMMI podero, com pequeno esforo, aumentar e
comprovar o nvel de maturidade da rea de Teste de Software.
Conforme apresentado na Guia 1 do MPT:
O MPT voltado para a melhoria das reas de Teste de Software de empresas

de qualquer porte. O modelo leve e possvel de ser adotado por reas de
Teste de Software para apurar o seu nvel de maturidade, sem com isso onerar
os seus processos anteriormente implementados.
O objetivo principal ser garantir que reas de Teste de Software de tamanho
reduzido possam ser avaliadas e estimuladas a alcanarem nveis maiores de
maturidade, sem que para isso tenham que incorrer em altos custos
operacionais.
O Guia de implementao do MPT.BR est subdividido em nveis de

maturidade, a exemplo do MPS.BR e CMMI. O nvel um (1) contempla apenas a
rea de Gerncia de Projetos. O objetivo atender reas de testes de todos os
tamanhos, mesmo aquelas com nmero reduzido de profissionais.
O MPT.BR apresentado com uma estrutura de cinco (5) nveis de maturidade,
sendo o nvel 1 o mais baixo e o nvel 5 o mais alto. Na tabela 1, veremos como
esto subdivididas as reas de processo do MPT.BR.
reas de processo do MPT.BR :
Nvel 1
Gerncia de Projetos de Teste - GPT
Nivel 2
Gerncia de Requisitos de Teste - GRT
Nivel 3
Aquisio AQU (opcional)
Gerncia de Configurao GCO
Garantia da Qualidade - GQA
Medio - MED
Nivel 4
Gerncia de Recursos Humanos - GRH
Gerncia de Reutilizao - GRU (opcional)
Gerncia de Riscos - GRI
Nivel 5
Verificao - VER
Validao VAL
De forma a garantir a aderncia a uma das reas de processo do modelo, a
organizao dever implementar as prticas especficas e as prticas genricas,

que se aplicam a todas as reas de processo, correspondentes ao nvel de
maturidade visado. A avaliao de que a unidade de teste alcanou um
determinado nvel ser feita por meio da comprovao objetiva dos
resultados alcanados e do exame das evidncias (diretas, indiretas e
afirmaes) de que a empresa implantou cada uma das prticas especficas e
genricas para aquela rea de processo e grau de maturidade visado.
Desta forma, temos a seguinte organizao:
rea de processo
Prticas especficas
Objetivos genricos
Prticas genricas
Iniciando o Bate-Papo sobre MPT

A chegada do MPT ao mercado brasileiro traz novas oportunidades de
qualificao profissional para os interessados pela rea de processos e
tambm para as empresas que desejam melhorar sua rea de teste baseada
em nveis de maturidade.
Com esta to nova realidade, e em processo de gestao, no mercado de
Testes de Software brasileiro, algumas questes, quase que inevitavelmente,
so levantadas:
Ser certificado MPT vale pena?
Por que os selos de qualidade e melhoria, so to criticados hoje em dia,
principalmente pelos agilistas?
Qual a posio do mercado em relao s empresas certificadas?
Para uma empresa cujo core business no o Teste de Software,
interessante a certificao?
Com o objetivo de ajudar os profissionais de teste a pensar sobre as questes
colocadas, a equipe do DFTestes se rene em uma mesa redonda e partilha
opinies e conhecimentos sobre o assunto como segue:
Ser certificado MPT vale pena?
Os profissionais podero se certificar como implementadores e/ou avaliadores

do MPT e a meu ver, uma tima oportunidade para os profissionais que
gostam da rea de processo e/ou querem investir na rea obtendo um
diferencial de mercado.
Por que os selos de qualidade e melhoria so to criticados hoje em dia,
principalmente pelos agilistas?
Algumas experincias ouvidas sobre o MPS.BR, mostram que empresas
buscaram o selo apenas para serem melhor colocadas em licitaes. De incio,
a empresa aceita o investimento e passa por toda burocracia para
implementao do processo mas, depois que o avaliador vira as costas
engavetam toda documentao e volta vida normal. Implantar processo,
seguir prticas um tanto quanto burocrtico, se na organizao no tiver o
apoio da alta gerncia para que tudo seja seguido, mesmo sem a presena do
implementador e aps a certificao, nada funciona. Uma soluo adotada
pelo MPS.BR para resolver essa situao foi colocar prazo de validade nas
certificaes, ou seja, a cada 3 anos a empresa passa pelo processo de
reavaliao, se no se recertificar, sai da lista dos certificados em determinado
nvel.
Para o Shmuel Gershon, os agilistas no inventaram as crticas aos selos de
qualidade. As reclamaes so antigas, s olhar para as crticas ao ISO9000 e
ao Six Sigma.
Uma das limitaes de todos os processos uniformizados a uniformidade do
processo. Como ele esttico e uniforme, quem tem que se adaptar a
empresa e os empregados. Empresas no so uniformes, so compostas por
interaes no uniformes entre pessoas no uniformes.
Empresas so diferentes e programam softwares diferentes. O processo para
tratar de qualidade o mesmo em um produto web-based e embedded? Um
controlador de equipamento mdico e um administrador de contedo? Uma
empresa com 700 empregados e uma com 7?
O Shmuel certssimo em seus comentrios, mas quanto ao MPT.BR temos
uma nova perspectiva. Como explanado pelo objetivo do MPT, ele est sendo
preparado para reas de teste de todos os tamanhos, inclusive para reas de
teste de tamanho reduzido.
Para o Fabrcio Ferrari, o foco do MPT implica na f de que existem contextos
diferentes e o tamanho um dos parmetros uma boa novidade na rea de

estandardizao de processos, que tende a ver tudo com tamanho nico.
Por outro lado:
Tamanho da empresa um parmetro fraco sobre seu contexto;
Comumente empresas com tamanho reduzido sentem menos a falta de
processos do que grandes;
Comentrio implica que tamanho reduzido resulta em nveis menores de
maturidade.
Sobre a limitao citada pelo Shmuel, acredita-se que uma verdade, e o pior
como alguns profissionais encaram esses selos. Infelizmente, muitos ganham
os seus uniformes (adorei essa analogia) e percebem que ficam bonitinhos
com ele, da ento, a sua maior preocupao deixar o uniforme bem
limpinho.
Mas e o cliente? ahh ele ter uma primeira impresso muito boa da
empresa uniformizada, e como dizem a primeira impresso a que fica (ou
no). No entanto aps um tempo, o cliente vai perceber que as aparncias
enganam.
O mais importante para qualquer fornecedor atender bem o cliente, isso
to lgico. Selos, certificaes profissionais, entre outros so plus, primeiro
voc tem que comer o feijo com arroz, pra depois comer a sobremesa!
O Edwagney afirma ter o mesmo entendimento do Shamuel, alm de
compartilhar o material que est em (https://itqualityview.wordpress.com/),
Edwagney complementa dizendo que o ponto crucial de alguns processos de
qualidade, e processos em geral, no dar certo em algumas organizaes
que elas no lanam mo da sua cultura, da sua poltica, no usam o que tem
de melhor. No adaptam um determinado padro aos padres j existentes
na empresa.
Como experincia profissional adquiridas nas empresas por onde passou,
Edwagney relata que a questo era: Vamos implantar isso de qualquer
forma. Conhece o ditado: Top-guela-down? mais ou menos por a
Usar padres e processos faz parte da inovao e da melhoria da qualidade,
porm, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se
ganha usando o lado bom do conhecimento e cultura da empresa.
Para Shmuel Gershon em um primeiro momento, pareceria uma questo de

oferta e demanda. igual ISO9001 se a empresa vai perder mercado por
falta de certificao, ento certamente vale pena. Se a empresa consegue
manter diferenciao comercial sem o certificado, ento no vale pena.
Certo? O nico problema na situao descrita que no caso de uma
certificao sobre testes, quem cria a demanda so as prprias empresas
certificadas. Assim como nas certificaes de indivduos, existe tanta confuso
ao redor do que testes e testadores fazem que fcil apresentar uma
certificao e dizer Aqui oh, no se preocupe, ns somos certificados, por isso
somos melhores que a concorrncia. Ao criar a demanda, criamos um crculo
vicioso onde quem no se certifica fica pra trs. No fim das contas, se uma
empresa acredita que deve passar pelo processo de certificao, tudo bem,
mas com cuidado e delicadeza.
Qual a posio do mercado em relao s

empresas certificadas?
Tanto o mercado nacional quanto mercado internacional esto cada vez mais
exigentes por qualidade e produtividade, e menos tolerantes a variaes de
prazo e custo.
Uma alternativa adotada para se exigir um nvel aceitvel de qualidade foi a
comprovao de que a empresa est desenvolvendo software com foco em
qualidade. Esta comprovao vem com os selos de certificao tais como:
CMMI, MPS.Br, entre outros.
Deve-se manter sempre em mente que a melhoria do processo que
realmente traz o aumento da qualidade e da produtividade da empresa. A
certificao um importante diferencial de marketing, mas no deve ser um
fim em si mesma.
A melhor atitude planejar a capacitao do processo e da equipe aos poucos,
de acordo com a possibilidade financeira da empresa. recomendada uma
consultoria especfica para auxiliar nesse planejamento, identificando e
priorizando cada rea do processo e cada treinamento necessrio para a
equipe de projeto.
Para uma empresa cujo core business no o

Teste de Software, interessante a
certificao?
A melhor resposta depende de cada empresa, gerente, lder e equipe. A
equipe deve se conhecer o suficiente para escolher.
Como citado anteriormente, temos diversos modelos de processo de testes. A
maioria deles do exterior. Implantar um processo aqui no Brasil seria
trabalhoso, alm, de muito caro, pois no h instituies
implementadoras/avaliadoras assim como profissionais qualificados para tal.
Para o Shmuel Gershon, depende: Uma possibilidade: Sim! pelo menos vai ter
um processo mais estruturado. Outra: No! Onde existia incompetncia
catica, agora existir uma incompetncia organizada e rigorosa. O problema
desta ltima, que agora ningum mais percebe que tem que melhorar. Ou
ainda: Depende! Pode ser que o dono da empresa se sinta inseguro e a
certificao vai deix-lo mais cordato para guiar a empresa. Ou pode ser que a
equipe seja madura o suficiente para no deixar a certificao ou o rigor do
processo atrapalhar a operao. Pode ser que o gerente de testes no queira a
certificao de jeito nenhum, e certificar-se vai criar rixas desnecessrias. Pode
ser que a equipe seja to madura e com tima performance que inserir as
mudanas da certificao vai atrapalhar. Tudo pode ser.
Com o MPT, toda esta realidade muda, pois um modelo gestado
internamente possuindo, espalhados pelo Brasil, profissionais
implementadores qualificados e instituies avaliadoras, alm de ser muito
mais barato.
"Se uma fbrica de software possui internamente profissionais que testam o
software, acredito que sim. Trabalhei em uma empresa que mantm no
mercado um grande ERP. A empresa possui uma fbrica de desenvolvimento
de aproximadamente 70 desenvolvedores (em sua matriz) e um departamento
de teste com 8 testadores. Para o mercado seria interessante mostrar para os
clientes que a qualidade do software desenvolvido assegurada por processos
estabelecidos, maduros, entre outros." (Ueslei Silva)
Vrios benefcios j so conhecidos quando uma fbrica de software implanta

um processo de desenvolvimento. Com a implantao de processo de teste,
no vem a ser diferente e concatenando ambos, essa lista s tende a

aumentar. Como exemplos, podemos citar:
Aumento da qualidade do software produzido;
Aumento da satisfao do cliente;
Aumento da produtividade da empresa;
Reduo dos custos de desenvolvimento;
Diminuio da rotatividade de pessoal;
Acelerao da curva de aprendizado dos profissionais envolvidos no
projeto;
Aumento da moral da equipe;
Entre outros.
Concluso
Conclumos que processo timo para a empresa como um todo, traz vrios
benefcios, mas submete a empresa a um investimento inicial caro. O processo
de implementao burocrtico e necessita do apoio da alta gerncia e
colaborao de todos os envolvidos no projeto, caso contrrio a
implementao tornar-se- um processo lento e doloroso. No fim, poucas
mudanas podero ser vistas. Uma vez sendo apoiado por todos os
interessados, tudo torna-se mais fcil e rpido e assim a empresa sofrer
menos em seu processo de implementao. Contar com o apoio de uma
consultoria especializada uma prtica comum, pois, garante de alguma
forma a efetividade do processo.
Quanto ao fato de certificar-se, uma empresa dever estudar vrios pontos
para uma avaliao de Custo X Benefcio, de forma a comprovar a viabilidade
do investimento a ser feito para a implementao do processo.
MPT.BR Guia de Implementao Parte 1: Nvel 1 (verso 2.1)

DIAS, Andr. Por que investir em melhoria de processos? Pronus. Disponvel
em:
<http://www.pronus.eng.br/artigos_tutoriais/processo_desenvolvimento/mel
horia_processo.php?pagNum=0>. Acessado em: 14/03/2010.
made with

Visões Sobre Teste de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Visões Sobre Teste de Software

Hochgeladen von

Copyright:

Verfügbare Formate

Vises sobre Teste

Captulo 1: Testar to fcil, que at a minha me

Captulo 2: Certificaes, valem a pena?

Captulo 3: O Testador tambm necessita saber

Captulo 4: Testar sem documentao possvel?

Captulo 5: Quando documentar no preciso?

Captulo 6: Utilizao de Processos geis no Teste

10. Captulo 7: Teste gil, como implementar?

11. Captulo 8: Quando Automatizar?

Este ebook foi criado com o intuito de disseminar e facilitar o acesso a

Como este contedo surgiu?

Revisor: Marcelo Andrade

(...) a terra em si de muito bons ares (...) Em tal maneira graciosa

Hoje, mais de 1500 desses testadores de software se renem no frum de

Mas a educao de parceiros no o nico objetivo deste livro. O principal

com cliente DIRECTV dos E.U.A, atua na rea de qualidade e melhoria de

formas de contribuir para o mundo e tambm para o crescimento pessoal e

Revisor: Rodrigo Souza

Linha de Evoluo entre TI e Testes

Hetzel conceituou o Teste de Software como sendo qualquer atividade que

As organizaes no do a devida importncia atividade, que informal,

A abordagem dos testes no foi adequada para as novas tecnologias. Na

realidade, pouco esforo foi feito nas organizaes para adequar os

Mesmo com o surgimento de padres, modelos e metodologias reconhecidas

Qual a realidade da disciplina de Testes de Software? Os mitos se tornaram

realidade e a nossa misso mudar a viso do prprio profissional da rea de

Figura 1.02 - Ishikawa - Qualidade no Software Entregue

A seguir sero apresentados alguns casos reais de problemas que ocorreram

software. A falta de conhecimento deste papel inicia-se:

Software est inserida como uma atividade do desenvolvedor.

A viso de um desenvolvedor diferente de um Testador, geralmente

as condies. J o Testador, tem uma viso mais crtica e detalhista.

RODRIGUES, Nando. Site do Submarino apresenta problemas de

Revisor: Felipe da Silva

Software, quase que um consenso (dentro da comunidade de testes

Certificaes existentes na rea de testes de

QAI Quality Assurance Institute

A CSTE voltada para especialistas em Testes deSoftware, esta certificao

Software a manter suas habilidades sempre atualizadas e so vistos como

Certified Software Quality Analyst (voltada para especialistas em garantia da

ISTQB International Software Testing Qualifications

O CTAL possui como pr-requisitos que o candidato tenha a certificao CTFL

sistemas, desenvolvimento, garantia da qualidade ou reas correlatas.

ALATS Associao Latino Americana de Testes de

Software. Os exames de qualificao para a CBTS ocorrem duas vezes ao

ISEB Information Systems Examination Board

ISEB Foundation Level

Foundation Certificate in Software Testing: esta certificao voltada para

ISEB Practitioner Level

IIST International Institute of Software Testing

O IIST uma instituio formada por um conselho, formado de especialistas e

Qual o caminho a ser seguido por um

A certificao um bom incio para quem deseja iniciar na rea de teste. No

adquirir experincia e conhecimento na rea se desejar alavancar a carreira.

Figura 2.01 - Cargos e Salrios

Figura 2.02 - Cargos e salrios distribudos por estados

Adquirir e separar material de estudo e fazer simulados podem fazer a

diferena para o candidato. Recomenda-se fazer, no mnimo, dois

As diversas certificaes existentes exigem diferentes nveis de conhecimento e

mercadolgico. Sem dvida, as certificaes agregam valor ao candidato,

Scarazzato, F. Entrevista com Fernando Scarazzato. Disponvel em:

QAI Brasil - Quality Assurance Institute. Disponvel em

Caetano, C. Cargos e Salrios: Quanto ganha o profissional de teste e