A metodologia de teste de software depende de dados defeituosos?

É um fato bem conhecido na engenharia de software que o custo de corrigir um erro aumenta exponencialmente quanto mais tarde no desenvolvimento esse bug é descoberto. Isso é suportado pelos dados publicados no Code Complete e adaptados em várias outras publicações.

No entanto, esses dados nunca existiram . Os dados citados pelo Code Complete aparentemente não mostram essa correlação de custo / tempo de desenvolvimento, e tabelas semelhantes publicadas apenas mostraram a correlação em alguns casos especiais e uma curva plana em outros (ou seja, nenhum aumento no custo).

Existem dados independentes para corroborar ou refutar isso?

E se verdadeiro (ou seja, se simplesmente não há dados para suportar esse custo exponencialmente mais alto para erros descobertos mais tarde), como isso afeta a metodologia de desenvolvimento de software?

A metodologia de teste de software depende de dados defeituosos?

Sim, comprovadamente. Examinar a curva de custo ágil da mudança mostra que parte do trabalho de Kent Beck no XP (não tenho certeza se isso fazia parte de sua motivação ou justificativa) era "achatar a curva" dos custos de defeitos, com base no conhecimento da " curva exponencial "que fica atrás da tabela Código completo. Portanto, sim, trabalhe em pelo menos uma metodologia - a que mais fez popularizar o desenvolvimento do primeiro teste - é pelo menos em parte baseada em dados defeituosos.

Existem dados independentes para corroborar ou refutar isso?

Sim, certamente existem outros dados que você pode procurar - o maior estudo que conheço é a análise de defeitos feitos na Hughes Aircraft como parte de seu programa de avaliação CMM . O relatório de lá mostra como os custos dos defeitos dependiam da fase para eles : embora os dados nesse relatório não incluam variações, você precisa tomar cuidado para tirar muitas conclusões "isso custa mais do que isso". Você também deve observar que, independentemente da metodologia, houve mudanças nas ferramentas e técnicas entre os anos 80 e hoje que questionam a relevância desses dados.

Portanto, supondo que ainda tenhamos um problema para justificar esses números:

como isso afeta a metodologia de desenvolvimento de software?

O fato de confiarmos em números que não podem ser verificados não impediu as pessoas de progredir com base em histórias e experiências: da mesma maneira que muitos negócios de aprendizes são aprendidos. Eu não acho que houve um Journal of Maçonaria Baseada em Evidências durante a Idade Média, mas um monte de edifícios grandes, impressionantes e duradouros foram, no entanto, construídos com certa quantidade de sucesso observável. O que isso significa é que estamos baseando nossa prática principalmente no "que funcionou para mim ou para as pessoas que conheci"; não é uma coisa ruim, mas talvez não seja a maneira mais eficiente de melhorar um campo de milhões de pessoas que fornecem a pedra angular da era tecnológica atual.

Acho decepcionante que, na chamada disciplina de engenharia, não tenha uma base melhor empirismo, e suspeito (embora claramente não possa provar) que poderíamos fazer um progresso melhor e mais claro na melhoria de nossas técnicas e metodologias. esse fundamento em vigor - assim como a medicina clínica parece ter sido transformada pela prática baseada em evidências. Isso se baseia em algumas grandes suposições:

• que a natureza proprietária da maioria das práticas de engenharia de software não impede a coleta de dados úteis e relevantes suficientes;
• que as conclusões tiradas desses dados são geralmente aplicáveis ​​(como a engenharia de software é uma profissão qualificada, variações pessoais na experiência, capacidade e gosto podem afetar essa aplicabilidade);
• que os engenheiros de software "em campo" são capazes e motivados para fazer uso dos resultados assim obtidos; e
• que sabemos realmente que perguntas devemos fazer em primeiro lugar. Este é obviamente o maior ponto aqui: quando falamos em melhorar a engenharia de software, o que queremos melhorar? Qual é a medida? Melhorar essa medida realmente melhora o resultado ou é uma brincadeira com o sistema? Como exemplo, suponha que a gerência da minha empresa decidisse que diminuiríamos a proporção entre o custo real do projeto e o custo previsto do projeto. Eu poderia começar a multiplicar todas as minhas estimativas de custo por um fator de falsificação e atingir essa "meta". Deveria então tornar-se prática padrão da indústria falsificar todas as estimativas?

