Was kosten Unit-Tests?

Jetzt, auf dem Höhepunkt des Konjunkturzyklus in einer so heißen Branche wie der Softwareentwicklung, ist es nicht üblich, Geld zu zählen. Oft wird dieser Prozess im Prinzip als kreative Aktivität positioniert, bei der nichts gerechtfertigt werden muss und der Künstler besser weiß, was und wie er schreiben soll. Insbesondere zum Thema Unit-Tests und TDD gibt es viele Kontroversen, aber leider geraten sie alle in unbewiesene Aussagen und emotionale Angriffe, die durch Beweise für erfolgreich ausgewählte Artikel und Bücher von Methodologen bestätigt werden, die mit Konsultationen und Verkäufen von Schulungen verdienen, die in ihren im Gegenzug enthalten sie absolut keine Statistiken oder Berechnungen oder im Gegenteil zu pauschalen Anschuldigungen von smushylebstvo und anderen Sünden der Jugend.

Im Gegensatz zu ähnlichen leeren Argumenten gibt Ihnen dieser Artikel nicht nur Denkanstöße, sondern auch eine Methode zur Bewertung der wirtschaftlichen Machbarkeit der Einführung von Komponententests für ein bestimmtes Projekt. Ich werde sofort betonen, dass unsere Bewertung für das Unit-Test-Implementierungsprojekt wie jede Bewertung auf Annahmen über die Zukunft des Produkts, des Teams und verschiedener Indikatoren basiert, die nur subjektiv bewertet werden können. Dennoch ist die Situation, in der ein Programmierer eine Expertenbewertung von Indikatoren abgibt, die zumindest in irgendeiner Weise mit seinem Tätigkeitsbereich zusammenhängen, viel besser, als ihn direkt zu fragen, ob es für das Unternehmen rentabel ist, Komponententests durchzuführen oder nicht. Letztendlich neigen Programmierer normalerweise nicht dazu, über grundlegende Finanzindikatoren nachzudenken, sondern nicht nur Entwickler, sondern auch Tester und Manager können die Zeit, die sie für das Schreiben von Tests aufgewendet haben, oder die Wahrscheinlichkeit eines kritischen Fehlers in ihrer Abwesenheit bewerten.

Was kostet das?

Wenn wir die Kosten für irgendetwas berechnen wollen, müssen wir zunächst zumindest allgemein verstehen, was Wert ist. Wenn wir ein Wurstbrot kaufen, stellt sich diese Frage nicht, da ein Preisschild darunter hängt. Bei dem Projekt handelt es sich jedoch nicht um eine einmalige Zahlung, sondern um einen Cashflow, der lange anhält. Wir investieren ihn zuerst und zahlen uns dann. Um es richtig zu bewerten, müssen Sie berücksichtigen, dass das morgen erhaltene Geld weniger kostet als heute. Wenn die Wurst im Abonnement verkauft würde, wäre dies nicht schwierig. Die Kosten des Abonnements könnten berechnet werden, indem zukünftige Zahlungen für sie durch den Inflationsbetrag abgezinst werden. Im Falle des Projekts müssen wir jedoch berücksichtigen, dass das Unternehmen, das in es investiert, erwartet, dass es nicht nur seine Kosten kompensiert, sondern auch so viel verdient, dass es seine Risiken abdeckt. Es gibt eine Vielzahl von Risiken, aber letztendlich kommt es darauf an, dass die Rendite des in die Umsetzung des Projekts investierten Geldes nicht garantiert und schlecht vorhergesagt wird. Geld kann zu einer Bank gebracht oder an einen harten Kreditnehmer geliehen werden und garantiert regelmäßig Zinsen zahlen. Sie können jedoch nicht in ein Projekt investieren, sodass Sie einen vorhersehbaren Auszahlungsfluss im Zeitplan erhalten. Aus Sicht des Investors sollte in diesem Fall des Unternehmens der Cashflow, der mit der vom Projekt erzielten erforderlichen Rendite abgezinst wird, auch als Barwert bezeichnet, positiv sein:

$$

Um dies zu berechnen, müssen wir wissen, wie viel Geld das Projekt im ersten, zweiten, dritten Jahr usw. bringen oder essen wird, sowie den Abzinsungssatz, der nicht nur rentabler als bei der Bank sein sollte, sondern auch die Risiken abdeckt .

