Eu não tenho nenhum trabalho de pesquisa ou estatística para dar a você, mas relatarei minha experiência de trabalhar em uma equipe / organização que historicamente teve uma cobertura de teste de unidade de baixa a média e nenhum teste de ponta a ponta, e gradualmente movendo a barra para onde estamos agora, com uma abordagem mais ATDD (mas, ironicamente, não TDD tradicional).
Especificamente, é assim que os cronogramas do projeto costumavam se desenvolver (e ainda se desenrolam em outras equipes / produtos na mesma organização):
- Até 4 semanas de análise e implementação
- 2 semanas de teste de regressão, correção de bugs, estabilização e preparação de lançamentos
- 1-2 semanas de correção de defeitos conhecidos
- 2-3 semanas de problemas de limpeza de código e pós-produção (defeitos desconhecidos / interrupções não planejadas)
Isso parece uma sobrecarga ridícula, mas na verdade é muito comum, mas geralmente é mascarada em muitas organizações por um controle de qualidade ausente ou ineficaz. Temos bons testadores e uma cultura de testes intensivos; portanto, esses problemas são detectados precocemente e corrigidos com antecedência (na maioria das vezes), em vez de serem permitidos a execução lenta ao longo de muitos meses / anos. O custo de manutenção de 55% a 65% é menor do que a norma geralmente aceita de 80% do tempo gasto na depuração - o que parece razoável, porque tivemos alguns testes de unidade e equipes multifuncionais (incluindo o controle de qualidade).
Durante o primeiro lançamento de nosso produto mais recente pela nossa equipe, começamos a adaptar os testes de aceitação, mas eles não eram muito bons e ainda tínhamos que confiar em muitos testes manuais. O lançamento foi um pouco menos doloroso do que outros, em parte devido à IMO, devido aos nossos testes de aceitação aleatórios e também devido à nossa cobertura muito alta de testes unitários em relação a outros projetos. Ainda assim, passamos quase duas semanas em regressão / estabilização e duas semanas em questões de pós-produção.
Por outro lado, todos os lançamentos desde o lançamento inicial tiveram critérios de aceitação e testes de aceitação, e nossas iterações atuais são assim:
- 8 dias de análise e implementação
- 2 dias de estabilização
- 0-2 dias combinados de suporte e limpeza de pós-produção
Em outras palavras, progredimos de 55 a 65% para a manutenção de 20 a 30%. Mesma equipe, mesmo produto, a principal diferença é a melhoria progressiva e a racionalização de nossos testes de aceitação.
O custo de manutenção é de 3 a 5 dias para um analista de controle de qualidade e de 1 a 2 dias para um desenvolvedor. Nossa equipe tem 4 desenvolvedores e 2 analistas de controle de qualidade, então (sem contar UX, gerenciamento de projetos etc.), isso é um máximo de 7 dias / homem em 60, o que aumentarei até uma sobrecarga de implementação de 15% apenas para continuar o lado seguro.
Gastamos 15% de cada período de lançamento desenvolvendo testes de aceitação automatizados e, no processo, podemos cortar 70% de cada lançamento fazendo testes de regressão e corrigindo erros de pré-produção e pós-produção.
Você deve ter notado que a segunda linha do tempo é muito mais precisa e também muito mais curta que a primeira. Isso foi possível graças aos critérios de aceitação iniciais e aos testes de aceitação, porque simplifica enormemente a "definição de concluído" e nos permite estar muito mais confiantes na estabilidade de uma versão. Até agora, nenhuma outra equipe teve êxito com um cronograma de lançamento quinzenal, exceto talvez ao fazer lançamentos de manutenção razoavelmente triviais (somente correção de bugs, etc.).
Outro efeito colateral interessante é que conseguimos adaptar nossa programação de lançamentos às necessidades dos negócios. Uma vez, tivemos que prolongá-lo para cerca de três semanas para coincidir com outro lançamento, e conseguimos fazê-lo enquanto fornecíamos mais funcionalidades, mas sem gastar tempo extra em testes ou estabilização. Em outra ocasião, tivemos que reduzi-lo para cerca de 1 ½ semanas, devido a feriados e conflitos de recursos; tivemos que trabalhar menos com desenvolvedores, mas, como esperado, pudemos gastar correspondentemente menos tempo em testes e estabilização sem introduzir novos defeitos.
Portanto, na minha experiência, os testes de aceitação, especialmente quando realizados muito cedo em um projeto ou sprint, e quando bem mantidos com os critérios de aceitação elaborados pelo Dono do produto, são um dos melhores investimentos que você pode fazer. Diferentemente do TDD tradicional, que outras pessoas apontam corretamente, está mais focado na criação de código testável do que no código sem defeitos - o ATDD realmente ajuda a detectar defeitos muito mais rapidamente; é o equivalente organizacional de ter um exército de testadores fazendo um teste de regressão completo todos os dias, mas muito mais barato.
A ATDD o ajudará em projetos de longo prazo realizados no estilo RUP ou (ugh) Waterfall, projetos com duração de 3 meses ou mais? Eu acho que o júri ainda não participou. Na minha experiência, os riscos maiores e mais feios em projetos de longo prazo são prazos irrealistas e requisitos variáveis. Prazos irreais farão com que as pessoas tomem atalhos, incluindo atalhos de teste, e alterações significativas nos requisitos provavelmente invalidarão um grande número de testes, exigindo que sejam reescritos e potencialmente aumentem a sobrecarga da implementação.
Tenho certeza de que o ATDD tem uma recompensa fantástica para os modelos Agile, ou para equipes que não são oficialmente Agile, mas têm agendas de lançamento muito frequentes. Eu nunca tentei em um projeto de longo prazo, principalmente porque nunca estive em uma organização ou sequer ouvi falar em fazê-lo nesse tipo de projeto; portanto, insira o aviso padrão aqui. YMMV e tudo isso.
PS No nosso caso, não é necessário nenhum esforço extra do "cliente", mas temos um Dono do produto em tempo integral dedicado que realmente escreve os critérios de aceitação. Se você está no ramo de "consultoria", suspeito que pode ser muito mais difícil fazer com que os usuários finais escrevam critérios úteis de aceitação. Um Dono / Gerente de Produto parece ser um elemento essencial para fazer o ATDD e, embora eu possa mais uma vez falar apenas da minha própria experiência, nunca ouvi falar do ATDD ser praticado com sucesso sem que alguém cumpra esse papel.
