„Man muss unterscheiden zwischen einem Fehler und einer Fehlbedienung“, sagt ein IT-Tester in einem Interview über nicht standardmäßige Szenarien und Fehler

Was denken die Menschen in deinem Umfeld, was du eigentlich machst?

Nun, da ich diesen Job schon während der Covid-Zeit gemacht habe und damals mehrere Monate bei meinen Eltern verbrachte, konnten sie es mit eigenen Augen sehen. Und die Reaktionen der Leute lassen sich meist so zusammenfassen: „Du machst ja eigentlich das Gleiche wie damals, als du als Kind am Computer gespielt hast, oder?“ – also, dass ich nur klicke und beobachte, was passiert.

Das ist natürlich eine sehr vereinfachte Sichtweise. Ich habe einen technischen Hintergrund, daher verstehen meine Angehörigen vielleicht ein bisschen, worum es geht. Wenn ich sage, dass ich Tester bin, stellen sich viele vor, dass ich einfach nur mehr klicke als andere. Und vielleicht stimmt das sogar ein wenig – aber es geht um weit mehr als nur ums Klicken.

Ich glaube, die meisten Menschen sind sich des Umfangs und der Komplexität dieser Arbeit nicht bewusst. Früher, als ich selbst nur Nutzer war und kein Tester, dachte ich auch oft: „Wie kann es sein, dass sie diesen Fehler nicht bemerkt haben?“ Aber als ich auf die andere Seite wechselte, verstand ich: Es gibt tausende Kombinationen, die getestet werden müssen. Man kann einfach nicht alles abdecken. Es ist unmöglich, eine Anwendung zu 100 % zu testen. Jeder denkt, dass gerade sein Fehler ein entscheidender ist und hätte entdeckt werden müssen. Aber die Realität ist: Das geht schlichtweg nicht. Und genau das ist, glaube ich, das größte Missverständnis.

Und wie sieht das in der Praxis aus? Wann steigst du in den Entwicklungsprozess ein?

Wenn der Programmierer seine Arbeit abgeschlossen hat, übergibt er sie an mich – er markiert die jeweilige Funktionalität im System, in der Anwendung oder in der Lösung als „ready for review“, also bereit zum Testen. Wichtig ist aber zu wissen, dass das nicht bedeutet, dass sie schon beim Kunden installiert ist. In unserem Prozess gibt es mehrere Umgebungen: Entwicklungs-, Integrations- und erst danach Produktionsumgebung. Das Testen findet hauptsächlich in der Entwicklungsumgebung statt und nur in Ausnahmefällen in der Integrationsumgebung.

Zum Beispiel: Wenn eine neue Funktion entwickelt wird, greife ich nicht gleich während der Entwicklung ein, sondern erst, wenn das Ganze fertig ist. Es bringt nichts, halbfertige Lösungen zu testen, weil spätere Teile die vorherigen beeinflussen können. Sobald also etwas abgeschlossen ist, bekomme ich die Information, dass es fertig ist, es wird in die Testumgebung eingespielt – und ich beginne mit dem Testen.

Wie läuft das Testen konkret ab?

Zuerst sehe ich mir an, was geändert oder hinzugefügt wurde. Ich habe ein vorbereitetes Testszenario – also genaue Schritte, wie ich die jeweilige Situation simuliere. Wenn sich der Fehler so zeigt, wie ich ihn beschrieben habe, und er behoben ist, kann ich das als gelöst betrachten. Wenn nicht, schicke ich es an den Entwickler zurück und ergänze eine genaue Fehlerbeschreibung.

In so einem Fall erstelle ich ein sogenanntes „Issue“ in JIRA – das ist das Tool, das wir zur Nachverfolgung des gesamten Entwicklungszyklus verwenden. In diesem „Issue“ schreibe ich den Titel des Fehlers, eine Beschreibung, in welcher Version und Umgebung er aufgetreten ist, füge Screenshots hinzu und vor allem die genauen Schritte, wie der Fehler reproduziert werden kann. Der Entwickler muss nachvollziehen können, wie ich dorthin gelangt bin, weil er den Fehler bei sich prüfen muss.

