Existem estudos científicos sobre TDD que usam o custo total de propriedade de um produto como medida?

11

Quando eu estava lendo o resumo do trabalho anterior em Dogsa T, Batic D. A eficácia do desenvolvimento orientado a testes: um estudo de caso industrial. Diário de Qualidade de Software. 2011; 19 (4): 643-661. me ocorreu que as medidas usadas em muitos estudos em torno do TDD são baseadas em coisas como linhas de código, defeitos e tempo gasto no desenvolvimento.

Existem estudos por aí que enfocam o custo total de propriedade de produtos que foram desenvolvidos usando TDD versus desenvolvimento tradicional anterior ou último teste?

Estou especialmente interessado no custo total de aquisição e custos operacionais.

— Patrik Björklund
fonte

3

Existem alguns estudos sobre as implicações e benefícios do TDD, mas os resultados são contraditórios. Alguns projetos (isso é, na minha experiência) têm uma taxa de erros mais baixa e um custo de propriedade como resultado do uso do TDD, pois o custo da alteração de um recurso diminui drasticamente. Alguns outros são interrompidos.

Alguns estudos ( aqui está o slide n50) - mostram que o número de bugs aumentou com a cobertura. Estou assumindo que uma cobertura maior implica TDD e que um número maior de erros implica um custo mais alto de propriedade.

Do meu ponto de vista, nenhuma métrica ou prática por si só pode estar relacionada a melhor qualidade ou menor custo de propriedade. Há uma combinação de fatores que podem levar a alguma correlação. E esses fatores mudam entre equipes e projetos.

Acho que todos já ouvimos histórias de equipes, que começaram a usar TDD, escrevendo métodos de teste de 100 linhas, o que (na minha opinião) aumenta o custo de propriedade, pois a atualização desse teste será cara.

Minha regra pragmática é que as pessoas que se importam e estão ansiosas para aprender , trabalhando em um ambiente que as apóie e com suas idéias, tenham melhor qualidade e custo de propriedade.

— Augusto
fonte

o slide n50 é extremamente enganador. "Quanto mais cobertura, mais erros" provavelmente significa "quanto mais cobertura, mais erros ... você encontrará". É possível, mas duvido que mais cobertura leve a mais defeitos injetados. Isso está simplesmente afirmando que quanto mais cobertura, maior o rendimento do defeito na fase de desenvolvimento. E sim, existem muitas métricas que podem medir a qualidade e o custo de propriedade - # defeitos injetados por fase, rendimento de defeitos por fase e retrabalho são coisas mensuráveis, com impacto direto na qualidade e no custo. Veja PSP / TSP para alguns ótimos exemplos dessas métricas.

— Michael

Michael, no contexto desse slide, o apresentador mostra o que está relacionado a uma maior densidade de erros. Uma das métricas eram os casos de teste; portanto, quanto mais casos de teste uma classe tiver, maior será o erro na classe. O que o apresentador tenta dizer é que nenhuma métrica, por si só, se correlaciona com uma menor densidade de erros.

— 223 Augusto

0

Não tenho estudos específicos, mas posso dizer por experiência pessoal e pelas experiências de outros desenvolvedores que sei que, quando aplicadas corretamente em projetos de médio e grande porte, o TDD reduz o tempo de colocação no mercado, reduz bugs e defeitos e melhora a qualidade do código .

Tendo dito que não existem balas de prata, você pode escrever um bom código sem TDD? sim, você pode escrever código incorreto usando TDD yes. Além disso, dependendo do seu projeto, o TDD pode aumentar muito o custo de propriedade do código, um bom exemplo é a NASA, onde o custo por linha de código é enorme, mas o custo de propriedade não é o foco, é a falta de defeitos.

Quando aplicado corretamente, o TDD aumentará seus custos iniciais e sua base de códigos, mas você obtém os benefícios a longo prazo dos testes de regressão, detecção precoce de erros e melhor design de código, o que deve reduzir defeitos e custos de teste e tempo de manutenção, reduzindo assim o custo total de propriedade.

— Bob The Janitor
fonte