O fabuloso futuro das áreas de testes

Certa vez estive em uma grande empresa de software do Brasil. Eram ainda meados de 2003 e o gerente da área de qualidade e testes me mostrou, com distinto orgulho, o seu enorme espaço ocupado por quase 200 analistas de testes que trabalhavam incansavelmente para endereçar milhares de defeitos de software produzidos todo mês pelas centenas de desenvolvedores desta empresa. Ele me mostrou as filas de defeitos, os gráficos de acompanhamento de defeitos e o seu rigoroso processo de testes. Um processo e prática espetaculares, mas para um problema que não deveria existir.  Ou seja, um enorme desperdício de dinheiro.

Antes de justificar esta afirmação, considere o cenário da sua casa, com sua esposa, filhos, pais ou mesmo colegas. Cada um dos habitantes da sua casa é bastante desordeiro. Ninguém arruma a cama, remove a poeira da casa, lava pratos, passa roupas e ninguém também lava os banheiros. Neste cenário, você irá precisar de uma diarista. Mas se você e seus habitantes da sua casa forem ainda mais bagunceiros, você irá precisar da diarista duas, três ou quatro vezes por semana. No extremo, você irá precisar de uma ou duas empregadas para limpar tudo aquilo que você não deveria produzir de lixo e desordem. Quantos aqui considerariam o cenário da desordem como natural e se sujeitariam a pagar por duas empregadas para manter um apartamento em ordem? Se você é como a maioria da população, entenderia que isso é muito caro e faria a sua parte para que tanta bagunça não acontecesse. A sua motivação é econômica! Simples assim.

Vamos agora de volta ao software, onde a cultura da tolerância do desenvolvedor lambão é natural. Desenvolvedores não deveriam escrever código apenas e gerar defeitos em larga escala. Desenvolvedores tem a obrigaçao de tirar a poeira do quarto todo dia e lavar suas latrinas em base semanal. Isto é, desenvolvedores devem refatorar o seu código, executar testes de unidade, aplicar TDD e integrar o seu código em base diária. Sem desculpas! Isto se chama Código Limpo e é uma prática provada e usada com excelência pelos times mais eficientes da TI. Ao fazer isso, a maior parte dos defeitos seria eliminada na origem e uma pequena porcentagem dos problemas seria enviado para uma fila de defeitos dos analistas de testes. Ao não fazer isso, a sua empresa irá gastar muito mais dinheiro para remover defeitos que não deveriam existir.

E o que acontece com os analistas de testes?

Analistas de testes são importantíssimos em um projeto de software. São tão importantes que eles deveriam sair do quartinho dos defeitos, normalmente acionados no final do projeto quando o desespero já tomou conta de todos, e participarem do jogo lado a lado com analistas de negócio e desenvolvedores desde o primeiro dia do projeto. Analistas de testes devem trabalhar lado a lado com analistas de negócio e desenvolvedores, observando em tempo real o resultado dos builds, executando testes em base diária e gerando feedbacks no mesmo ritmo para os desenvolvedores (do lado deles, e não através de ferramentas de defeitos). O trabalho pareado entre analistas de testes e desenvolvedores é recomendado e gera altíssima interação. Desenvolvedores recebem feedback de manhã e de tarde para estressar novos casos de testes em seus códigos e a cada dia novos builds mais poderosos são gerados pelo time. Novos testes de unidade nascem e florescem em base diária e os cenários de testes são exercitados com cada vez mais propriedade e robustez pelos analistas de testes.

Times ágeis trabalham desta forma.

Não existe o “time de desenvolvedores” e o “time de testes”. Da mesma forma, no futebol não existe o “time dos goleiros” e o “time dos centro-avantes”. Existe o time de futebol! E no desenvolvimento de software, deve existir o “time de produto”, com o goleiro, centro-avante e outros papéis necessários para fazer gols, defender a sua meta e vencer a partida.

E o que acontece com as áreas de testes?

Ainda existirão nas empresas disfuncionais e que aguardam a lenta morte da baixa produtividade nos seus projetos. Mas irão certamente morrer à medida que as empresas mais eficientes tomarem os seus lugares com práticas provadas da indústria que gerarem maior eficiência econômica.

Pensamento do dia: “Vida longa aos Analistas de Testes, morte rápida para as áreas de testes”.


4 comentários

Frederico Moreira · 6 de maio de 2015 às 21:03

Excelente artigo Marco.
Parabéns.

    Marco Mendes · 9 de maio de 2015 às 17:01

    Obrigado, Fred!

Rodrigo · 6 de maio de 2015 às 19:55

Belo texto.
Estamos implantando aos poucos aqui na empresa este conceito do Analista de Teste trabalhar junto com o time de desenvolvimento. Em 4 meses os resultados são muito bons, as aquém do que a Diretoria espera. Neste contexto, os analistas de teste estão junto com time de desenvolvimento/manutenção de sistemas legados, construídos a mais de 20 anos e que não há documentação alguma. Nem os desenvolvedores sabem o que o sistema faz.

Temos uma área de testes separada, hoje focada 90% do tempo em automação de testes (testes de regressão funcionais) . Para alguns projetos desenvolvidos por uma fábrica de software interna, temos o analista de testes separa da equipe de desenvolvimento.

O que fazer com esta equipe de automação de testes, que cuida também do delivery final para o cliente, ou seja, só se entrega algo para o cliente se passar por esta equipe de automação de testes.

Neste cenário, o que você sugere que possa ser mudado?

atc.
Rodrigo
gerente da área de testes.

    Marco Mendes · 9 de maio de 2015 às 17:11

    Oi, Rodrigo. Obrigado pela questão colocada.

    A primeira coisa que faria, no seu lugar, é buscar uma conversa sincera e franca com o time de desenvolvimento para buscar com eles um aumento contínuo da qualidade do código. Não sei que práticas o seu time de desenvolvimento trabalha, mas esta mudança que citei somente ocorre se desenvolvedores forem sensibilizadas que eles devem TESTAR, e muito o seu código. Este teste deve ser realizado por testes de unidade, refatoração, testes não-funcionais, integração diária, testes com massas de dados complexas que simulem o mundo real e quem sabe um dia trazer práticas de TDD e ATDD. No caso de sistemas legados, é importante também mostrar para a diretoria que os efeitos desta mudança não se darão em algumas semanas. É necessário trabalhar meses a fio para você perceber as vantagens deste modelo para sistemas de grande porte legado. Mas considere a alternaitva ruim. Se você não fizer isso agora, o seu custo irá aumentar continuamente e a sua empresa irá ficar, a cada dia, mais ineficiente. Acredito que isso merece atenção sua e sua diretoria, em minha humilde opinião 🙂

    Ação mínima para segunda-feira: Se você puder, compre e dê como presente para o desenvolvedor mais próximo do seu time o livro Código Limpo.

    http://www.buscape.com.br/codigo-limpo-robert-cecil-martin-8576082675.html

    Pode ser o início de uma pequena revolução na sua empresa.
    Como diria um sábio que esqueci o nome agora, uma caminhada de 1000 kilômetros começa com um pequeno passo.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *