Como convencer a administração a “investir” em testes de unidade?

44

Como você convenceu seu gerente a permitir que você fizesse teste unitária?

Por "uso", quero dizer, ter permissão para se desenvolver, fazer check-in no controle de origem e manter os testes de unidade ao longo do tempo, etc.

As objeções típicas de gerenciamento são:

  1. O cliente não pagou por testes de unidade
  2. O projeto não permite tempo para testes unitários
  3. dívida técnica? Qual dívida técnica?

Você conhece outras objeções? Quais foram suas respostas?

Obrigado antecipadamente!

    
por louisgab 04.04.2011 / 19:46
fonte

5 respostas

25

Eu enfrentei esse problema recentemente quando um cliente estava envolvido com nossa metodologia, mas a alta gerência ficou sabendo que os desenvolvedores estavam gastando seu tempo testando em vez de desenvolver e estavam preocupados com isso - afinal, eles tinham pessoas de QA para fazer o teste! Eu escrevi sobre como eu lidei com isso aqui:

link

Para resumir, comparei nossas horas estimadas com as horas reais do projeto e comparei nossa taxa de defeitos com a taxa de defeitos de outras equipes. No nosso caso, esses números foram comparados favoravelmente e não houve mais preocupações.

Minha conclusão com base nessa experiência é:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

Em outros projetos, trabalhamos com desenvolvedores de clientes que não criaram testes de unidade ou TDD e tivemos que manter testes que eles quebram. No entanto, torna-se muito fácil vender a abordagem TDD para esses desenvolvedores de clientes quando você pode dizer a eles o que eles quebraram no código antes que eles saibam!

Portanto, no seu caso, eu faria isso discretamente, se necessário (talvez haja uma pequena área do código que você pode começar a testar com frequência ou que você é responsável por fazer isso), mas acompanhe seus números - qual é o esforço para criar seus testes? Qual é a taxa de defeito? Como isso se compara com outros projetos / membros da equipe?

Na minha opinião, ninguém precisa pedir permissão ou pedir desculpas por querer fazer o trabalho corretamente e qualquer desenvolvedor profissional deve tentar testar seu código com testes automatizados onde for possível e prático. Espero que seja ambas as coisas no seu caso. Boa sorte!

    
por 05.04.2011 / 00:40
fonte
20

Mostrar o retorno do investimento (ROI)

Escrever testes automatizados leva tempo. Uma vez. A execução de testes automatizados leva o tempo zero, porque você pode fazer outra coisa enquanto está em execução.

Exemplo: o recurso de teste manual X demora 30 minutos. Escrever um teste automatizado levaria 1 hora. Mesmo se não tivermos bugs, teremos que testar o recurso X dez vezes durante o andamento do projeto, à medida que suas camadas e componentes dependentes forem modificados. Então, automatizar o teste do recurso X nos poupará 4 horas durante a vida do projeto.

Na realidade, é quando você tem um bug que os testes automatizados realmente valem a pena - Primeiro, eles descobrem erros precoces e baratos, o que economiza tempo e constrangimento. Segundo, se você tiver um bug difícil e passar por muitos ciclos de code-build-test para descobrir, o tempo economizado em testes manuais é extraordinariamente rápido.

As empresas entendem economizar tempo e dinheiro. É como vender isso.

    
por 04.04.2011 / 22:41
fonte
15

Se você já os confrontou, e eles não estão bem com isso, mas você não se sente confortável escrevendo código sem eles ... então não pergunte novamente. Basta escrevê-los e não verificá-los.

O gerenciamento não vai contar as linhas de código, mas eles verão que todos os seus checkins têm taxas de aprovação mais altas de QA (ou clientes) e, eventualmente, perguntarão por que ... então você pode ser como " BAM! TDD! "

Você não está mexendo com o projeto, processo ou fonte ... então não vejo um motivo negativo. Honestamente, eu não vejo uma razão para que seja diferente do tempo de execução de todos os testes manuais de execução + entrada + verificação de resultados.

    
por 04.04.2011 / 19:59
fonte
7

1) O cliente não pagou pelos testes unitários

O cliente (pensou que) pagou por uma solução de trabalho. Dependendo dos defeitos de fixação contratuais pode realmente ser rentável para sua empresa. Se houver bloqueio suficiente. Então, voltando a pagar por uma solução de trabalho. O TDD deve ajudar esse objetivo.

2) O projeto não permite tempo para TDD

O TDD não demora mais. Ele deve reduzir a quantidade de código estranho ou supérfluo e focar a base de código no que faz os testes passarem. Todos os testes que passam, sujeitos à qualidade e adequação do teste, significam que o código está pronto.

3) dívida técnica? Qual dívida técnica?

Tenho a impressão de que você pode estar argumentando para adicionar testes retrospectivamente ao código existente. Este é um pesadelo, vender no melhor dos tempos e não traz os benefícios que você poderia esperar. No entanto, adicionar testes à medida que você corrige bugs deve ser aceitável e ajudar a longo prazo.

Eu não recomendo escrever os testes, como a Snorfus sugeriu. Parece bom em teoria, mas os testes de unidade podem e fazer mudarem ao longo do tempo. Conforme os requisitos mudam, novos recursos são adicionados e os testes de unidade precisam ser atualizados. Se você estiver trabalhando como parte de uma equipe, seus testes de unidade ficarão desatualizados, à medida que outros adicionarem recursos / correções.

Estou abordando os pontos específicos que você mencionou em vez de criar novos pontos porque há espaço para progredir ou entender por que ele está sendo bloqueado.

    
por 04.04.2011 / 20:56
fonte
4

Para cada cliente que enfrenta problemas de produção,

  1. Escreva um teste de unidade e envie um e-mail para o gerente dizendo que você adicionou um teste de unidade para cobrir o cenário.

  2. E diga a ele que Esse problema não ocorrerá novamente na produção porque o nosso teste de unidade está a decorrer todas as noites e nós vamos conhecer antes que o código vá para a produção, assistindo a este teste de unidade falha.

  3. Diga a ele que, se já tivéssemos esse teste de unidade em vigor antes do código foi para a produção, esta questão de produção nunca teria aconteceu.

Faça isso de forma consistente e persistente e logo ele será convencido. Os gerentes não gostam do cliente que enfrenta problemas de produção e ele comprará a ideia de teste da unidade. Boa sorte.

    
por 03.02.2012 / 16:42
fonte