Vom Geistesblitz zum Game-Changer: Die Erfolgsgeschichte des ITGAIN SchrittRekorders (ISR)

Die Geburtsstunde einer Idee

Es begann mit einer simplen, aber hartnäckigen Frage in meinem Kopf als erfahrener Softwaretester und Testmanager: „Wie können wir Abweichungen in komplexen Softwareumgebungen schneller verstehen – ohne auf vage Nutzerbeschreibungen angewiesen zu sein?“

In der Praxis zeigte sich immer wieder das gleiche Problem:

• Ein Klick zu viel, ein Tastendruck im falschen Moment – und schon trat ein Fehler auf.
• Support-Teams erhielten oft nur unvollständige oder subjektive Fehlerberichte.
• Entwickler mussten Bugs mühsam nachstellen, was Zeit und Nerven kostete.
• Der Status eines zuvor definierte Testfalles konnte hinsichtlich seiner einzelnen Designschritte nicht revisionssicher nachvollzogen werden.

Meine Vision: Ein Werkzeug, das jede Nutzeraktion präzise dokumentiert – unauffällig, lückenlos, kontextbezogen und zeitsparender

Vom Konzept zum Prototyp

Auf Basis der Idee galt es zunächst zu klären, mit wem ich dies Idee, vom Konzept bis zu den ersten Prototypen entwickeln könnte.

Typischerweise sind die Kollegen aus den Softwareentwicklerteams in Kundenprojekten gebunden und um das Vorhaben stringent voranzubringen, brauchte es entsprechende Ressourcen. Meine Lösung: ich entwickle den ITGAIN SchrittRekorder zusammen mit einem Werkstudenten der technischen Informatik.

Werkstudierende bringen oft unverstellte Sichtweisen mit. Sie sind noch nicht in festgefahrenen Denkmustern verankert und hinterfragen bestehende Prozesse. Gerade bei einem neuen Produkt wie dem SchrittRekorder war diese „unverbrauchte“ Denkweise wertvoll, um Funktionen zu gestalten, die nicht nur technisch machbar, sondern auch intuitiv nutzbar sind.

Zudem ISR bot sich als Thema für die wissenschaftliche Untersuchung der Testaufzeichnung im Kontext des Softwaretestprozesses mit einem besonderen Fokus auf den Explorativen Test an Bachelorarbeit an. Es galt bestehende Methoden, Herausforderungen und Optimierungspotenziale systematisch zu analysieren.

Erster Prototyp

Zunächst galt es zu bewerten, in welcher Programmiersprache der ITGAIN SchrittRekorder (ISR) das Licht der Welt erblicken sollte.

Unsere Wahl fiel auf die leistungsstarke, objektorientierte Programmiersprache C++. Die Entscheidung, den ISR in C++ zu entwickeln, ist auf technischen und strategischen Gründen zurückzuführen:

Technische Vorteile

• Direkter Zugriff auf Systemressourcen
  C++ erlaubt eine sehr feingranulare Kontrolle über Betriebssystemfunktionen – ideal für ein Tool, das Mausbewegungen, Tastatureingaben und Screenshots erfassen muss.
• Performance und Effizienz
  Schrittaufzeichnung kann ressourcenintensiv sein.
  C++ bietet hohe Ausführungsgeschwindigkeit und geringe Speicherbelastung, was besonders bei längeren Testsitzungen wichtig ist.
• Plattformnähe (Windows API)
  Der SchrittRekorder ersetzt das veraltete Windows-eigene Tool „Steps Recorder (PSR.exe)“. C++ ist hervorragend geeignet, um direkt mit der Windows API zu arbeiten und native Funktionen zu nutzen.
• Stabilität bei GUI-Interaktionen
  Für ein Tool, das Benutzerinteraktionen dokumentiert, ist Stabilität entscheidend. C++-basierte Anwendungen sind oft robuster gegenüber unerwarteten GUI-Verhalten.

Strategische Gründe

• Langfristige Wartbarkeit
  C++ ist eine etablierte Sprache mit breiter Entwicklerbasis und vielen verfügbaren Bibliotheken – das erleichtert die Pflege und Weiterentwicklung.
• Plattformunabhängigkeit
  C++ ist plattformübergreifend, und Programme, die in C++ geschrieben sind, können (grundsätzlich) auf den Betriebssystemen Windows, Linux und macOS laufen.
• Unabhängigkeit von Laufzeitumgebungen
  Im Gegensatz zu Sprachen wie Java oder Python benötigt C++ keine zusätzliche Runtime – das macht die Software leichter zu verteilen und zu starten.

Der erste Prototyp des ITGAIN SchrittRekorders war noch weit entfernt von der heutigen Version und wohl mehr ein zarter Versuch, um zu prüfen, ob das Vorhaben mit einem jungen Studenten realisiert werden kann.

Schnell konnte ein Pre-Release zwar Eingaben aufzeichnen, aber die Daten waren noch unstrukturiert und nur bedingt auswertbar.

Ich setzte nun auf drei Grundprinzipien:

1. Echtzeit-Aufzeichnung – jede Eingabe mit Zeitstempel.
2. Kontextanalyse – welche Anwendung war aktiv, welche Daten wurden übergeben, welche „Besonderheit“ gab es z. B. während der operativen Testdurchführung und sollte kommentiert werden.

3. Fehlerfokus – automatische Hervorhebung relevanter Abschnitte.

Schon in dieser frühen Phase zeigte sich: Das Potenzial war enorm – nicht nur für den Studenten als Bachelorarbeit, sondern auch für Support, Qualitätssicherung und Schulung.