Dev Box Testing: como reduzir o custo de correção de um bug?

Antes de tudo, você já pensou em quanto custa um bug?

Segundo uma matéria no site do FEMAMA, os custos para tratamento de câncer aumentam conforme o estágio da doença, ou seja, tratar o câncer em estágio avançado é muito mais caro que na fase inicial. A matéria apresenta a informação de que o tratamento de câncer de cólon, no primeiro estágio, custa pouco mais de R$ 4,1 mil. No terceiro estágio passa para R$ 77 mil. O de câncer de mama, que custa R$ 11,3 no primeiro estágio, passa para R$ 55 mil no terceiro estágio. Mas calma, você não teve um delírio (nem eu), e ainda estamos falando sobre Dev Box Testing. O ponto é que acabamos de concluir que na medicina curar é muito mais caro e traumático do que prevenir, e quanto mais alto o estágio da doença, mais caro e menos chances de cura. Seguindo o mesmo conceito, podemos reduzir o custo de correção de um bug.

O trabalho que teríamos para corrigir um possível bug por entendimento incorreto na planning, seria muito pequeno, perto do que teríamos ao corrigir esse bug após a funcionalidade já ter sido entregue ao cliente. Como o bug já estaria no cliente, ele poderia ter perda financeira, perda da confiança em nosso produto, dentre outros problemas.

Para a correção, seria necessário parar um time de desenvolvimento que já está envolvido com outra atividade. Os desenvolvedores teriam que entrar novamente no contexto, entender a funcionalidade até encontrar a raiz do problema. Esse bug teria que passar por todas as etapas do processo de desenvolvimento, como por exemplo, a revisão do código e testes. Uma nova versão seria liberada ao cliente que teria que se programar para fazer a instalação em seu ambiente. Que trabalheira não é mesmo? Agora, imagina se esse bug tivesse sido encontrado na planning, com uma pergunta? Em alguns minutos de conversa entre o time, o que geraria um baita problema no futuro estaria resolvido. Então, como na medicina, quanto mais cedo um bug for encontrado, mais fácil e menos impactante é sua correção.

‍

Mas o que esse tal de Dev Box Testing tem a ver com isso?

O Dev Box Testing é a rodada inicial de testes feitos na máquina de desenvolvimento, antes que o código seja enviado ao repositório para a revisão. É uma técnica de agilidade que tem como principal objetivo reduzir o custo de correção de um bug.

Ciclo de desenvolvimento SEM o Dev Box Testing:

‍

Ciclo de desenvolvimento COM o Dev Box Testing:

‍

Teoria é fácil, mas como faz na prática?

1. Em sua máquina após a conclusão da codificação, o desenvolvedor convida o Analista de Qualidade para juntos fazerem o Dev Box Testing.

2. Com ambos na mesma máquina, o desenvolvedor demonstra a funcionalidade implementada.

3. O Analista de Qualidade assume o controle da máquina e realiza alguns cenários.

4. Caso sejam apontados bugs, o desenvolvedor que acompanha o teste anota.

5. Após o término, o Analista de Qualidade deixa a máquina para que o Desenvolvedor faça as correções.

Caso um dos dois ou ambos estejam atuando de forma remota e não presencial, pode ser utilizada uma ferramenta para acesso remoto ou o desenvolvedor pode executar os cenários conforme o pedido do responsável pelos testes.

Pontos importantes

- Para bugs complexos encontrados durante o dev box, o Analista de Qualidade pode ser chamado para uma nova validação após a correção.

- O Dev Box Testing é um teste básico, rápido e direto, e não tem como objetivo substituir o teste completo realizado no ambiente de QA após o envio ao repositório e revisão do código. O teste completo deve ser realizado normalmente dentro do processo, principalmente porque podem ter tido alterações solicitadas na etapa de revisão do código ou podem ter problemas que aparecerão somente no ambiente de testes.

- O tempo gasto para isso deve variar de 10 a 15 minutos, com base na complexidade da história ou defeito implementado.

E o que ganhamos com isso?

- Redução do ciclo de feedback;

- Redução de retrabalho;

- Mais agilidade no processo de desenvolvimento;

- Melhor cobertura de testes automáticos;

- Melhor comunicação e integração entre desenvolvedor e Analista de Qualidade.

Imagine ter que voltar uma atividade para realizar novamente todo o processo por conta de um bug que seria facilmente identificado pelo o analista de qualidade, no primeiro teste que fizesse? Se esse bug for impeditivo, o responsável pelos testes ainda terá que aguardar para prosseguir, mesmo após a atividade ter sido liberada para ele. Com a prática do Dev Box, temos um feedback mais rápido dos problemas. Esse bug seria corrigido ainda em tempo de desenvolvimento, quando o responsável pela codificação ainda está com o ambiente preparado, e com a “mão na massa”, o que reduz o retrabalho já que o ele não precisaria voltar para corrigi-lo após ter entregue a atividade de desenvolvimento.

Claro que na maioria das vezes não será possível eliminar todos os bugs no dev box, até porque esse não é o objetivo e os testes são básicos. Porém, eliminar o máximo possível nessa etapa é fundamental para que o teste mais completo, feito após o processo de revisão do código, possa ser feito com mais tempo e foco.