De minha parte, a resposta para "como isso afeta a metodologia de desenvolvimento de software" não é "muito".

Seja pego pelo desenvolvedor ou pelo usuário final, seja preciso mais dinheiro para corrigi-lo depois de ter sido pego pelo usuário ou não, o fato é que um bug foi encontrado no sistema. Se capturado pelo desenvolvedor, espero que seja uma solução rápida. A mesma esperança se aplica aos bugs detectados pelo usuário.

Independentemente do custo real por hora do desenvolvedor para corrigir um bug detectado por um usuário final, existe o custo intangível de manter o estereótipo de que os codificadores sugam o que fazem. Quando um usuário encontra um bug, a culpa é do desenvolvedor. Portanto, cada bug encontrado pelo usuário final reduz a confiança do usuário no sistema. É como visitar uma casa que você deseja comprar e ver uma mancha de água aparecendo pelo teto em um canto da casa. Isso, por si só, é uma solução fácil, mas você se pergunta o que a causou e o que mais essa causa raiz pode ter afetado. Quanto vale a sua paz de espírito? Você pode ter que rasgar as paredes de volta aos pregos e inspecionar visualmente tudo para garantir que a mancha provenha de um incidente isolado que foi corrigido. Saber que isso pode ser uma possibilidade não o deixa muito confiante em casa. Similarmente,

Esses custos intangíveis são evitados quanto mais cedo o bug for detectado, que é o objetivo declarado das metodologias no estilo TDD. Um bug detectado durante a digitação pelo desenvolvedor ou parceiro em um par, um detectado no momento da compilação ou detectado pelo teste de unidade / integração (a camada adicionada pelo TDD), é um bug que o usuário nunca precisa conhecer, que seu o gerente de projetos nunca precisa se desculpar e que você não precisa fazer nada do que está fazendo certo neste segundo para mudar de marcha para o modo de correção de defeitos em uma parte do sistema que você pensou ter deixado para trás semanas atrás.

Eu prefácio isso com o fato de que a maior parte do que estou descobrindo vem dos anos 1970 e início dos anos 1980. Durante esse período, os modelos de processos seqüenciais eram muito mais comuns do que as abordagens iterativas e / ou incrementais (o modelo Spiral ou os métodos ágeis). Grande parte deste trabalho é construída sobre esses modelos seqüenciais. No entanto, não acho que isso destrua o relacionamento, mas um dos benefícios das abordagens iterativas / incrementais é liberar recursos (uma fatia vertical inteira de um aplicativo) rapidamente e corrigir problemas nele antes que as dependências sejam injetadas e a complexidade de cada fase é alto.

Acabei de retirar minha cópia da Software Engineering Economics e encontrei uma referência aos dados por trás deste gráfico no Capítulo 4. Ele cita "Inspeções de projeto e código para reduzir erros no desenvolvimento de programas" por ME Fagan ( IEEE , PDF da UMD ), EB Daly, "Gerenciamento da engenharia de software", WE Stephenson, "Uma análise dos recursos utilizados no desenvolvimento de software para sistemas de salvaguarda" ( ACM ) e "vários projetos da TRW".

... o custo relativo de corrigir erros de software (ou fazer outras alterações de software) em função da fase em que as correções ou alterações são feitas. Se um erro de requisitos de software for detectado e corrigido durante a fase de planos e requisitos, sua correção é uma questão relativamente simples de atualizar a especificação de requisitos. Se o mesmo erro não for corrigido até a fase de manutenção, a correção envolverá um inventário muito maior de especificações, código, manuais do usuário e de manutenção e material de treinamento.

