…ou como ser o primeiro que começa a usar testes ágeis.

Quando se trabalha em projetos e produtos digitais, você provavelmente encontra o termo “ágil” todo o tempo.

A palavra ágil é amplamente utilizada (e às vezes mal utilizada). Ela se refere à metodologia de gerenciamento de projetos que se esforça para estabelecer certos princípios de colaboração, flexibilidade e transparência. Ela enfatiza a importância do feedback ao longo de todo o fluxo de trabalho de desenvolvimento.

Então, quando se fala em testes, as equipes de desenvolvimento web se voltam para as abordagens tradicionais ao invés de seguirem o caminho ágil.

Neste artigo, vou passar uma visão geral sobre testes ágeis bem como algumas dicas úteis sobre como começar com a ideia de testes ágeis.

O que é teste ágil?

Basicamente, o teste ágil significa que você faça uso da abordagem ágil ao longo de seu fluxo de trabalho de testes e monitoramento de bug.

Ao falamos sobre testes ágeis, precisamos voltar um passo e dar uma olhada no quadro geral do desenvolvimento web.

Nos velhos tempos, a maioria dos fluxos de trabalho de desenvolvimento web e de engenharia de software foi estruturada ao longo do chamado framework waterfall.

Mais do que um modelo waterfall

A abordagem waterfall basicamente afirma que cada passo do projeto decorre de uma série linear de etapas sequenciais. O fluxo de trabalho ficaria assim:

Testes Agile – a diferença

A diferença entre testes ágeis e a abordagem waterfall é que o teste em si não é um passo separado no projeto. Em contraste com o framework waterfall, testes ágeis exigem colaboração contínua entre todos os membros da equipe e as partes interessadas.

Ao longo de todo o fluxo de trabalho, o teste se torna uma parte essencial de todas as fases do projeto.

Portanto, a estrutura para equipes ágeis se parece mais ou menos como isto:

Fluxo de trabalho é necessário com ágil?

Este modelo de testes ágeis tem sido desenvolvido como um contra-framework para os fluxos de trabalho tradicionais, mais burocráticos. Embora equipes ágeis ainda precisem de fluxos de trabalho básicos, quero destacar que ágil em si não se concentra demais em fluxos de trabalho.

Ou como Martin Fowler diz:

Os métodos ágeis são orientados para as pessoas, em vez de orientados para o processo.

Sim. Isso é ótimo, já que todos os esforços são inúteis se as pessoas não estão usando os produtos que nós construímos, certo?

Os fluxos de trabalho são bastante estáticos e resistentes à mudança, mas as pessoas são adaptáveis e prosperam com a mudança. Às vezes, as pessoas mudam por is mesmas.

Acelerar o ciclo de desenvolvimento com feedback contínuo

Portanto, esse estado constante de mudança nos obriga a colocar feedback contínuo no centro dos nossos projetos e esforços. Ser ágil também significa fornecer pontos de contato para feedback contínuo.

Embora não seja nada novo, feedback é fundamental. Pedir feedback continuo durante todo o projeto requer uma cultura de feedback na qual as pessoas são incentivadas a avaliar o que eles estão fazendo em uma base diária.

QA ágil: mais do que feedback e fluxos de trabalho

Não são o fluxo de trabalho e o feedback contínuo que fazem com que equipes ágeis se destaquem. É a colaboração ágil.

Em projetos tradicionais, as equipes de QA muitas vezes servem “como o protetor da qualidade“. O teste deve evitar que qualquer software ruim chegue ao público. Isso resulta em fluxos de trabalho longos e reuniões de bugs, nos quais os membros da equipe do projeto argumentam sobre a prioridade para os bugs.

Nunca, jamais discuta sobre bugs reuniões do projeto.

(Fonte: 6 surprisingly easy bug tracking hacks)

Com uma comunicação contínua entre os membros da equipe do projeto, partes interessadas e usuários finais, melhores relações são estabelecidas e mais trabalho pode ser feito, com a equipe também sendo sensível e flexível o suficiente para mudar os requisitos do projeto.

Testando a forma ágil

A maneira tradicional de teste, basicamente, afirma: especifique os requisitos, faça o desenvolvimento e os teste. A execução dos testes acontece no final do projeto. Isso também é chamado de abordagem “test-last”.

Por outro lado, testar primeiro tem uma série de benefícios. É por isso que eu recomendo fortemente que você defina os testes ao mesmo tempo em que estiver especificando seus requerimentos.

Isto não só lhe dá uma visão clara do que precisa ser feito e quais metas que você compartilha, mas também ajuda você a especificar seus requerimentos com mais detalhes.

Encerrando

Agile ganhou o jogo em engenharia de software. Então, por que não fazer uso de testes ágeis também? Continuous deployment e testes estão se tornando a norma. Portanto, o teste de software deve fazer sua mudança de papel do modo atual para algo mais flexível e eficiente quando se trata de testar as coisas.

O teste não é apenas mais uma fase. Garantir o progresso contínuo significa garantir ciclos de testes e feedback contínuos.

***

Thomas Peham faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://usersnap.com/blog/agile-testing/