Como você convence a gerência a "investir" em testes de unidade?

46

Como você convenceu seu gerente a deixar seu teste de unidade?

Por "uso", quero dizer que estou autorizado a desenvolver, fazer check-in para o 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 pelos testes de unidade
  2. O projeto não permite tempo para testes de unidade
  3. Dívida técnica? Que dívida técnica?

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

Desde já, obrigado!

louisgab
fonte
6
Há um capítulo inteiro no artofunittesting.com sobre esse mesmo tópico.
StuperUser
6
Não misture testes e TDD, POR FAVOR ! Isso faz as pessoas pensarem que não precisam de testes, a menos que façam TDD!
precisa saber é o seguinte
1
Pessoas que precisam convencer estão além de convencer. Considere o seu cenário uma causa perdida.
precisa saber é o seguinte
@Pavel, no começo eu pensei que você estivesse falando sério, mas você está certo. Eu quero ter a "permissão" para testar a unidade, ponto final. TDD é coisa minha.
louisgab
6
por que você sente a necessidade de obter permissão para verificar se seu código funciona conforme o esperado?
Jaap

Respostas:

25

Eu me deparei com esse problema recentemente quando um cliente estava de acordo com nossa metodologia, mas a gerência superior percebeu que os desenvolvedores estavam gastando seu tempo testando em vez de desenvolvendo e estavam preocupados com isso - afinal, eles tinham pessoal de controle de qualidade para fazer o teste! Eu escrevi sobre como eu lidei com isso aqui:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

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

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

... a melhor maneira de convencer alguém de que sua abordagem para fazer algo é prática e pragmática, é fazê-lo e compará-lo com outras abordagens. As pessoas não se importam com dogmas, ou por que você acha que algo deve ser o melhor caminho. Somente mostrando às pessoas os números e medindo a eficácia de sua abordagem, você pode realmente mostrar que suas práticas são eficazes.

Em outros projetos, trabalhamos com desenvolvedores de clientes que não criaram testes de unidade ou fizeram TDD e tivemos que manter os testes que eles quebram. No entanto, fica 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 percebam!

Portanto, no seu caso, eu faria isso furtivamente, se necessário (talvez exista uma pequena área do código que você possa começar a testar que muda frequentemente ou da qual você é responsável), mas acompanhe seus números - qual é o esforço para criar seus testes? Qual é a taxa de defeitos? 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 seu trabalho corretamente e qualquer desenvolvedor profissional deve tentar testar seu código com testes automatizados sempre que possível e prático. Espero que seja essas duas coisas no seu caso. Boa sorte!

Paddyslacker
fonte
Obrigado pela resposta. Eu tentei o link, mas ele parece quebrado. Eu acho que gostaria de ler se estivesse disponível.
Joe J
Joe, desculpe pelo deadlink. Eu publiquei isso novamente no meu blog pessoal, então o link deve funcionar agora.
Paddyslacker
2
Essa é uma boa resposta, mas nem todos podem comparar facilmente o que estão fazendo com algum outro projeto. Não me lembro onde o li, mas o argumento mais convincente para uma pessoa de negócios que vi foi comparar testes de unidade com contabilidade de dupla entrada. Ingenuamente, fazer os números duas vezes é uma perda de tempo. Mas qualquer um que saiba alguma coisa sobre contabilidade consideraria fazer apenas um lado dos livros uma negligência imperdoável e irresponsável de deveres. O teste de unidade é o análogo do desenvolvimento da contabilidade de dupla entrada.
JimmyJames
@ JimmyJames, eu concordo que você nem sempre pode comparar com outro projeto, e eu concordo com a sua analogia sobre contabilidade de dupla entrada. Eu acho que se você está começando a usar testes de unidade em uma base de código existente sem testes, pode comparar a taxa de defeitos da base de código e outras métricas entre a parte coberta pelos testes de unidade e o código descoberto, para ter alguns dados reais para backup sua abordagem também.
Paddyslacker 2/17/17
@Paddyslacker Não discordo. É uma coisa meio de galinha e ovo. Se você precisar de permissão para começar a escrever testes de unidade, é difícil usá-los para mostrar a prova de que a permissão deve ser concedida. Não é nem ou. A comparação com dados reais é um argumento muito, muito mais forte. Esse argumento alternativo é mais fraco, mas mais fácil de montar.
21419 JimmyJames
20

Mostrar o retorno do investimento (ROI)

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

Exemplo: O teste manual do recurso X leva 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 curso do projeto, à medida que suas camadas e componentes dependentes forem modificados. Portanto, automatizar o teste do recurso X nos poupará 4 horas ao longo da vida do projeto.

Na realidade, é quando você tem um bug que os testes automatizados realmente valem a pena - Primeiro, eles encontram erros mais cedo e mais barato, o que economiza tempo e vergonha. Segundo, se você tiver um bug difícil e passar por muitos ciclos de teste de construção de código para descobrir isso, o tempo economizado no teste manual aumenta extraordinariamente rápido.

