O custo de um atraso maior entre desenvolvimento e controle de qualidade

Na minha posição atual, o controle de qualidade se tornou um gargalo. Tivemos a infeliz ocorrência de recursos sendo mantidos fora da versão atual para que o controle de qualidade pudesse terminar o teste. Isso significa que os recursos que estão sendo desenvolvidos podem não ser testados por duas a três semanas após o desenvolvedor já ter prosseguido. Com o desenvolvedor avançando mais rápido que o controle de qualidade, esse intervalo de tempo só aumentará.

Continuo folheando minha cópia do Code Complete, procurando um trecho "Hard Data" que mostre que o custo de correção de defeitos cresce exponencialmente quanto mais tempo ele existe. Alguém pode me indicar alguns estudos que apoiam esse conceito? Estou tentando convencer os poderes de que o gargalo do controle de qualidade é muito mais caro do que eles pensam.

Você não precisa de nenhuma referência, IMHO. Aqui está o que você poderia (e deveria ) fazer:

Quantifique o custo do atraso! Vamos supor que leva 1 semana para testar os recursos. Um atraso de duas a três semanas implica que o recurso não estará disponível até a quarta semana. E isso também assumindo 100% de sucesso. Adicione um tempo de fixação de mais uma semana, para que isso ocorra com cerca de 5 semanas de atraso.

Agora, se possível, acesse o prazo esperado do projeto / recurso. Até quando o cliente espera isso? Será que vai escorregar? Caso contrário, outras pessoas escaparão como consequência? Então, em quanto tempo o 'lançamento' será adiado como resultado?

Qual é o 'custo para a empresa' dessa liberação, ou seja, quanto o cliente espera lucrar com essa liberação? Se eles esperam US $ 5200 / ano de lucro desse lançamento, todas as semanas caem custando US $ 100 em receita perdida. Essa é a visão do cliente. Você pode ou não ter acesso a esses dados, mas vale a pena levar em consideração e declarar como o atraso pode afetar o relacionamento.

Agora, qual é a perda para os desenvolvedores? Depois que o desenvolvedor passa para outros recursos, você pede que ele interrompa o ciclo e 'conserte' o recurso anterior. Qual é a perda de tempo / esforço? Converta-o em custo para a empresa usando o salário como um múltiplo para cada hora desperdiçada como resultado. Você pode usar isso para dizer a quantidade de "lucro / receita" na qual o lixo está "consumindo".

O que você encontrou pode ser convenientemente quantificado usando o "Custo do Atraso" - defendido por Don Reinerstein no fluxo Princípios de Desenvolvimento de Produto e também por Dean Leffingwell no Agile Software Requirements. Você deve ser capaz de apoiar todas essas reivindicações por fatores econômicos para convencer as 'potências superiores', cuja língua principal é $$ - você deve falar a língua deles para convencê-las :)

Besta da sorte! (trocadilho :)

Eu realmente não acho que o Code Complete seja o recurso certo para você aqui. Este não é um problema de código, é um problema de processo e talvez um problema de gerenciamento.

Se parte do seu processo é particularmente fraca, é hora de eliminar a Teoria das Restrições :

1. Identifique a restrição.

   Isso significa encontrar a parte mais lenta ou ineficiente do processo geral. No seu caso, está testando. Mas que parte dos testes? É isso:

   • Preparando o ambiente de teste?
   • Determinando o que testar?
   • Testes funcionais (de aceitação)?
   • Testes de regressão?
   • Teste exploratório?
   • Relatar bugs / defeitos dos testes?
   • Determinando as etapas para reproduzir um bug?
   • Obtendo esclarecimentos de desenvolvedores ou gerentes de projeto?
   • Corrigindo os problemas encontrados no estágio de controle de qualidade?

   Todos esses são problemas muito diferentes e exigem soluções diferentes. Você precisa decidir qual é o mais caro / importante. Justificar isso à gerência não deve ser difícil, pois todas as atividades acima custam tempo (dinheiro AKA) e apenas algumas delas são de valor agregado.

2. Explorar a restrição.

   Em outras palavras, otimizar em torno do processo de constrangimento. Nunca deixe os testadores ficarem ociosos. Isso equivale essencialmente a:

   • Colocar testadores dentro das equipes de desenvolvimento, se ainda não estiverem, para que haja um ciclo de feedback contínuo com os desenvolvedores.
   • Tendo implantações de teste freqüentes, sempre há algo novo / corrigido para testar.
   • Tornando a comunicação mais rápida e frequente. Por exemplo, prefira as mensagens instantâneas sobre os threads de email.
   • Garantir que os testadores tenham as melhores ferramentas disponíveis (máquinas rápidas, vários monitores, rastreamento de erros simplificado etc.)

   Esse estágio não é sobre a otimização do processo de teste em si (ainda), é mais sobre a redução de custos indiretos. Não perca tempo com os testadores. Eliminar o tempo realmente desperdiçado também deve ser uma venda fácil para a gerência.

