Um dos princípios fundamentais do desenvolvimento Agile é que o teste é uma responsabilidade comum. Todo mundo na equipe deverá descobrir o que testar e testar o produto. Em essência, toda a equipe é co-proprietária de todos os testes.

No entanto, alguns tipos de testes, especialmente os testes funcionais, são difíceis de ser compartilhados. Ao contrário dos testes unitários, que são conceituados e implementados por desenvolvedores, os testes funcionais são geralmente implementados por desenvolvedores, mas conceituados por outra pessoa (podendo ser engenheiros de produto, QA, BA, testadores, ou outros papéis. Pelo bem da sanidade, vou me referir a esse grupo como QA). Essa dinâmica força uma transferência, o que torna difícil de realmente compartilhar de testes.

Uma maneira de lidar com essa questão é exigir que todos os membros de uma equipe Agile possa tanto conceituar quanto implementar testes funcionais. Em outras palavras, certifique-se de que cada membro da equipe possa codar. Apesar de possível, essa abordagem elimina todo um grupo de profissionais de QA que são ótimos para entender o que testar e encontrar bugs, mas não estão interessados em escrever código. Isso não é o ideal.

Uma maneira melhor é o QA e os devs unirem forças e escreverem testes juntos. Essa colaboração poderia funcionar como a técnica de “teste ping-pong”, comum no pareamento TDD. Ao usar essa técnica, um desenvolvedor escreve um teste de falha e seu par escreve o código de passagem. Não seria ótimo se houvesse uma maneira de fazer algo semelhante com um pareamento QA/Dev?

Felizmente, existem ferramentas disponíveis que tornam esse tipo de colaboração possível. Vou me concentrar em duas: Test Manager e Twist.

Os competidores

Microsoft Test Manager

A Microsoft lançou o Test Manager como parte do Visual Studio 2010. Ele permite que você defina casos de teste e organize-os. Cada caso de teste é um conjunto de passos, e eles podem ser compartilhados (o que significa que um passo pode ser reutilizado em diferentes casos de teste). Eles podem ser automatizados usando Coded UI Tests, que são escritos em C# e podem ser executados contra um navegador.

Twist

O Twist é uma ferramenta da ThoughtWorks Studios. Ele também permite que você defina casos de teste, organize seus testes, e automatize os passos dentro de um caso de teste usando Sahi ou Selenium. Você interage com o Twist por meio de uma versão personalizada do Eclipse, e os testes são automatizados em Java.

A comparação

Sei que essas duas ferramentas são muito mais do que apenas a criação de testes, mas estou basicamente interessado em saber como elas solucionam o problema da colaboração. Para entender isso, precisamos considerar como cada ferramenta facilita “passar o bastão” entre QA e desenvolvedores. Correndo o risco de simplificação excessiva, deve ser fácil fazer algo assim:

• QA escreve um teste e entrega o teclado ao Dev
• O Dev escreve o código para implementar o teste
• Ambas as partes executam o teste e se certificam de que ele passa
• Dev entrega o teclado de volta para QA
• Enxágue e repita a operação para melhores resultados

Com a solução da Microsoft, os QAs deverão trabalhar em um ambiente (Test Manager), enquanto os devs estarão em outro (Visual Studio). Esse fato por si só torna a colaboração que eu descrevi acima relativamente envolvida e desnecessariamente complicada:

No Visual Studio:

 

No Text Manager:

 

Por outro lado, o Twist permite que ambas as partes coexistam no mesmo ambiente, e transferir um teste escrito para implementação é literalmente tão simples quanto selecioná-lo e pressionar e Ctrl + Clique. O Twist cria automaticamente (ou reutiliza) uma classe conteiner Java com uma função nomeada com o mesmo nome que a etapa de teste:

 

O ponto principal

Mesmo correndo o risco de dizer o óbvio, vou afirmar que apenas uma dessas ferramentas torna mais fácil colaborar, e ela não é o Test Manager. Para ser honesto, isso é bastante decepcionante, pois o Test Manager se integra muito bem no desenvolvimento do ecossistema da Microsoft e ele teria sido bom de usar.

***

Texto original disponível em http://tatiyants.com/agile-testing-dev-qa-collaboration/