Zum Beispiel: Melde dich an, klicke auf das Dokument, führe diese Aktion aus – und dort tritt das Problem auf. Es muss exakt beschrieben sein.

Also erstellst du für jeden Bug ein solches „Protokoll“?

Ja. Und dieses Protokoll besteht nicht nur aus Text. Es muss technisch nachvollziehbar sein, Screenshots, Versionsangaben und genaue Bedingungen enthalten. Zum Beispiel kann es vorkommen, dass der Entwickler den Fehler nicht reproduzieren kann – dann prüfen wir, ob das Problem nur in einem bestimmten Browser oder Gerät auftritt. Vielleicht habe ich in Chrome getestet, er aber in Firefox. Und der Fehler tritt nur dort auf. Oder sogar nur auf dem iPhone, oder nur auf einem Android-Gerät mit einer bestimmten Version.

Einmal hatten wir sogar einen gemeldeten Bug, und am Ende stellte sich heraus, dass der Benutzer den DuckDuckGo-Browser verwendete. Es ist also unmöglich, alle denkbaren Kombinationen von Hardware, Software und Umgebungen zu testen. Deshalb konzentrieren wir uns immer auf das, was für den Zielmarkt relevant ist – zum Beispiel, wenn wir testen.

Und dieses Testszenario von dir – ist das ein standardisiertes Dokument?

Ja, wir haben erstellte Testszenarien. Einige habe ich selbst geschrieben, andere meine Kollegen. Idealerweise sollten diese Szenarien dokumentiert und unter allen Testern geteilt werden – besonders, wenn mehrere Leute im Team sind. Manche Szenarien sind auch für automatisierte Tests vorgesehen; diese sind in speziellen Sammlungen abgelegt und ebenfalls beschrieben – was sie tun und welches Ergebnis erwartet wird.

Und was passiert, wenn du zum Beispiel dreißig Bugs findest?

Jeden einzelnen trage ich als separates Issue in JIRA ein. Jeder muss beschrieben und dokumentiert werden, und der Entwickler geht sie dann durch. Wenn er sie behoben hat, spielt er die korrigierte Version erneut ein, und ich gehe wieder alle Szenarien durch. Wenn alles gelöst ist, markiere ich es als abgeschlossen – und wir können weitermachen.

Und das wiederholt sich bei jeder Version?

Genau. Bei jeder neuen Version. Zum Beispiel haben wir Version 1.0, die Entwickler haben die Bugs behoben, und ich teste wieder. Wenn immer noch Fehler da sind, wiederholt sich der Zyklus.

Gibt es so etwas wie eine „fehlerfreie Version“?

Theoretisch ja. In der Praxis nein. Jede Anwendung hat Bugs. Die Frage ist nur, welche davon akzeptabel sind. Zum Beispiel ein Fehler, der nur in der Kombination Firefox auf dem iPad auftritt – das ist so marginal, dass er als niedrige Priorität gilt. Natürlich gibt es verschiedene Bug-Kategorien. Wir haben „Blocker“, was bedeutet, dass wir gar nicht weitermachen können – etwa, wenn der Server nicht funktioniert. Dann „Critical“, also Fehler in der Kernfunktionalität. Danach folgen „Major“, „Minor“ und schließlich „Trivial“, etwa ein Logo mit zu geringer Auflösung oder ein leicht verschobenes Element auf einem ungewöhnlichen Gerät. Das sind meist nur kosmetische Dinge.

Wie viel muss man eigentlich wirklich testen? Lässt sich das überhaupt quantifizieren?

