Der Aufwand entsteht nicht nur bei der Entwicklung.
Bei jeder neuen Softwareversion entsteht ein wiederkehrender Aufwand für Test, Regression, Release, Kundenabnahme und gegebenenfalls Fehleranalyse.
Der entscheidende Punkt: Dieser Aufwand entsteht auf beiden Seiten der Softwarelieferkette – beim Lieferanten und beim Kunden.
Ein Fehler verursacht dabei nicht nur Kosten durch seine Behebung. Bereits die Reproduktion, die Kommunikation, Rückfragen und wiederholten Tests können einen erheblichen Teil des Gesamtaufwands ausmachen.
Zwei Seiten, ein gemeinsamer Prozess.
Die Qualität einer Softwarelieferung wird nicht an einem einzelnen Punkt entschieden. Sie entsteht über eine Kette aus Entwicklung, Qualitätssicherung, Release, Kundenabnahme, Support und Fehlerbehebung.
Aufwand beim Lieferanten
- Regressionstests nach Änderungen
- Wiederholung bestehender Tests bei neuen Versionen
- Überprüfung komplexer Benutzerabläufe
- Reproduktion von Kundenfehlern
- Auswertung von Logs und technischen Informationen
- Rückfragen an Kunden zur Rekonstruktion des Ablaufs
- Entwicklung und Prüfung von Korrekturen
- erneute Regressionstests nach Fehlerbehebungen
Aufwand beim Kunden
- Vorbereitung von Abnahme- und Regressionstests
- Einbindung von Key-Usern und Fachanwendern
- manuelle Durchführung wiederkehrender Arbeitsabläufe
- Dokumentation von Testergebnissen
- Meldung und Beschreibung von Fehlern
- Bereitstellung zusätzlicher Informationen
- Wiederholung von Tests nach Korrekturen
- erneute Prüfung nach Updates und Hotfixes
Ein Fehlerbericht beschreibt das Ergebnis – nicht immer den Weg dorthin.
Für die technische Analyse ist häufig entscheidend, was unmittelbar vor dem Fehler passiert ist.
Benutzeraktion
Welche Funktion wurde geöffnet? Welche Eingaben wurden gemacht? Welche Schritte wurden unmittelbar vor dem Fehler durchgeführt?
Systemzustand
Welche technischen Zustände lagen zu diesem Zeitpunkt vor? Welche Prozesse, Ressourcen, Exceptions oder Netzwerkaktivitäten waren beteiligt?
Reproduzierbarkeit
Kann genau derselbe Ablauf auf der Entwicklungs- oder Testumgebung erneut ausgeführt werden?
Technische Logs liefern wertvolle Informationen. Sie stellen den Zusammenhang zwischen einem technischen Ereignis und der konkreten Benutzeraktion jedoch nicht automatisch her.
Genau diese Verbindung ist für eine schnelle Ursachenanalyse entscheidend.
Benutzeraktion und technische Diagnose werden zu einem reproduzierbaren Vorgang.
GUITestStudio verbindet die Ausführung eines realen Benutzerablaufs mit der kontinuierlichen technischen Beobachtung der laufenden Anwendung.
Benutzeraktionen
Die durchgeführten Arbeitsschritte werden aufgezeichnet und können später reproduziert werden.
Technische Informationen
Während der Sitzung können unter anderem CPU-Auslastung, Speicherverbrauch, Netzwerkaktivität, Prozesse, Exceptions und Stacktraces erfasst werden.
Wiederholbarkeit
Ein aufgezeichneter Ablauf kann erneut ausgeführt und damit für Fehleranalyse und Regressionstests wiederverwendet werden.
Aus einem Fehlerbericht wird ein reproduzierbarer technischer Vorgang.
Der Entwickler muss den ursprünglichen Benutzerablauf nicht mehr ausschließlich anhand einer Beschreibung rekonstruieren. Der konkrete Ablauf kann wiederholt und gleichzeitig technisch analysiert werden.
Vom manuellen Kreislauf zu einem wiederverwendbaren Prozess.
Heute
Mit GUITestStudio
Ein einmal aufgezeichneter Ablauf kann mehrfach genutzt werden.
Aus einem einmal manuell durchgeführten realen Arbeitsablauf kann ein wiederverwendbarer Regressionstest entstehen.
Version A
Arbeitsablauf wird aufgezeichnet und als reproduzierbarer Testfall gespeichert.
Version B
Derselbe Ablauf wird nach dem Update erneut automatisch ausgeführt.
Version C
Der Test bleibt Bestandteil der Testsuite und kann bei weiteren Releases erneut ausgeführt werden.
Dadurch entsteht mit jedem Release eine wachsende Sammlung realer und wiederverwendbarer Testszenarien.
Das einmal investierte Wissen über einen Arbeitsablauf muss nicht bei jeder neuen Version erneut manuell aufgebaut werden.
Eine gemeinsame Testbasis für beide Seiten.
Besonders interessant wird der Ansatz, wenn standardisierte Tests vom Lieferanten mit individuellen Testszenarien eines Kunden kombiniert werden.
Lieferanten-Tests
Standardisierte Tests für zentrale und wiederkehrende Funktionen werden erstellt und über Releases hinweg wiederverwendet.
Kundenspezifische Tests
Der Kunde kann eigene reale Arbeitsabläufe aufzeichnen und als Ergänzung zu den Standardtests verwenden.
Gemeinsame Fehlerbasis
Bei einem Fehler steht nicht nur eine Beschreibung, sondern ein reproduzierbarer Ablauf inklusive technischer Informationen zur Verfügung.
Nicht nur funktionale Regressionen werden sichtbar.
Derselbe aufgezeichnete Nutzungsvorgang kann auf unterschiedlichen Softwareversionen ausgeführt und hinsichtlich technischer Kennzahlen verglichen werden.
Speicher
Vergleich des Speicherverbrauchs während eines identischen Nutzungsvorgangs.
CPU
Erkennung veränderter Auslastungen und neuer oder stärkerer Lastspitzen.
Langzeitverhalten
Beobachtung des Ressourcenverhaltens bei längeren und wiederholten Nutzungsszenarien.
Damit entsteht neben dem funktionalen Regressionstest eine zusätzliche Qualitätsebene:
messbare Performance- und Ressourcenregression.
Der wirtschaftliche Hebel liegt in der gesamten Prozesskette.
Der Nutzen entsteht nicht nur durch eingesparte Testzeit. Entscheidend ist die mögliche Reduzierung des Gesamtaufwands von der Softwareänderung bis zur erfolgreichen Kundenabnahme.
| Bereich | Heutiger Aufwand | Möglicher Beitrag von GUITestStudio |
|---|---|---|
| Regression | Wiederholung manueller Arbeitsabläufe | Automatisierte, wiederverwendbare Testfälle |
| Fehlerreproduktion | Rekonstruktion anhand von Beschreibungen | Wiedergabe aufgezeichneter Benutzeraktionen |
| Fehleranalyse | Getrennte Betrachtung von Benutzeraktion und Logs | Gemeinsame Betrachtung von Ablauf und technischen Daten |
| Rückfragen | Mehrfache Abstimmung zwischen Kunde und Lieferant | Vollständigerer und reproduzierbarer Fehlerkontext |
| Kundenabnahme | Wiederkehrende manuelle Durchführung | Automatisierte Wiederholung definierter Szenarien |
| Performance | Einzelne technische Messwerte | Vergleich desselben Nutzungsvorgangs über Versionen |
Nicht theoretisch bewerten – sondern messbar ausprobieren.
Der Nutzen von GUITestStudio sollte anhand realer Prozesse bewertet werden. Dafür bietet sich ein begrenzter Pilotbetrieb an, bei dem der bisherige Aufwand mit dem Aufwand unter Einsatz von GUITestStudio verglichen wird.
01 · Fehleranalyse
Ausgewählte reale Fehler werden mit GUITestStudio aufgezeichnet und reproduziert.
- Zeit bis zur Reproduktion
- Anzahl der Rückfragen
- Zeit bis zur Ursachenanalyse
- Zeit bis zur Fehlerbehebung
02 · Regression
Bestehende manuelle Tests werden als automatisierte Testfälle abgebildet.
- Anzahl automatisierter Tests
- manuelle Testzeit vorher/nachher
- Ausführungszeit
- erkannte Regressionen
03 · Releasevergleich
Identische Nutzungsszenarien werden auf unterschiedlichen Versionen ausgeführt.
- Speicherverbrauch
- CPU-Auslastung
- Netzwerkaktivität
- auffällige Lastspitzen
04 · Kundensystem
Ein ausgewähltes Kunden-Testsystem wird in den Prozess einbezogen.
- Aufwand für Kundentests
- Reproduzierbarkeit von Fehlern
- Kommunikationsaufwand
- Aufwand für erneute Abnahmen
Entscheidend ist nicht die Anzahl der Funktionen des Tools, sondern die messbare Veränderung des bestehenden Prozesses.
| Messgröße | Fragestellung |
|---|---|
| Zeit bis zur Reproduktion | Wie schnell kann ein gemeldeter Fehler reproduzierbar dargestellt werden? |
| Zeit bis zur Ursachenanalyse | Wie schnell lässt sich die technische Ursache eingrenzen? |
| Rückfragen | Wie viele Kommunikationsschritte zwischen Kunde und Lieferant sind erforderlich? |
| Manueller Testaufwand | Wie viel Zeit entfällt durch automatisierte Wiederholung? |
| Automatisierte Testfälle | Wie viele reale Arbeitsabläufe können dauerhaft automatisiert abgesichert werden? |
| Vor Release erkannte Fehler | Welche Regressionen werden bereits vor der Kundenabnahme erkannt? |
| Kundenaufwand | Wie stark reduziert sich der Aufwand für wiederkehrende Abnahme- und Regressionstests? |
| Performance | Lassen sich Veränderungen von CPU, Speicher und anderen Ressourcen objektiv nachvollziehen? |
GUITestStudio als Verbindung zwischen Softwarelieferant und Kunde.
Die wesentliche Idee besteht nicht darin, einen weiteren Testmechanismus bereitzustellen.
GUITestStudio soll den heute teilweise getrennten Prozess von Test, Release, Kundenabnahme, Fehlerkommunikation und Fehleranalyse stärker miteinander verbinden.
Aus einem realen Benutzerablauf kann ein reproduzierbarer Test werden. Aus einem reproduzierbaren Test können technische Vergleichsdaten entstehen. Und aus einer Fehleraufzeichnung kann ein Vorgang werden, der auf beiden Seiten nachvollziehbar und wiederholbar ist.
Testautomatisierung
Wiederholbare Absicherung bestehender Arbeitsabläufe über mehrere Releases.
Fehlerdiagnose
Verbindung von Benutzeraktion und technischem Systemzustand.
Reproduzierbarkeit
Derselbe Ablauf kann auf unterschiedlichen Testsystemen und Versionen erneut ausgeführt werden.
Kundenabnahme
Individuelle Kundenszenarien können als dauerhafte Tests erhalten bleiben.
Performance
Vergleich des technischen Verhaltens identischer Nutzungsvorgänge über verschiedene Versionen.
Prozesskosten
Reduzierung wiederkehrender Aufwände bei Entwicklung, Support und Kunden.
Weniger Aufwand bei jeder Softwareänderung.
Jede neue Version erzeugt heute erneut Test- und Analyseaufwand. Ein Teil dieses Aufwands lässt sich durch wiederverwendbare Tests und reproduzierbare Fehleranalysen dauerhaft reduzieren.
Der Lieferant und der Kunde müssen nicht bei jeder Version wieder bei null beginnen.
Ein einmal erstellter Testfall, ein einmal aufgezeichneter Arbeitsablauf und eine einmal dokumentierte Fehlerreproduktion können über zukünftige Releases hinweg wiederverwendet werden.
Damit kann GUITestStudio zu einer gemeinsamen technischen Grundlage für eine effizientere Softwarelieferung und Qualitätssicherung werden.
Was automatisierte Tests
tatsächlich verändern können
Bei wiederkehrenden Softwaretests entsteht der Aufwand nicht nur beim Softwarelieferanten. Auch auf Kundenseite müssen Abläufe nach Updates erneut geprüft, Fehler reproduziert und Ergebnisse dokumentiert werden. Werden dieselben Testabläufe automatisiert, kann ein einmal erstellter Testfall auf beiden Seiten wiederverwendet werden.
Vollzeitkräfte
Beispielhaft gebundene Mitarbeiter auf Lieferantenseite, die im betrachteten Szenario mit wiederkehrenden Test-, Prüf- und Analyseaufgaben beschäftigt sind.
Pro Monat beim Kunden
Fünf Mitarbeiter führen jeweils fünf Tage pro Monat wiederkehrende Tests und Prüfungen nach Softwareupdates durch.
pro Jahr
Theoretisches jährliches Arbeitsvolumen aus beiden Seiten, wenn die genannten Kapazitäten vollständig für diese Aufgaben eingesetzt werden.
Vom manuellen Aufwand zum automatisierten Testlauf
Die folgende Rechnung ist bewusst als Modellrechnung aufgebaut. Sie zeigt die Größenordnung des Potenzials und stellt keine Aussage über die tatsächlich heute anfallenden Personalkosten dar.
Was entspricht diese Arbeitszeit finanziell?
Für eine beispielhafte Betrachtung werden auf Lieferantenseite Vollkosten von 80 € pro Arbeitsstunde und auf Kundenseite 55 € pro Arbeitsstunde angesetzt. Diese Werte dienen ausschließlich der Modellrechnung und können durch die tatsächlichen internen Vollkostensätze ersetzt werden.
Lieferantenseite
38.400 Stunden × 80 € pro Stunde ergeben ein theoretisches jährliches Arbeitskostenvolumen von rund 3,07 Mio. €.
Kundenseite
2.400 Stunden × 55 € pro Stunde ergeben ein theoretisches jährliches Arbeitskostenvolumen von rund 132.000 €.
Gesamtvolumen
Zusammen entspricht das einem theoretischen Arbeitskostenvolumen von rund 3,20 Mio. € pro Jahr.
Nicht jeder Test lässt sich vollständig automatisieren
Entscheidend ist deshalb nicht die Annahme, dass GUITestStudio sämtliche Mitarbeiter ersetzt. Interessanter ist die Frage, welcher Anteil der wiederkehrenden manuellen Arbeit automatisiert werden kann.
* Modellrechnung auf Basis von 80 €/h auf Lieferantenseite und 55 €/h auf Kundenseite. FTE-Äquivalent auf Basis von 1.600 Arbeitsstunden pro Jahr. Die Werte dienen zur Veranschaulichung des möglichen Potenzials und sind keine Prognose tatsächlicher Einsparungen.
Ein Testfall kann auf beiden Seiten Arbeit ersetzen – ohne den Testfall zweimal erstellen zu müssen.
Ein einmal aufgezeichneter Ablauf kann beim Softwarelieferanten für Regressionstests eingesetzt und anschließend beim Kunden für Abnahme- und Updateprüfungen wiederverwendet werden. Tritt dabei ein Fehler auf, stehen neben dem Testergebnis auch Screenshots, Zeitablauf, technische Diagnosedaten und – je nach Konfiguration – Metriken zur Verfügung.
Ein realer Ablauf wird einmal durchgeführt.
Der Ablauf wird beliebig oft wiederholt.
Testfälle und Sitzungen können zwischen den Beteiligten ausgetauscht werden.
Fehler werden mit dem tatsächlichen Ablauf und technischen Informationen betrachtet.
Was diese Rechnung nicht berücksichtigt
Das dargestellte Potenzial beschränkt sich bewusst auf den wiederkehrenden Testaufwand. Zusätzliche Effekte können durch schnellere Fehlerreproduktion, weniger Rückfragen zwischen Kunde und Lieferant, verkürzte Analysezeiten sowie die frühere Erkennung von Regressionen entstehen. Diese Effekte sind in der Modellrechnung noch nicht monetarisiert.
Gerade bei der Fehlersuche kann deshalb ein zusätzlicher Hebel entstehen: Statt dass Support, Kunde und Entwicklung einen Fehler schrittweise durch Rückfragen rekonstruieren müssen, kann eine aufgezeichnete Sitzung den tatsächlichen Ablauf einschließlich der verfügbaren Diagnosedaten direkt weitergeben.
Was automatisierte Tests
tatsächlich verändern können
Bei wiederkehrenden Softwaretests entsteht der Aufwand nicht nur beim Softwarelieferanten. Auch auf Kundenseite müssen Abläufe nach Updates erneut geprüft, Fehler reproduziert und Ergebnisse dokumentiert werden. Werden dieselben Testabläufe automatisiert, kann ein einmal erstellter Testfall auf beiden Seiten wiederverwendet werden.
Vollzeitkräfte
Beispielhaft gebundene Mitarbeiter auf Lieferantenseite, die im betrachteten Szenario mit wiederkehrenden Test-, Prüf- und Analyseaufgaben beschäftigt sind.
Pro Monat beim Kunden
Fünf Mitarbeiter führen jeweils fünf Tage pro Monat wiederkehrende Tests und Prüfungen nach Softwareupdates durch.
pro Jahr
Theoretisches jährliches Arbeitsvolumen aus beiden Seiten, wenn die genannten Kapazitäten vollständig für diese Aufgaben eingesetzt werden.
Vom manuellen Aufwand zum automatisierten Testlauf
Die folgende Rechnung ist bewusst als Modellrechnung aufgebaut. Sie zeigt die Größenordnung des Potenzials und stellt keine Aussage über die tatsächlich heute anfallenden Personalkosten dar.
Was entspricht diese Arbeitszeit finanziell?
Für eine beispielhafte Betrachtung werden auf Lieferantenseite Vollkosten von 80 € pro Arbeitsstunde und auf Kundenseite 55 € pro Arbeitsstunde angesetzt. Diese Werte dienen ausschließlich der Modellrechnung und können durch die tatsächlichen internen Vollkostensätze ersetzt werden.
Lieferantenseite
38.400 Stunden × 80 € pro Stunde ergeben ein theoretisches jährliches Arbeitskostenvolumen von rund 3,07 Mio. €.
Kundenseite
2.400 Stunden × 55 € pro Stunde ergeben ein theoretisches jährliches Arbeitskostenvolumen von rund 132.000 €.
Gesamtvolumen
Zusammen entspricht das einem theoretischen Arbeitskostenvolumen von rund 3,20 Mio. € pro Jahr.
Nicht jeder Test lässt sich vollständig automatisieren
Entscheidend ist deshalb nicht die Annahme, dass GUITestStudio sämtliche Mitarbeiter ersetzt. Interessanter ist die Frage, welcher Anteil der wiederkehrenden manuellen Arbeit automatisiert werden kann.
* Modellrechnung auf Basis von 80 €/h auf Lieferantenseite und 55 €/h auf Kundenseite. FTE-Äquivalent auf Basis von 1.600 Arbeitsstunden pro Jahr. Die Werte dienen zur Veranschaulichung des möglichen Potenzials und sind keine Prognose tatsächlicher Einsparungen.
Ein Testfall kann auf beiden Seiten Arbeit ersetzen – ohne den Testfall zweimal erstellen zu müssen.
Ein einmal aufgezeichneter Ablauf kann beim Softwarelieferanten für Regressionstests eingesetzt und anschließend beim Kunden für Abnahme- und Updateprüfungen wiederverwendet werden. Tritt dabei ein Fehler auf, stehen neben dem Testergebnis auch Screenshots, Zeitablauf, technische Diagnosedaten und – je nach Konfiguration – Metriken zur Verfügung.
Ein realer Ablauf wird einmal durchgeführt.
Der Ablauf wird beliebig oft wiederholt.
Testfälle und Sitzungen können zwischen den Beteiligten ausgetauscht werden.
Fehler werden mit dem tatsächlichen Ablauf und technischen Informationen betrachtet.
Was diese Rechnung nicht berücksichtigt
Das dargestellte Potenzial beschränkt sich bewusst auf den wiederkehrenden Testaufwand. Zusätzliche Effekte können durch schnellere Fehlerreproduktion, weniger Rückfragen zwischen Kunde und Lieferant, verkürzte Analysezeiten sowie die frühere Erkennung von Regressionen entstehen. Diese Effekte sind in der Modellrechnung noch nicht monetarisiert.
Gerade bei der Fehlersuche kann deshalb ein zusätzlicher Hebel entstehen: Statt dass Support, Kunde und Entwicklung einen Fehler schrittweise durch Rückfragen rekonstruieren müssen, kann eine aufgezeichnete Sitzung den tatsächlichen Ablauf einschließlich der verfügbaren Diagnosedaten direkt weitergeben.