Manuelle Tests: man zahlt für jeden Testrun immer höhere Summen, weil Tests immer umfangreicher werden müssen. Automatische Tests: man investiert zu Beginn und zahlt dann nur noch wenig für die kontinuierlichen Anpassung.
ROI-Diagramm siehe unten
manuelle Tests sind unzuverlässig
Faktor Mensch: Konzentration lässt nach, Betriebsblindheit, Änderungen werden ignoriert, …
manuelle Tests sind grob
Testkombinatorik (z.B. verschiedene Browser testen) kaum möglich -> unentdeckte Bugs können sehr teuer werden. Testabdeckung wird durch Testautomatisierung höher.
manuelle Tests sind monoton
„Fließbandarbeit“ -> Jobattraktivität niedrig
Zum verbreiteten Argument, dass manuelle Tests per se langsamer sind: siehe
Vorteile automatischer Tests
bereits bei niedriger Testabdeckung:
Fast & Focussed Feedback
Die automatischen Tests sind die Grundvoraussetzung für Continuous Integration und all deren Vorteile sind somit die der Testautomatisierung. Dieser Punkt ist der wichtigste – hier ist der größte Effizienzhebel des Testautomatisierung für’s Softwareprojekt! Nightly build(Mindestziel bei Testautomatisierung): Nachts automatisch komplett testen und am nächsten Morgen haben Entwickler Kenntnis über mögliche Regressionen ihrer Codeänderungen.
Focussed: – Je weniger Systemänderungen (nicht nur Commits, auch Plattformupdates etc.), die von einem Regressionstests erfasst werden, desto besser. Weil der „Ursachenraum“ entsprechend klein ist, kann die Ursache der Regression auch schneller gefunden werden. Dies spart gegenüber sog. Big Bangs sowohl Zeit als auch Geld über die gesamte Lebensdauer eines Projekts.
Fast: – Je schneller die Tests erfolgen, desto frischer ist das Thema noch im Kopf des Entwicklers und er muss sich nicht nach 3 Wochen wieder in die Thematik aufwändig einarbeiten, um das Problem zu lösen. – Die Wahrscheinlichkeit, dass der regressions-verursachende Entwickler am nächsten Morgen noch da ist, ist größer, als am Ende eines Releasezyklus. Er könnte krank geworden oder in Urlaub gegangen sein. Ein Kollege müsste sich erst mühsam in fremden Code einarbeiten um die Regression zu beheben. – Vermeiden von Folgefehlern — Entwickler baut seine Lösung nicht auf einem wackligen Fundament weiter. Wegen des Defects müsste er eigentlich einen anderen Ansatz nehmen, weil er ihn aber nicht frühzeitig entdeckt, verschwendet er Zeit mit diesem Ansatz — Entwicklerkollegen (und auch der Entwickler selbst) bauen ihre Lösungen u.U. auf dem Defect auf, die Fehlerdichte kumuliert immer mehr und am Ende entsteht ein gordischer Knoten. Die technischen Schulden steigen
Hotfixes müssen nicht mehr ungeprüft eingespielt werden bzw. können zeitnah nach dem Einspielen auf der Produktivumgebung nachgetestet werden. -> geringeres Risiko von teuren Bugs
Bessere Verteilung
Wenn alle Bugs erst zum monatlichen Regressionstests gefunden werden, reicht die Debuggingzeit möglicherweise nicht mehr aus, den Deploymenttermin zu halten. Monatliche Regressionstests werden selten ein zweites Mal nach dem Debugging durchgeführt, obwohl mit jedem Debugging potenziell eine weitere Regression stattfinden kann.
ab hoher Testabdeckung:
Kürzere Time-To-Market
Releasezyklen können stark verkürzt werden -> kürzere Time-To-Market: wichtige Features werden zeitnah und nicht erst beim nächsten Release wirksam.
Mutigeres Programmieren wird ermöglicht
Softwareentwickler müssen nicht mehr so defensiv programmieren, weil sie mit der Testautomatisierung ab einem bestimmten Level ein gutes Sicherheitsnetz haben. Defensives Programmieren kostet das Projekt unnötig Entwicklerzeit.
