ARTIKEL · SOFTWARETESTS · WIRTSCHAFTLICHKEIT

Manuell oder automatisiert testen — wann lohnt es sich?

Automatisierung lohnt sich, wenn derselbe Test oft und identisch laufen muss: bei der Regression stabiler, geschäftskritischer Prozesse mit häufigen Releases. Neue Funktionen, exploratives Testen und die Abnahme testet man besser von Hand. Die Amortisation lässt sich mit einer Formel abschätzen: einmalige Aufbaukosten geteilt durch den jährlich eingesparten manuellen Aufwand. Im folgenden Beispiel ist jede Annahme offengelegt, sodass Sie mit Ihren eigenen Zahlen nachrechnen können.

Kontakt aufnehmen Testautomatisierung →

Wann lohnt sich Automatisierung?

Wenn ein Test zugleich stabil, häufig und geschäftskritisch ist. Je mehr der folgenden Punkte zutreffen, desto schneller amortisiert er sich:

Er läuft oftVor jedem Release, vor jedem Deployment, jede Nacht. Bei einem Dynamics-365-System sind das 6–10 Releases im Jahr — zwei Microsoft-Wellen, eigene Entwicklungen, Fixes.

Der Prozess ist stabilSchritte und erwartetes Ergebnis ändern sich nicht jede Woche. Ist Oberfläche oder Prozess noch im Fluss, frisst die Skriptpflege die Einsparung auf.

Er ist geschäftskritischBricht er, kostet es Geld: Das Angebot geht nicht raus, der Auftrag erreicht das ERP nicht, die SLA-Frist verstreicht.

Viele DatenkombinationenDerselbe Prozess mit mehreren Preislisten, Währungen, Ländern — von Hand mühsam und fehleranfällig, maschinell günstig.

Das erwartete Ergebnis ist eindeutigEine Maschine kann nur entscheiden, ob das Ergebnis der Erwartung entspricht. Wo ein Urteil nötig ist („passt das so für den Anwender?“), braucht es einen Menschen.

Nicht alles lohnt sich zu automatisieren. Die manuelle Regression eines mittleren Dynamics-365-Systems umfasst 50–200 Testfälle; 30–50 gut gewählte automatisierte Testfälle decken rund 80 % des Risikos ab.

Was kosten manuelle und automatisierte Tests? Ein Rechenbeispiel

Die Rechnung braucht sechs Eingaben. Zwei (N und M) sind die typische Spanne bei mittleren Dynamics-365-Systemen; der Rest sind Annahmen, die Sie durch Ihre eigenen ersetzen sollten. Das Beispiel ist weder ein Angebot noch ein gemessenes Ergebnis, sondern zeigt die Methode.

Symbol	Bedeutung	Wert im Beispiel	Quelle
N	Releases pro Jahr (zwei Microsoft-Wellen, eigene Entwicklungen, Fixes)	6 / 8 / 10	typische Spanne: 6–10
M	manueller Regressionstest je Release	2 / 3,5 / 5 Personentage	typische Spanne bei einem mittleren Dynamics-365-System: 2–5 Personentage
B	Aufbau der automatisierten Suite (einmalig)	30 Personentage (40 Testfälle × 0,75 Tage)	Annahme — der reale Wert hängt von Werkzeug und System ab
A	je Release nach einem automatisierten Lauf: Fehleranalyse, Testpflege (1 Tag) und verbleibende manuelle Prüfung (0,5 Tage)	1,5 Personentage	Annahme
L	Werkzeuglizenz pro Jahr	0 (Playwright)	mit Tosca oder der Katalon-Team-Edition steigen die Kosten um die Jahresgebühr
D	Tagessatz	Ihr eigener Tagessatz	das Beispiel rechnet in Personentagen; für einen Geldbetrag mit Ihrem eigenen internen oder Tester-Tagessatz multiplizieren

