Quanto custam os testes de unidade?

Agora, no auge do ciclo econômico em uma indústria tão quente como o desenvolvimento de software, não é habitual contar dinheiro. Muitas vezes, esse processo, em princípio, é posicionado como uma atividade criativa, onde não há necessidade de justificar nada, e o artista sabe melhor o que e como escrever. Em particular, há muita controvérsia sobre o tema dos testes de unidade e TDD, mas, infelizmente, todos eles caem em declarações não comprovadas e ataques emocionais, confirmadas por provas de artigos e livros selecionados com sucesso por metodologistas que ganham em consultas e vendas de treinamentos, que, em sua por sua vez, eles não contêm absolutamente nenhuma estatística ou cálculo ou, pelo contrário, acusações radicais de smushylebstvo e outros pecados da juventude.

Ao contrário de argumentos vazios semelhantes, este artigo fornecerá não apenas informações para reflexão, mas também uma metodologia para avaliar a viabilidade econômica da introdução de testes de unidade em um projeto específico. Enfatizarei imediatamente que, como qualquer avaliação, nossa avaliação para o projeto de implementação do teste de unidade será baseada em suposições sobre o futuro do produto, equipe e vários indicadores, que só podem ser avaliados subjetivamente. No entanto, a situação em que um programador faz uma avaliação especializada de indicadores que estão pelo menos de alguma forma relacionados ao seu campo de atividade é muito melhor do que perguntar diretamente se é rentável para a empresa usar testes de unidade ou não. No final, os programadores geralmente não estão inclinados a sequer pensar em indicadores financeiros básicos, mas não apenas nos desenvolvedores, mas também nos testadores e gerentes capazes de avaliar o tempo gasto escrevendo testes ou a probabilidade de um bug crítico na sua ausência.

Qual é o custo

Primeiro de tudo, se vamos calcular o custo de qualquer coisa, precisamos primeiro, pelo menos em termos gerais, entender o que é valor. Quando compramos um pão de salsicha, essa questão não surge, uma vez que o preço está abaixo dele. Porém, no caso do projeto, não estamos lidando com um pagamento único, mas com um fluxo de caixa que dura muito tempo, investimos primeiro e depois nos pagamos. Para avaliá-lo corretamente, é necessário considerar que o dinheiro recebido amanhã custará menos que hoje. Se a lingüiça fosse vendida por assinatura, não seria difícil, o custo da assinatura poderia ser calculado descontando os pagamentos futuros pela quantidade de inflação. No entanto, no caso do projeto, precisamos levar em consideração que a empresa, investindo nele, espera não apenas compensar seus custos, mas também ganhar, tanto quanto cobrir seus riscos. Há um grande número de riscos, mas no final tudo se resume ao fato de que o retorno do dinheiro investido na implementação do projeto não é garantido e mal previsto. O dinheiro pode ser levado a um banco ou emprestado a algum devedor forte e garantido o pagamento de juros regularmente, mas você não pode investir em um projeto para ter um fluxo de pagamentos previsível dentro do cronograma. Portanto, do ponto de vista do investidor, nesse caso, a empresa, o fluxo de caixa descontado à taxa de retorno exigida gerada pelo projeto, também chamada de valor presente líquido, deve ser positivo:

$$

Para calculá-lo, precisamos saber quanto dinheiro o projeto trará ou consumirá no primeiro, segundo, terceiro ano, etc., bem como a taxa de desconto, que não deve apenas ser mais lucrativa do que no banco, mas também cobrir os riscos. .

De fato, esta é uma fórmula um tanto simplificada. A rigor, a taxa mudará de ano para ano, portanto, WACC1 * WACC2 * WACC3, etc., deve ser usado no denominador, mas, na prática, mesmo avaliadores profissionais negligenciam isso, porque Em virtude da metodologia de cálculo do WACC, as expectativas do mercado em relação às taxas futuras já foram incorporadas às taxas atuais e é improdutivo fazer suposições sobre isso.