3. Subordine outras atividades à restrição.

   Nesse ponto, os testadores são o mais produtivos possível, por isso, precisamos começar a pedir emprestado a produtividade de outras áreas:

   • Instrua os desenvolvedores e a equipe de operações a darem prioridade aos testadores, não importa em que outra coisa eles estejam trabalhando.
   • Se você não possui equipes multifuncionais, reserve uma sala de reuniões todos os dias em um horário predefinido, para que os testadores nunca precisem perder tempo tentando reservar uma.
   • Desviar uma porcentagem maior do tempo do desenvolvedor (e possivelmente operações) longe do trabalho de recursos; por exemplo, concentre-se em correções de bugs, dívida / refatoração de tecnologia, revisão de código e teste de unidade.
   • Teste de forma contínua e incremental - não desenvolva por três semanas e depois passe para os testadores. Faça com que os desenvolvedores trabalhem para tornar seu código imediatamente testável, por exemplo, com UIs de andaimes ou protótipos.

4. Eleve a restrição.

   Se os testadores estiverem trabalhando com capacidade total - em termos de produtividade e de sobrecarga mínima - e ainda não forem rápidos o suficiente, será necessário começar a investir mais em testes.

   • Se você confiar em implantações de teste manual, automatize-o usando scripts de gerenciamento de integração e configuração contínuos.
   • Se os planos de teste levarem muito tempo para serem criados, trabalhe para obter melhores critérios de aceitação (por exemplo, INVEST ). A maioria das organizações é inicialmente muito ruim nisso.
   • Se os testes de aceitação estiverem demorando muito, comece a automatizá-los. Use uma ferramenta como Cucumber ou FitNesse ou escreva testes do tipo xUnit, se necessário. Há também Selenium, Watij e outras ferramentas de automação de navegador, se o teste da interface do usuário demorar muito.
   • Se os testes de regressão estiverem demorando muito, automatize isso também. Se ele não pode ser automatizado, o foco na melhoria da qualidade fora do portão, ou seja, com maior ênfase na revisão de código, testes unitários, ferramentas de análise estática, etc. Os desenvolvedores devem estar bastante confiante de que há muito poucos reais erros antes de passá-lo ao controle de qualidade (os defeitos do produto são uma história diferente).
   • Se o teste exploratório for o gargalo, você poderá adiar parte disso até o lançamento, ou contratar uma empresa de testes para realizar coisas altamente paralelizáveis, como testar o mesmo fluxo de trabalho em vários navegadores.
   • Se os testadores não conseguirem reproduzir muitos bugs, considere criar um ambiente de teste de capacidade para começar a reproduzir erros intermitentes. Ou tente executar seus testes de aceitação automatizados em paralelo e continuamente, o dia todo, mantendo registros detalhados.
   • Se demorar muito para corrigir os bugs, comece a particionar seus projetos e / ou considere seriamente a possibilidade de re-arquitetar suas soluções. Ou, alternativamente, não conserte alguns deles; nem todo bug é crítico, você deve priorizá-lo juntamente com o trabalho de recursos.
   • Se tudo mais falhar, contrate mais testadores.

5. Volte para a Etapa 1.

Eu gostaria de dizer que tudo isso é senso comum, mas infelizmente não é, pelo menos não na maioria das organizações. Se você está recebendo muita resistência do gerenciamento, uma técnica inestimável é o Value Stream Mapping (uma técnica da manufatura enxuta), que você pode usar para mostrar quanto tempo e, portanto, o dinheiro é realmente desperdiçado todos os dias por um candidato a liberação ser incapaz para passar para a próxima etapa. É difícil entender o custo de oportunidade, mas essa é uma das melhores maneiras que encontrei para visualizá-lo e demonstrá-lo.

E se nada disso funcionar ... então talvez você esteja em uma empresa disfuncional, saia antes que seja tarde demais!

