Então a empresa decide adotar métodos ágeis top-down. Show, geralmente o alto escalão é quem boicota esse tipo de iniciativa. Começar com seu apoio já é meio caminho andado. A outra metade do caminho? Convencer o restante da empresa a fazer o movimento bottom-up da transformação ágil.

Embora para algumas pessoas isso possa soar muito fácil, não é tão fácil quanto parece – principalmente quando colocamos dois elementos-chave na equação de qualquer transformação ágil: sustentação e testes. Pretendo falar de sustentação em outro artigo, hoje vou me focar na questão de $1M, que é: como testar de maneira ágil?

O papel do testador em um Time Ágil (QA)

O primeiro ponto a ser definido, antes de falar de práticas, é do papel do testador. Primeiro que em Times Scrum (e 90% dos times usam Scrum ou ao menos ScrumBut), não existe o papel do analista de testes. Todo mundo que não é PO nem Scrum Master é um Desenvolvedor. Um analista de testes é alguém que colabora no desenvolvimento do produto. Logo, é co-responsável por todo o ciclo de desenvolvimento do mesmo, não apenas os testes.

Uma vez que, ao contrário do modelo Waterfall, não teremos uma fase de testes ao final do projeto, cabe ao profissional de testes participar ativamente de todo o processo, desde o planejamento (quer alguém melhor do que um QA para ajudar com critérios de aceite?), ao desenvolvimento – seja Pair Programming ou mesmo desenvolvendo testes automatizados – e finalmente os testes propriamente ditos, que ao invés de serem realizados todos no final do projeto (ou mesmo no final da iteração), devem ser realizados conforme os itens do Sprint Backlog venham sendo entregues pelos desenvolvedores.

Ufa! Sim, um QA Ágil tem muito mais trabalho que um QA tradicional, tendo de acompanhar o restante do time durante o dia a dia do projeto, ajudando-os, ao invés de focar-se em encontrar o maior número possível de bugs no final do projeto.

Não obstante, vale lembrar que qualidade não é responsabilidade exclusiva do QA, mas sim de todo o time, e cabe à ele também ressaltar e criar uma cultura de qualidade dentro do time constantemente, como se fosse um Scrum Master da qualidade ou QA Master.

Teste tradicional x Ágil

Essa mudança de mindset do profissional de qualidade é vital para que ele consiga entrar no modelo ágil do time. Isso porque com alguma frequência, times de desenvolvedores adotam métodos ágeis mas não agilizam os testes, geralmente delegando essa atividade para um time de QA, que muitas vezes fica em outro setor.

Neste cenário bi-modal, geralmente o time de QA vai se focar em construir documentações pesadas com casos de teste e registros dos testes realizados, além de exigir do time de desenvolvimento as demais documentações do projeto, como casos de uso (às vezes aceitam histórias de usuário).

O que acontece, é que dessa forma gasta-se um tempo e esforço enormes produzindo documentação quando poderíamos aproximar profissionais de QA dentro dos Times Scrum e colocá-los a trabalhar com o time, e não para o time.

Essa burocracia, aliada a uma cultura de “última linha de defesa da qualidade do software” gera um histórico enorme de conflitos entre devs e QAs que é totalmente desnecessário. No momento que algumas empresas separam a responsabilidade da qualidade entre times diferentes, um inadvertidamente culpa o outro por todo o tipo de problema encontrado no processo de desenvolvimento. Frases como:

• Os devs me largam software de qualquer jeito pra testar!
• Os QAs estão atrasando a entrega do projeto!
• Sou o maior, achei 30 bugs na última release do software, esses devs são uns incompetentes!
• Eu não vou testar o software que desenvolvi, os QAs são pagos pra isso!
• Entre outras pérolas.

O fato é que não há como ter um time ágil se o processo de QA não é ágil. A sprint não pode ser considerada bem sucedida se não temos todos itens do sprint backlog como DONE. E francamente, eles não podem estar definidos como DONE se não tiverem sido testados ainda.

O mindset do QA Ágil

Ao invés de se posicionarem como a última linha de defesa, os testadores de um time ágil devem se colocar como os evangelistas da qualidade dentro do time:

• Ajudando o PO a escrever critérios de aceite para suas User Stories;
• Realizando ATDD, BDD e/ou Specification by Example;
• Ajudando os devs a escreverem testes unitários automatizados;
• Desenvolvendo testes funcionais automatizados;
• Ajudando o Scrum Master com as métricas de qualidade do time;
• E, em último caso, realizando testes funcionais tradicionais.

Ou seja, o trabalho do QA não pode estar limitado a escrever documentos de teste no início da sprint e testar o software no final (isso sempre dá errado), mas sim desenvolver especificações e testes no início da sprint e iniciar os testes de software conforme os itens de backlog forem sendo entregues.

Só desta forma é que é possível garantir qualidade e agilidade ao mesmo tempo. Para resultados excepcionais, os profissionais do time devem estar dispostos a uma dedicação excepcional.

Automação de Testes

Você deve ter percebido que, em vários momentos, eu falei de automação de testes (ou alguma de suas práticas). Isso porque simplesmente não tem como falar de teste ágil de software sem falar de automação de teste.

Imagine o seguinte cenário: um desenvolvedor termina de codar a US001, ele entrega para o QA testar e o QA testa a US001. Outro desenvolvedor termina de codar a US002 e entrega para o QA. Como ela possui dependência com a US001, o QA testa a US002 e a US001 para garantir que tudo continua funcionando. O primeiro desenvolvedor termina uma US003 que causou mudanças em trechos de código que impactam outra user stories do sistema, mas sem clareza de quais são, logo, o QA faz uma regressão, testando US001, US002 e US003.

E quando o sistema atingir a marca da US100? Ou da US1000? Quantos QAs você vai precisar no seu time para atender à demanda de testes necessária?

Automatizar testes é a única maneira de garantir uma cobertura de qualidade no seu software. Não é uma questão de ser ágil ou não, mas uma questão de ser honesto quando você diz que seu sistema está 100% testado ou não.

Escrever testes unitários é o primeiro passo e deve ser regra dentro do seu time de desenvolvimento, independente de usarem TDD ou não. Mas são nos testes funcionais automatizados que está a beleza de frameworks como ATDD, BDD e Specification by Example.

Profissionais de qualidade modernos e realmente ágeis não escrevem documentação de teste para depois passarem horas fazendo testes manuais. Eles escrevem requisitos junto ao profissional de negócio de maneira que a especificação é o próprio teste funcional automatizado, ao mesmo tempo que garantem que os devs vão lhe entregar incrementos pequenos e facilmente testáveis, além do que eles já devem ter passado por uma bateria de unit tests.

Se você é um profissional de testes e quer continuar com demanda no mercado, principalmente nas empresas mais tops de tecnologia, você tem de aprender automação de testes. Fazer teste funcional hoje, é o mesmo que querer programar perfurando cartões: lento, ineficiente e não escala bem.

Referências

Vou ser sincero com você: meu livro de Scrum e Métodos Ágeis não fala de teste ágil de software. Mas as leituras abaixo falam muito bem:

• Test Driven Development
• eXtreme Programming
• ATDD by Example
• Agile Testing
• More Agile Testing

Tem outros livros ou dicas para compartilhar? Deixe nos comentários!