Como fornecer garantia de qualidade rapidamente

Mudando a garantia da qualidade para assistência de qualidade

Laura Daly Laura Daly

É difícil adaptar os métodos de testes tradicionais para uma cultura ágil; equipes se sentem forçadas a trocar a qualidade do seu produto pela velocidade de transporte.

Para combater estes problemas, as equipes na Atlassian são pioneiras em uma abordagem diferente para testes ágeis conhecidos como Assistência de qualidade. Em vez de criar uma equipe de teste separada responsável pela qualidade, uma pequena equipe de engenheiros de Assistência de qualidade orienta e mostra métodos sustentáveis de teste para toda a equipe de desenvolvimento. Saiba mais sobre essa transformação e como:

  • Criar uma cultura de qualidade
  • Encaminhar a responsabilidade de teste aos desenvolvedores
  • Impedir erros, não detectá-los

P & R

Leia as perguntas e respostas desta apresentação para saber mais sobre como uma equipe de 65 engenheiros cria e envia rapidamente um produto de alta qualidade com apenas seis engenheiros de controle de qualidade.  

P1: Quanto tempo leva para um desenvolvedor se adaptar este tipo de pensamento?

R1: é mais difícil mudar a cultura de toda uma equipe do que transformar as pessoas. Levamos cinco anos para levar a equipe do Jira Software para o nível de mentalidade de qualidade que ela tem hoje, mas não leva muito tempo para que cada desenvolvedor consiga acompanhar o ritmo. Eles adotam rapidamente essa mentalidade com os colegas desenvolvedores e aprendem as habilidades de testes trabalhando em duplas e em workshops. A parte mais difícil é coletar todo o conhecimento sobre riscos e o produto. Pode levar anos, mas eliminamos isso com o compartilhamento de conhecimento em demonstrações e reuniões de garantia de qualidade.

P2: Ainda há uma necessidade de casos de teste? Eles são apenas para testes de regressão/automatizados?

R2: os casos de testes manuais com script não são usados em nossa estratégia. Se um teste é apenas uma "verificação" – ou seja, um conjunto de etapas predefinidas e uma declaração definida – é mais eficiente e há menos probabilidade de erros ao executá-lo em um computador Se um teste for genuinamente um teste – exige pensamento crítico, liberdade para investigar e avaliação de erro – é melhor executá-lo como parte do teste exploratório para incluir essa liberdade e inteligência no teste.

P3: Normalmente, desenvolvedores são mais custosos do que testadores. Se usarmos desenvolvedores como testadores, isso não será um uso ineficiente do orçamento/mão de obra?

R3: absolutamente, usar desenvolvedores como testadores para executar uma etapa de teste separada é custoso e desperdiça muito tempo do desenvolvedor. Mas ter uma etapa de teste separada – até mesmo uma executada pelos testadores – é custoso e desperdiça o tempo do desenvolvedor. Sempre que uma história ou erro é enviado dos testadores para os desenvolvedores, isso não significa apenas um custo de teste, mas também o custo do desenvolvedor. Ao diminuir a taxa de rejeição de 100% para 4%, economizamos muito tempo que estava sendo desperdiçado no retrabalho de histórias e na correção de erros sem sentido antes da liberação. Economizamos o tempo gasto em investigação, relatórios, triagem, avaliação, reprodução e correção de erros encontrados internamente. E o código é projetado do zero de um modo mais passível de teste, pois os desenvolvedores sabem que são os únicos que precisarão fazer o teste. Nossa etapa DoTing (desenvolvedor em teste) foi uma etapa intermediária ao longo do caminho da melhoria da qualidade, então foi possível remover totalmente a etapa de teste separada. Foi um investimento temporário que já foi pago.

P4: Temos desenvolvedores e testadores de garantia de qualidade em fusos horários diferentes. Este modelo só funcionaria no mesmo fuso horário? Como você trabalha com equipes remotas?

R4: fornecemos assistência remota de qualidade com equipes na Polônia e no Vietnã, com um engenheiro de assistência de qualidade da Austrália. Não é tão eficaz quanto ter uma equipe de assistência de qualidade no local, pois grande parte de ser um bom engenheiro de assistência de qualidade é criar um relacionamento pessoal com os desenvolvedores. Um engenheiro remoto de assistência de qualidade é facilmente eliminado de cena, o que torna muito mais difícil avaliar a cultura geral da equipe. No entanto, conseguimos executar demonstrações remotas de assistência de qualidade com êxito, e fizemos sessões de emparelhamento com chamadas de vídeo – ligando diretamente do computador do desenvolvedor ao do assistente de qualidade e compartilhando a tela.

P5: As notas de garantia de qualidade têm como base história por história ou é criada uma base de conhecimento de notas de garantia de qualidade? Como você lida com os riscos recorrentes?

R5: as observações da assistência de qualidade são com base em cada história, então, normalmente, os engenheiros de assistência de qualidade que identificam padrões de riscos recorrentes. Isso se tornou pior ao longo dos anos à medida que nossa equipe de assistência de qualidade do Jira Software aumentou, pois cada engenheiro de assistência de qualidade não sabe, necessariamente, o que os outros sabem. Até agora, mitigamos essas reuniões semanais de compartilhamento de conhecimento, bem como as páginas wiki nas quais monitoramos riscos comuns ou surpreendentes. Estamos chegando a um ponto em que isso não é mais dimensionado. No momento estamos trabalhando em uma base de conhecimento mais estruturada com um banco de dados de regras que é executado em relação a cada validação. Então, por exemplo, se você estiver usando o objeto Usuário no seu código do Jira Software, a ferramenta adiciona um comentário ao problema informando: "O objeto Usuário pode ser nulo se o usuário atual for anônimo, certifique-se de que você está lidando com isso corretamente". Isso nos ajudará a obter conhecimento além da área de assistência de qualidade e, no melhor cenário, pode até mesmo substituir a necessidade de reuniões e demonstrações de assistência de qualidade. Isso seria útil!