Projetando maior qualidade com práticas de testes ágeis

Ainda há uma necessidade de testes manuais– mas não do modo como você pensa!

Dan Radigan Dan Radigan
Buscar tópicos

O gerenciamento de projetos cascata separa o desenvolvimento e o teste em duas etapas diferentes: os desenvolvedores criam um recurso e, em seguida, encaminham para a equipe de garantia de qualidade (GQ) para testes. A equipe de GQ escreve e executa planos de teste delineados. Eles também arquivam defeitos ao verificar com muita atenção regressões em recursos existentes que possam ter sido causadas pelo novo trabalho.

Muitas equipes que usam os modelos de teste cascata ou outros tradicionais percebem que, à medida que o produto é desenvolvido, a quantidade de testes aumenta exponencialmente, e a equipe de garantia de qualidade sofre para acompanhar o ritmo. Os proprietários de projeto encaram uma escolha indesejável: atrasar a liberação ou economizar no teste. (Vou dar uma chance para você acertar qual opção ganha 99% das vezes). Nesse meio tempo, o desenvolvimento foi movido para outro local. Então, o débito técnico não apenas acumula, como também abordar todos os defeitos exige uma troca de contexto custosa entre duas partes da base de código. Insulto, conheça a lesão.

Para piorar a situação, as equipes de garantia de qualidade são tradicionalmente recompensadas de acordo com a quantidade de bugs encontrados, o que coloca os desenvolvedores na defensiva. E se houvesse uma maneira melhor para ambos, desenvolvedores e garantia de qualidade, reduzir o número de bugs no código e, ao mesmo tempo, eliminar essas trocas dolorosas que os proprietários de projetos precisam fazer? Não criaria um software geral melhor?

Uso do teste ágil.

Migrando de um método de teste tradicional para um ágil

A meta de uma equipe de desenvolvimento ágil é entregar, continuamente, novos recursos com qualidade. As equipes que passam a usar o método ágil normalmente têm problemas com como incorporar o tempo de teste na velocidade do método ágil. Esse é um desafio legítimo, pois as metodologias de teste tradicionais simplesmente não são adequadas para um contexto ágil. O ritmo do desenvolvimento requer uma nova abordagem para garantir qualidade em todas as builds. Na Atlassian, fazemos teste com agilidade. Observe a fundo a abordagem de teste com Penny Wyatt, líder sênior da equipe de garantia de qualidade do Jira Software.

Como um débito de cartão de crédito, isso começa com uma pequena quantidade, mas se acumula rapidamente–e drena a equipe da agilidade que é tão importante. Para enfrentar a bola de neve do débito técnico, na Atlassian, a gente permite (ou melhor, esperamos) que os desenvolvedores sejam defensores ferozes da qualidade. A gente acredita que os desenvolvedores agregam habilidades fundamentais que ajudam a proporcionar qualidade ao produto:

  • Os desenvolvedores são ótimos em resolver problemas com código.
  • Desenvolvedores que escrevem os próprios testes são mais empenhados em corrigir quando encontram falha.
  • Desenvolvedores que entendem os requisitos de recursos e as implicações dos respectivos testes geralmente escrevem códigos melhores.

Acreditamos que cada história do usuário no backlog requer código do recurso e código de teste automatizado. Embora algumas equipes atribuam aos desenvolvedores o código do recurso, enquanto a equipe de teste executa os testes automatizados, achamos mais eficaz ter um único engenheiro entregando o conjunto completo.

Dica profissional:

Use uma abordagem inovadora para lidar com os erros em novos recursos e as regressões em recursos existentes. Se aparecer um bug durante o desenvolvimento, reserve um momento para entender o erro, corrija ele e prossiga. Se uma regressão aparecer (por exemplo, algo funcionava antes, mas não funciona mais), então é provável que reapareça. Crie um teste automatizado para proteção contra essa regressão no futuro.

Este modelo não significa que os desenvolvedores trabalham sozinhos. É importante ter engenheiros de garantia de qualidade na equipe também. A GQ traz uma perspectiva importante para o desenvolvimento de um recurso, e bons engenheiros de GQ sabem onde os erros costumam se esconder e podem aconselhar os desenvolvedores em prováveis "pegadinhas".

Toque humano no teste exploratório

Nas equipes de desenvolvimento, os membros da equipe de garantia de qualidade trabalham junto com os desenvolvedores em testes exploratórios, uma valiosa prática durante o desenvolvimento para eliminar bugs mais graves. Semelhante ao que ocorreu com a revisão de código, a gente viu conhecimento de teste ser transferido pela equipe de desenvolvimento por causa disso. Quando os desenvolvedores se tornam melhores testadores, um código melhor é entregue logo na primeira vez.

Mas os testes exploratórios não são manuais? Não. Pelo menos não no mesmo sentido que um teste de regressão manual. Os testes exploratórios são uma abordagem de pensamento crítico baseada em risco para testes e que permite que a pessoa que faz o teste use o próprio conhecimento de riscos, dados de implementação e necessidades dos clientes. Saber disso antecipadamente no processo de teste permite que o desenvolvedor ou o engenheiro de garantia de qualidade encontre os problemas com rapidez e abrangência, sem a necessidade de casos de teste com script, planos de teste minuciosos ou requisitos. Achamos isso muito mais eficaz do que o teste manual tradicional, pois podemos levar insights de sessões de testes exploratórias de volta para o código original e os testes automatizados. Os testes exploratórios também ensinam sobre a experiência de usar o recurso de uma forma que o teste com script não faz.

Manter a qualidade envolve uma mistura de testes automatizados e exploratórios. Conforme novos recursos são desenvolvidos, os testes exploratórios garantem que o novo código atenda ao padrão de qualidade com mais amplitude que os testes automatizados. Isso inclui facilidade de uso, design visual agradável e utilidade geral do recurso além da proteção robusta contra as regressões oferecida pelos testes automatizados.

A mudança pode ser difícil – muito difícil

Vou deixar você com uma anedota pessoal que resume muito bem minha jornada com o teste ágil. Eu me lembro de gerenciar uma equipe de engenharia, no início de minha carreira, que tinha forte resistência à escrita de testes automatizados, pois "esse trabalho era para GQ". Depois de várias iterações de código com erros e de ouvir todas as razões pelas quais os testes automatizados atrasariam a equipe, eu fui firme: todos os códigos novos tiveram que ser comprovados por testes automatizados.

Após uma única iteração, o código começou a melhorar. E o desenvolvedor que foi mais inflexivelmente contra escrever testes acabou por ser aquele que entrou em ação quando um teste falhou! Nas próximas iterações, os testes automatizados cresceram, foram dimensionados pelos navegadores e melhoraram a cultura de desenvolvimento. Claro, houve mais demora na liberação de um recurso. Mas os bugs e o retrabalho diminuíram significativamente, economizando muito tempo no final.

A mudança quase nunca é fácil. Mas, como a maioria das coisas vale a pena, se você trabalhar duro e criar novos padrões para si mesmo, a única pergunta que vai restar é "Por que não fizemos isso antes?!"