Além disso, as correções tardias envolvem um processo de aprovação e controle de mudanças muito mais formal e uma atividade muito mais extensa para revalidar a correção. Esses fatores se combinam para tornar o erro tipicamente 100 vezes mais caro de corrigir na fase de manutenção em grandes projetos do que na fase de requisitos.

Bohem também analisou dois projetos menores e menos formais e encontrou um aumento no custo, mas muito menos significativo do que as cem vezes identificadas nos projetos maiores. Dado o gráfico, as diferenças parecem ser 4 vezes maiores para corrigir um defeito de requisitos após o sistema estar operacional do que na fase de requisitos. Ele atribuiu isso ao menor estoque de itens que compõem o projeto e à formalidade reduzida que levou à capacidade de implementar reparos mais simples e mais rápidos.

Com base na Boehm em Economia de engenharia de software, a tabela no Code Complete é bastante inchada (a extremidade inferior dos intervalos geralmente é muito alta). O custo para fazer qualquer alteração na fase é de fato 1. Extrapolando da Figura 4-2 em Economia de Engenharia de Software, uma alteração de requisitos deve ser de 1,5 a 2,5 vezes na arquitetura, de 2,5 a 10 em codificação, de 4 a 20 em testes e de 4 a 4 100 em manutenção. A quantia depende do tamanho e complexidade do projeto, bem como da formalidade do processo usado.

No Apêndice E de Barry Boehm e Agilidade e Disciplina de Equilíbrio de Richard Turner, há uma pequena seção sobre as descobertas empíricas sobre o custo da mudança.

Os parágrafos de abertura citam o Extreme Programming Explained de Kent Beck, citando Beck. Ele diz que, se o custo das mudanças aumentasse lentamente ao longo do tempo, as decisões seriam tomadas o mais tardar possível e apenas o necessário seria implementado. Isso é conhecido como "curva plana" e é o que impulsiona a programação extrema. No entanto, o que a literatura anterior encontrou foi a "curva íngreme", com sistemas pequenos (<5 KSLOC) com alteração de 5: 1 e sistemas grandes com alteração de 100: 1.

A seção cita o Centro de Engenharia de Software Empiricamente Baseado da Universidade de Maryland (patrocinado pela National Science Foundation). Eles realizaram uma pesquisa na literatura disponível e descobriram que os resultados tendiam a confirmar uma proporção de 100: 1, com alguns resultados indicando um intervalo de 70: 1 a 125: 1. Infelizmente, esses eram tipicamente projetos de "grande design inicial" e gerenciados de maneira seqüencial.

Existem exemplos de "pequenos projetos Java comerciais" executados usando o Extreme Programming. Para cada história, a quantidade de esforço na correção de erros, novo design e refatoração foi rastreada. Os dados mostram que, à medida que o sistema é desenvolvido (mais histórias de usuários são implementadas), o esforço médio tende a aumentar em uma taxa não trivial. O esforço na refatoração aumenta cerca de 5% e os esforços para a fixação do esforço aumentam cerca de 4%.

O que estou aprendendo é que a complexidade do sistema desempenha um grande papel na quantidade de esforço necessária. Ao criar fatias verticais através do sistema, você diminui a velocidade da curva adicionando lentamente complexidade em vez de adicioná-la em pilhas. Em vez de lidar com a massa de complexidade de requisitos, seguida por uma arquitetura extremamente complexa, seguida por uma implementação extremamente complexa e assim por diante, você começa de maneira muito simples e complementa.

Que impacto isso tem no custo a ser corrigido? No final, talvez não muito. No entanto, possui as vantagens de permitir mais controle sobre a complexidade (por meio do gerenciamento de dívidas técnicas). Além disso, as entregas frequentes frequentemente associadas ao ágil significam que o projeto pode terminar mais cedo - em vez de entregar o "sistema", as peças são entregues até que as necessidades da empresa sejam satisfeitas ou mudem drasticamente em relação a um novo sistema (e, portanto, um novo projeto) é preciso.

As métricas e modelos de Stephen Kan em engenharia de qualidade de software têm uma seção no capítulo 6 sobre o custo-benefício da remoção de defeitos de fase.

Ele começa citando o artigo de Fagan de 1976 (também citado em Economia de Engenharia de Software) para afirmar que o retrabalho feito em design de alto nível (arquitetura do sistema), design de baixo nível (design detalhado) e implementação pode ser entre 10 e 100 vezes mais barato do que o trabalho realizado durante os testes no nível do componente e do sistema.

Ele também cita duas publicações, de 1982 e 1984, de Freedman e Weinberg que discutem sistemas grandes. O primeiro é "Manual de orientações, inspeções e revisões técnicas" e o segundo é "Revisões, orientações e inspeções". A aplicação das revisões no início do ciclo de desenvolvimento pode reduzir o número de erros que atingem as fases de teste em um fator de 10. Essa redução no número de defeitos leva à redução dos custos de teste em 50% a 80%. Eu precisaria ler os estudos com mais detalhes, mas parece que o custo também inclui encontrar e corrigir os defeitos.

Um estudo realizado por Remus em 1983, "Validação Integrada de Software na Visão de Inspeções / Revisão", estudou o custo de remoção de defeitos em diferentes fases, especificamente design / código de inspeções, testes e manutenção, usando dados do Santa Teresa Laboratory da IBM na Califórnia. Os resultados citados indicam uma relação de custo de 1:20:82. Ou seja, um defeito encontrado nas inspeções de projeto ou código tem um custo de alteração de 1. Se o mesmo defeito escapar para o teste, custará 20 vezes mais. Se ele escapa todo o caminho para um usuário, ele multiplicará o custo de correção em até 82. Kan, usando dados de amostra das instalações de IBM em Rochester, Minnessota, considerou o custo de remoção de defeitos do projeto AS / 400 semelhante em 1:13:92. No entanto, ele ressalta que o aumento no custo pode ser devido à maior dificuldade em encontrar um defeito.

As publicações de Gilb de 1993 ( "Inspeção de software" ) e 1999 ("Otimizando processos de controle e qualidade de especificação de engenharia de software") sobre inspeção de software são mencionadas para corroborar os outros estudos.

Informações adicionais podem ser encontradas na página da Construx em Aumento de custo de defeitos , que fornece várias referências sobre o aumento no custo de reparo de defeitos. Deve-se notar que Steve McConnell, autor do Code Complete, fundou e trabalha para o Construx.

Recentemente, ouvi uma palestra, Real Software Engineering , dada por Glenn Vanderburg na Lone Star Ruby Conference em 2010. Ele fez a mesma palestra na Scottish Ruby Conference e Erubycon em 2011, QCon San Francisco em 2012 e O'Reilly Software Architecture Conference em 2015 . Só ouvi a Lone Star Ruby Conference, mas a conversa evoluiu ao longo do tempo à medida que suas idéias eram refinadas.

Venderburg sugere que todos esses dados históricos estão realmente mostrando o custo para corrigir defeitos à medida que o tempo avança, não necessariamente à medida que um projeto se move através das fases. Muitos dos projetos examinados nos documentos e livros mencionados anteriormente eram projetos sequenciais de "cascata", onde fase e tempo se moviam juntos. No entanto, um padrão semelhante surgiria em projetos iterativos e incrementais - se um defeito fosse injetado em uma iteração, seria relativamente barato corrigi-la. No entanto, à medida que as iterações avançam, muitas coisas acontecem - o software se torna mais complexo, as pessoas esquecem alguns dos pequenos detalhes sobre o trabalho em módulos ou partes específicas do código, os requisitos mudam. Tudo isso aumentará o custo da correção do defeito.