As empresas entendem economizar tempo e dinheiro. É assim que se vende.

Steven A. Lowe
fonte
3
Além disso, depois que o aplicativo é implantado e alguém pede uma alteração, é muito mais fácil ver se você está quebrando alguma coisa com as alterações.
M4tt1mus
4
@mattimus: absolutamente - uma suíte de testes automatizada compensa como uma anuidade; é, na verdade, o seguro
Steven A. Lowe
15

Se você já os enfrentou e eles não concordam, mas você não se sente à vontade para escrever código sem eles ... então não pergunte novamente. Basta escrever e não fazer check-in.

A gerência não contará linhas de código, mas eles verão que todos os seus check-ins têm taxas de aprovação mais altas do controle de qualidade (ou clientes) e, eventualmente, perguntarão o porquê ... então você pode ser como "BAM! TDD ! "

Você não está mexendo no projeto, processo ou fonte ... então não vejo uma razão negativa. Honestamente, não vejo uma razão pela qual seja diferente em termos de tempo do que executar todos os seus testes de execução manual + entrada + verificação de resultados.

Steven Evers
fonte
4
+1: você precisa testar de qualquer maneira. Basta escrever testes de unidade em vez de discutir sobre como o teste "deve" ser feito.
precisa saber é o seguinte
1
Apenas tê-los localmente não funciona bem em um ambiente de equipe com uma base de código compartilhada, outras pessoas continuarão quebrando seus testes com as alterações.
Alb
3
@ Alb: Esse é o preço que você paga quando a gerência não entra em cena - melhor do que nenhum teste.
Steven Evers
3
Bravo. Qualquer teste é melhor que nenhum teste. Se um teste for interrompido por causa da alteração de outra pessoa, é um bom motivo para perguntar por que a API mudou sem nenhum aviso.
precisa saber é o seguinte
"A gerência não vai contar linhas de código", isso é verdade. Obrigado pela resposta!
louisgab
7

1) O cliente não pagou pelos testes de unidade

O cliente (pensou que) pagou por uma solução funcional. Dependendo dos contratos, a correção de defeitos pode ser realmente lucrativa para sua empresa. Se houver bloqueio suficiente. Voltemos a pagar por uma solução que funcione. O TDD deve ajudar nesse objetivo.

2) O projeto não permite tempo para TDD

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

3) Dívida técnica? Que dívida técnica?

Tenho a impressão de que você pode estar argumentando por adicionar retrospectivamente testes ao código existente. Este é um pesadelo vendido na melhor das hipóteses e não traz os benefícios que você pode 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 de qualquer maneira, como sugeriu Snorfus. Soa bom na teoria, mas testes de unidade pode e fazer a mudança ao longo do tempo. À medida que os requisitos mudam, novos recursos são adicionados, 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 adicionam recursos / correções.

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

Ian
fonte
5
"Eu não recomendo escrever os testes de qualquer maneira" - eu já estive nessa posição antes. É difícil manter os testes sozinho. Se esse fardo se tornar muito pesado, basta abandonar os testes. Pelo menos você os tinha quando estava trabalhando ativamente na base de código, o que deve ajudar no design / correção inicial, se não estiver capturando regressões. Encontrei um valor tremendo em testes de unidade para fins de design, mas encontrei poucas regressões quando os testes não são mantidos no mesmo nível que o código.
9788 Steve
1
Quem adicionou recursos / correções e não atualizou os testes de unidade não entendeu o conceito de teste de unidade.
Akira Yamamoto
Na verdade, Akira, esse é um dos problemas mais confusos que afetam a viabilidade do TDD ou de processos relacionados. Tenha em mente que, aparentemente, eu escrevi isso há 7 anos, muito ainda é relevante. Escrever testes (bons, objetivos, concisos) é difícil. Escrever testes para uma base de código que não possui nenhum é muito difícil. Fazer com que o gerenciamento não técnico veja os benefícios é difícil (a menos que eles leiam um artigo sobre o assunto, nesse caso, você será "métrico" até a morte. Até o conceito de unidade é difícil. Sou um classicista, então a minha ideia de uma unidade não é o mesmo que um mockist de (como um exemplo com 30 caracteres restantes).
Ian
4

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

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

  2. Diga a ele que esse problema não ocorrerá novamente na produção, porque nosso teste de unidade está sendo executado todas as noites e saberemos antes que o código entre em produção, observando essa falha no teste de unidade.

  3. Diga a ele que se já tivéssemos esse teste de unidade em vigor antes do código ser produzido, esse problema de produção nunca teria acontecido.

Faça isso de forma consistente e persistente e em breve ele ficará convencido. Os gerentes não gostam do cliente enfrentando problemas de produção e ele comprará a ideia de teste da unidade. Boa sorte.

java_mouse
fonte
Isso é bom :-)
BVengerov 04/12/19