Die Formel: jährliche Einsparung = N × (M − A) − L/D (in Personentagen), Amortisation = B ÷ jährliche Einsparung (in Jahren). Manuelle Regression und Nacharbeit nach dem automatisierten Lauf werden mit dem Tagessatz multipliziert zu Geld.

Szenario	Manuelle Regression pro Jahr (N × M)	Automatisierte Läufe pro Jahr (N × A)	Einsparung pro Jahr	Amortisation (B ÷ Einsparung)
Kleines System: 6 Releases, 2 Tage	12 Personentage	9 Personentage	3 Personentage	ca. 10 Jahre — lohnt sich nicht
Mittel: 8 Releases, 3,5 Tage	28 Personentage	12 Personentage	16 Personentage	ca. 23 Monate
Groß: 10 Releases, 5 Tage	50 Personentage	15 Personentage	35 Personentage	ca. 10 Monate

Alle drei Zeilen rechnen mit demselben Aufbau von 30 Personentagen und einem lizenzkostenfreien Werkzeug. Wird eine Tosca- oder Katalon-Lizenz gebraucht, mindert deren Jahresgebühr die Einsparung, und die Amortisation verschiebt sich nach hinten.

Was zeigt das Beispiel über die Amortisation?

Release-Anzahl und manueller Aufwand entscheidenBei einem kleinen System mit wenigen Releases ist der Handtest günstiger: Die Amortisation dauerte zehn Jahre. Bei einem mittleren System sind es rund zwei Jahre, bei einem großen unter einem Jahr.

Wartung ist nicht nullAuch nach einem automatisierten Lauf gibt es Arbeit: Fehlschläge analysieren, Tests nach Oberflächenänderungen korrigieren. Wer das ignoriert, überschätzt die Einsparung.

Die Zahl der Läufe steht nicht in der FormelDie manuelle Regression läuft 6–10-mal im Jahr, weil sie teuer ist. Die automatisierte jede Nacht und vor jedem Deployment — zu denselben Kosten. Fehler werden Tage nach ihrem Entstehen gefunden, nicht erst vor dem nächsten Release; die Formel bepreist das nicht, in der Praxis ist es aber der größere Gewinn.

Fehler in der Produktion auch nichtEin kritischer Fehler in der Produktion — Angebotserstellung ausgefallen, falscher ERP-Auftrag — ist kein Testaufwand, sondern ein geschäftlicher Schaden. Das Beispiel enthält nur den Testaufwand.

Eine praktische Faustregel: Dauert die manuelle Regression mindestens 3 Personentage je Release und gibt es mindestens 8 Releases im Jahr, lohnt es sich, die Automatisierung durchzurechnen. Mit den Release Waves trifft das auf die meisten Dynamics-365-Systeme zu — siehe warum Anpassungen bei der Release Wave brechen.

Welche Testarten bleiben manuell, welche lassen sich automatisieren?

Testart	Zweck	Manuell oder automatisiert?
Funktionaler Test	erfüllt die neue oder geänderte Funktion die Anforderung	zuerst manuell; was stabil und geschäftskritisch ist, wandert in die automatisierte Regression
Exploratives Testen	skriptlose, zeitlich begrenzte Suche nach Fehlern in Grenzfällen und unerwarteten Pfaden	immer manuell — das ist menschliche Neugier, kein Skript
Systemintegrationstest (SIT)	kommen die Daten von Ende zu Ende durch: CRM → ERP → Fakturierung	erste Runde von Hand; stabile Schnittstellen lassen sich auf API-Ebene automatisieren
Abnahmetest (UAT)	akzeptiert der Fachbereich die Lösung	manuell, durch die Key User; eine fachliche Entscheidung, die wir nicht automatisieren
Manueller Regressionstest	funktioniert, was bisher lief, auch nach der Änderung	der wichtigste Kandidat für Automatisierung: dasselbe, oft, identisch

Beides ist also kein Wettbewerb, sondern Arbeitsteilung: Manuelles Testen deckt das Neue und das ab, was menschliches Urteil braucht; Automatisierung schützt das Bestehende. Die manuellen Testfälle gehen dabei nicht verloren — aus den stabilen entsteht die automatisierte Suite.

