O papel do QA nas iterações ágeis
Algumas dicas de como melhorar o seu trabalho com Quality Assurance.
Em ambientes ágeis o QA tem diferentes atividades ao longo de toda iteração (e mesmo antes de ela começar). O time todo deve ser responsável pelas atividades de teste, mas nós como QAs ainda somos os principais responsáveis pela cultura de qualidade.
Segundo Lisa Crispin e Janet Gregory no livro “Agile Testing”, programar e testar são duas etapas do mesmo processo de desenvolvimento de software, e a entrega ocorre quando os dois papéis trabalham de forma próxima para contribuir incrementalmente a cada iteração ágil. Neste post, vamos passar por algumas dicas de como trabalhar de forma ágil garantindo a qualidade dos produtos. Vamos lá?
Quais princípios ágeis devem guiar a automatização de testes?
- Mantenha simples
Assuma um design enxuto, com escopo mínimo e utilize a ferramenta mais simples para automatizar. - Feedback iterativo
Pequenas iterações permitem testes com diversas abordagens e avaliação rápida dos resultados: estamos entregando o resultado esperado? Caso não, é possível mudar o caminho para a próxima iteração. - Abordagem de time
A automatização dos testes deve existir, mas nem todo o time tem conhecimento em programação. A proximidade entre desenvolvedores e QAs pode auxiliar na velocidade do aprendizado e na diminuição do débito técnico do time. - Ter tempo para fazer o certo
Resolver problemas e desenvolver soluções robustas demora, e a pressão para entregas rápidas e com alto volume é contraproducente. As iterações deveriam considerar tempo para brainstorming de ideias, treinamento formal e o desenvolvimento em si. - Aprenda fazendo
A melhor forma de aprender a programar é escrevendo seus próprios casos e códigos. Quanto mais cometer erros e aprender a resolvê-los, mais rápido evoluirá. - Aplique os fundamentos de “Agile Coding” nos testes
Faça pareamentos, refatoração constante dos testes, design orientado a objetos e testes independentes entre si.
O que podemos adiantar antes mesmo da iteração começar?
1. Planejamento de testes
O intuito de planejar os testes é mitigar os riscos analisados, conhecer as histórias e caminhos que serão automatizados, mapear quais recursos de infraestrutura serão necessários para o ambiente de testes e como será disponibilizada a massa para eles.
O maior benefício é endereçar preocupações e antever soluções de bugs de alto risco. Para este momento não decidimos “como testar cada história” e sim “quais tipos de testes serão feitos” (pensando nos quadrantes de testes — figura acima).
Um dos objetivos é preparar a infraestrutura de integração contínua, para que os testes automatizados estejam numa pipeline, e os builds feitos em ambiente estável o suficiente para os demais testes.
2. Ampla visão do produto
Devemos entender como cada história vai afetar o sistema como um todo (principalmente os legados). É preciso coordenar previamente o envolvimento de terceiros no projeto e planejar tempo extra para testar a aplicação em conjunto, já que a integração envolve riscos e incertezas. É recomendado começar os testes de interfaces o mais cedo possível.
Se for trabalhar em uma funcionalidade nova com ferramentas novas, seja realista e considere os riscos e prazos envolvidos no processo. Caso tenha tido iterações anteriores e exista bugs reportados em produção, é importante priorizar e estimar a solução deles, já que afetam diretamente o valor gerado para o cliente.
O que podemos fazer para não negligenciar os testes?
1. Ajudar na definição das histórias a serem desenvolvidas
Participamos das reuniões de planejamento de iteração com o objetivo principal de questionar diferentes aspectos da funcionalidade e a definição do valor a ser entregue. Mantemos constante colaboração com clientes e programadores para escrever testes de alto nível, que guiarão o desenvolvimento das funcionalidades, elucidarão dúvidas e ilustrarão exemplos de usuários reais (testes de aceitação ou User Acceptance Tests).
Também consideramos todos os pontos de vista da mesma história, ajudando na definição de cenários alternativos.
2. Auxiliar nas estimativas, na priorização e na análise de risco
Precisamos fazer estimativas das atividades de programação e de teste, tanto para codificação de testes unitários quanto pra desenvolvimento de cenários end to end. Outra abordagem comum é a criação de colunas para identificação das tarefas que estão prontas para teste. Tarefas (ou histórias) estarão “finalizadas” somente quando estiverem completamente testadas.
Podemos auxiliar na priorização das histórias e na definição de story points por meio de questionamentos: “qual valor será entregue nessa história?”, “como o usuário final utilizará a funcionalidade de fato?”, “o que poderia acontecer de pior?”, “quais considerações de teste poderiam modificar a estimativa?”, “será trabalhoso conseguir massa para os testes?”, “terá alguma dependência de terceiros ou riscos severos?”.
Uma rápida análise de risco pode determinar a priorização e o foco dos testes da aplicação. Talvez seja uma história mais complexa ou que tenha foco na segurança, usabilidade, performance, etc..
3. Escrever os testes em alto nível em primeiro lugar
Quando as histórias tiverem sido divididas em tarefas menores, começamos a escrever os casos de teste em alto nível. Revê-los com clientes aumenta a transparência e melhora a comunicação, mas também é necessário fazer o alinhamento de expectativas com os programadores, que podem utilizá-los para guiar o desenvolvimento e contribuir com uma visão mais técnica.
Conforme pequenos pedaços testáveis de código são produzidos, podemos começar a automatizar, mesmo sem ter a interface disponível. O primeiro e mais simples cenário deve ser o caminho feliz, aquele que garante que a funcionalidade principal está entregando o valor esperado. Depois que o mínimo foi garantido, podemos adicionar outros casos de teste e utilizar edge cases.
4. Testar de forma incremental
Assim que testes automatizados já estiverem garantindo alguma qualidade da funcionalidade, é o momento de começar os testes exploratórios (manuais): tente cenários diferentes e observe se o comportamento está alinhado com o esperado. Se o resultado desses testes apresentar uma funcionalidade que não tinha sido coberta anteriormente, novas histórias de desenvolvimento podem ser criadas para próximas iterações.
Assim que a interface estiver pronta já é indicado mostrá-la aos usuários para obter feedbacks rápidos pois podemos descobrir algo que não estava claro anteriormente.
Em um cenário ideal, já há um conjunto de testes automatizados de regressão que está rodando numa pipeline integração contínua. Caso não seja sua realidade, esta infraestrutura deve ser a prioridade do time.
O objetivo dos testes de regressão é detectar mudanças inesperadas que afetam o sistema e que não perceberíamos facilmente de forma manual. Caso tenha um conjunto rodando, poderá adicionar outros casos críticos para a funcionalidade conforme for evoluindo.
Programadores deveriam rodar todos os testes unitários antes de enviar o código para a integração. Caso algum falhe, a prioridade é consertar. A integração contínua deve ser rápida e, por isso, os testes da pipeline não podem demorar. Testes mais longos, como os de integração e end to end, por exemplo, devem ser programados e rodados separadamente.
5. Resolver bugs assim que forem detectados
Mostrar os bugs para os programadores sempre será mais eficiente do que reportá-los em alguma ferramenta. Reportar é o mais indicado somente caso não haja ninguém disponível para resolver naquele momento.
Solucionar bugs são prioridades em relação a novas funcionalidades. Quando mandados para produção acumulam débito técnico, e precisarão ser resolvidos num futuro próximo. Código de má qualidade fará a velocidade de entrega diminuir. A solução é uma política de “zero bugs” ou planejamento de iterações específicas para resolver os problemas pendentes e refatorar os códigos, promovendo sustentabilidade ao projeto.
6. Ter documentação simples e dinâmica
Os próprios casos de testes de alto nível e os relatórios gerados pela automatização servem como documentação em um ambiente ágil. Exceções poderão ser tratadas de acordo com exigências específicas da gerência ou dos clientes.
Qual nosso papel no final da iteração?
1. Chegou o “end game”
Se a funcionalidade estiver estável e as tarefas de desenvolvimento foram finalizadas, é o momento de nos preocupar com o ambiente de pré-produção e de produção, contactar os administradores das bases de dados e todos que estejam relacionados.
Testes de integração dos sistemas, de carga e de estresse serão aplicados em ambiente de pré-produção, pois é o mais próximo do de produção. Também serão feitos os últimos testes exploratórios focando no sistema como um todo em cenários end to end.
2. Recolher feedbacks imediatos dos usuários
Os testes de aceitação do usuário (UAT) tem como objetivo verificar a usabilidade da funcionalidade (visão de negócios do produto), e eles devem começar assim que algumas tarefas são finalizadas.
Caso esteja trabalhando em funcionalidades para o grande público, existem os testes Alpha e Beta. O Alpha serve para obter feedback da funcionalidade como um todo e o Beta para reportar os problemas encontrados.
3. Colher métricas
A porcentagem de cobertura de código vai medir se os módulos programados estão sendo testados, mas não garantem que a funcionalidade foi desenvolvida seguindo a expectativa do cliente.
Muitas funcionalidades precisam de treinamento customizado para os usuários e nós somos alguns dos profissionais mais indicados para ministrá-lo, já que entendemos as demandas do negócio e sabemos como a funcionalidade foi desenvolvida.
4. Buscar promover entrega contínua
Quando produzimos pequenos incrementos de software com qualidade com determinada frequência, podemos escolher quando lançá-los. Pequenas entregas possuem menor risco de um impacto negativo massivo, principalmente se esse processo for automatizado e rápido.
E é isso! Espero que essas dicas te ajudem a trabalhar de forma cada vez mais ágil e promovendo uma cultura de qualidade. Lembrando que este artigo foi baseado nas páginas 298 a 304 e 327 a 517 do livro “Agile Testing”, de Lisa Crispin e Janet Gregory. Tem alguma dúvida ou observação? Aproveite o campo de comentários. E se você quiser trabalhar com testes em um time ágil de verdade é só dar uma olhada aqui e se candidatar a uma de nossas vagas. Vamos aprender juntos! Até a próxima.
Baseado em “Agile Testing”, págs 298 a 304 e págs 327 a 517.
