👩🏿‍🎤 👨🏿 ⏭️ Combien coûtent les tests unitaires? ✊ 😫 👩🏽‍🏭

Maintenant, au sommet du cycle économique dans une industrie aussi chaude que le développement de logiciels, il n'est pas habituel de compter l'argent. Souvent, ce processus se positionne en principe comme une activité créative, où il n'y a pas besoin de justifier quoi que ce soit, et l'artiste sait mieux quoi et comment écrire. En particulier, il y a beaucoup de controverse sur le sujet des tests unitaires et du TDD, mais, malheureusement, ils se glissent tous dans des déclarations non éprouvées et des attaques émotionnelles, confirmées par des preuves d'articles et de livres sélectionnés avec succès par des méthodologistes qui gagnent des consultations et des ventes de formations, qui, dans leur à leur tour, ils ne contiennent absolument aucune statistique ou calcul, ou, au contraire, des accusations massives de smushylebstvo et d'autres péchés de la jeunesse.

Contrairement à des arguments vides similaires, cet article vous donnera non seulement matière à réflexion, mais également une méthodologie pour évaluer la faisabilité économique de l'introduction de tests unitaires sur un projet spécifique. Je soulignerai immédiatement que, comme toute évaluation, notre évaluation du projet de mise en œuvre du test unitaire sera basée sur des hypothèses concernant l’avenir du produit, de l’équipe et de divers indicateurs, qui ne peuvent être évalués que de manière subjective. Néanmoins, la situation où un programmeur donne une évaluation experte d'indicateurs qui sont au moins en quelque sorte liés à son domaine d'activité est bien meilleure que de lui demander directement s'il est rentable pour l'entreprise d'utiliser des tests unitaires ou non. En fin de compte, les programmeurs ne sont généralement pas enclins à penser aux indicateurs financiers de base, mais non seulement les développeurs, mais aussi les testeurs et les gestionnaires sont en mesure d'évaluer le temps passé à écrire des tests ou la probabilité d'un bug critique en leur absence.

Quel est le coût

Tout d'abord, si nous voulons calculer le coût de quoi que ce soit, nous devons d'abord au moins en termes généraux comprendre ce qu'est la valeur. Lorsque nous achetons un pain de saucisse, cette question ne se pose pas, car une étiquette de prix y est accrochée. Mais dans le cas du projet, nous n'avons pas affaire à un paiement unique, mais à un flux de trésorerie qui dure longtemps, et nous l'investissons d'abord, puis nous payons. Afin de l'évaluer correctement, vous devez considérer que l'argent reçu demain coûtera moins cher qu'aujourd'hui. Si la saucisse était vendue par abonnement, ce ne serait pas difficile à faire, le coût de l'abonnement pourrait être calculé en actualisant les paiements futurs pour elle par le montant de l'inflation. Cependant, dans le cas du projet, nous devons tenir compte du fait que l'entreprise, en y investissant, s'attend non seulement à compenser ses coûts, mais aussi à gagner, au point de couvrir ses risques. Il existe un grand nombre de risques, mais au final, tout se résume au fait que le retour sur investissement investi dans la mise en œuvre du projet n'est pas garanti et mal prévu. L'argent peut être apporté à une banque ou emprunté à un emprunteur difficile et garanti de payer des intérêts sur une base régulière, mais vous ne pouvez pas investir dans un projet de sorte que vous vous retrouvez avec un flux de paiement prévisible dans les délais. Par conséquent, du point de vue de l'investisseur, dans ce cas, l'entreprise, le flux de trésorerie actualisé au taux de rendement requis généré par le projet, également appelé valeur actuelle nette, devrait être positif:

$display$

Pour le calculer, nous devons savoir combien d'argent le projet apportera ou mangera la première, la deuxième, la troisième année, etc., ainsi que le taux d'actualisation, qui devrait non seulement être plus rentable qu'à la banque, mais aussi couvrir les risques .

En fait, c'est une formule quelque peu simplifiée. À strictement parler, le taux changera d'année en année, donc WACC1 * WACC2 * WACC3, etc., devrait être utilisé dans le dénominateur, mais dans la pratique même les évaluateurs professionnels négligent cela, car En vertu de la méthodologie de calcul du WACC, les attentes du marché concernant les taux futurs ont déjà été intégrées dans les taux actuels et il est improductif de faire des hypothèses à ce sujet.