Existem diferentes tipos de fluxos de caixa, mas tomei o fluxo de caixa mais conveniente para nossos propósitos para a empresa, que leva em conta não apenas o dinheiro devido aos proprietários, mas também aos credores. Obviamente, a maioria das empresas de TI não possui dívidas visíveis simplesmente porque ninguém as empresta sem garantia e elas não têm o que prometer, mas ainda há exceções, por exemplo, essa abordagem pode ser conveniente ao avaliar um projeto no desenvolvimento interno de uma empresa de manufatura emprestada . A segunda razão pela qual a FCFF é de particular interesse para nós é a simplicidade de seu cálculo, a FCFF é apenas lucro operacional menos impostos, custos líquidos de capital e alterações no capital de giro.

Como o FCFF é um fluxo de caixa para proprietários e credores ao mesmo tempo, é descontado a uma taxa ponderada do custo de capital, próprio e emprestado.

Nas grandes empresas, o custo do capital é monitorado pelo departamento financeiro, portanto, você pode simplesmente solicitar, mas, no caso geral, ainda precisamos de uma fórmula para calcular o WACC:

$$

Aqui Re é o custo do patrimônio, Rd é o custo do capital emprestado (ou seja, a taxa efetiva das dívidas da empresa), P é o valor de mercado do patrimônio, EV é o custo total da empresa (EV = P + D, onde D é dívida).

Em seguida, precisamos determinar Re, para isso, existem modelos diferentes, mas a maneira mais fácil é usar o modelo CAPM, em que Re = Rb + β * Premium, em que Rb é a taxa livre de risco, Premium é o prêmio para o retorno do investimento em ações, e não em emprestado e β é um fator de risco que mostra quanto mais arriscado nosso projeto é em relação aos negócios de uma determinada empresa média.

Como é garantida a qualidade e quais são os testes de unidade

Agora precisamos decidir o que são testes de unidade. Curiosamente, muitas pessoas, mesmo próximas ao desenvolvimento, costumam chamar todos os testes de unidade de testes automatizados, mas isso, é claro, não é assim.

O teste é dividido em funcional e não funcional. Não funcional inclui itens que não estão diretamente relacionados à funcionalidade do software, por exemplo, testes de carga ou testes relacionados à segurança. Funcional, no entanto, significa apenas verificar a conformidade com os requisitos e a ausência de erros em sua implementação, será discutido especificamente.

A primeira coisa que precisa ser feita para garantir a qualidade é assumir a função de controle dos desenvolvedores e contratar a pessoa que será responsável por ela. Portanto, um testador aparece na equipe, envolvida em testes manuais. Nenhum projeto sério é simplesmente inconcebível sem testes manuais; é a base que o projeto precisa de maneira vital e a grande maioria dos problemas que serão descobertos e corrigidos no tempo será o mérito dos testadores. Nesta fase, tudo parece simples: se você deseja qualidade, contrate um especialista em qualidade.

À medida que o projeto cresce, o tempo para testes manuais será cada vez menor, de modo que os testadores estarão cada vez mais ocupados trabalhando com novos recursos do sistema e cada vez menos verificarão as partes do sistema que não deveriam ter mudado. No entanto, à medida que a complexidade do sistema aumenta e há uma probabilidade de dependências explícitas e implícitas aparecerem entre seus componentes, das quais os desenvolvedores podem perder de vista, ainda é aconselhável verificar algumas coisas todas as vezes antes do lançamento. Esse problema é especialmente agudo em metodologias flexíveis, com iterações curtas e lançamentos frequentes. Isso implica logicamente a necessidade de automatizar o trabalho dos testadores, por exemplo, escrever um script que clique nos botões e verificar o resultado em si, ou usar ferramentas mais poderosas e transformar um testador comum em um especialista em testes automatizados capaz de automatizar a parte rotineira de seu trabalho.

