Um time Ágil que não preza pela qualidade não é realmente Ágil.
Por que testamos?
Normalmente, encaramos o desenvolvimento de testes apenas como uma forma de garantir a qualidade, porém testes são muito mais sobre design que sobre qualidade. Eles são guias para que o desenvolvedor possa saber se está fazendo a coisa certa da maneira correta. Além disso, eles orientam o desenvolvedor na definição das responsabilidades e fornecem um rápido feedback sobre o software desenvolvido.
Em um time Ágil quem é responsável pela qualidade?
A responsabilidade pela qualidade do software produzido por um time Ágil é do próprio time.
“Ah, então, pra que serve um QA em um time Ágil?”
O papel de um QA em um time Ágil é de estar à frente em relação ao conhecimento sobre quais os testes mais adequados para determinadas situações e como realizar tais testes. Qualquer membro de um time Ágil pode assumir uma tarefa de desenvolver testes, e o QA deve ajudar quando for necessário.
Os Quadrantes de Testes
Os quadrantes de testes servem como guia para saber quais testes deveríamos fazer, como eles contribuem para o time ou produto e como tais testes encaram o produto.
Technology-Facing x Business-Facing
Enquanto os testes que estão voltados para o negócio verificam o modo como o dado está sendo apresentado e validam se o software atende os critérios de aceitação propostos pelo cliente, os testes voltados à tecnologia verificam se aquele dado foi calculado corretamente e validam o funcionamento do software tentando detectar possíveis erros de execução.
Supporting the Team x Critique Product
Testes que suportam o time são aqueles testes que permitem que o time sinta confiança no produto entregue. Com eles, é possível saber se o software produzido está atendendo aos critérios propostos pelo cliente e permitem que o desenvolvedor saiba se seu código está funcionando como o esperado.
Já os testes que criticam o produto tentam levá-lo à casos extremos, a fim de detectar bugs que normalmente não seriam percebidos. Com isso, ele previne que o software falhe em aspectos como carga e segurança.
Testar antes de desenvolver.
Às vezes, imersos em um problema durante o desenvolvimento de um software, podemos acabar perdendo a visão do todo e deixar de desenvolver parte do escopo do software. Escrever os apropriados testes antes de desenvolver pode evitar que isso aconteça. Parece complexo pensar em testar antes de desenvolver, né? Porém, é bem menos difícil que aparenta.
Existem diversos métodos para testar antes de desenvolver. No BDD, por exemplo, é possível escrever testes para as features antes de começar a desenvolver.
Exemplos de funcionalidades também podem ser úteis onde não cabe um BDD. Veja como um teste de funcionalidade pode fazer a diferença:
Um time precisava desenvolver um software que alertasse o suporte quando um pedido estivesse muito tempo sem status definitivo, pois isso poderia indicar um problema relacionado ao processamento do pedido. O software solicitado permitiria que o suporte visualizasse os pedidos e os recriasse caso necessário.
Entretanto, o time estava pisando em território totalmente incerto e eles não sabiam exatamente quais ferramentas utilizar no desenvolvimento do alerta. Com isso, passaram tanto tempo pesquisando e desenvolvendo que esqueceram completamente que nem sempre esse alerta indicaria que o pedido estava realmente com problemas, que, por exemplo, poderia simplesmente ser uma lentidão no processamento e ele não deveria ser recriado. No ato da entrega, o alerta tinha apenas um link permitindo a recriação dos pedidos.
Este erro só foi percebido no momento do review do cliente. E, com toda a sua razão, o cliente reprovou o review e ainda se justificou: “Não é possível que o suporte recrie um pedido sem ver os dados dele. Precisamos decidir se é ou não necessário recriá-lo.”
Este problema poderia ser evitado com um simples teste:
No caso de um ou mais pedidos ficarem por mais de 10 minutos com um status não definitivo, eu gostaria de receber um alerta que me permitisse verificar as informações deles e ter a opção de recriar os que eu julgar necessário.
Quando usar ou não um E2E
Testes ponta-a-ponta simulam o comportamento do usuário, por isso é o teste mais próximo da realidade que se pode fazer. Entretanto, eles são caros para desenvolver, manter e executar. Além disso, eles não fornecem um feedback preciso de onde se encontra o erro. Por estes motivos, os mesmos devem ser usados em casos onde não é possível testar em níveis mais baixos como de Integração ou Unitário.
Teste Unitário
Testes unitário testam a menor unidade possível do seu código. Para isso, muitas vezes eles utilizam mocks de dados ou de outras funcionalidades. Eles são fáceis de manter, baratos de executar e possuem um feedback preciso. Quando acontecem falhas, é possível identificar precisamente onde está o erro. Os testes unitários dão mais confiança ao desenvolvedor no código produzido.
TDD
TDD é a pratica de escrever os testes antes do código. Não tem como alguém entender o que é TDD e não achar que é uma boa ideia! Porém, ainda assim, é uma prática difícil de ser executada e implementada.
Confesso que, eu que gosto muito de testes, não sou muito fã de testar quando todo o código está pronto. É realmente horrível a sensação de “eu poderia estar tomando um café ou fazendo uma nova tarefa, mas estou aqui escrevendo os testes para uma solução pronta”.
Além disso, acaba gerando um problema grave de “testes por formalidade” ou “testes que não testam nada”, além de aumentar muito o tempo gasto para fazer os testes, pois um código que não foi feito para ser testado vai ser refatorado diversas vezes para que se torne “testável”.
O TDD colabora no design do código, já que o código é feito depois do teste e ele já é escrito de forma que permita ser testado. Mesmo que o desenvolvedor fique imerso em resolver um problema encontrado na codificação de um método, ele não esquecerá de verificar se a solução encontrada cobrirá todo o problema, pois os possíveis casos já foram escritos como teste antes. O TDD também induz o desenvolvedor a definir melhor as responsabilidades de cada método do seu código, evitando uma complexidade muito alta nele.
Consequências de não testar ou testar de forma errada
As consequências de testar de forma errada são os testes por formalidade. Na verdade, eles não testam quase nada e tem como objetivo apenas atingir o coverage do código. Testes assim fazem com que existam bugs em excesso e que o time gaste muito tempo corrigindo-os.
Mas, o que é testar de forma errada?
É não fazer o teste de uma forma eficaz, por exemplo, testar após todo o código estar pronto.
Então, a única forma correta de testar é o TDD?
Certamente não. Mas foi a única solução efetiva que eu encontrei até hoje.
Pior que testar de forma errada é não testar. Às vezes, por testar de forma errada, o time passa a ter uma falsa sensação de que o tempo gasto testando é desperdício e que está tudo bem negociar a qualidade do software para entregar no tempo. Dessa forma, fica muito fácil entrar em débito técnico e gerar excesso de bugs no software desenvolvido.
Falsa sensação de perda de tempo ao testar. É falsa porque mesmo que demore mais para o software ficar pronto, o tempo que o time ganha pela redução no número de bugs e no tempo gasto para resolver um bug é imensa.
E, então, por que testamos?
Testamos para produzir um software de qualidade que atenda o cliente e que possa ser mantido sem que uma alteração atrapalhe todo o funcionamento do software, para reduzir o número de bugs e para que, em caso de um bug apareça que ele não se repita.