Was ist die Testpyramide, und wohin gehören UI-Tests?

Die Testpyramide zeigt, wie viele Tests auf welcher Ebene sinnvoll sind: unten viele schnelle und günstige, oben wenige langsame und teure.

Basis: Unit-TestsGeschäftslogik in Plug-ins und eigenem Code, vom Entwickler geschrieben. Läuft in Sekunden, bricht selten, meldet einen Fehler am frühesten.

Mitte: API- und IntegrationstestsDie Dataverse Web API sowie ERP- und Fakturierungsschnittstellen unterhalb der Oberfläche (etwa Postman, Newman in der CI). Schnell, stabil, unempfindlich gegen Oberflächenänderungen.

Spitze: UI-End-to-End-TestsTricentis Tosca, Katalon oder Playwright im Browser: Lead → Angebot → Auftrag. Sie sehen, was der Anwender sieht, sind aber langsamer und pflegeintensiver — deshalb braucht es wenige, gut gewählte.

Über der Pyramide: manuelles TestenExploratives Testen und Abnahme. Das automatisieren wir nicht, denn hier kommt es auf das menschliche Urteil an.

In Dynamics 365 liegt das meiste Risiko in Anpassungen und Integrationen, deshalb decken wir neben der Oberfläche auch die API-Ebene ab. Details und Werkzeuge stehen auf der Seite Testautomatisierung.

Wie fängt man am besten an?

Mit eigenen Zahlen rechnenReleases pro Jahr, manuelle Regression je Release, interner Tagessatz. Liegt die Amortisation über zwei Jahren, bleiben Sie beim Handtest und prüfen erneut, wenn die Release-Anzahl steigt.

Klein beginnenDie erste Runde sind automatisierte Tests für einige kritische Prozesse, die bereits in der CI laufen; dann zeigt sich der reale Pflegeaufwand, und darauf lässt sich der weitere Ausbau aufbauen.

Manuelle Testfälle behaltenDie vorhandene manuelle Regressionsliste ist der beste Ausgangspunkt: Aus ihr wählen wir die zu automatisierenden Fälle nach Risiko aus.

Häufige Fragen

Was kostet Testautomatisierung?

Drei Posten: Werkzeuglizenz (Playwright ist kostenlos, Tosca und die Katalon-Team-Edition haben eine Jahresgebühr), Aufbau der Suite (einmalig) und Wartung (laufend). Das Beispiel oben zeigt die Methode; ein konkretes Angebot erstellen wir nach der Analyse von System und Testfällen.

Wann amortisiert sich Testautomatisierung?

Wenn die einmaligen Aufbaukosten geteilt durch den jährlich eingesparten manuellen Aufwand einen vertretbaren Zeitraum ergeben. In unserem Beispiel: ca. 10 Jahre bei einem kleinen System (lohnt sich nicht), ca. 23 Monate bei einem mittleren, ca. 10 Monate bei einem großen — die Annahmen stehen in der Tabelle.

Ersetzt Automatisierung manuelles Testen?

Nein. Sie ersetzt die Regression, nicht den Test neuer Funktionen, das explorative Testen oder die Abnahme. Beides ist Arbeitsteilung.

Wie viele Testfälle sollte man automatisieren?

Bei einem mittleren Dynamics-365-System decken 30–50 risikobasiert ausgewählte Testfälle rund 80 % des Risikos ab. Seltene, volatile oder einmalige Fälle prüft man günstiger von Hand.

Wie schnell gibt es Ergebnisse?

Ergebnisse gibt es schon mit der ersten Runde: Wir beginnen mit automatisierten Tests für einige kritische Prozesse, die sofort in der CI laufen; ab dann gibt es vor jedem Release Rückmeldung.

Sprechen wir über Ihr Projekt.

Schreiben Sie uns, was Sie planen — wir melden uns innerhalb weniger Tage.

Kontakt aufnehmen