Support: Vom Test zum Deep Dive.
In der IT-Welt verändern sich täglich Anforderungen, Prozesse und Systeme. Ein geänderter Link in einem System kann über Schnittstellen in einem anderen System zum Fehler führen.
Für unsere Kolleg*innen im Support heißt das: unsere Kunden jederzeit arbeitsfähig zu halten – persönlich, lösungsorientiert und auf Augenhöhe.
Manche Supportfälle zeigen besonders deutlich, wie wertvoll dabei Erfahrung, technische Kompetenz und ein lösungsorientiertes Miteinander sein können.
Ein Beispiel, das das besonders gut zeigt, hat sich ergeben.
Der Fall „AB.pdf“ wird zur Herausforderung.
Wir hatten mehrere Supportfälle mit nicht archivierbaren Akten. Die Ursache sei gefunden und behoben, meldeten die Systementwickler zurück: Ursache waren Dokumentennamen mit weniger als 3 Zeichen. Die Programmkorrektur würde jetzt kürzere Dokumentennamen mit Unterstrichen „_“ auffüllen.
Unser Anwenderberater, auch mit dem Testing beauftragt, führte einen praxisnahen Grenztestfall durch: eine Datei namens „AB.pdf“ als Abkürzung für Auftragsbestätigung in die Akte laden. Als erwartetes Ergebnis sollte nach Auffüllen mit Unterstrich also eine Datei „AB_.pdf“ in der Akte stehen.
Doch nach dem Upload blieb der Name „AB.pdf“. Der Unterstrich fehlte.
Vom Test zum Deep Dive
Unser Tester wusste Dank Programmiererfahrung: Solche Fehler lassen sich aufdecken, wenn man den Code Schritt für Schritt im Debugging-Modus durchgeht.
Er bat den Entwickler, ihm den Programmcode zu zeigen. Auch wenn keine Haltepunkte im Script gesetzt werden konnten, konnten sie sich Zeile für Zeile ansehen, was das Programm genau machte.
Schon nach wenigen Zeilen zeigten sich die Fehler:
- Fehler Nummer 1: Zur Verkettung von Texten wurde das „+“-Symbol verwendet – korrekt wäre das „&“
- Fehler Nummer 2: Bei der Prüfung der Länge des Dateinamens wurde auch die Endung „.pdf“ mitgezählt – und so aus „ab“ plötzlich statt zwei sechs Zeichen.
Nach zwei kurzen Korrekturen funktionierte das Programm wieder einwandfrei. Der Dateiname wurde wie gewünscht auf „AB_.pdf“ ergänzt.
Der Entwickler war sichtlich erleichtert. Der System Owner zeigte sich beeindruckt, dass unser Support nicht nur praxisnahe Testfälle liefert, sondern auch noch technische Analysen auf Augenhöhe durchführt.
Support ist mehr als eine Hotline
Dieser Fall zeigt eindrücklich: Unser Support ist kein Callcenter – er ist ein entscheidender Erfolgsfaktor im Projektalltag. Wir helfen nicht nur, wenn etwas nicht läuft – wir helfen dabei, es besser zu machen.
Was uns dabei wichtig ist:
- Wir machen Betroffene zu Beteiligten – von Anfang an.
- Wir sprechen nicht nur über Probleme, sondern auch über Verbesserungen.
- Wir testen Änderungen, und simulieren Prozesse gemeinsam mit praxisnahen Testfällen, bevor sie live gehen.
- Wir sind vor Ort – oder direkt im Call – wenn es zählt.
Ob mit gezielten Tipps, Mini-Trainings oder konkreten Eingriffen: Wir bringen Menschen ins Handeln, nicht nur Systeme zum Laufen
Unser Fazit.
Tester*innen, die aus dem Support die Praxisfälle und Systemschwächen kennen, können bessere Testfälle schreiben, die Systeme in die Knie zwingen.
Und sie können beim Wiederaufstehen helfen und im Debugging echten Mehrwert leisten, wenn sie typische Programmierfehler kennen.
Beratung, Support und Testing aus einer Hand – auf Augenhöhe zu starken Lösungen. Das ist ILTIS