Essas medidas podem fornecer um nível decente de qualidade, mas não há limite para a perfeição. O que os testadores fazem é chamado de teste de caixa preta; sua responsabilidade é não conhecer todos os recursos da implementação; portanto, o teste geralmente é focado em cenários típicos e não define o objetivo de quebrar o sistema ou verificar seu comportamento em condições atípicas. Além disso, algumas coisas não são fáceis de verificar simplesmente devido à falta de uma interface, por exemplo, se o objetivo da iteração é desenvolver uma biblioteca para acessar dados ou alguma API específica, para testá-lo, você precisará escrever algum aplicativo ou pelo menos algo que usaria esse componente. Nesses casos, você deve retornar parcialmente a função de controle de qualidade aos desenvolvedores e solicitar que eles escrevam testes de integração. Este é o segundo tipo de testes automatizados usados ​​no projeto. Seu objetivo é testar a correção da interação dos componentes do sistema escritos por pessoas diferentes, testar o comportamento desses componentes em condições limítrofes, bem como a correção da reação a falhas no ambiente.

Bem, temos testadores que testam todo o projeto quanto à conformidade com os requisitos, existem testes para automatizar seu trabalho e existem testes que testam partes do projeto escritas por diferentes desenvolvedores, o que mais pode ser feito? Os testes de unidade afirmam ser o quarto nível de controle de qualidade. Eles verificam o código escrito por um programador e, como regra, testam a parte mínima do código, que é basicamente adequada para testar, por exemplo, uma classe separada. Na prática, na maioria das vezes o próprio desenvolvedor escreve testes de unidade para seu próprio código, e seu número e necessidade são mal controlados. De acordo com minhas observações, cerca de 40% do tempo para o desenvolvimento do recurso em si pode ser chamado de uma quantidade típica de tempo do desenvolvedor gasto em testes de unidade, embora essa proporção possa variar bastante. O estudo de caso de código aberto do projeto SQLite é amplamente conhecido, onde, devido ao excesso de mão-de-obra gratuita pouco qualificada fornecida por um grande número de pessoas que desejam trabalhar em um projeto conhecido, essa força de trabalho é utilizada na forma militar, ou seja, escrevendo testes de unidade inúteis, cujo volume em algum momento em 100 vezes o volume do código do próprio DBMS. Os casos inversos em que os testes de unidade não são gravados ou gravados em um volume mínimo também não são surpreendentes. No final, quase todo software desenvolvido até o final do zero, ou seja, antes da era da terceirização e do Agile, foi criado sem testes de unidade.

Custos, ajuste de complexidade e mítico pessoa-mês

Obviamente, se você precisar escrever testes de unidade ou qualquer outra coisa, precisará dedicar mais tempo ao projeto ou contratar desenvolvedores adicionais. A principal questão que surge nesse caso é se a dependência do tempo e do custo de desenvolvimento da quantidade de código é linear ou se obedece a outra lei.

Era uma vez um repositório SVN gratuito no notório serviço Assembla, que fornecia serviços de hospedagem de origem e ferramentas de colaboração, ou seja, um rastreador, estatísticas e outras bobagens. Mais tarde, o brinde terminou, mas eles não pararam de enviar boletins e notificações. Então, em 2015, seu funcionário publicou um pequeno post intitulado "Quantas pessoas devem discutir uma tarefa?" Agora, ele é preservado apenas no arquivo da Web . A essência do cargo era a seguinte: o funcionário coletou estatísticas sobre os clientes, plotando a dependência da duração da tarefa com o número de pessoas que o discutiram, o resultado foi o seguinte:



Pode-se ver que a dependência é não-linear. Duas pessoas geralmente estão envolvidas na solução de um problema que dura dois dias, três pessoas - quatro dias e quatro pessoas - já com seis dias. O que eles estão fazendo lá? Pode-se supor que a tarefa exija várias etapas do trabalho, por exemplo, no caso de duas pessoas, Vasya faz sua parte da tarefa e depois a transfere para Petya, que dura dois dias. Três pessoas já podem brigar e mais uma vez compartilhar responsabilidades, descobrir quem é o culpado e o que fazer, e um grupo de sete pessoas passará seis dias adicionais discutindo, negociando e se opondo.

Obviamente, também se pode supor que uma equipe amigável de sete pessoas tenha tarefas difíceis que são muito mais simples e quanto mais pessoas estiverem ocupadas com a tarefa, maior será, pois a amizade é mágica! Portanto, essas considerações podem parecer exageradas e eu não as incluirei em cálculos subsequentes; no entanto, se você quiser obter uma estimativa mais conservadora, não seria inapropriado fazer alguma correção para a não linearidade do aumento de custos com o crescimento da base de código do projeto, o que, é claro, Também são incluídos testes de unidade, ou para estabelecer uma certa margem de segurança nos requisitos para o nível de NPV.

Se explicarmos a não linearidade desse cronograma apenas pelo crescimento do tamanho da equipe, os custos associados a ele poderão ser estimados a partir da tabela a seguir da dependência da parcela de tempo perdido na comunicação sobre o tamanho do grupo de trabalho:



Por exemplo, se houver cinco desenvolvedores em uma equipe e você acredita que precisa contratar dois para que todos possam gastar mais 40% de seu tempo em testes de unidade, esteja preparado para o fato de que os custos de desenvolvimento podem aumentar em mais de 40%. A equipe crescerá e se tornará menos eficaz, em vez de 5 * 0,625 = 3,125 unidades convencionais de produtividade, terá 7 * 0,539 = 3,77 unidades, e a quantidade de trabalho aumentará de 1 para 1,4 unidades convencionais de trabalho, respectivamente, o tempo necessário para o desenvolvimento aumentará 16%.

Uma conclusão interessante que pode ser extraída do gráfico é que, quando o número de pessoas é superior a dez, o valor de cada novo participante se torna menor que o custo adicional da comunicação e a lei de Brooks começa a funcionar. Resta apenas tentar dividir as tarefas em tarefas menores ou envolver funcionários mais experientes e eficientes em sua implementação.

Obviamente, é difícil dizer que a não linearidade do gráfico do Assembla está associada apenas a uma diminuição da eficiência como resultado do crescimento da equipe, mas está de acordo com o entendimento intuitivo da complexidade e da lei de Brooks; portanto, se você não quer correr riscos e precisa de uma estimativa conservadora, esses dados podem Torne-se uma boa ajuda.

Os benefícios dos testes de unidade

Além dos custos, os testes de unidade também trazem benefícios. Obviamente, na grande maioria dos casos, um bug que pode ser detectado por testes de unidade será detectado em outros níveis de controle de qualidade, mas sempre há uma chance de uma falha técnica e, teoricamente, os testes de unidade podem reduzi-lo. Pessoalmente, não conheço esses casos. Felizmente, todos os testadores com quem trabalhei eram pessoas extremamente responsáveis, mas quando se trata de tão baixas probabilidades, a experiência pessoal pode não ser representativa. As falhas podem ter consequências diferentes, por exemplo, uma empresa pode ter um SLA, cuja violação acarreta certas perdas financeiras; por exemplo, a empresa será forçada a oferecer aos clientes um mês de uso gratuito de seus serviços como compensação, perdendo 1/12 da receita. Nesse caso, o controle rígido da qualidade, que reduz a probabilidade de violações de SLA durante o ano de 10% para 8%, reduzirá as perdas anuais médias em cerca de 0,17% da receita. Esse dinheiro será o componente positivo do fluxo de caixa que precisa ser adicionado ao modelo.