In der Tat ist dies eine etwas vereinfachte Formel. Genau genommen wird sich die Rate von Jahr zu Jahr ändern, daher sollte WACC1 * WACC2 * WACC3 usw. im Nenner verwendet werden, aber in der Praxis vernachlässigen dies sogar professionelle Gutachter, weil Aufgrund der WACC-Berechnungsmethode wurden die Markterwartungen in Bezug auf zukünftige Zinssätze bereits in die heutigen Zinssätze einbezogen, und es ist unproduktiv, Annahmen darüber zu treffen.

Es gibt verschiedene Arten von Cashflows, aber ich habe für unsere Zwecke den für das Unternehmen am besten geeigneten Cashflow verwendet, der nicht nur das den Eigentümern, sondern auch den Gläubigern geschuldete Geld berücksichtigt. Natürlich haben die meisten IT-Unternehmen keine spürbaren Schulden, nur weil ihnen niemand ohne Sicherheiten Kredite gewährt, und sie haben nichts zu verpfänden, aber es gibt immer noch Ausnahmen. Dieser Ansatz kann beispielsweise bei der Bewertung eines Projekts in der Eigenentwicklung eines ausgeliehenen Fertigungsunternehmens hilfreich sein . Der zweite Grund, warum FCFF für uns von besonderem Interesse ist, ist die einfache Berechnung. FCFF ist nur das Betriebsergebnis abzüglich Steuern, Nettokapitalkosten und Veränderungen des Betriebskapitals.

Da FCFF sowohl für Eigentümer als auch für Kreditgeber gleichzeitig ein Cashflow ist, wird er mit einem gewichteten Satz der Eigenkapitalkosten, sowohl der eigenen als auch der geliehenen, abgezinst.

In großen Unternehmen werden die Kapitalkosten von der Finanzabteilung überwacht. Sie können sie also einfach anfragen. Für den allgemeinen Fall benötigen wir jedoch noch eine Formel zur Berechnung des WACC:

$$

Hier sind Re die Eigenkapitalkosten, Rd die Fremdkapitalkosten (dh der effektive Zinssatz für die Schulden des Unternehmens), P der Marktwert des Eigenkapitals, EV die Gesamtkosten des Unternehmens (EV = P + D, wobei D Schulden sind).

Als nächstes müssen wir Re bestimmen, dafür gibt es verschiedene Modelle, aber der einfachste Weg ist das CAPM-Modell, wobei Re = Rb + β * Premium, wobei Rb der risikofreie Zinssatz ist, Premium die Prämie für die Kapitalrendite ist, nicht in geliehen, und β ist ein Risikofaktor, der zeigt, wie viel riskanter unser Projekt in Bezug auf das Geschäft eines bestimmten durchschnittlichen Unternehmens ist.

Wie Qualität gewährleistet ist und welche Unit-Tests durchgeführt werden

Jetzt müssen wir entscheiden, was Unit-Tests sind. Seltsamerweise nennen viele Leute, selbst wenn sie kurz vor der Entwicklung stehen, oft automatisierte Testeinheitentests, aber das ist natürlich nicht so.

Das Testen ist in funktionale und nicht funktionale unterteilt. Nicht funktionsfähig umfasst Dinge, die nicht direkt mit der Funktionalität der Software zusammenhängen, z. B. Lasttests oder Tests im Zusammenhang mit Sicherheit. Funktional bedeutet jedoch nur, die Einhaltung der Anforderungen und das Fehlen von Fehlern bei ihrer Implementierung zu überprüfen. Es wird speziell darauf eingegangen.

Das erste, was getan werden muss, um die Qualität sicherzustellen, ist, die Kontrollfunktion von den Entwicklern zu übernehmen und die Person einzustellen, die dafür verantwortlich ist. Es erscheint also ein Tester im Team, der mit manuellen Tests beschäftigt ist. Kein ernsthaftes Projekt ist ohne manuelle Tests einfach nicht vorstellbar. Es ist die Grundlage, die das Projekt dringend benötigt, und die überwiegende Mehrheit der Probleme, die rechtzeitig entdeckt und behoben werden, ist das Verdienst der Tester. In dieser Phase sieht alles einfach aus: Wenn Sie Qualität wünschen, stellen Sie einen Qualitätsspezialisten ein.