Das ist schwer zu beziffern, aber ich vergleiche es oft damit, dass das Testen mindestens die Hälfte der gesamten Entwicklungszeit ausmacht. Es ist nichts, was man „nebenbei“ erledigen kann. Wenn man eine Woche lang programmiert, sollte man mindestens genauso viel Zeit fürs Testen einplanen. Und je komplexer die Anwendung ist, desto mehr Kombinationen entstehen – und desto mehr Zeit braucht man.

Ein Beispiel sind Sprachversionen – das ist ein Kapitel für sich. Wenn du eine Anwendung hast, die in Englisch, Polnisch, Ungarisch, Tschechisch und Slowakisch läuft, musst du alles in jeder Version durchklicken. Auch wenn du die Sprache nicht verstehst, achtest du darauf, ob Texte fehlen, etwas falsch umbrochen ist oder fremde Zeichen auftauchen. Wir hatten einmal den Fall, dass in der ungarischen Version plötzlich eine Meldung auf Ukrainisch angezeigt wurde. Solche Dinge passieren einfach.

Meiner Meinung nach wird das Testen immer noch unterschätzt – vor allem, wie viel Zeit und Energie es erfordert. Und das gilt besonders für manuelles Testen, bei dem man alles händisch machen muss: Eingabekombinationen, verschiedene Geräte, verschiedene Situationen.

Und was ist mit den Fällen, die sich nicht automatisch testen lassen? Macht ihr alles von Hand?

Lange haben wir rein manuell gearbeitet, aber jetzt stellen wir um, sodass wir zumindest einen Teil der Szenarien automatisiert abdecken. Gemeinsam mit den Entwicklern haben wir das Ziel, automatisierte Tests zu erstellen, die jeden Tag laufen. Gleichzeitig erstelle ich neue, kürzere manuelle Szenarien, die sich in ein bis zwei Tagen durchgehen lassen. Es geht nicht darum, alles auf einmal zu testen, sondern die wichtigen Teile operativ überprüfen zu können.

Und wenn du dann alle Szenarien durchgegangen bist, was dann? Ist das Projekt damit für dich beendet?

Das hängt vom Projekt ab. Manchmal endet damit mein Einsatz, manchmal mache ich auch nach dem Go-live weiter – Support, Kundenkonsultationen. Es kommt wirklich darauf an, wie das Projekt aufgesetzt ist.

Musst du bei deiner Arbeit also wie ein Benutzer denken?

Ich versuche, mich in die Rolle des Benutzers hineinzuversetzen – und das ist nicht immer einfach. Jeder Benutzer hat andere Gewohnheiten und nutzt das System auf seine eigene Weise. Es gibt Menschen, die unlogisch oder konfus klicken oder etwas ganz anders machen, als man erwarten würde. Gerade sie entdecken oft Fehler, die normales Testen nicht aufdeckt. Daher kommt es vor, dass der Kunde einen Fehler meldet und wir nur den Kopf schütteln: „Wir haben das doch getestet, alles war in Ordnung!“

Und was machst du dann?

Ich beginne zu verifizieren, auszuprobieren, zu simulieren … und nicht immer gelingt es mir. Es gibt Situationen, in denen ich den Fehler nicht reproduzieren kann. Das ist das Schlimmste – wenn du nicht weißt, was die Person genau gemacht hat. Dann stellst du fest, dass sie einen sehr unüblichen Weg gegangen ist, den ein normaler Benutzer nie versuchen würde. In solchen Fällen muss man bewerten: Ist das ein Fehler, der sich wiederholen kann, oder etwas so Einzigartiges, dass sich eine Behebung nicht lohnt?

Zum Beispiel kann es bei großen Systemen wie Dokumentenportalen mit zehntausenden Benutzern passieren, dass sich jemand nicht registrieren kann. Für uns ist das ein Signal: OK, wir müssen in die Logs schauen und herausfinden, warum es passiert ist. Vielleicht ist es nur eine technische Ausnahme. Oder die Person hat es gerade versucht, als ihr das Internet ausgefallen ist. Und dann schauen wir oft in die Developer-Konsole, verfolgen, welche Antwort vom Server kam, was passiert ist. Wenn ich es simulieren kann, kann ich den Fehler bestätigen und angehen. Wenn nicht, muss ich weiter nachforschen.

