Projetando maior qualidade com práticas de testes ágeis

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

Dan Radigan Dan Radigan

O gerenciamento de projetos cascata separa o desenvolvimento e o teste em duas etapas diferentes: os 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 detalhados. Eles também arquivam defeitos ao verificar minuciosamente 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 é 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.

To make matters worse, QA teams are traditionally rewarded according to how many bugs they find, which puts developers on the defensive. What if there was a better way for both developers and QA to reduce the number of bugs in the code while also eliminating those painful trade-offs project owners have to make? Wouldn't it create better all-around software?

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 compilações. Na Atlassian, fazemos teste de modo ágil.  Observe detalhadamente nossa 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 recurso 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 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.

Pro Tip:

Lide com os erros em novos recursos e as regressões em recursos 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 um recurso, 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 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. À medida que novos recursos são desenvolvidos, o teste exploratório garante que o novo código atenda o padrão de qualidade de modo mais amplo do 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 fornecidas 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 um recurso. 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?!"