Mas você não resolverá esse problema simplesmente largando alguns papéis na mesa do gerente e pedindo que joguem dinheiro no problema, porque eles assumirão (corretamente) que jogar dinheiro nele pode não ser realmente resolvido, e pode até gerar pior. Você precisa fornecer soluções , e é disso que se trata esta resposta. Se você apresentar o problema como "aqui está uma lista de maneiras pelas quais podemos começar a resolver esse problema, em ordem decrescente de custo / benefício", em vez de "precisamos de mais testadores", você terá muito mais sucesso.

As páginas 29 e 30 podem ter os dados que você está procurando, embora possa ser necessário um acompanhamento.

Eu examinaria a pesquisa mencionada nesta frase na página 30:

Dezenas de empresas descobriram que o simples foco na correção de defeitos mais cedo ou mais tarde em um projeto pode reduzir custos e cronogramas de desenvolvimento por fatores de dois ou mais (McConnell 2004).

BTW, foi sua pergunta que me levou a pegar o livro novamente para atualizá-lo :-)

O que você está descrevendo é um gargalo em um processo. A teoria Lean afirma que sempre haverá um gargalo em um processo, mas sua gravidade pode variar amplamente. Se o controle de qualidade contratou mais um, o desenvolvimento pode se tornar um gargalo.

Para entender o custo, imagine a seguinte situação. Você escolheu um dos desenvolvedores. Seu trabalho nunca seria garantido pela qualidade, mas sempre seria enfileirado indefinidamente. Imagine que isso significaria que o controle de qualidade poderia garantir o trabalho dos demais desenvolvedores em tempo hábil e não haveria custo de atraso.

Nesse cenário, o custo do atraso é o custo do salário do desenvolvedor, porque seu trabalho seria desperdiçado.

A razão pela qual discuto em termos de custo e não do valor criado pelo processo, é simplesmente porque é mais difícil documentar o valor de um processo, mesmo que seja muito melhor.

Continuo folheando minha cópia do Code Complete, procurando um trecho "Hard Data" que mostre que o custo de correção de defeitos cresce exponencialmente quanto mais tempo ele existe. Alguém pode me indicar alguns estudos que apoiam esse conceito?

O custo exponencial de encontrar um bug parece basear-se em um estudo do NIST . O estudo foi uma pesquisa que pressupõe estágios distintos em cascata:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( tabela aqui daqui )

Um dos objetivos das metodologias de desenvolvimento de software Agile é remover esses estágios distintos e reduzir esses custos. As figuras não se aplicam ao usar outras metodologias para cascata.

Seu problema não é com o controle de qualidade; na verdade, se ele estiver realizando testes, os atrasos serão praticamente a menor das suas preocupações. Deixe-me expulsar (novamente, como é um equívoco comum no setor de programação) ... QA Garante a qualidade do produto supervisionando todo o SDLC, desde Requisitos (talvez mais cedo), até o desenvolvimento, verificação, liberação e suporte. O teste garante que não haja defeitos óbvios no código. Há uma diferença muito grande e importante. Se você tivesse um controle de qualidade real, eles estariam por todo o departamento de Teste / V&V perguntando por que estavam custando o tempo de negócios (e, portanto, dinheiro) atrasando as liberações, ou por todo o gerenciamento do projeto, garantindo que eles estavam gerenciando o cronograma do projeto corretamente ou fazendo toda a gestão Certifique-se de que havia testadores suficientes para o código que está sendo produzido, etc ...

Então, assumindo o controle de qualidade, você realmente quer dizer Teste, voltando à questão original. O Code Complete acertou - o custo de um defeito é o tempo que leva da inserção à correção. A detecção precoce só é útil se você também a corrigir precocemente, mas a interpretação da maioria das pessoas está errada.

(Nota: eu estou interpretando o advogado do Diabo aqui, não leve nada disso literalmente, pois não sei nada de você.) O atraso causado pelo seu departamento de Teste é um custo, absolutamente, no entanto, tenho que perguntar se você está esperando que eles encontrem seus defeitos, o que você está fazendo - caso não encontre seus próprios defeitos? Talvez se eles tivessem menos trabalho (através de uma entrada de qualidade superior com menos defeitos de sua parte), o atraso não seria tão significativo e o custo seria menor - como gerente, eu perguntaria como você planeja reduzir os defeitos no código que entrega para teste, pois (com base no seu argumento) esses defeitos custam mais se encontrados por teste do que você.

Além disso, como gerente, posso afirmar que não é o trabalho de testes que encontra seus defeitos. O trabalho deles é encontrar que não há defeitos - se você espera que eles encontrem defeitos, talvez você não tenha feito seu trabalho suficientemente bem.

Cuidado ao abordar isso. Se você não tiver uma solução para o problema, provavelmente ficará em segundo lugar.