Was sind die bizarrsten Szenarien?

Klassisch ist, dass der Benutzer dreimal hintereinander auf denselben Button klickt. Aber nicht im Sinne von verzweifeltem Klicken, weil sich etwas nicht lädt. Es geht um Situationen, in denen ein Button nur für eine Sekunde angezeigt wird – und der Benutzer schafft es, ihn dreimal hintereinander zu drücken und damit den gesamten Prozess zu zerstören.

Oder wir testen Situationen mit langsamer Internetverbindung – ich muss meinen Browser verlangsamen, Verzögerungen einstellen, weil das die reale Umgebung der Benutzer simuliert, die an Orten mit schlechterem Signal leben. Menschen funktionieren unterschiedlich, haben verschiedene Geräte und Bedingungen. Jemand klickt auf etwas, geht dann kochen, kommt nach zwei Stunden zurück und erwartet, dass er immer noch weitermachen kann, als wäre nichts passiert. Aber in der Zwischenzeit ist die Anwendung abgelaufen, hat ihn abgemeldet oder der Link ist abgelaufen. Und sie wundern sich, warum es nicht funktioniert.

Und begegnet dir auch, dass ein Kunde einen Fehler meldet, aber es sich in Wirklichkeit nicht um einen Bug handelt?

Das ist ein häufiges Szenario. Zum Beispiel steht in der Dokumentation, wie das System funktionieren soll, aber der Benutzer macht es völlig anders, nicht so, wie es erwartet wird. Und dann geht etwas schief. Er meldet sich und sagt, er habe einen Bug, aber in Wirklichkeit hat er nur den vorgesehenen Prozess umgangen. Und wir müssen das bewerten – ist das ein echter Fehler? Oder nur eine falsche Verwendung? Und manchmal ist es tatsächlich ein Produktions-Bug, der sofort behoben werden muss. Ein anderes Mal hat der Benutzer einfach etwas getan, was das System zwar erlaubt, aber nicht vorgesehen war. Und daraus entsteht dann das Problem. Der Tester muss in der Lage sein, diese Grenze zu erkennen.

Also musst du das System sowohl von innen als auch von außen kennen.

Auf jeden Fall. Zum Beispiel weiß ich bis heute nicht genau, wie Internetbanking in der realen Umgebung einer Bank aussieht, wenn ich es nicht selbst benutze. Aber ich kenne die Prozesse, weiß, wie sie funktionieren und wie sie mit anderen Modulen zusammenarbeiten sollen. Es hat Monate gedauert, bis wir alle Zusammenhänge verstanden haben. Damit unsere Anwendung funktioniert, muss nämlich alles mit mehr als zehn anderen Systemen von verschiedenen Anbietern verknüpft sein. Jedes macht etwas anderes, alles muss zusammen harmonieren. Und dann muss das Ganze noch Sicherheitsprüfungen, Freigaben und Kontrollen bestehen...

Du hast erwähnt, dass du mit Analysten und Entwicklern zusammenarbeitest. Wer ist dein engster Kreis von Leuten, mit denen du täglich kommunizierst?

In erster Linie sind das Entwickler und Analysten. Mit den Analysten bespreche ich die Systemlogik und funktionale Anforderungen, mit den Entwicklern wiederum, wie etwas implementiert wurde und welche technischen Einschränkungen es gab. Manchmal kommt auch der Projektmanager oder ein Berater dazu, gelegentlich direkt der Kunde. Und manchmal, wenn der Fehler außerhalb meines Testrahmens liegt, antworte ich auch als Berater – ich suche also heraus, was eigentlich passiert ist, warum es nicht reproduzierbar war und wer die Antwort haben könnte.

Wie bist du eigentlich in die IT gekommen?