Eu acho que isso provavelmente está mais próximo da realidade. Em um projeto em cascata, o custo aumenta devido à quantidade de artefatos que precisam ser corrigidos devido a um problema de upstream. Em projetos iterativos e incrementais, o custo aumenta devido a um aumento na complexidade do software.

É apenas uma lógica simples.

Erro detectado nas especificações.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Como você pode ver mais tarde, quando o erro é detectado, mais pessoas estão envolvidas, mais trabalho precisa ser refeito e, em qualquer ambiente "normal", a papelada e a burocracia aumentam exponencialmente quando você pressiona o UAT.

Tudo isso sem incluir os custos em que uma empresa pode incorrer devido a um erro no software de produção (vendas perdidas, excesso de pedidos, hackers de clientes etc. etc.)

Eu não acho que alguém tenha conseguido escrever um sistema não trivial que nunca teve bugs na produção, mas tudo o que você pode fazer para detectar bugs cedo economizará tempo e esforço a longo prazo. Revisões de especificações, revisões de código, testes de unidade extensivos, uso de codificadores diferentes para escrever os testes etc. etc. são todos métodos comprovados para detectar bugs mais cedo.

Eu acredito que isso é, e sempre foi, sobre gerenciamento de riscos e economia. Qual é o custo de reduzir o número de defeitos versus o valor presente do impacto de defeitos futuros. A trajetória do pássaro amarelo estar um pouco fora do Angry Birds não equivale à trajetória de um míssil de cruzeiro Tomahawk estar fora. Os desenvolvedores de software em qualquer projeto não podem tomar decisões com base nessa tabela. Nesse sentido, nada muda.

A maneira como acho que isso tende a funcionar é via feedback, erros caros no campo fazem as empresas restringirem seus processos de qualidade, enquanto nenhuma reclamação do campo faz com que as empresas o relaxem. Assim, com o tempo, as empresas de desenvolvimento de software tenderão a convergir ou oscilar em torno de algo que funcione para elas (+/-). O código completo pode influenciar alguns valores iniciais ou pode puxar as empresas levemente de uma maneira ou de outra. Uma empresa que gasta muito esforço na remoção de defeitos que ninguém notaria provavelmente perderá negócios para um concorrente que tem uma abordagem mais otimizada. Por outro lado, uma empresa que libera produtos de buggy também sai do negócio.

Alguns artigos relevantes de uma pesquisa rápida (leia os artigos completos, faça mais pesquisas e forme sua própria opinião):

Uma revisão sistemática da literatura sobre pesquisa de custo de qualidade de software (2011)

"Embora a comunidade tenha desenvolvido um bom entendimento da estrutura do domínio de pesquisa, a validação empírica costuma faltar. Apenas cerca de um terço dos artigos analisados ​​apresenta um estudo de caso ou resultados empíricos mais abrangentes. Isso parece ser insuficiente para a pesquisa de custo de qualidade de software , que depende fortemente de dados quantitativos para gerar novas descobertas. Portanto, há uma necessidade de novas abordagens para coletar dados de custo de qualidade, além de uma cooperação mais forte entre a indústria e a pesquisa para disponibilizar esses dados ".

Avaliando o custo da qualidade do software (1998)

"Finalmente, vimos que é importante monitorar os custos de conformidade e não conformidade de software, para que as políticas de conformidade possam ser ajustadas para reduzir os custos totais de qualidade de software".

O comportamento de custo de defeitos de software (2004)

Resumo ... "A pesquisa atual tenta atualizar nosso conhecimento da maneira como os defeitos e as despesas para corrigi-los (ou alternativamente, deixando-os não corrigidos) influenciam o custo final do software" ... "defeitos não corrigidos tornam-se exponencialmente mais caros com cada fase em que não estão resolvidos "

Cobertura de teste e defeitos pós-verificação: um estudo de caso múltiplo (2009)