Il existe différents types de flux de trésorerie, mais j'ai pris le flux de trésorerie le plus pratique pour nos besoins pour l'entreprise, qui prend en compte non seulement l'argent dû aux propriétaires, mais aussi aux créanciers. Bien sûr, la plupart des sociétés informatiques n'ont pas de dettes notables simplement parce que personne ne leur prête sans garantie et qu'elles n'ont rien à donner en gage, mais il y a encore des exceptions, par exemple, cette approche peut être pratique lors de l'évaluation d'un projet dans le développement interne d'une entreprise de fabrication prêtée . La deuxième raison pour laquelle le FCFF nous intéresse particulièrement est la simplicité de son calcul, le FCFF est juste un bénéfice d'exploitation moins les impôts, les coûts en capital nets et les variations du fonds de roulement.

Étant donné que le FCFF est à la fois un flux de trésorerie pour les propriétaires et les prêteurs, il est actualisé à un taux pondéré du coût du capital, à la fois propre et emprunté.

Dans les grandes entreprises, le coût du capital est contrôlé par le service financier, vous pouvez donc le demander, mais pour le cas général, nous avons encore besoin d'une formule de calcul du WACC:

$display$

Ici, Re est le coût des capitaux propres, Rd est le coût du capital emprunté (c'est-à-dire le taux effectif sur les dettes de l'entreprise), P est la valeur marchande des capitaux propres, EV est le coût total de l'entreprise (EV = P + D, où D est la dette).

Ensuite, nous devons déterminer Re, pour cela il existe différents modèles, mais le moyen le plus simple est de prendre le modèle CAPM, où Re = Rb + β * Premium, où Rb est le taux sans risque, Premium est la prime pour le retour sur investissement en capitaux propres, pas en emprunté, et β est un facteur de risque qui montre à quel point notre projet est plus risqué par rapport aux activités d'une certaine entreprise moyenne.

Comment la qualité est assurée et quels sont les tests unitaires

Nous devons maintenant décider quels sont les tests unitaires. Curieusement, de nombreuses personnes, même proches du développement, appellent souvent des tests unitaires de tests automatisés, mais ce n'est bien sûr pas le cas.

Les tests sont divisés en fonctionnels et non fonctionnels. Non fonctionnel comprend des éléments qui ne sont pas directement liés à la fonctionnalité du logiciel, par exemple, les tests de charge ou les tests liés à la sécurité. Fonctionnel, cependant, signifie simplement vérifier la conformité aux exigences et l'absence d'erreurs dans leur mise en œuvre, il sera discuté spécifiquement.

La première chose à faire pour garantir la qualité est de prendre la fonction de contrôle des développeurs et d'embaucher la personne qui en sera responsable. Un testeur apparaît donc dans l'équipe, qui effectue des tests manuels. Pas un seul projet sérieux n'est tout simplement inconcevable sans test manuel; c'est la base qui est vitale pour le projet et la grande majorité des problèmes qui seront découverts et corrigés à temps seront le mérite des testeurs. A ce stade, tout semble simple: si vous voulez de la qualité, faites appel à un spécialiste de la qualité.

Au fur et à mesure que le projet se développe, le temps pour les tests manuels sera de moins en moins, donc les testeurs seront de plus en plus occupés à travailler avec de nouvelles capacités du système et de moins en moins vérifieront les parties du système qui n'auraient pas dû changer. Cependant, à mesure que la complexité du système augmente et qu'il est probable que des dépendances explicites et implicites apparaissent entre ses composants, que les développeurs peuvent théoriquement perdre de vue, il est toujours conseillé de vérifier certaines choses à chaque fois avant la publication. Ce problème est particulièrement aigu dans les méthodologies flexibles avec leurs courtes itérations et leurs versions fréquentes. Cela implique logiquement la nécessité d'automatiser le travail des testeurs, par exemple, d'écrire un script qui cliquera sur les boutons et vérifiera le résultat lui-même, ou utilisera des outils plus puissants et transformera un testeur ordinaire en spécialiste des tests automatisés capable d'automatiser la partie de routine de son travail.

Ces mesures peuvent fournir un niveau de qualité décent, mais il n'y a pas de limite à la perfection. Ce que les testeurs font est appelé test de boîte noire, leur responsabilité n'est pas de connaître toutes les fonctionnalités de l'implémentation, donc le test est généralement axé sur des scénarios typiques et n'a pas pour objectif de casser le système ou de vérifier son comportement dans des conditions atypiques. De plus, certaines choses ne sont pas faciles à vérifier simplement en raison du manque d'interface, par exemple, si le but de l'itération est de développer une bibliothèque pour accéder aux données ou à une API spécifique, pour le tester, vous devrez écrire une application ou au moins quelque chose qui utiliserait ce composant. Dans de tels cas, vous devez renvoyer partiellement la fonction de contrôle qualité aux développeurs et leur demander d'écrire des tests d'intégration. Il s'agit du deuxième type de tests automatisés utilisés sur le projet. Leur objectif est de tester l'exactitude de l'interaction des composants du système écrits par différentes personnes, de tester le comportement de ces composants dans des conditions limites, ainsi que l'exactitude de la réaction aux défaillances de l'environnement.

