Práticas recomendadas para testes ágeis e por que elas são importantes

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

Dan Radigan Por Dan Radigan
Buscar tópicos

O gerenciamento de projetos cascata separa o desenvolvimento e o teste em duas etapas diferentes: os os desenvolvedores criam uma função e, em seguida, encaminham para a equipe de garantia de qualidade (GQ) para testes. A equipe de GQ escreve e executa planos de teste detalhados. Eles também arquivam defeitos ao verificar minuciosamente regressões em funções 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 é desenvolvimento, a quantidade de testes aumenta exponencialmente–e a equipe de assistência 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. (Darei 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?

É aí que entram os testes ágeis e de DevOps.

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

A meta das equipes ágeis e de DevOps é entregar, continuamente, novas funções com qualidade. No entanto, as metodologias de teste tradicionais não são adequadas para uma estrutura ágil ou de DevOps. O ritmo do desenvolvimento requer uma nova abordagem para garantir qualidade em todos os builds. Na Atlassian, a gente faz testes ágeis. Observe em detalhes a abordagem de teste com Penny Wyatt, líder sênior da equipe de assistência 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 consome a equipe que deve ter muita agilidade. Para enfrentar a bola de neve do débito técnico, na Atlassian , capacitamos (ou melhor, esperamos) nossos desenvolvedores para que eles sejam campeões em qualidade. Acreditamos que os desenvolvedores agregam habilidades fundamentais que ajudam a proporcionar qualidade ao produto:

  • Os desenvolvedores são ótimos em resolver problemas com o código.
  • Desenvolvedores que escrevem os seus próprios testes investem mais tempo na correção caso eles falhem.
  • Os desenvolvedores que entendem os requisitos de função e as implicações de testes geralmente escrevem um código melhor.

Acreditamos que cada história de usuário na lista de pendências requer código da função e código de teste automatizado. Embora algumas equipes atribuam aos desenvolvedores o código da função, enquanto a equipe de teste executa os testes automatizados, achamos mais eficaz ter um único engenheiro entregando o conjunto completo.

Dica profissional:

Lide com os erros em novas funções e as regressões em funções existentes de modo diferente. Se aparecer um erro durante o desenvolvimento, reserve um momento para entender o erro, corrija-o 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 controle de qualidade na equipe também. A GQ traz uma perspectiva importante para o desenvolvimento de uma função, e bons engenheiros de GQ sabem onde os erros geralmente se escondem e podem aconselhar os desenvolvedores em prováveis "pegadinhas".

Toque humano no teste exploratório

Em nossas equipes de desenvolvimento, os membros da equipe de GQ trabalham junto com os desenvolvedores em testes exploratórios, uma valiosa prática durante o desenvolvimento para eliminar erros mais graves. De modo semelhante à revisão de código, vimos transferência de conhecimentos de teste pela equipe de desenvolvimento por causa disso. Quando os desenvolvedores se tornam melhores testadores, um código melhor é entregue logo na primeira vez.

Mas o teste exploratório não é um teste manual? Não. Pelo menos não no mesmo sentido que um teste de regressão manual. O teste exploratório é uma abordagem de pensamento crítico, baseada em risco, para testes e que permite que a pessoa que faz o teste use seu conhecimento de riscos, detalhes de implementação e as necessidades dos clientes. Saber disso antecipadamente no processo de teste permite que o desenvolvedor ou o engenheiro de GQ encontre problemas rapidamente e de forma abrangente, sem a necessidade de casos de teste com script, planos de teste detalhados 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. O teste exploratório também nos ensina sobre a experiência de usar a função de uma forma que o teste com script não faz.

Manter a qualidade envolve uma mistura de testes automatizados e exploratórios. Conforme novas funções são desenvolvidas, 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 da função 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 controle de qualidade". 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 nossa cultura de desenvolvimento. Claro, houve mais demora na liberação de uma função. Mas os erros e o retrabalho diminuíram significativamente, economizando muito tempo no final.

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