"Também descobrimos que o esforço de teste aumenta exponencialmente com a cobertura de teste, mas a redução nos problemas de campo aumenta linearmente com a cobertura de teste. Isso sugere que, para a maioria dos projetos, é provável que os níveis ideais de cobertura sejam bem inferiores a 100%".

Faça a ponte entre o processo de teste de software e o valor comercial: um estudo de caso (2009)

Não consigo responder à sua primeira parte da pergunta, pois simplesmente não verifiquei. Mas posso formular uma resposta para sua segunda pergunta e talvez sugerir uma possível resposta para a primeira.

Não é necessário dizer que alguns fatores mais importantes no custo de correção de um bug, exceto as ferramentas de desenvolvimento intrinsecamente difíceis de usar, são a complexidade intrínseca do produto e o quão bem o usuário pode entender esse produto.

Focando um segundo no código, sob a suposição de que o código é tipicamente escrito e mantido por desenvolvedores capazes de lidar com as complexidades intrínsecas de seu código (o que pode não ser totalmente verdadeiro e pode merecer seu próprio debate), eu ousaria sugerir que: importância crucial na manutenção e, portanto, na correção de bugs, é a capacidade dos mantenedores de entender o referido código.

A capacidade de entender o código é bastante aprimorada pelo uso de ferramentas comprovadas de engenharia de software que, infelizmente, são na maioria das vezes usadas de maneira inadequada ou inadequada. Usando o nível certo de abstração, a modularidade, o aprimoramento da coesão do módulo e a redução do acoplamento do módulo são ferramentas críticas para lidar com a complexidade que precisam de uso adequado. Codificação para interfaces, ou, no POO, evitando o uso excessivo de herança sobre composição, empacotando por recurso, são algumas das técnicas que geralmente recebem atenção insuficiente na codificação.

Acredito que as realidades da concorrência no setor impõem uma força negativa ao emprego de métodos de melhoria da qualidade no desenvolvimento de software, mantendo baixa a qualidade intrínseca do software como uma medida de sucesso contínuo.

Consequentemente, acredito que, na indústria, o software tende a sofrer mais com os custos de correção de erros, à medida que cresce. Nesses produtos, os bugs se tornam mais difíceis de corrigir com o tempo, porque o sistema fica mais difícil de entender à medida que cresce. As preocupações apresentadas por cada recurso são excessivamente acopladas a outras preocupações, dificultando a compreensão. Ou, o nível certo de abstração não foi empregado, dificultando ao mantenedor formular um modelo adequado do sistema e raciocinar sobre ele. A falta de documentação certamente não ajuda.

Há exceções. Tenho certeza de que o Google não está funcionando no seu ritmo sem algumas práticas sólidas confirmadas por desenvolvedores estelares. E outros provavelmente estão na mesma situação. Mas para a maioria do software, eu não ficaria surpreso se os dados fez de fato confirmam a alegação de código completo .

Outra resposta! Desta vez, para abordar a questão do título "A morhtodoligia de software depende de dados defeituosos".

A resposta real é "não há dados". Como não há um grande corpo confiável de dados em projetos de software, existem defeitos, sucessos no mercado, etc.

Todas as tentativas de reunir esses dados foram subfinanciadas, estatisticamente defeituosas ou, portanto, específicas para um projeto específico, das quais não é possível derivar conclusões gerais.

Além disso, acho que nunca haverá, o processo de desenvolvimento de software é muito subjetivo e escorregadio para uma medição rigorosa. As organizações mais bem posicionadas para reunir esses dados (as grandes casas de software e os integradores de sistemas) sabem em seu coração que quaisquer números obtidos a partir de seu desempenho seriam profundamente embaraçosos.

As únicas organizações que publicam números sobre o custo e o sucesso de projetos de software
são departamentos governamentais e, somente então, porque precisam fazê-lo; sim, esses números são profundamente embaraçosos, não importa o quanto eles massageiem os números.

Portanto, em conclusão, todos os estudos de software são necessariamente puramente subjetivos, porque não há dados reais nos quais basear uma conclusão objetiva.