Ao pensar nos métodos ágeis, muita gente volta os olhos para o desenvolvimento propriamente dito e se esquece de um elemento crucial: os testes. Sem testar com agilidade, você não será ágil de fato.

E, pior do que isso, terá que lidar com gargalos, conflitos e erros que poderiam ser evitados se a transformação ágil fosse levada a cabo de maneira ampla, e não apenas por algumas equipes ou colaboradores.

A questão é: como testar de forma ágil?

O QA Ágil

Em times ágeis, a rigor não há o papel de “analista de testes”: ou você é scrum master, ou é product owner, ou é desenvolvedor. Além disso, como não há uma fase de testes ao final do projeto (algo que é típico do modelo Waterfall), o profissional de testes precisa participar ativamente do processo inteiro.

É importante que ele colabore com a elaboração dos critérios de aceite, desenvolva testes automatizados e realize os testes propriamente ditos conforme os itens do backlog de sprint são entregues pelos desenvolvedores.

Cabe destacar que a qualidade, numa cultura ágil, não é responsabilidade exclusiva do QA, e sim de todo o time.

A [desnecessária] disputa entre Devs x QAs

Esse entendimento a respeito da qualidade é um dos pilares da testagem ágil. Sem ele, é muito provável que os testes sejam delegados exclusivamente a um time de QA, em um pouco eficiente cenário bi-modal.

Gasta-se com isso muito tempo e esforço produzindo documentações (com casos de testes, registros de testes realizados, casos de uso etc.) ao invés de promover uma colaboração realmente eficiente entre os profissionais de QA e os Times Scrum. Também cresce o risco de conflitos entre “os dois lados”, com devs acusando QAs de atrasar a entrega do projeto e QAs acusando devs de entregar softwares mal escritos.

Todos pela Qualidade

Há uma série de maneiras pelas quais os testadores de um time ágil podem ser “evangelistas da qualidade” na equipe:

• Desenvolver testes funcionais automatizados;
• Ajudar o PO a escrever critérios de aceite para suas histórias de usuário;
• Realizar ATDD (Acceptance-test-driven development), BDD (Behavior driven development) e/ou testes Specification-by-example;
• Ajudar o Scrum Master a definir e monitorar as métricas de qualidade do time;
• Ajudar os devs a escrever testes unitários automatizados.

Desenvolver especificações e testes no início da sprint e iniciar os testes conforme os itens de backlog são entregues é mais eficiente do que apenas escrever documentos de testes no início da sprint e testar o software no final.

Automatizar é preciso

A automação é crucial para garantir uma sólida cobertura de testes no software. Mas como encaixá-la na cultura ágil?

O primeiro passo é escrever testes unitários, independentemente de a equipe adotar a abordagem TDD ou não. Nos testes funcionais automatizados está um dos pontos fortes de frameworks como ATDD, Specification-by-example e BDD.

Dentro do mindset ágil, os profissionais de qualidade escrevem requisitos junto ao profissional de negócio – com isso, a especificação é o próprio caso de teste funcional a ser automatizado, e os devs entregam incrementos pequenos e facilmente testáveis.

Realizar uma transformação ágil na sua organização é possível e vai elevá-la a um novo patamar. Quer saber como? Clique aqui e entre em contato com um especialista.