Im Grunde hat es als Spiel begonnen. Zu Hause hatten wir einen Computer, einige der ersten Spiele, die mir meine Eltern verboten haben, weil sie angeblich „blutig“ waren – wie zum Beispiel Duke Nukem. Aber das hat mich fasziniert. Ich habe versucht, die Verbote zu umgehen, Spiele zu kopieren, sie heimlich zu installieren, Installationen in versteckten Ordnern zu verstecken...

Nach und nach bin ich da hineingewachsen, habe mir selbst Dinge beigebracht, ausprobiert. Und das ist etwas, das mir heute unglaublich hilft. Denn viele Leute sagen: „Ich arbeite doch jeden Tag mit dem Computer.“ Aber wenn du zehn Jahre in einer Bank arbeitest und immer nur Excel oder Word öffnest, heißt das noch lange nicht, dass du die Prinzipien verstehst. Du sagst: „Windows-Taste + E? Keine Ahnung, was das macht.“ Aber wenn du der Typ Mensch bist, der gerne im System „herumstochert“, ausprobiert, sucht, dann hast du einen großen Vorteil. Du kannst Dinge aus einer anderen Perspektive sehen.

Also sollte ein Tester ein bisschen ein „Selbstlerner“ sein?

Ein Tester in unserem Team sollte nicht jemand sein, der immer darauf wartet, dass man ihm eine genaue Aufgabe gibt und er sie dann Schritt für Schritt abarbeitet. Klar, manchmal ist es so. Aber oft eben nicht. Wir haben zum Beispiel manchmal achtzigseitige Dokumentationen. Voller Beschreibungen, wie etwas funktionieren soll. Aber trotzdem lässt sich vieles nicht vollständig simulieren. Im Bankenumfeld gibt es so viele Besonderheiten, dass es fast unmöglich ist, alles in einen Test zu übertragen. Und wenn du darauf wartest, dass dir jemand alles aufzeichnet und genau sagt: „Mach das so“, dann hast du ein Problem. Deshalb ist es wichtig, dass ein Tester denken kann, fehlende Informationen ergänzt, abschätzen kann, was sich noch überprüfen lässt und was schon darüber hinausgeht.

Was würdest du sagen, was ist die Grundausstattung eines Testers?

Auf jeden Fall Geduld. Und die Fähigkeit, „out of the box“ zu denken. Ein Tester muss in der Lage sein, Dinge aus einer anderen Perspektive zu sehen, sowohl aus der Sicht des Benutzers als auch aus der des Entwicklers. Fantasie haben und den Drang, Fehler zu finden. Es reicht nicht, einfach einer Anleitung zu folgen. Wenn dir jemand sagt: „Teste das Signieren eines Dokuments“, dann reicht es nicht, nur das Grundszenario durchzuspielen — öffnen, unterschreiben, absenden.

Du musst auch ausprobieren, was passiert, wenn du etwas kaputt machst. Was passiert, wenn du falsche Daten eingibst? Wenn du die Seite mitten im Signiervorgang schließt? Wenn du auf etwas klickst, wo du eigentlich nicht solltest?

Was ist also das größte Missverständnis, dem du in Bezug auf deine Arbeit am häufigsten begegnest?

Das größte Missverständnis ist die Vorstellung, dass man alle Fehler entdecken kann. Die Leute denken, ihr Fehler sei so gravierend, dass ihn jemand bestimmt getestet haben muss. Aber in der Praxis gibt es buchstäblich Tausende von Kombinationen, und es ist einfach nicht möglich, alles zu testen. Stell dir einen normalen Benutzer vor: Etwas funktioniert nicht, es wird keine Fehlermeldung angezeigt, ein Bild wird nicht richtig dargestellt... und er sagt sich: „Wie ist es möglich, dass ihr genau das nicht entdeckt habt?“ Aber wenn du dir überlegst, wie viele Möglichkeiten es gibt, auf wie vielen Geräten, mit welcher Software, in welchen Kombinationen... alles zu 100 % zu testen ist unmöglich.

