QA vs Dev? Quem ganha? Ninguém, todo mundo perde...
Thiago Brito
25 de Fevereiro de 2019 4 minutos de leitura

No início parecia que tudo era uma guerra, o foco do time de QA era reprovar e identificar bugs e do time de Dev era se defender e provar que estavam errados. Quem ganhou? Ninguém... A empresa perdeu!

Hoje eu quero te contar uma história sobre algo que aconteceu comigo e como é possível criar um ambiente realmente produtivo dentro da empresa mudando a forma como o time de QA e Dev trabalham juntos.

Eram dois times um de desenvolvimento e outro de qualidade. O de desenvolvimento estava no interior do Rio de Janeiro e o de qualidade em Brasília.

A distancia tornava a comunicação bastante difícil e, quando um erro ocorria, entender o que o QA estava fazendo para reproduzir o erro era difícil. E claro o time de desenvolvimento queria se defender ao máximo tentando mostrar que aquele erro… bem… o erro não existia.

Existia um agravante enorme neste processo que era o fato dos testes realizados pelo time de qualidade não serem automatizados. Em alguns casos, a homologação de uma versão levava até um mês.

Imagina o que acontece ficar um mês esperando uma versão ser aprovada? Ou pior, imagina encontrar um erro no vigésimo dia? Complicado.

Os dois times não se entendiam, as discussões eram enormes e sempre eram escaladas para os gerentes que subiam para os diretores, a diretoria de Dev e QA eram diferentes também.

Muitas vezes um pequeno vazamento de memória era motivo para guerras politicas infinitas.

O produto não estava com uma boa qualidade e o mercado percebeu isso rapidamente. As coisas não estavam boas.

Tornando a história curta, foram feitas algumas alterações:

  • O time de qualidade passou a responder ao mesmo diretor do time de desenvolvimento
  • Foi montado um time de qualidade junto com o time de desenvolvimento
  • A bateria de testes passaria a ser totalmente automatizada
  • Time de QA e Dev juntos. O que acontece?

    A primeira coisa que reparei era que as brigas ficaram ali do lado. Os dois times ainda brigavam e tinham vários pontos em que discordavam sim.

    Porém, um efeito muito interessante é que, algo que levava 2 ou 3 dias de discussão, e-mails interminaveis e brigas politicas. Passaram a serem resolvidos em alguns minutos, em vários casos, menos de 5 minutos já era possível entender se um bug era um bug mesmo ou não.

    Ok, agora também não é possível simplesmente ignorar o cara que está do lado. Então os problemas aparentes ficam mais fáceis de serem resolvidos.

    QA e Dev respondendo a mesma diretoria?

    A grande vantagem é que agora os times passaram a trabalhar em deixar o produto com boa qualidade e não mais em brigas politicas e discussões interminaveis.

    Você tem que resolver o problema e ponto final! Os gerentes se conversam, mas em geral os proprios QA e Dev devem se organizar para resolver. Somente entram na briga quando não tem jeito ou quando é necessário eliminar um grande obstáculo do caminho que não é possível ser feito pelo time.

    Teste manual vs Testes automatizados?

    Estamos em 2019, eu acho que não preciso mais falar muito sobre isso. Se sua bateria de teste é manual, alguma coisa muito errada está acontecendo.

    O time de QA deve ser um time de programadores qualificados para aumentar a qualidade dos testes e a automação. Se possível, no próprio processo de integração continua já devem ser executados testes que deem uma segurança de que nada grave no produto está acontecendo.

    Fazer isso traz um aumento de produtividade enorme. Cada segundo gasto com testes automatizados aumenta muitas horas de produtividade e dores de cabeça.

    Com os testadores do lado. O Dev não vai nem querer saber de testar! Certo? Errado? Talvez...

    O desenvolvimento de código é atribuição de Dev? Sim.

    O desenvolvimento de testes é atribuição do QA? Talvez.

    Até agora o que eu vi funcionar melhor é que todo o time Dev + QA (eles estão juntos agora, lembra?) devem ser responsáveis pelos testes.

    Se os Unit Tests são bons para garantir que algo não está quebrando, ótimo… Eles são mais do que obrigação de todo desenvolvedor criá-los. Porém, em alguns casos são necessários testes de integração, interface ou qualquer outro tipo de teste que você achar melhor. Quem faz isso?

    O time é claro. Eu vejo como o time de QA olhando para a qualidade do produto como um todo, garantindo que as boas práticas estão sendo seguidas, que toda a estrutura de testes está funcionando e executando corretamente de forma contínua.

    Criar novos testes é uma atribuição compartilhada entre o Dev e QA

    O melhor dos mundos é aquele em que o acesso a toda bateria de teste é disponibilizada para todos e qualquer um pode mexer e adicionar novos casos de testes rapidamente.

    O foco deve ser entregar um produto de qualidade com consistencia. Qualquer coisa diferente disso é secundária e deve ser reavaliada

    Depois das mudanças a qualidade aumentou significativamente.

  • O tempo de homologação que levava antes 1 mês em alguns casos agora leva 5 dias úteis no pior dos casos
  • O time de Dev e QA está muito mais integrados, com autonomia e em paz
  • O número de falhas e a consistência na liberação de novas releases com qualidade mais do que já pagou todo o esforço feito
  • Em suma, se seus times de Dev e QA estão separados e/ou você tem muitos testes manuais. Muito provavelmente você terá um problema sério de qualidade e performance nos seus produtos.

    Talvez seja melhor ler esta história de novo e tentar mudar algumas coisas para ter um final mais feliz. :-)