Revista Testes Ageis

Prévia do material em texto

Edição 27 - Engenharia de Software Magazine 7 
Eduardo Habib
eduardohabib@gmail.com
Possui Graduação e mestrado em Ciência da 
Computação na UFMG. Atua na área de testes 
de software há nove anos. Nesses anos teve 
experiência no planejamento, especificação 
e execução de testes manuais, automação 
de testes, testes de desempenho e testes de 
segurança. Possui três anos de experiência le-
cionando no ensino superior. Frequentemente 
ministra treinamentos e/ou palestras relacio-
nados a testes de software já tendo, inclusive, 
ministrado a disciplina de Testes de Software 
na PUC Minas. Possui as certificações IBM 
Certified Specialist - Software Quality e CTFL 
do BSTQB. Atualmente é Gerente de testes no 
SYNERGIA - DCC/UFMG e professor no curso 
de Ciência da Computação da UNIBH.
De que se trata o artigo?
Nesse artigo pretende-se demonstrar alguns as-
pectos que afetam os testes em processos ágeis 
e que, se tratados com antecedência, aumentam 
a chance de sucesso dos testes nesses ambientes. 
Será visto ainda como resolver alguns problemas 
que surgem devido à adoção desses processos e 
como se modi„cará o papel e o relacionamento 
dos testadores com o restante da equipe. 
Para que serve?
A estratégia de testes utilizada em um ambien-
te ágil deve ser diferente da estratégia em um 
ambiente que segue um processo tradicional, 
o que torna necessário, antes da adoção de um 
processo ágil, que se pense em como resolver 
determinados problemas relacionados aos tes-
tes nesse ambiente.
Em que situação o tema é útil?
Como nos próximos anos os pro„ssionais de teste 
estarão sob o aumento de pressão para consegui-
rem testar melhor e mais rápido, a resolução de 
problemas inerentes aos testes ágeis é útil em 
equipes que pretendem vir a utilizar um desses 
processos, visto que isso aumenta a probabilida-
de de sucesso dos testes nesses ambientes.
Testes ágeis
Como os testes serão modificados com o advento das metodologias ágeis
Em fevereiro de 2001, 17 desenvolve-dores de software se reuniram em uma estação de esqui, nos EUA, 
com o objetivo de conversar, comer, rela-
xar e trocar ideias em comum. Durante as 
conversas, foram discutidas alternativas 
para melhorar a produtividade dos proje-
tos de desenvolvimento de software. Para 
isso, basearam-se nos anos de experiência 
no desenvolvimento de software de todos 
os participantes do encontro. Embora 
cada um dos envolvidos tenha trabalha-
do em projetos que seguiam processos 
e práticas diferentes, um conjunto de 
princípios parecia ter sido respeitado nos 
projetos que tiveram sucesso.
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
8 Engenharia de Software Magazine - Testes ágeis
Com base nos princípios em comum, foi criado o Manifesto 
para o Desenvolvimento Ágil de Software, que definiu os 
quatro princípios básicos que os métodos ágeis deveriam 
valorizar. São eles:
• Indivíduos e iterações entre eles, ao invés de processos e 
ferramentas;
• Software funcionando ao invés de documentação compre-
ensiva e detalhada;
• Colaboração com os clientes ao invés de negociação de 
contratos;
• Adaptação às mudanças ao invés de seguir o plano inicial.
Desde então, cada vez mais organizações começaram a 
adotar metodologias ágeis no desenvolvimento de software. 
Entretanto, segundo Stuart Reid, na realidade existem poucas 
empresas que utilizam processos realmente ágeis e que seguem 
todos os princípios do manifesto. Na prática, o termo ágil tem 
sido aplicado a qualquer projeto de desenvolvimento interativo 
cujas iterações não durem mais do que quatro semanas. 
Segundo Joachim Herschmann, em seu artigo “The Future of 
Testing - How Testing and Technology will Change‰, não há dúvidas 
que nos próximos anos profissionais de teste, qualidade e or-
ganizações que desenvolvem software como um todo, estarão 
sob o aumento de pressão para conseguirem testar melhor e 
mais rápido. A utilização de processos ágeis é uma tentativa 
de conseguir isso.
A aplicação das metodologias ágeis não é, contudo, tão fácil 
quanto explicada nos livros e nem tão difícil quanto pregam 
alguns adeptos das metodologias tradicionais. Para uma 
empresa aplicar um processo ágil, é necessário fazer diversas 
modificações no processo de desenvolvimento e na cultura da 
empresa. Em alguns casos, como em uma empresa que segue 
um processo muito bem definido, essas modificações podem 
ser mais profundas. Porém, se bem planejadas, podem ser 
realizadas sem grandes traumas.
É muito comum empresas que utilizam processos ágeis 
darem relatos demonstrando o quão boas são essas metodo-
logias. No entanto, a maioria dos relatos sobre a utilização 
das metodologias ágeis não entram em detalhes sobre como 
funcionam os testes nesses processos. Apesar disso, qualquer 
um que esteja envolvido em projetos ágeis percebe facilmente 
que as abordagens tradicionais de teste não funcionam bem 
nesses casos.
Em um mundo cada vez mais competitivo, a qualidade 
torna-se a cada dia mais importante, tornando os testes uma 
atividade crucial no ciclo de vida do desenvolvimento de sof-
tware. Isso aumenta a necessidade de treinamento da equipe 
para que todos estejam mais qualificados. Com a utilização 
cada vez maior dos processos ágeis, é importante que os 
profissionais de teste sejam mais qualificados e saibam como 
trabalhar nesses processos.
No que diz respeito aos testes, antes de implantar um pro-
cesso ágil, é necessário que determinadas questões sejam 
respondidas para que os testes ocorram com sucesso. Nas 
próximas seções essas questões serão levantadas e discutidas, 
e será demonstrado como as pessoas que trabalham com de-
senvolvimento de software devem modificar a forma como 
pensam sobre o trabalho dos profissionais de qualidade e teste 
nas metodologias ágeis.
Estratégias de testes em projetos ágeis
Para que os testes em projetos que utilizam as metodologias 
ágeis sejam um sucesso, é necessária a definição de algu-
mas estratégias de teste que cubram todas as atividades de 
desenvolvimento.
Visando definir essas estratégias, Rex Black recomenda um 
conjunto de testes que funciona bem com as metodologias 
ágeis. O conjunto de testes sugerido por ele é:
• Testes baseados em riscos;
• Testes de regressão automatizados;
• Testes reativos (também chamado de testes dinâmicos).
Testes baseados em risco funcionam em praticamente todas 
as situações, já que essa estratégia permite desenvolver, manter 
e executar os testes na ordem prioritária dos riscos. Assim, 
garante-se que as funcionalidades de maior risco de negócio 
serão testadas com mais cuidado. Além disso, funcionalidades 
prioritárias serão testadas antes e caso apresentem problemas 
existirá mais tempo para corrigi-las. Testes de regressão au-
tomatizados são importantes porque, como nos testes ágeis 
as modificações são constantes e não é viável refazer todos 
os testes todo dia, nos testes automatizados é verificado se o 
que foi alterado não sofreu algum efeito colateral. Os testes 
reativos, por sua vez, por não exigirem muita documentação, 
são pouco afetados por mudanças de requisitos. Isso permite 
que se explorem diversos aspectos do sistema que os testes 
baseados em risco e os testes de regressão automatizados 
podem deixar passar despercebido.
Equipes multifuncionais
Desenvolvimento ágil se refere a um grupo de metodologias 
de desenvolvimento de software baseadas em desenvolvimen-
to interativo, onde os requisitos e soluções evoluem através da 
colaboração entre as equipes multifuncionais. Esse ponto é 
muito importante para o sucesso da aplicação das metodologias 
ágeis. Assim, idealmente, espera-se que todos os membros da 
equipe estejam aptos a realizar todas as tarefas.
Na prática, normalmente existe algumgrau de especialização 
entre os membros da equipe, e a maioria das equipes ágeis não 
atinge a meta de ser totalmente multifuncional, até porque 
as pessoas dificilmente gostam de executar todas as tarefas. 
Visando minimizar esse problema algumas empresas acabam 
criando, dentro do processo ágil, uma iteração para testes e 
outra para desenvolvimento. 
Entretanto, separar totalmente as atividades de teste e 
desenvolvimento em iterações diferentes não faz sentido 
no contexto dos testes ágeis. Por isso, Rex Black sugere que 
mesmo utilizando metodologias ágeis, a equipe de testes seja 
independente. Porém, ele sugere que um dado requisito seja 
testado na mesma iteração em que ele foi implementado. Isso 
Edição 27 - Engenharia de Software Magazine 9 
AGILIDADE
é importante porque os erros cadastrados serão reportados na 
mesma iteração em que o desenvolvedor realizou a codificação. 
Com isso, eles tendem a ser corrigidos mais rapidamente já que 
é mais fácil para o desenvolvedor se lembrar dos detalhes do 
funcionamento do código que ele codificou há pouco tempo.
Aumento de períodos de estresse
Aumentar excessivamente a pressão sobre a equipe pode 
ocasionar perda de produtividade e uma maior rotatividade 
dos membros da equipe. Por outro lado, é natural no desen-
volvimento de sistemas que existam períodos estressantes 
para a equipe de testes, períodos esses que normalmente são 
próximos às entregas de versões para o cliente. O problema 
nas metodologias ágeis é que como ocorrem entregas de novas 
versões funcionais em curto espaço de tempo, os períodos de 
estresse serão mais frequentes. 
Testes baseados em risco minimizam este problema, pois 
garantem que ao fim de uma iteração as funcionalidades mais 
críticas já foram testadas. Assim, evita-se que a equipe fique 
sob grande estresse e tenha que fazer muitas horas extras para 
testar funcionalidades críticas, já que essas funcionalidades 
serão testadas antes. Visando diminuir o estresse da equipe, 
algumas metodologias ágeis, como o XP, sugerem que os 
membros da equipe não trabalhem mais do que 8hs/dia e cinco 
vezes por semana, pois é necessário que a equipe descanse 
para que a produtividade não caia.
Relacionamento entre os membros da equipe
Como os processos ágeis incentivam a comunicação face a face, 
é extremamente importante que haja maturidade e respeito entre 
os envolvidos para evitar que ocorram conflitos. Dessa forma, o 
planejamento e a tomada de decisões realizadas pela equipe de 
teste devem ser feitos em conjunto, de forma que todos “abracem” 
as decisões tomadas e as metas estabelecidas. Os melhores proces-
sos ágeis provêem um ambiente que incentiva a responsabilidade, 
confiança e colaboração entre os membros da equipe.
Para incentivar essas características, não é recomendado que 
seja gasto tempo reportando todos os defeitos encontrados. 
Se o desenvolvedor e o testador trabalham próximos, muitas 
vezes um do lado do outro, pode ser simples mostrar um de-
feito para que o desenvolvedor possa corrigi-lo rapidamente. 
Além disso, a redução do cadastro de erros acaba diminuindo 
os conflitos entre implementadores e testadores. Entretanto, é 
importante ressaltar que, se um defeito não puder ser corrigido 
e verificado rapidamente, ele deve ser cadastrado para que 
não seja esquecido.
Outro ponto a se ressaltar é a importância dos implementado-
res, que são quem normalmente codificam os testes de unidade, 
compartilharem com os testadores o que foi codificado nesses 
testes. Isso é importante porque, se o testador souber quais ca-
sos estão sendo cobertos pelos testes de unidade, ele consegue 
selecionar melhor os testes que serão executados, priorizando 
aqueles que não se sobrepõem aos testes de unidade.
Portanto, nos processos ágeis, a função principal do testador 
é facilitar o trabalho da equipe dando um feedback rápido. Isso 
demonstra que, seguindo os princípios das metodologias 
ágeis, é mais importante a execução do teste do que a sua 
modelagem.
Dificuldade de realizar todos os testes em iterações 
curtas
A maioria dos métodos ágeis buscam minimizar o risco 
desenvolvendo partes funcionais do software em curtos 
períodos, chamados de iteração, cuja duração normalmente 
não é maior do que quatro semanas. A meta de equipes que 
utilizam esses processos é desenvolver o software de manei-
ra incremental e ao fim de cada período entregar uma parte 
funcional do software. 
Porém, é bastante comum verificar em determinados proje-
tos ágeis a finalização de uma iteração sem que alguns testes 
tenham sido realizados. Isso ocorre porque existem testes, 
como o de confiabilidade, desempenho e segurança, que po-
dem durar facilmente mais de duas semanas, e reservar esse 
tempo dentro de um curto período é, na prática, muito difícil. 
Em muitos desses projetos, é comum a existência de uma fase 
de teste que se inicia em uma iteração e continue durante a 
iteração seguinte. Assim, garante-se que um teste crítico cuja 
duração seja maior do que o tempo disponível na iteração 
será executado.
Automação dos testes em processos ágeis
Nem todas as funções de um sistema podem ter seus testes 
automatizados devido a diversos fatores como o custo exces-
sivo de automação ou até mesmo devido à incompatibilidade 
das ferramentas de automação utilizadas com determinados 
componentes do sistema. Entretanto, nas funcionalidades onde 
é possível aplicar a automação a um custo factível existe um 
grande potencial de ganho com a diminuição do esforço gasto 
re-testando pontos do sistema que podem vir a sofrer efeitos 
colaterais de alterações no software.
Como nos processos ágeis a cada iteração é entregue uma 
versão funcional do software, as constantes modificações no 
sistema podem gerar efeitos colaterais em uma interface já 
testada. Se essa interface teve seus testes automatizados, os 
efeitos colaterais tendem a ser descobertos com mais facilidade. 
Assim, toda vez que um teste falha, o testador pode verificar o 
motivo da falha e reportar o defeito ou, caso seja uma alteração 
de requisitos, corrigir o teste. 
Contudo, para que não seja gasto muito tempo com manuten-
ção dos scripts de teste já que o software estará sob constante 
alteração, é necessário escolher bem o que automatizar. Nesse 
contexto, sugere-se que sejam automatizados os testes das 
interfaces mais estáveis, pois automações realizadas em inter-
faces estáveis não sofrem muitos problemas de manutenção.
Apesar de, conforme recomendado, diversas empresas terem 
automatizado testes apenas para interfaces estáveis, muitos 
projetos de automação têm falhado. Existem diversas razões 
pelas quais nos últimos anos a automação de testes teve um 
sucesso limitado. Uma das razões é que as versões iniciais 
das ferramentas de automação de testes não eram maduras 
10 Engenharia de Software Magazine - Testes ágeis
o suficiente, o que fez com que fosse requerido um esforço 
substancial para construir testes automatizados robustos. 
Além disso, até pouco tempo atrás, ninguém conhecia muito 
os problemas que seriam encontrados, e testadores com conhe-
cimento específico em testes automatizados eram raros, o que 
acabava ocasionando o uso indevido das ferramentas.
As empresas desenvolvedoras de ferramentas de automação 
de testes, bem como os testadores, aprenderam a lição. O au-
mento da necessidade de automação dos testes significa que 
não só haverá uma grande e forte demanda por ferramentas 
de teste que possam suportar um elevado grau de automação, 
mas também deverão existir testadores altamente qualificados 
e muito mais competentes. 
Os testes puramente manuais ou puramente gravados em 
ferramentas que requerem pouco ou nenhum conhecimento 
técnico de um testador irão se tornar cada vez mais escassos. 
Isso porque, para suportar o alto grau de automação que 
futuramente será requeridopor todos os testes como os de 
desempenho, regressão e de aceitação, pode ser necessária 
a codificação de bibliotecas para auxiliar na conclusão dessa 
tarefa. E essas bibliotecas muito provavelmente terão que ser 
codificadas por testadores, pois como são eles que trabalham 
diretamente com a automação, é natural que eles possuam 
um entendimento maior dos problemas enfrentados durante 
esse processo. 
Perfil dos testadores
Um dos grandes mal entendidos no desenvolvimento ágil é 
que os testes como um todo (e as pessoas que participam de 
todo o processo) podem se adaptar a mudanças sem muita 
ajuda ou sem mudanças no perfil da equipe.
Qualquer organização, ao adotar uma metodologia ágil, 
deveria possuir uma política clara sobre a composição da 
equipe e sua estabilidade. Por exemplo, todos os membros 
de equipes ágeis deveriam permanecer na mesma equipe 
durante todo o projeto. Como nos processos ágeis estimula-
se a comunicação face a face, é importante que não se perca 
pessoas da equipe. Para minimizar o fato inevitável de que 
é praticamente impossível manter a mesma equipe durante 
todo o projeto, deve-se difundir o conhecimento entre seus 
membros. Assim, uma eventual saída de um membro não será 
tão prejudicial ao projeto.
Além disso, todos os testadores deveriam possuir os conhe-
cimentos requeridos para trabalharem bem em um ambiente 
ágil, já que o analista de testes exerce, em um ambiente ágil, 
um papel diferente do que ele normalmente desempenha em 
processos tradicionais. 
Em processos ágeis é necessário que o testador instrua os 
clientes e desenvolvedores em questões relativas a testes, pois 
os clientes e os desenvolvedores participam mais ativamente 
dos testes nesses processos. Os testadores devem também 
participar bem mais intensamente de revisões realizadas e 
dos testes de unidade implementados, pois tendo uma noção 
maior do que já foi verificado e testado, é possível priorizar 
melhor os testes.
Há o envolvimento dos testadores também em estimativas de 
desenvolvimento, definição do critério de saída e revisão das 
estórias dos usuários, tornando-as testáveis. Dessa forma, para 
que seja possível realizar as tarefas citadas, é extremamente 
necessário que existam testadores na equipe que possuam faci-
lidade de comunicação e um maior conhecimento técnico para 
que, quando necessário, a equipe consiga realizar bem atividades 
como codificação e levantamento de requisitos com o cliente. 
Este perfil de testador multifuncional é muito importante, 
visto que, nos processos ágeis, o testador muitas vezes vai 
ajudar a apontar o local exato onde o erro ocorre, ao invés de 
apenas listar os passos para reproduzi-lo.
Lidando com grande volume de mudanças
A utilização de processos ágeis cria desafios reais para as 
equipes de teste e para a criação de outros documentos, como 
as especificações de teste. Mesmo que a equipe de projetos 
forneça à equipe de testes uma documentação adequada, dois 
princípios da metodologia ágil mantêm esse desafio vivo. 
Como as metodologias ágeis encorajam mudanças e incen-
tivam a comunicação face a face como a forma mais eficiente 
de propagar a informação, é bem provável que mudanças de 
requisitos surjam e não sejam documentadas. Com isso, mui-
tas vezes, após perder tempo confirmando um determinado 
comportamento, reproduzindo-o e reportando-o, será desco-
berto que o erro na verdade foi uma mudança de requisito não 
documentada e não é um erro.
Nenhuma estratégia de testes conhecida impede que erros 
inválidos sejam cadastrados (um defeito é invalidado quando 
ele descreve um comportamento que é o correto). Dessa forma, 
é requerido que o gerente acompanhe o percentual desses erros 
cadastrados e, quando necessário, atue para que o percentual 
diminua. Rex Black diz no artigo “How Agile Methodologies 
Challenge Testing”, que em projetos estáveis e bem definidos é 
comum que o número de defeitos invalidados esteja em torno 
de 5% do total de defeitos. Projetos ruins, no entanto, possuem 
uma taxa superior a 20%. Isso indica que a informação não está 
circulando de forma eficiente e que a equipe de testes gastou 
tempo isolando situações cuja equipe de projeto definiu como 
correta, mas não documentou. Esse tempo poderia ser gasto na 
busca por defeitos reais. O gasto com defeitos inválidos seria 
evitado se a informação tivesse circulado melhor dentro da 
equipe, o que poderia ser obtido com uma maior integração 
entre testadores e desenvolvedores.
Testes de unidade
Muitos dos autores, praticantes e acadêmicos envolvidos 
com metodologias ágeis, pregam que sejam realizados testes 
unitários para que os softwares sejam desenvolvidos com mais 
a segurança e qualidade.
Contudo, a capacidade dos testes de unidade de detectar 
defeitos é limitada. Segundo Caper Jones, os testes de uni-
dade detectam de 25% a 30% dos defeitos de um software. 
Enquanto isso, foi demonstrado por Rex Black – no artigo 
How Agile Methodologies Challenge Testing – que até 85% dos 
Edição 27 - Engenharia de Software Magazine 11 
AGILIDADE
defeitos podem ser detectados antes do sistema 
entrar em produção se forem realizados testes de 
sistema no software por uma equipe independente. 
Portanto, apesar dos testes de unidade auxiliarem 
na detecção de defeitos, os testes de sistema ainda 
são melhores para detectar a grande maioria dos 
defeitos do software.
Além disso, durante o desenvolvimento, devi-
do à falta de tempo, muitos programadores não 
realizam testes de unidade ou o fazem de forma 
precária. Isso é muito crítico, especialmente para 
um projeto que utiliza metodologia ágil, já que um 
ou dois dias de atraso nos testes devido a defeitos 
blocantes no código significa, percentualmente, um 
atraso muito grande em pequenas iterações.
A possibilidade de entrega de testes de unidade 
pouco efetivos é outra razão para a qual se reco-
menda a utilização da estratégia de testes baseados 
em risco, pois os defeitos nos pontos mais críticos 
do software serão detectados antes.
Percebe-se, portanto, que os testes de unidade 
são extremamente necessários, mas é importante 
ter ciência de suas limitações e de que a realização 
desses testes não eliminará a necessidade da rea-
lização de outros testes.
Documentação
Uma resposta natural e comum dos testadores às 
documentações ruins são os testes exploratórios. 
Porém, mesmo em processos ágeis, documenta-
ções ruins deveriam ser raras já que elas podem 
ocasionar diversos problemas para a equipe, como 
a diminuição da cobertura dos testes e o aumento 
dos defeitos inválidos reportados pela equipe. 
Um dos principais mal entendidos do manifesto 
ágil é o que diz respeito à documentação. Muitos 
acreditam que nos processos ágeis o código deve 
ser implementado e que a documentação não pre-
cisa ser feita. O Manifesto ágil não diz nada sobre 
não se documentar os requisitos, e muitas pessoas 
ligadas ao desenvolvimento ágil querem resgatar 
a credibilidade dessas metodologias devido a esse 
desentendimento. 
Quando o manifesto fala sobre documentação, ele 
pretende demonstrar que é necessário encontrar 
um ponto de equilíbrio entre o que escrever na 
documentação e o que não escrever. Dessa forma, 
pretende-se evitar situações comuns em muitas 
empresas onde muita documentação é produzida, 
armazenada em um repositório e nunca mais con-
sultada (e muito menos atualizada).
Os responsáveis pelas especificações devem 
garantir, portanto, um conjunto mínimo de in-
formações que permitam desenvolver e testar o 
requisito. Dessa forma, deve-se chegar a um meio 
termo entre a diminuição da documentação e as informações necessárias 
pelos testadores para realizar os testes.
O fato é que, tipicamente, as documentações nos processos ágeis são bem 
menores do que as utilizadas em processos tradicionais. Uma condição 
essencialpara o sucesso dessas metodologias e que minimiza eventuais 
problemas na documentação ajudando os testes é a participação ativa de 
um usuário da aplicação no processo de desenvolvimento. Dessa forma, 
caso surja alguma dúvida durante os testes, o usuário pode ser consultado 
e ajudar na resolução da mesma.
Papel do gerente de testes
Como os processos ágeis sugerem que as equipes sejam multifuncio-
nais, muitas vezes é questionado o papel do gerente de testes nesses 
processos. Uma equipe de testes liderada por um bom gerente de testes 
pode fazer com que a equipe trace um objetivo melhor e unificado. 
Isso ocorre porque o gerente, que normalmente é uma pessoa experiente 
em testes, pode direcionar determinadas tarefas para as pessoas que 
possuam mais afinidade com elas, podendo ainda, tirar as dúvidas dos 
testadores quanto à execução de determinadas atividades. 
Essa liderança acaba por fazer com que cada testador realize sua ta-
refa de forma subotimizada. Assim, com o auxílio do gerente, a equipe 
é isolada de algumas considerações com as quais ele se preocupará e, 
quando necessário, repassará a todos os membros da equipe.
12 Engenharia de Software Magazine - Testes ágeis
Envolvimento dos testadores nas fases iniciais
Já é consenso na comunidade que quanto mais cedo se ini-
ciam os testes, mais dinheiro é economizado. Os problemas 
causados por um produto mal testado é bem conhecido por 
todos. Problemas nos testes normalmente significam que a 
maioria dos erros serão encontrados tardiamente, o que pode 
fazer com que eles sejam extremamente difíceis e caros de 
corrigir. 
Nas metodologias ágeis, onde a documentação utilizada nos 
testes é mais reduzida, é ainda mais importante do que nas 
metodologias tradicionais que os testadores sejam envolvidos 
nos testes desde o início do projeto, antes mesmo de haver 
qualquer código implementado. 
Isso é necessário porque os testadores irão conhecer a apli-
cação mais cedo, ajudarão a inserir informações na documen-
tação necessárias aos testes e ficarão menos dependentes da 
documentação do mesmo. Os testadores podem, ainda, ajudar 
os desenvolvedores a fazer os testes de unidade e conversar 
com os clientes a fim de ajudá-los a aperfeiçoar os requisitos, 
antes mesmo deles entrarem na iteração.
Participação de testadores em múltiplos projetos
Eric Jimmink ressalta no artigo “Testing in an organization 
going agile”, que nenhum testador deve fazer parte de mais de 
um projeto ao mesmo tempo, pois isso ocasiona uma grande 
perda de tempo com a mudança de contexto. Por esse motivo 
o testador acaba perdendo o foco do seu trabalho, além do 
que, sempre que aparecer uma tarefa prioritária, se o tempo 
do testador é dividido entre dois projetos, fica difícil que ele 
realize tal tarefa em tempo hábil. 
Entretanto, ao estimar o esforço em um determinado pro-
jeto, muitas vezes chega-se a números quebrados, como por 
exemplo, 3.5 pessoas. Nesses casos, o mais recomendado é 
a formação da equipe do projeto com pessoas que consigam 
realizar atividades diferentes de sua especialidade, ou seja, 
a formação de uma equipe multifuncional. A troca de ativi-
dades no mesmo projeto gera um desperdício menor do que 
dividir uma pessoa entre dois projetos diferentes.
O recrutamento de testadores
Segundo Rex Black, em seu livro “Managing the Testing Pro-
cess”, antigamente as empresas selecionavam os profissionais 
que possuíam bom perfil de comunicação e bons conhecimen-
tos técnicos para trabalhar nas áreas com as quais possuíam 
mais afinidade, enquanto aqueles que eram bons tecnicamente, 
mas possuíam perfil de comunicação ruim eram candidatos 
a trabalhar em testes. Esse modelo de seleção pode funcionar 
quando se segue um processo com muita documentação, e 
na qual a necessidade de comunicação com outras pessoas é 
mínima pois tudo está muito bem documentado. 
Contudo, em um processo ágil, onde o testador precisa 
conversar ativamente com o cliente e demais envolvidos no 
projeto, ele deve possuir boas técnicas de comunicação. Assim, 
o recrutamento de testadores ágeis deve priorizar aqueles que 
se comunicam bem. 
É muito mais fácil suprir deficiências técnicas dos funcioná-
rios, ensinando técnicas e estratégias de teste, do que ensinar 
uma pessoa super competente tecnicamente, mas com proble-
mas em se comunicar com as pessoas, a se comunicar bem.
Testabilidade
Testabilidade é a medida do quão bem e quão eficiente uma 
aplicação pode ser testada. Desenvolver uma aplicação pen-
sando em testabilidade economiza tempo, dinheiro e diminui 
o risco. Com o advento das metodologias ágeis, onde as ite-
rações são curtas e o tempo para testar o software também, 
desenvolver pensando em testabilidade passou a ser crucial. 
Aplicações que são mais fáceis de testar serão, em um mesmo 
intervalo de tempo, mais testadas do que aplicações que são 
difíceis de testar.
Mesmo utilizando a estratégia de testes baseados em risco, 
o maior problema é que as áreas que são mais difíceis de tes-
tar (ou seja, com pior testabilidade) normalmente são as que 
apresentam o maior risco de negócio.
Uma organização madura no que diz respeito a processos 
ágeis possui equipes misturadas de testadores e desenvolve-
dores. Essa interação mais próxima entre a equipe ajudará na 
divisão de responsabilidades para a automação dos testes, na 
adoção do desenvolvimento dirigido a testes e na execução 
regular de grandes suítes de teste. Para essas equipes a testa-
bilidade não é uma questão de escolha e sim de necessidade 
evidente. Portanto, cada vez mais se torna vital que o software 
seja desenvolvido pensando-se na facilidade de testá-lo.
Localização da equipe
Uma condição de sucesso dos projetos ágeis é a localização da 
equipe. Nesses projetos, o ideal é que os membros da equipe 
consigam conversar sem sair da sala e, preferencialmente, 
sem mesmo sair da cadeira. Isso possibilita que o testador, ao 
suspeitar de algum problema, simplesmente converse com os 
responsáveis.
Entretanto, existem casos em que a equipe tem a necessidade 
de atuar geograficamente separada. Embora possa realmente 
vir a dificultar os testes, hoje em dia isso já não é um problema 
sem solução, visto que podem ser realizadas reuniões diárias 
utilizando programas como o skype. Além disso, se a empresa 
dispuser de um bom link com a internet, é possível até a re-
alização de videoconferências diárias para resolver qualquer 
problema do projeto e alinhar metas e objetivos.
Conclusão
Uma das tendências mais interessantes no desenvolvimento 
de software e que começa a ser visualizada é que os Testes de 
Software estão começando a ficar cada vez mais alinhados com 
as necessidades do negócio. A utilização maior das metodolo-
gias ágeis e o aumento da preocupação em como integrar os 
testes a essas metodologias são uma manifestação disso.
As metodologias ágeis são conhecidamente mais flexíveis para 
se adaptar às mudanças que ocorrem normalmente ao longo do 
projeto. As equipes de testes também terão que ser mais flexíveis 
Edição 27 - Engenharia de Software Magazine 13 
AGILIDADE
e, para isso, terão que mudar radicalmente se comparado ao seu 
funcionamento em projetos tradicionais, adaptando-se às mu-
danças inerentes ao processo ágil para que não haja diminuição 
da qualidade dos testes. Para isso, os testadores terão que se 
envolver no processo desde o começo, dando feedbacks rápidos 
aos desenvolvedores sobre como uma nova funcionalidade 
funciona ao invés de fazer isso no fim do processo.
As ferramentas e as habilidades exigidas dos testadores mu-
darão como parte de uma transformação rápida, e os testadores 
serão obrigados a procurar cada vez mais por novos conheci-
mentos sob o risco de ficarem fora do mercado se isso não for 
feito. Com o incentivo da comunicação face a face, desenvolve-
dores e testadoresterão de colaborar mais um com o outro, o que 
exigirá que ambos aumentem suas habilidades em outras áreas. 
As empresas desenvolvedoras de software podem ajudar nesse 
processo de aprendizado fornecendo treinamentos e caminhos 
de carreira diferentes para perfis diferentes de pessoas.
Uma maior qualificação da equipe irá auxiliar em uma me-
lhor e mais robusta automação dos testes. Isso é essencial ao se 
adotar estratégias ágeis de desenvolvimento. Sem automações 
robustas dos testes será impossível manter a qualidade, e muito 
menos melhorá-la nos ambientes ágeis.
Por fim, os testes serão verdadeiramente ágeis quando forem 
integrados naturalmente ao processo de desenvolvimento, não 
sendo apenas uma fase após a codificação pelos desenvolve-
dores. Eles serão ágeis quando toda a equipe entender que os 
testadores estão tentando atingir um objetivo, que é o mesmo 
de todos. 
WATKINS, John. Agile Testing: How to Succeed in an Extreme Testing Environment. Cambridge 
university Press, 2009
PERRY, E., William. Effective Methods for Software Testing. Wiley Press, Inc.. New York 1995.
Farrell-Vinay, Peter, Manage Software Testing. Auerbach Publications., 2008
Testing Experience: The Magazine for Professional Testers, Agile Testing, Setembro de 2009.
COHN, Mike. Agile Estimating and Planning. Prentice Hall. 2005 
CRISPIN, Lisa. Testing Extreme Programming. Addison-Wesley. 2002
MYERS, Glenford J. The Art of Software Testing. John Wiley & Sons, Inc., New York, NY, 1979.
PRESSMAN, R. S., “Software Engineering: A Practitioner’s Approach”, McGraw-Hill, 6th ed, Nova York, 
NY, 2005.
GILB, Tom. Agile Specification Quality Control, em Testing Experience Magazine. Março de 2009.
BLACK, Rex. Managing the Testing Process, Microsoft Press, Junho de 1999.
Referências 
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine
tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u F
eedback
so
b
re
 esta edição