A Lisiane é System Tester há quase dois anos e, para desempenhar as suas funções, usa metodologias ágeis. Hoje, partilha connosco a sua visão profissional do tema, que é cada vez mais discutido na área do IT.

 

“Afinal o que são as metodologias ágeis, qual o motivo de serem tão utilizadas e como impactam a área de testes de software? Vou contar um pouco da minha experiência, como Tester de software, e tentar responder a estas perguntas.

Metodologias ágeis – O que são?

Muitos de nós, da área da Tecnologia da Informação, e em especial os envolvidos em ciclos de desenvolvimento de software, já trabalham com as denominadas “Metodologias Ágeis”. Conhecidas também por “agile methodologies” ou simplesmente “agile”, estão directamente ligadas ao modo como desenvolvemos softwares. Ainda que, hoje em dia, o termo seja utilizado de forma abrangente, a motivação por trás de sua existência é simples: fazer o que fazemos da melhor forma possível. O conhecido Manifesto para o Desenvolvimento Ágil de Software apresenta então quatro princípios básicos, que passo a citar:

Indivíduos e interacções mais do que processos e ferramentas;

Software funcional mais do que documentação abrangente;

Colaboração com o cliente mais do que negociação contractual;

Responder à mudança mais do que seguir um plano.

Isto não quer dizer que os outros pontos deixem de ser importantes, mas a ênfase, no entanto, deve ser na eficiência da produção do software e, por isso, a interacção, a funcionalidade, a colaboração e a adaptabilidade acabam por se tornarem mais importantes, na medida em que agilizam os processos sem perda da qualidade.

 

Elevada utilização de metodologias ágeis – porquê?

Ainda que a utilização das metodologias ágeis se tenha tornado popular, e se mantenha em crescimento, podemos verificar que em décadas passadas se realizaram movimentos para encontrar melhores técnicas de desenvolvimento de softwares. A grande questão é que na era tecnológica, em que nos encontramos, com uma ampla comunicação, temos valorizado a eficiência e a velocidade do desenvolvimento do software com crescente intensidade. Estamos na época do “click”, isto é, ao clicar num botão compramos um produto ou contratamos um serviço. Como consequência disso, também passa a haver a necessidade de um software ser desenvolvido o mais rapidamente possível.

Em contrapartida, ainda muitas empresas utilizam o chamado “modelo cascata”, que antes das metodologias ágeis se tornarem populares, ditava as regras do ciclo de desenvolvimento do software. Explicando de forma simples, podemos imaginar o desenvolvimento em modelo cascata como uma escada, onde só podemos subir ao próximo degrau depois de subir o degrau anterior. Ainda que possua diversas vantagens, justamente pela sua solidez e alta riqueza nos tópicos das especificações, este modelo acaba por dificultar o fluxo dos processos, tornando-se extremamente difícil para os envolvidos lidar com qualquer tipo de imprevisto. Além disso, o tempo dispensado na etapa de planeamento é muito extenso, uma vez que requer uma análise muito detalhada, prevendo cada etapa do ciclo. Tendo em comparação o modelo actual com o modelo antigo, podemos ver o motivo da preferência por metodologias ágeis.

 

Como é que as metodologias ágeis impactam a área de testes de software?

As metodologias ágeis possuem ferramentas e princípios úteis a qualquer área, desde o marketing, aos recursos humanos e até mesmo ao design, estas adaptam-se às particularidades de cada sector, e é sempre possível inovar e tornar os processos mais eficientes. Assim sendo, é natural que, em muitos casos, a área de testes de software também fosse afectada, ainda para mais tendo em consideração a sua relação próxima com o ciclo de desenvolvimento do software, não sendo incomum ouvirmos o termo “testes ágeis” relacionado com este próprio ciclo. Por ser uma forma nova de actuar nos processos de desenvolvimento, é também natural que existam variações na forma de implementação dos testes ágeis, que irão variar de acordo com a organização de sectores, projectos e equipas dentro de uma empresa.

 

Na prática, como são os testes ágeis?

