Casos de teste no Ágil
Uma reflexão sobre documentação suficiente
Faz sentido usar casos de teste dentro de um contexto Ágil? Será que isso nos ajuda ou nos atrapalha? Neste artigo eu trago um pouco da minha experiência para te ajudar a tirar suas próprias conclusões.
Um pouco da minha história
Assim como boa parte de quem começa a trabalhar na área de testes, me senti um pouco perdida no início. Por onde começar? Como organizar meu próprio trabalho para ajudar o meu time o máximo possível?
Sempre trabalhei em um time Ágil e sempre fui a única QA do time. No início, parecia fazer sentido documentar com algum nível de detalhe os testes que eram feitos, no formato de casos de teste usando a ferramenta TestLink.
Na minha visão na época, isso aparentava ser um ganho de produtividade, pois resolvia 2 problemas:
- Se precisar testar isso de novo depois, não vou precisar planejar este teste novamente (ainda não fazia ideia do poder da automação de testes)
- Se novos membros entrarem para o time, vai ser mais fácil explicar a eles o que testar (o que poderia ser resolvido com uma sessão de testes em par, por exemplo)
Com o passar do tempo, algumas fichas foram caindo.
Era sempre uma correria pra conseguir testar tudo até o término da sprint (até aqui nenhuma novidade: todos que atuam em um contexto Ágil passam por isso). Então no fim das contas muitas vezes não dava tempo de olhar de novo todos os casos de teste que tinham sido criados no passado para ver o que valia a pena testar de novo. Acabava fazendo sessões de testes exploratórios para cobrir o mais importante em busca de alguma regressão e fazia os testes das novas features da sprint.
Nos testes exploratórios, costumava utilizar minhas próprias heurísticas para guiar a sessão. Depois acabei descobrindo que já existem várias heurísticas super úteis, como as mencionadas neste post do Gabriel Santos.
Além disso nunca sobrava tempo para atualizar os casos de teste pertinentes quando mudava a especificação. Então eu sabia que alguns dos casos de teste registrados nem serviam mais e acabavam ficando misturados com casos de teste que ainda eram válidos. Simplesmente um caos se formava.
Ao gastar tempo valioso da sprint escrevendo tantos artefatos eu estava indo no caminho inverso a um dos valores do Ágil, que diz:
Software funcionando, mesmo com funcionalidade reduzida, é muito mais útil e valioso do que documentação excessivamente detalhada
E dessa forma tinha a sensação de que cada vez mais os meus casos de teste eram uma bola de ferro no meu pé, ao invés de ser uma mão na roda.
Quando tinha novos membros no time para me ajudar a testar, era muito mais fácil explicar para eles cara a cara o que tinha que testar ou fazer sessões de testes em par do que pedir que eles ficassem lendo os casos de teste. É exatamente isso o que diz um dos princípios do Manifesto Ágil:
O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa face-a-face
Após essas fichas iniciais terem caído, passei um tempo usando casos de teste, mas como uma lista de verificação para que eu lembrasse o que era mais importante. Nem chegava a colocar detalhes nos passos, era bem alto nível. Fui reduzindo cada vez mais a documentação, pois percebi que não precisava de tantos detalhes assim, nem tinha tempo de olhar. Fui adotando mapas mentais em substituição aos casos de teste. Ou seja, passei a documentar as condições de teste, ou ideias de teste.
Fazendo essas mudanças, ganhei mais tempo para interagir com o time e ajudá-los a desenvolver com qualidade, dando insights sobre testes e qualidade de software. Também ganhei tempo para investir no que realmente importa: testar o software e construí-lo com qualidade.
E o que a minha história pode nos ensinar?
O ponto principal é: entenda o contexto onde você está inserido. Não estou dizendo que casos de teste devem ser abolidos para sempre em todos os times. A questão é que no meu dia-a-dia eles estavam mais me atrapalhando do que ajudando.
Porém, existem situações em que casos de teste fazem sentido, por exemplo no contexto tradicional. Nesse caso, eles são muito comuns e úteis. Mas não podemos esquecer que o contexto tradicional tem características muito diferentes do contexto Ágil.
Relembrando algumas diferenças entre o contexto tradicional e o Ágil:
- Separação de papéis: enquanto em um time Ágil o QA planeja e executa testes, no tradicional há papéis separados para cada atividade (analista de teste e testador, respectivamente).
- Tempo disponível: no tradicional, existe uma fase específica de testes, que ocorre ao final do projeto. Dessa forma, o time de teste tem meses para planejar os testes. Já num contexto Ágil, os ciclos de desenvolvimento costumam ser de 2 semanas, ou seja, o tempo para o planejamento de testes é extremamente reduzido.
- Escopo: no tradicional, o escopo é fechado. Isso significa que ele não sofrerá quaisquer alterações até o final do projeto. Já no Ágil, o escopo é aberto, o que indica que mudanças nos requisitos poderão ser constantes e o time deve ser capaz de lidar com isso.
Consegue perceber que casos de teste encaixam como uma luva em um contexto tradicional, mas não fazem sentido em um contexto Ágil?
Você deve estar pensando agora: ok, entendi que criar e manter casos de teste no Ágil é inviável. Mas como eu mantenho uma documentação suficiente nesse contexto? Ou não documento nada?
Calma! Não vamos ser tão radicais :)
Não estou dizendo que não é pra ter documentação nenhuma dos testes que são feitos, apenas acredito que existem formas melhores de fazer isso do que escrever páginas e páginas de casos de teste que só você (ou nem você) vai ler :)
Então o que vale a pena documentar em um contexto Ágil? Segue uma lista que pode te ajudar:
- Documente bem os bugs encontrados: passos para reprodução, mencionar claramente o impacto do problema para os usuários, estabelecer prioridade, severidade e também a classificação do defeito. Essas informações vão ajudar na reprodução e correção do problema, bem como ajudarão no levantamento de métricas para melhoria do processo de desenvolvimento.
- Faça mapas mentais para documentar os testes planejados, mas sem excesso de detalhes, apenas o que é suficiente para que você saiba o que precisa ser feito. No planejamento dos testes é fundamental o uso de técnicas de teste para que possamos testar mais gastando menos tempo.
- Automatize testes! Não há documentação melhor do que uma que pode ser executada, não acha? Além de saber como você testou no passado, ela vai te ajudar a testar no presente e nesse caso sim, vale a pena dar manutenção, porque vai te ajudar a testar no futuro!
- Documente os riscos relacionados à história ou funcionalidade que está sendo desenvolvida. Eles serão uma importante base para os testes baseados em riscos. Para saber mais sobre esse tipo de teste, super recomendo esta apresentação.
- Decisões importantes tomadas pelo time também devem ser documentadas em um lugar visível para todos, por exemplo em uma Wiki.
- Reports de testes exploratórios baseados em sessão.
Neste artigo, contei um pouco da minha experiência com casos de teste em um contexto Ágil. Espero que tenha te ajudado a refletir sobre a sua experiência com o uso de casos de teste.
Acredito que o ponto principal é sempre questionarmos se a forma como trabalhamos e as ferramentas que usamos estão nos ajudando ou nos atrapalhando, ao invés de seguir trabalhando sempre da mesma forma por pura força do hábito.
Como James Bach nos ensinou em Lessons Learned In Software Testing: teste depende do contexto e o Ágil é bem diferente do tradicional.
Pense nisso ;)
Agradecimento especial aos meus queridos revisores: Julio de Lima, Gabriel Santos, Juliana Santana e Paulo Oliveira