Wenn das Projekt wächst, wird die Zeit für manuelle Tests immer kürzer, sodass Tester immer mehr mit den neuen Systemfunktionen arbeiten und immer weniger Teile des Systems überprüfen, die sich nicht geändert haben sollten. Da die Komplexität des Systems jedoch zunimmt und es wahrscheinlich ist, dass explizite und implizite Abhängigkeiten zwischen seinen Komponenten auftreten, die Entwickler theoretisch aus den Augen verlieren können, ist es dennoch ratsam, einige Dinge jedes Mal vor der Veröffentlichung zu überprüfen. Dieses Problem ist besonders akut bei flexiblen Methoden mit ihren kurzen Iterationen und häufigen Veröffentlichungen. Dies impliziert logischerweise die Notwendigkeit, die Arbeit von Testern zu automatisieren, z. B. ein Skript zu schreiben, das auf die Schaltflächen klickt und das Ergebnis selbst überprüft, oder leistungsfähigere Tools zu verwenden und einen normalen Tester in einen automatisierten Testspezialisten zu verwandeln, der in der Lage ist, den Routineteil seiner Arbeit zu automatisieren.

Diese Maßnahmen können ein angemessenes Qualitätsniveau bieten, der Perfektion sind jedoch keine Grenzen gesetzt. Was Tester tun, wird als Black-Box-Test bezeichnet. Sie sind nicht dafür verantwortlich, alle Funktionen der Implementierung zu kennen. Daher konzentriert sich das Testen normalerweise auf typische Szenarien und setzt nicht das Ziel, das System zu beschädigen oder sein Verhalten unter atypischen Bedingungen zu überprüfen. Darüber hinaus sind einige Dinge nicht einfach zu überprüfen, da keine Schnittstelle vorhanden ist. Wenn das Ziel der Iteration beispielsweise darin besteht, eine Bibliothek für den Zugriff auf Daten oder eine bestimmte API zu entwickeln, müssen Sie zum Testen eine Anwendung oder zumindest eine solche schreiben würde diese Komponente verwenden. In solchen Fällen müssen Sie die Qualitätskontrollfunktion teilweise an die Entwickler zurückgeben und sie bitten, Integrationstests zu schreiben. Dies ist die zweite Art von automatisierten Tests, die für das Projekt verwendet werden. Ihr Ziel ist es, die Richtigkeit der Interaktion von Systemkomponenten zu testen, die von verschiedenen Personen geschrieben wurden, das Verhalten dieser Komponenten unter Grenzbedingungen sowie die Richtigkeit der Reaktion auf Fehler in der Umgebung zu testen.

Nun, wir haben Tester, die das gesamte Projekt auf Übereinstimmung mit den Anforderungen testen, es gibt Tests zur Automatisierung ihrer Arbeit und es gibt Tests, die Teile des Projekts testen, die von verschiedenen Entwicklern geschrieben wurden. Was kann man noch tun? Unit Tests behaupten, die vierte Stufe der Qualitätskontrolle zu sein. Sie überprüfen den von einem Programmierer geschriebenen Code und testen in der Regel den minimalen Teil des Codes, der grundsätzlich zum Testen beispielsweise einer separaten Klasse geeignet ist. In der Praxis schreibt der Entwickler meistens selbst Komponententests für seinen eigenen Code, und deren Anzahl und Bedarf werden schlecht kontrolliert. Nach meinen Beobachtungen können etwa 40% der Zeit für die Entwicklung des Features selbst als typische Entwicklerzeit für Komponententests bezeichnet werden, obwohl dieses Verhältnis stark variieren kann. Die Open-Source-Fallstudie des SQLite-Projekts ist weithin bekannt. Aufgrund des Überschusses an gering qualifizierten freien Arbeitskräften, die von einer großen Anzahl von Personen bereitgestellt werden, die an einem bekannten Projekt arbeiten möchten, wird diese Belegschaft auf militärische Weise eingesetzt, dh durch das Schreiben nutzloser Komponententests, deren Volumen irgendwann in 100-faches Code-Volume des DBMS. Die umgekehrten Fälle, in denen Komponententests nicht oder auf ein Mindestvolumen geschrieben sind, sind ebenfalls nicht überraschend. Am Ende wurde fast die gesamte Software, die bis zum Ende der Null entwickelt wurde, dh vor der Ära des Outsourcings und der Agilität, ohne Komponententests erstellt.

Kosten, Komplexitätsanpassung und mythischer Personenmonat

Wenn Sie Unit-Tests oder etwas anderes schreiben müssen, müssen Sie entweder mehr Zeit für das Projekt aufwenden oder zusätzliche Entwickler einstellen. Die Hauptfrage, die sich in diesem Fall stellt, ist, ob die Abhängigkeit von Entwicklungszeit und -kosten von der Codemenge linear ist oder ob sie einem anderen Gesetz folgt.