Um dos benefício dessa prática, além de feedback mais rápido, redução do retrabalho e mais agilidade no processo de desenvolvimento, é a melhora na cobertura dos testes automáticos feitos pelo desenvolvedor. Com essa troca de conhecimento no momento do dev box, o desenvolvedor ganha insumos para implementar seus testes de forma que possam cobrir uma quantidade maior de cenários.

Sabemos que o trabalho em equipe é muito importante na agilidade, e mesmo com times formados por pessoas com especialidades diferentes, a comunicação entre elas também sofre modificação. O analista de qualidade e desenvolvedor sentam juntos para aplicar o Dev Box, o que estabelece ainda mais uma boa relação, comunicação e um vínculo de parceria entre eles, já que ambos estão focados naquele momento e contribuindo para deixar o processo mais ágil e entregar a tarefa ao cliente com mais qualidade em um menor tempo.

O objetivo desse procedimento é agilizar o processo de desenvolvimento, antecipando os problemas para que o custo de correção seja menor, deixando o ciclo de vida do bug mais curto, ganhando tempo para focar nos cenários que são mais críticos para o sistema.

A forma de trabalhar apresentada aqui é uma sugestão. Você pode e deve adaptar para a sua equipe e projeto que tem características específicas e suas particularidades, sempre pensando na redução do retrabalho, agilidade, qualidade e interação entre as pessoas do time. Como essa prática simples, e que apresenta impacto positivo, é fácil incluí-la no fluxo do time. Então, o que você está esperando para aplicar e ver os resultados?

‍

O que dizer do Dev Box Testing que conheço há pouco tempo e já considero pacas?

“A ideia de aplicarmos o dev box testing foi simplesmente genial! Durante a atuação dos testes locais, não só impediram a passagem de bugs para os demais ambientes, mas também é passado a perspectiva do QA e a visão de diversos cenários. Dessa maneira, tivemos essa análise profunda já durante o tempo de desenvolvimento. É uma prática de extrema importância para qualquer sistema! – Gian Raphael Martins da Costa – Software Developer“

“O Dev Box Testing vem ajudando na pré-validação no ciclo de desenvolvimento, estamos conseguindo antecipar problemas e entregar fluxos para o QA seguir sem diversas interrupções ocasionadas por problemas. Com isso estamos reduzindo problemas que poderiam trazer risco para Sprint e aumentando a qualidade de entrega do produto. – Matheus Bongiorno – Software Developer”

“O Dev Box Testing proporcionou uma redução de tempo no fluxo de desenvolvimento, bugs podem ser identificados com mais velocidade e menos burocracia, além disso, essa dinâmica estimula os envolvidos a identificarem fluxos alternativos antes não vistos, permitindo uma cobertura maior no tratamento de possíveis erros. – Daniel Elvis Quevedo – Software Developer”

“No início do Dev Box no time, foi difícil assimilar que após fazer o deploy da aplicação para ser testada se obtêm a resposta: “TUDO CERTO”, a cabeça trava, como assim tudo certo? não tem bug? NÃO. Isso vem ocorrendo devido ao convívio com o QA proporcionado pela prática do Dev Box. A programação passou a ser de certo modo preventiva, pois os pontos de falhas estão ficando cada vez mais claros. – Edson Pereira do Nascimento Junior – Software Developer”

“O Devbox testing nos ajudou a melhorar a qualidade da entrega entre as fases de desenvolvimento e testes, reduzindo o número de erros básicos encontrados pelo time de QA. – Eduardo Marinho David – Software Architect”

“O processo de dev box testing ajudou muito nas entregas, garantindo ainda mais qualidade para o cliente, que tem se mostrado realmente satisfeito com o resultado. – Alan Marcel da Costa – Product Owner”

“O Dev Box Testing foi uma prática adotada em nossas sprints que trouxe muitos benefícios. O que inicialmente surgiu como piloto em nossos projetos acabou virando uma atividade presente em praticamente todas as nossas tarefas. Aplicamos essa boa prática por aproximadamente 6 meses e verificamos que o número de bugs reportados na etapa de teste diminuiu significativamente, consequentemente houve uma diminuição no retrabalho, tanto na etapa de desenvolvimento quanto na etapa de teste, e proporcionou ainda mais qualidade nas entregas e melhor aproveitamento do tempo nas sprints. Embora nosso time sempre tenha atuado de forma unida e colaborativa, essa atividade conjunta promoveu aproximação da equipe e permitiu que os desenvolvedores pudessem conhecer e entender um pouco mais do trabalho executado pelo especialista de teste. Feedbacks positivos surgiram por todos os lados: Cliente feliz com a qualidade das entregas e baixo número de bugs no ambiente de produção, equipe técnica unida, engajada e motivada. – Renata Gumerato Aguiar – Team Leader“

“O Dev Box Testing trouxe ainda mais agilidade para um time já habituado a utilizar boas práticas de desenvolvimento e processos ágeis. Percebemos que houve melhora na integração entre desenvolvedores e analistas de qualidade, além de maior cuidado com a qualidade do código fonte e compreensão sobre a importância dos testes. – Natalia Bortoletto Cruz – Manager”

‍