Eh bien, nous avons des testeurs qui testent l'ensemble du projet pour vérifier la conformité aux exigences, il y a des tests pour automatiser leur travail, et il y a des tests qui testent des parties du projet écrites par différents développeurs, que faire d'autre? Les tests unitaires prétendent être le quatrième niveau de contrôle qualité. Ils vérifient le code écrit par un programmeur et, en règle générale, ils testent la partie minimale du code, qui est fondamentalement appropriée pour tester, par exemple, une classe distincte. En pratique, le plus souvent, le développeur écrit lui-même des tests unitaires pour son propre code, et leur nombre et leurs besoins sont mal contrôlés. Selon mes observations, environ 40% du temps pour développer la fonctionnalité elle-même peut être appelé une quantité typique de temps de développeur passé sur des tests unitaires, bien que ce ratio puisse varier considérablement. L'étude de cas open source du projet SQLite est largement connue.En raison de l'excès de main-d'œuvre peu qualifiée fournie par un grand nombre de personnes qui souhaitent travailler sur un projet bien connu, cette force de travail est utilisée à la manière de l'armée, c'est-à-dire en écrivant des tests unitaires inutiles, dont le volume à un moment donné dans 100 fois le volume de code du SGBD lui-même. Les cas inverses où les tests unitaires ne sont pas écrits ou sont écrits sur un volume minimum ne sont pas non plus surprenants. Au final, presque tous les logiciels développés jusqu'à la fin du zéro, c'est-à-dire avant l'ère de l'externalisation et de l'Agile, ont été créés sans tests unitaires.

Coûts, ajustement de la complexité et mois-personne mythique

Bien sûr, si vous devez écrire des tests unitaires ou autre chose, vous devrez soit consacrer plus de temps au projet, soit embaucher des développeurs supplémentaires. La principale question qui se pose dans ce cas est de savoir si la dépendance du temps et du coût de développement sur la quantité de code est linéaire, ou si elle obéit à une autre loi.

Il était une fois un référentiel SVN gratuit sur le célèbre service Assembla, qui fournissait des services d'hébergement source et des outils de collaboration, c'est-à-dire un tracker, des statistiques et d'autres bêtises. Plus tard, le cadeau a pris fin, mais ils n'ont pas cessé d'envoyer des newsletters et des notifications. Ainsi, en 2015, leur employé a publié un court article intitulé «Combien de personnes devraient discuter d'une tâche?» Maintenant, il n'est conservé que dans les archives Web . L'essence du poste était la suivante: l'employé a collecté des statistiques sur les clients, en traçant la dépendance de la durée de la tâche sur le nombre de personnes qui en ont discuté, le résultat était le suivant:

On peut voir que la dépendance est non linéaire. Deux personnes sont généralement impliquées dans la résolution d'un problème de deux jours, trois personnes - quatre jours et quatre personnes - déjà six jours. Que font-ils là-bas? Nous pouvons supposer que la tâche nécessite plusieurs étapes de travail, par exemple, dans le cas de deux personnes, Vasya fait sa part de la tâche, puis la transfère à Petya, de sorte qu'elle dure deux jours. Trois personnes peuvent déjà se quereller et partager à nouveau leurs responsabilités, découvrir qui est à blâmer et quoi faire, et un groupe de sept personnes passera six jours supplémentaires à discuter, à négocier et à s’abandonner.

Bien sûr, on peut également supposer qu'une équipe amicale de sept personnes a des tâches difficiles qui sont beaucoup plus simples et plus les gens sont occupés avec la tâche, plus elle peut être grande, car l'amitié est magique! Par conséquent, de telles considérations peuvent sembler farfelues, et je ne les inclurai pas dans les calculs ultérieurs, cependant, si vous souhaitez obtenir une estimation plus prudente, il ne serait pas hors de propos de corriger la non-linéarité de la croissance des coûts avec la croissance de la base de code du projet, qui, bien sûr, Des tests unitaires sont également inclus, ou pour établir une certaine marge de sécurité dans les exigences relatives au niveau de VAN.

Si nous expliquons la non-linéarité de ce calendrier uniquement par la croissance de la taille de l'équipe, alors les coûts qui y sont associés peuvent être estimés à partir du tableau suivant de la dépendance de la part de temps perdu en communication sur la taille du groupe de travail:

Par exemple, s'il y a cinq développeurs dans une équipe et que vous pensez que vous devez en embaucher deux pour que tout le monde puisse consacrer 40% de son temps supplémentaire à des tests unitaires, préparez-vous au fait que les coûts de développement peuvent augmenter de plus de 40%. L'équipe grandira et deviendra moins efficace, au lieu de 5 * 0,625 = 3,125 unités de productivité conventionnelles, elle aura 7 * 0,539 = 3,77 unités, et la quantité de travail passera de 1 à 1,4 unités de travail conventionnelles, respectivement, le temps requis pour le développement augmentera de 16%.

Une conclusion intéressante qui peut être tirée du graphique est que lorsque le nombre de personnes est supérieur à dix, la valeur de chaque nouveau participant devient inférieure au coût supplémentaire de la communication et la loi Brooks commence à fonctionner. Il ne reste plus qu'à essayer de diviser les tâches en plus petites, ou à impliquer des employés plus expérimentés et efficaces dans leur mise en œuvre.

Bien sûr, il est difficile de dire que la non-linéarité du graphique d'Assembla n'est associée qu'à une diminution de l'efficacité résultant de la croissance de l'équipe, mais elle est en bon accord avec la compréhension intuitive de la complexité et de la loi de Brooks, donc si vous ne voulez pas prendre de risques et que vous avez besoin d'une estimation prudente, ces données peuvent Devenez une bonne aide.

Les avantages des tests unitaires

Outre les coûts, les tests unitaires présentent également des avantages. Bien sûr, dans la grande majorité des cas, un bogue qui pourrait être détecté par des tests unitaires sera détecté à d'autres niveaux de contrôle qualité, mais il y a toujours un risque d'échec technique et théoriquement, les tests unitaires peuvent le réduire. Personnellement, je ne connais pas de tels cas, heureusement, tous les testeurs avec qui j'ai travaillé étaient des personnes extrêmement responsables, mais quand il s'agit de probabilités aussi faibles, l'expérience personnelle peut être non représentative. Les défaillances peuvent avoir des conséquences différentes, par exemple, une entreprise peut avoir un SLA, dont la violation entraînera certaines pertes financières, par exemple, l'entreprise sera obligée de donner aux clients un mois d'utilisation gratuite de ses services en compensation, perdant 1/12 des revenus. Dans ce cas, le renforcement du contrôle de la qualité, qui réduit la probabilité de violations de SLA au cours de l'année de 10% à 8%, réduira les pertes annuelles moyennes d'environ 0,17% des revenus. Cet argent sera la composante positive du flux de trésorerie qui doit être ajoutée au modèle.

Veuillez noter qu'un tel calcul simple n'est applicable que lorsque la probabilité de pertes est faible, si la probabilité est supérieure à 15-20% et peut conduire à la faillite ou à la liquidation de l'entreprise, il est conseillé d'utiliser des modèles d'évaluation optionnels, par exemple, comme un arbre de décision. Heureusement, dans la plupart des cas, une sorte de bogue stupide n'est pas quelque chose qui peut mettre en faillite une entreprise et nous n'avons pas besoin de plonger dans l'horreur du calcul du coût des options.

Exemple un: Bison

Bison est une grande boutique en ligne, ils se disent le détaillant en ligne n ° 1 en Russie. La société n'est pas publique, mais lors d'une récente opération de recapitalisation, sa capitalisation totale a été estimée à 50 milliards de roubles, soit le double du chiffre d'affaires annuel. Une capitalisation supplémentaire était nécessaire en raison des pertes d'exploitation, mais les actionnaires espèrent atteindre une marge bénéficiaire d'exploitation de 10% après que la société aura réussi à gagner une part de marché plus élevée et à doubler ses revenus en un an, après quoi elle devra commencer à gagner, et la croissance des revenus ralentira. jusqu'à 30% la deuxième année, 20% la troisième année et finalement fixé à 10% la quatrième et les années suivantes. Cependant, les banques ne sont pas très sûres à ce sujet et donnent à Bizon une longue prudence, la dette totale de la société n'est que de 10 milliards de roubles à un taux de 11%. Bison est une entreprise plutôt maladroite et mal gérée au niveau opérationnel, l'embauche incontrôlée d'employés a déjà conduit au fait qu'elle emploie 600 programmeurs, dont le budget salarial total est de 1,5 milliard de roubles par an et qui consacrent environ 30% de leur temps de travail à des tests unitaires. La société n'a aucune obligation envers les clients et une panne technique ne peut que conduire à un arrêt temporaire des ventes, et en cas de panne, un retour à l'ancienne version du site prend environ une heure.

Quelle est la VAN de l'utilisation des tests unitaires chez le bison?

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):

$display$