Es war einmal ein kostenloses SVN-Repository für den berüchtigten Assembla-Dienst, das Quellhostingdienste und Tools für die Zusammenarbeit bereitstellte, dh einen Tracker, Statistiken und anderen Unsinn. Später endete das Werbegeschenk, aber sie hörten nicht auf, Newsletter und Benachrichtigungen zu senden. Daher veröffentlichte ihr Mitarbeiter 2015 einen kurzen Beitrag mit dem Titel „Wie viele Personen sollten eine Aufgabe besprechen?“. Jetzt wird es nur noch im Webarchiv gespeichert . Das Wesentliche des Beitrags war wie folgt: Der Mitarbeiter sammelte Statistiken über Kunden und zeichnete die Abhängigkeit der Dauer der Aufgabe von der Anzahl der Personen auf, die darüber diskutierten. Das Ergebnis war wie folgt:



Es ist ersichtlich, dass die Abhängigkeit nichtlinear ist. Normalerweise sind zwei Personen an der Lösung eines zwei Tage dauernden Problems beteiligt, drei Personen - vier Tage und vier Personen - bereits sechs Tage. Was machen sie dort? Wir können davon ausgehen, dass die Aufgabe mehrere Arbeitsschritte erfordert, zum Beispiel bei zwei Personen, Vasya erledigt seinen Teil der Aufgabe und überträgt sie dann an Petya, sodass sie zwei Tage dauert. Drei Personen können sich bereits streiten und erneut ihre Verantwortung teilen, herausfinden, wer schuld ist und was zu tun ist, und eine Gruppe von sieben Personen wird sechs zusätzliche Tage damit verbringen, miteinander zu diskutieren, zu verhandeln und sich zu unterhalten.

Natürlich kann man auch davon ausgehen, dass ein freundliches Team von sieben Personen schwierige Aufgaben hat, die viel einfacher sind und je mehr Menschen mit der Aufgabe beschäftigt sind, desto größer kann sie sein, denn Freundschaft ist Magie! Daher scheinen solche Überlegungen weit hergeholt zu sein, und ich werde sie nicht in nachfolgende Berechnungen einbeziehen. Wenn Sie jedoch eine konservativere Schätzung erhalten möchten, wäre es nicht unangebracht, die Nichtlinearität des Kostenwachstums mit dem Wachstum der Projektcodebasis zu korrigieren, was natürlich Unit-Tests sind ebenfalls enthalten, oder um einen gewissen Sicherheitsspielraum in den Anforderungen für die Höhe des Kapitalwerts zu legen.

Wenn wir die Nichtlinearität dieses Zeitplans ausschließlich durch das Wachstum der Teamgröße erklären, können die damit verbundenen Kosten anhand der folgenden Tabelle der Abhängigkeit des Zeitverlusts bei der Kommunikation von der Größe der Arbeitsgruppe geschätzt werden:



Wenn beispielsweise fünf Entwickler in einem Team sind und Sie der Meinung sind, dass Sie zwei einstellen müssen, damit jeder weitere 40% seiner Zeit für Unit-Tests aufwenden kann, sollten Sie sich darauf einstellen, dass die Entwicklungskosten um mehr als 40% steigen können. Das Team wird wachsen und weniger effektiv sein. Statt 5 * 0,625 = 3,125 konventionelle Produktivitätseinheiten wird es 7 * 0,539 = 3,77 Einheiten haben, und der Arbeitsaufwand wird von 1 auf 1,4 konventionelle Arbeitseinheiten erhöht, was der Entwicklungszeit entspricht wird um 16% steigen.

Eine interessante Schlussfolgerung, die aus der Grafik gezogen werden kann, ist, dass bei einer Anzahl von mehr als zehn Personen der Wert jedes neuen Teilnehmers unter den zusätzlichen Kommunikationskosten liegt und das Brooks-Gesetz zu funktionieren beginnt. Es bleibt nur zu versuchen, Aufgaben in kleinere zu unterteilen oder erfahrenere und effizientere Mitarbeiter in ihre Umsetzung einzubeziehen.

Es ist natürlich schwer zu sagen, dass die Nichtlinearität des Diagramms von Assembla nur mit einer Abnahme der Effizienz infolge des Wachstums des Teams verbunden ist, aber es stimmt gut mit dem intuitiven Verständnis der Komplexität und des Brooks-Gesetzes überein. Wenn Sie also keine Risiken eingehen möchten und eine konservative Schätzung benötigen, können diese Daten Werde eine gute Hilfe.