Partilhando um pouco da minha própria experiência, posso exemplificar um tipo de implementação. Inicialmente, vamos imaginar uma empresa tradicional, mesmo que adopte metodologias ágeis. Seguindo o fluxo de trabalho normal, é feita uma reunião para definir o que será desenvolvido, quais os seus requisitos e como as tarefas serão fragmentadas. Os programadores irão desenvolver as suas responsabilidades separadamente e, em muitos casos, o que foi desenvolvido é um fragmento apenas perceptível a nível de código. Após o desenvolvimento de todas as tarefas, e com o produto final pronto para entrega, é que os testers poderão iniciar a validação do que foi desenvolvido. Feitos os testes, o produto é entregue ao cliente e o processo repete-se com um novo produto.

No entanto, vamos supor que o tester encontrou um problema no produto: havia um botão, que deveria existir, mas não foi especificado nem desenvolvido. Dentro deste fluxo, não há mais tempo para conversar com o cliente, nem com o analista, para especificar, desenvolver e testar novamente. Mesmo em metodologia ágil, o processo acaba por ficar engessado devido às restrições impostas e divisões criadas no trabalho de cada uma das partes envolvidas. Verdade seja dita, na maior parte dos casos, este fluxo funciona bem e problemas como este podem ser facilmente resolvidos com o cliente, comprometendo-se a equipa a entregar a funcionalidade no produto seguinte. Porém, baseando-se no princípio de que podemos sempre melhorar e oferecer uma maior eficiência, imaginemos a implementação dos testes ágeis neste processo.

Fazendo uma comparação com o processo descrito anteriormente, imaginemos que ao invés de aguardar o produto final para iniciar os testes, o tester pode simplesmente fazer a verificação imediata da tarefa realizada pelo programador, praticamente em tempo real. Desta forma, a tarefa do programador não receberá o status de “concluída” enquanto não for também validada pelo tester. Assim, uma vez que todas as tarefas tenham sido concluídas e o produto esteja pronto para entrega, inicia-se uma nova fase de testes, na qual as tarefas já foram previamente validadas, restando apenas uma testagem de integração final a ser feita.

Voltamos então a imaginar a situação em que um botão importante para o funcionamento do produto não foi incluído no desenvolvimento. Identificando o problema, o tester pode rapidamente iniciar um diálogo com o analista e programadores, incluir a tarefa no fluxo de desenvolvimento e, se necessário, realinhar prioridades, resolvendo a questão. Nesta forma de trabalho, as partes envolvidas não actuam individualmente, mas em conjunto. O tester está sempre a par dos detalhes do requisito, fornecidos pelo analista, por sua vez, o programador sabe o que já foi validado pelo tester, e desta forma, a comunicação com o cliente é transparente.

Assim, relembrando os princípios que orientam os processos ágeis, temos ênfase nas interações das partes envolvidas, entregamos um produto funcional e de qualidade, com concordância do cliente e, tudo isto, com alta adaptabilidade aos imprevistos intrínsecos ao processo de desenvolvimento do software.

 

O que concluímos?

Existem casos onde a implementação de testes ágeis é muito positiva e, com a minha experiência profissional, posso facilmente identificar alguns pontos positivos e negativos:

Negativos:

– Normalmente, é necessário um ambiente próprio para testes, o que exige tempo exclusivamente para a manutenção deste ambiente;

– Requer testers com um maior conhecimento de programação, uma vez que a testagem é feita, muitas vezes, a nível de código;

– Exige um alto nível de integração entre analistas, programadores, testers e todas as restantes partes envolvidas no projecto, incluindo o próprio cliente, e dependendo da dimensão equipa/projecto, isto nem sempre é fácil de se obter.

Positivos:

– Implementado correctamente, um teste ágil costuma agregar uma maior qualidade ao produto entregue;

– A informação flui de forma mais transversal entre as partes envolvidas no projecto, o que reduz o número de equívocos por falta de comunicação;

– O número de bugs abertos é drasticamente menor, uma vez que são reportados e resolvidos ainda em fase de desenvolvimento;

– O conhecimento do próprio tester é aumentado a nível técnico, uma vez que deverá ter acesso aos projectos.

Com isto, vemos que em metodologias ágeis, ou em testes ágeis, não existe um modelo mágico que irá solucionar todos os nossos problemas, isto é um facto! Mas, como bem sabemos, cada projecto é único e tem as suas características e particularidades. O mais importante, quando falamos de metodologias ágeis, não é seguir passos ou princípios “à letra”, mas sim procurar a melhoria contínua dos nossos processos de trabalho. Nada está tão mal que não se possa fazer funcionar e nada está tão bem que não se possa melhorar.”

Lisiane Engel

System Tester – PrimeIT