Edição 27 - Engenharia de Software Magazine 7

Eduardo Habibeduardohabib@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 ágeisPara 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 multifuncionaisDesenvolvimento á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 algum grau 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 estresseAumentar 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 equipeComo 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 ágeisNem 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á requerido por 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 testadoresUm 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çasA 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 unidadeMuitos 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çãoUma 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 essencial para 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 testesComo 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 iniciaisJá é 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 projetosEric 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 testadoresSegundo 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.

TestabilidadeTestabilidade é 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 equipeUma 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ãoUma 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 testadores terã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ê

seu Feedback

sob

re esta edição