A revisão de código fica atrás do ciclo de entrega / teste

14

Em nosso processo Agile, temos Sprints de duas semanas. As tarefas são entregues diariamente (compilações diárias) e a equipe de teste conclui o teste imediatamente no dia seguinte ou no mesmo dia.

Também temos revisões do código Dev, que exigem algum tempo (1-2 horas), por isso são agendadas 3 vezes por semana: Mon-Weds-Fri. Os desenvolvedores se reúnem e sugerem como melhorar / refatorar o código.

Nosso problema é que, quando os Itens de Ação surgem após uma revisão de código, a maioria das tarefas já foi testada. Os testadores não querem testar novamente o que já passou nos testes. Eles não se importam com mudanças internas de desenvolvimento.

Estamos entendendo mal o processo Ágil? As revisões de código são incompatíveis com um ciclo de lançamento / teste diário? Não podemos realizar revisões de código todos os dias, pois eles ocupam o tempo de todos.

    
por gene b. 06.08.2015 / 22:27
fonte

5 respostas

8

Os testadores não querem fazer um novo teste é como dizer "codificadores não querem refatorar". Sua parte do trabalho. O processo pode ser reapresentado como algo assim: Tarefas são criadas. Código é gerado. Código é testado. Código é revisado. Imperfeições são encontradas no código. Novas Tarefas são criadas para lidar com essas imperfeições (por exemplo, o código é refatorado). Essas novas tarefas exigem novos testes.

    
por 06.08.2015 / 22:55
fonte
7

Se você for revisar o código em algum momento, não será mais caro fazer a revisão antes. E parece que você tem um processo de teste caro, então você não quer testar duas vezes. Portanto, é mais barato revisar o código antes do teste. Revisar o código após o teste não agiliza o trabalho. Isso faz com que seja mais devagar e tenta você a fornecer códigos mal escritos, mas testados com sucesso. Com o tempo, todo esse código não revisado tornará o trabalho mais lento e lento. Em seguida, um concorrente mais eficiente oferece um produto melhor a um custo menor e é o fim do jogo.

Além disso, automatize o teste. O teste manual é tão 1970.

    
por 07.08.2015 / 03:55
fonte
5

Se você está achando difícil conseguir que as revisões de código ocorram no tempo que você tem antes do controle de qualidade, considere a possibilidade de tornar as revisões de código mais leves, como Revisão de Código em Agile Teams, Parte II que @Dukeling postou discute.

Descobri que mesmo a coisa mais simples que poderia ser chamada de revisão de código trazia benefícios: antes de confirmar o código (ou inserir um DVCS), chame outro desenvolvedor e acompanhe sua alteração. Isso pode levar cinco ou dez minutos. O objetivo desta revisão de código é "Isso faz sentido para o outro desenvolvedor?" O objetivo não era detalhar as implementações de design ou se adequar completamente às idéias pessoais do revisor sobre como ele deveria ter sido escrito. Ele deu esses benefícios:

  • Melhor conhecimento compartilhado de como o código funcionava
  • Detectou códigos confusos ou potencialmente errôneos porque o ato de explicar o código foi suficiente para fazer o autor repensar as coisas
  • Ajudou a evoluir gradualmente os idiomas e o estilo da equipe, porque facilitou a explicação das coisas
  • Muito poucos resmungos da equipe

Revisões de código mais profundas funcionam melhor para encontrar problemas. Mas você tem que ser capaz de fazê-las e agir de acordo com elas para obter o valor. Um processo leve que você pode fazer o tempo todo pode ser mais útil do que um processo pesado que fica adiando ou apenas adiciona coisas ao backlog.

    
por 07.08.2015 / 05:17
fonte
1

Uma solução para esse problema é fazer uma revisão rápida do código por outro usuário, uma vez que a história do usuário tenha terminado, para que não haja nenhum erro básico / óbvio no código.

Mas isso tem que acontecer antes do ciclo de teste. Então, haveria menos alterações no código após o teste, quando você faz uma revisão maior com todos os membros da equipe.

    
por 07.08.2015 / 05:40
fonte
1

A partir dos sons, os testadores não querem testar novamente porque o teste é um processo doloroso / caro.

A automação de testes, tanto pelos desenvolvedores quanto pelos testadores, é um grande bônus para as equipes que tentam trabalhar de maneira ágil. Quanto mais baratos, mais fáceis e mais reproduzíveis forem os seus testes, mais você poderá executá-los - e menos resistência terá para mudar alguma coisa.

Fez um refatorador rápido com base em algum feedback do desenvolvedor? Pressione o grande botão vermelho que executa sua suíte de regressão / fumaça e faça uma rápida revisão manual para verificar quaisquer problemas visuais que possam ter surgido. Fácil!

Quando você estiver em um lugar como esse, o novo teste não será uma tarefa - será de segunda natureza.

    
por 10.08.2015 / 08:19
fonte