Einleitung
Als Interim CTO arbeite ich eng mit nicht-technischen Kollegen zusammen. Und oft kommen wir auf das Thema “Testabdeckung”. Für Nicht-Techniker sieht dieses Konzept sehr einfach aus. Hohe Testabdeckung ist gut, niedrige Testabdeckung ist schlecht. Zwingen wir die Teams einfach zu einer hohen Testabdeckung.
Aber so einfach ist es nicht - und Teams zu einer hohen Testabdeckung zu zwingen, führt in die Katastrophe. Schauen wir uns das an.
Was ist Testabdeckung?
Testabdeckung ist eine Metrik, die misst, wie viel Code durch automatisierte Tests getestet wird. Stellen Sie sich das als eine Möglichkeit vor, zu überprüfen, wie viel der Funktionalität Ihrer Software als korrekt verifiziert wurde. Wenn Sie sich Ihre Software als Buch vorstellen, wäre die Testabdeckung wie das Markieren der Textteile, die Korrektur gelesen wurden.
Die Falle der Eitelkeitsmetrik
Testabdeckung kann manchmal irreführend sein. Es ist ein bisschen wie der Aktienkurs eines Unternehmens. Wenn Sie sich ausschließlich darauf konzentrieren, den Aktienkurs zu steigern, mag das kurzfristig funktionieren, aber es kann langfristig zu katastrophalen Ergebnissen führen. Erinnern Sie sich an Enron? Sie haben Zahlen manipuliert, um auf dem Papier gut auszusehen, aber letztendlich führte es zu ihrem Untergang.
Das Gleiche gilt für die Testabdeckung. Ingenieure können bedeutungslose Tests schreiben, nur um den Prozentsatz der Abdeckung zu erhöhen. Diese Tests lassen es so aussehen, als ob alles gründlich geprüft wird, aber in Wirklichkeit verifizieren sie nichts Wesentliches.
Was Sie wirklich wollen, ist ein Team von Ingenieuren, die ihre Arbeit verstehen und darauf abzielen, stabile, zuverlässige Software zu schaffen, die Kunden glücklich macht. Dieser Ansatz führt natürlich zu einer hohen Testabdeckung.
Was Testabdeckung Ihnen nicht sagt
Hohe Testabdeckung bedeutet nicht automatisch, dass Ihre Software bombensicher ist. Sie brauchen keine 100% Testabdeckung, um zuverlässige Software und zufriedene Kunden zu haben. Konzentrieren Sie sich stattdessen auf die Qualität der Tests und die Stabilität des Codes.
Auf der anderen Seite kann eine niedrige Testabdeckung ein Warnsignal sein. Sie könnte auf Bereiche Ihrer Software hinweisen, die nicht gründlich getestet wurden. Dies kann für Ingenieure nützlich sein, um Teile des Codes zu identifizieren, die mehr Aufmerksamkeit benötigen.
Die Faustregel
Eine gute Faustregel ist, eine Testabdeckung von etwa 60% anzustreben. Dies ist ein Richtwert, der von Experten empfohlen wird, wie zum Beispiel von Google. In ihrem Buch “How Google Tests Software” von James Whittaker empfehlen sie, dass 60% Abdeckung ein vernünftiges Ziel ist.
Nach meiner Erfahrung erreichen Teams, die Zuverlässigkeit und Qualität priorisieren, oft nahezu 100% Testabdeckung. Das liegt nicht daran, dass sie dazu gezwungen werden, sondern weil sie es als Teil ihrer Aufgabe sehen, sicherzustellen, dass die Software zuverlässig ist.
Fazit
- Streben Sie mindestens 60% Testabdeckung an. Alles darunter könnte Anlass zur Sorge sein.
- Erzwingen Sie keine Testabdeckung. Ermutigen Sie stattdessen Ihre Ingenieure, sich auf die Produktion von zuverlässigem und stabilem Code zu konzentrieren. Das wird natürlich zu einer hohen Testabdeckung führen.
Durch das Verstehen und Anwenden dieser Prinzipien können Sie sicherstellen, dass Ihr Softwareentwicklungsprozess qualitativ hochwertige, zuverlässige Software hervorbringt, die Ihre Kunden glücklich macht.
Ihr Ziel sind zufriedene Kunden und nicht eine hohe Testabdeckung.