Observe que esse cálculo simples é aplicável apenas quando a probabilidade de perda é baixa, se a probabilidade for maior que 15-20% e pode levar à falência ou liquidação da empresa, é aconselhável usar modelos de avaliação opcionais, por exemplo, como uma árvore de decisão. Felizmente, na maioria dos casos, algum tipo de bug estúpido não é algo que pode levar à falência de uma empresa e não precisamos mergulhar no horror de calcular o custo das opções.

Exemplo Um: Bisonte

Bison é uma grande loja online, eles se autodenominam o varejista número 1 na Rússia. A empresa não é pública, mas em uma transação de recapitalização recente, sua capitalização total foi estimada em 50 bilhões de rublos, o que representa o dobro da receita anual. Foi necessária capitalização adicional devido a perdas operacionais, mas os acionistas esperam alcançar uma margem de lucro operacional de 10% depois que a empresa conseguir ganhar uma participação de mercado mais alta e dobrar a receita dentro de um ano, após o qual terá que começar a ganhar e o crescimento da receita diminuirá até 30% no segundo ano, 20% no terceiro ano e, finalmente, fixado em 10% no quarto e nos anos seguintes. No entanto, os bancos não têm muita certeza disso e dão a Bizon uma longa cautela, a dívida total da empresa é de apenas 10 bilhões de rublos a uma taxa de 11%. A Bison é uma empresa bastante desajeitada e mal gerenciada no nível operacional, a contratação descontrolada de funcionários já levou ao fato de empregar 600 programadores, cujo orçamento total da folha de pagamento é de 1,5 bilhão de rublos por ano e que gastam cerca de 30% do seu tempo de trabalho em testes de unidade. A empresa não tem obrigações para com os clientes e uma falha técnica pode levar a uma parada temporária nas vendas e, em caso de falha, uma reversão para a versão antiga do site leva cerca de uma hora.

Qual é o VPL do uso de testes de unidade no bisonte?

50, 65, 78 86 , , . 33%, , , . , 25% , DDOS . , 0,023% , 12 . , 11,5 , 14,8 , 17,8 19,6 .

, 450 .

, , , . , ! , - , , .

, , 10% , , -438, -480, -527 -579 , , , 10% . , , 20% , , 0.8: -351, -384, -421 -463 .

EV 50 + 10 = 60 , P 83% , D 17%, , 11% , WACC . , , 7,6%. , 4-6% , 5%, β (unlevered beta) 1,3. , , (levered beta):

$$

WACC

$$

, , , , 10% .

$$ , $$ , $$ .

10% , $$ , : $$ .
$$ .

:

– . , , . , , , 50 . . .
Durante a visita de Vasily à oficina, o especialista responsável pela produção disse-lhe, em termos gerais, o seguinte: “Caro colega! Por favor, preste atenção a este balde gigante de metal fundido. Se algo der errado, não apenas ficaremos extremamente desencorajados, mas também confrontados com dificuldades tecnológicas. O fato é que, se o alto-forno subir, o metal endurece e leva três meses para eliminar as consequências do acidente. "Não será fácil lidar com um pedaço gigante de metal na oficina e substituí-lo por um novo alto-forno". Vasily descobriu mais tarde que uma parada de emergência para um alto-forno poderia custar à empresa 8 bilhões de rublos.
Pergunta: Vasily está preocupado em escrever testes de unidade?
, : . , ( 50, - 10, ), , . , , - , , 100 10% * 8 = 800 .

: XSoft

A XSoft é uma empresa de terceirização de sucesso que acaba de assinar um contrato com outro cliente ocidental. O cliente planeja contratar 7 programadores, seu orçamento nesta parte é de 15 milhões de rublos por ano, dos quais a XSoft levará 3 milhões. O cliente é um bardana e não entende nada no desenvolvimento. Do ponto de vista da XSoft, os desenvolvedores devem escrever testes de unidade?

! , , -, , - . , , , .

Posfácio

, , . , . , , NPV / IRR. , IT. Excel .