Gibt es so etwas wie den stereotypen Tester?

Ich glaube nicht. Ich kenne zum Beispiel niemanden, der gezielt zum Testen gekommen ist. Meistens sind wir da alle irgendwie „hineingefallen“. Ich wurde direkt hineingeworfen: „Hier, das wirst du machen, wir haben dafür keinen anderen.“ Und ich sagte mir: „Na gut, ich probiere es.“ Und nach und nach habe ich gelernt.

Zeigt sich eine berufliche Deformation auch in deinem Privatleben?

Ich merke das, wenn mir jemand seinen Bildschirm teilt und ich beobachte, wie er klickt. Ob er schnell oder verwirrt ist, ob er überhaupt die Navigation versteht. Ich beobachte Benutzeroberflächen, was man verbessern könnte, wie es funktionieren sollte. Wenn ich ein Formular ausfülle oder auf einen Fehler im Onlineshop stoße, öffne ich automatisch die Konsole, schaue mir die Logs an und suche nach der Ursache. Und ich gebe zu, manchmal fülle ich sogar Feedback-Formulare aus, obwohl ich weiß, dass es mich aufhält. Weil ich weiß, dass irgendwo auf der anderen Seite jemand wie ich sitzt, dem ich damit helfen kann.

Braucht man eine spezielle Ausbildung oder Fähigkeiten?

Ich denke, man braucht vor allem Leidenschaft. Und einige grundlegende Computerkenntnisse. Was für mich heute selbstverständlich ist — sich im System zurechtzufinden, mit dem Browser zu arbeiten, selbst etwas zu testen — das ist keine Selbstverständlichkeit. Für mich war das natürlich, weil ich mich jahrelang damit beschäftigt habe. Aber viele Menschen ohne diese Grundlage kommen einfach nicht ins Testen hinein.

Und wem würdest du diesen Beruf empfehlen?

Allen, die gerne Probleme lösen, aber nicht direkt programmieren möchten. Jemandem, der gerne in Dingen „herumstochert“, analysiert, testet, versucht, Dinge zu zerstören und dann herausfindet, warum sie kaputtgingen. Manchmal ist es schön, einen Bug zu haben, der scheinbar unlösbar ist, aber dann findest du das eine Detail, das ihn verursacht hat, und hast dieses „Bossfight“-Gefühl wie in einem Spiel. Und das ist das beste Gefühl überhaupt.

Du hast Videospiele erwähnt, hast du auch Rezensionen geschrieben?

Ja, über zehn Jahre lang. Es war ein Hobby, das daraus entstand, dass ich eine Leidenschaft für Spiele hatte und sie aus einer etwas anderen Perspektive betrachten konnte – sowohl technisch als auch in Bezug auf die Benutzererfahrung.

Und beschäftigst du dich heute noch mit Spielen?

Klar, ich spiele immer noch. Und manchmal verleitet es mich dazu zu denken: „Das kann ich doch.“ Aber ich passe inzwischen auf, weil ich weiß, dass das den ganzen Spielspaß ruinieren kann. Zum Beispiel in Spielen, in denen du ein Objekt greifen und bewegen kannst – wenn du dabei eine andere Tastenkombination drückst, dupliziert sich das Objekt. Solche Dinge können die Herausforderung zerstören. Und in Spielen wie Dark Souls ruiniert das komplett die Atmosphäre, wenn du es dir durch einen Exploit „leichter machst“.

Was ist das beste Spiel der letzten Zeit?

Elden Ring. Es ist ein RPG, hauptsächlich Singleplayer. Eine riesige offene Welt. Historisch gesehen halte ich Half-Life 2 für das beste. Das war ein Durchbruch, weil es die Physik in Spiele brachte. Die Interaktion mit der Umgebung war völlig anders. Heute hat das zum Beispiel Baldur’s Gate 3, deshalb ist es so erfolgreich.