Die Vorteile von Unit-Tests

Unit-Tests bringen neben den Kosten auch Vorteile. Natürlich wird in den allermeisten Fällen ein Fehler, der durch Unit-Tests aufgefangen werden könnte, auf anderen Ebenen der Qualitätskontrolle abgefangen, aber es besteht immer die Möglichkeit eines technischen Fehlers, und theoretisch können Unit-Tests diesen Fehler reduzieren. Persönlich kenne ich solche Fälle nicht, zum Glück waren alle Tester, mit denen ich zusammengearbeitet habe, äußerst verantwortungsbewusste Personen, aber wenn es um so niedrige Wahrscheinlichkeiten geht, kann die persönliche Erfahrung nicht repräsentativ sein. Ausfälle können unterschiedliche Konsequenzen haben. Beispielsweise kann ein Unternehmen eine SLA haben, deren Verletzung bestimmte finanzielle Verluste mit sich bringt. Beispielsweise muss das Unternehmen seinen Kunden einen Monat lang die kostenlose Nutzung seiner Dienste als Entschädigung gewähren und dabei 1/12 des Umsatzes verlieren. In diesem Fall werden durch eine Verschärfung der Qualitätskontrolle, die die Wahrscheinlichkeit von SLA-Verstößen während des Jahres von 10% auf 8% verringert, die durchschnittlichen jährlichen Verluste um etwa 0,17% des Umsatzes verringert. Dieses Geld ist die positive Komponente des Cashflows, der dem Modell hinzugefügt werden muss.

Bitte beachten Sie, dass eine solche einfache Berechnung nur dann anwendbar ist, wenn die Wahrscheinlichkeit von Verlusten gering ist, wenn die Wahrscheinlichkeit höher als 15-20% ist und zum Konkurs oder zur Liquidation des Unternehmens führen kann. Es ist ratsam, optionale Bewertungsmodelle zu verwenden, beispielsweise einen Entscheidungsbaum. Glücklicherweise kann in den meisten Fällen ein dummer Fehler ein Unternehmen nicht bankrott machen, und wir müssen uns nicht in den Schrecken stürzen, die Kosten für Optionen zu berechnen.

Beispiel Eins: Bison

Bison ist ein großer Online-Shop, sie nennen sich den führenden Online-Händler in Russland. Das Unternehmen ist nicht öffentlich, aber bei einer kürzlich durchgeführten Rekapitalisierungstransaktion wurde seine Gesamtkapitalisierung auf 50 Milliarden Rubel geschätzt, was dem doppelten Jahresumsatz entspricht. Aufgrund von Betriebsverlusten war zusätzliche Kapitalisierung erforderlich, aber die Aktionäre hoffen auf eine Betriebsgewinnmarge von 10%, nachdem es dem Unternehmen gelungen ist, innerhalb eines Jahres einen höheren Marktanteil zu erreichen und den Umsatz zu verdoppeln. Danach muss es anfangen zu verdienen, und das Umsatzwachstum wird sich verlangsamen bis zu 30% im zweiten Jahr, 20% im dritten Jahr und schließlich 10% im vierten und den folgenden Jahren. Die Banken sind sich jedoch nicht sehr sicher und geben Bizon eine lange Vorsicht, die Gesamtverschuldung des Unternehmens beträgt nur 10 Milliarden Rubel bei einer Rate von 11%. Bison ist ein eher ungeschicktes und schlecht geführtes Unternehmen auf operativer Ebene. Die unkontrollierte Einstellung von Mitarbeitern hat bereits dazu geführt, dass 600 Programmierer beschäftigt sind, deren Gesamtbudget 1,5 Milliarden Rubel pro Jahr beträgt und die etwa 30% ihrer Arbeitszeit für Unit-Tests aufwenden. Das Unternehmen hat keine Verpflichtungen gegenüber Kunden und ein technischer Fehler kann nur zu einem vorübergehenden Verkaufsstopp führen. Im Falle eines Fehlers dauert ein Rollback auf die alte Version der Website etwa eine Stunde.

Wie hoch ist der Kapitalwert bei der Verwendung von Unit-Tests bei Bisons?

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 . . .
: « ! , . - , , . , , . ». , 8 .
: -?
, : . , ( 50, - 10, ), , . , , - , , 100 10% * 8 = 800 .

: XSoft

XSoft – , . 7 , 15 , XSoft 3 . – . XSoft, ?

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

Nachwort

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