Was macht eigentlich ein Softwaretester?

Es folgt eine Auflistung von Schlagzeilen, die aufgrund von Softwarefehlern zustande gekommen sind. Manche davon mögen lustig oder seltsam sein, aber wenn es um Menschenleben geht, hört der Spaß auf.

• Falscher Fahrpreis sorgte für Ansturm auf Ticketautomaten - 2,07 EUR statt 207 EUR
• Softwarefehler legt die Kassen lahm
• Boeing 737 MAX: Softwarefehler für Absturzserie verantwortlich
• 6h lang kein Notruf in Amerika

Aber wie verhindert man eigentlich, dass es überhaupt so weit kommt?

Software ist vom Menschen gemacht. Wir Menschen sind nicht perfekt. Darum kann auch Software nicht perfekt sein. Keine Software wird ohne Fehler ausgeliefert.Es geht aber darum, die Anzahl der Fehler möglichst gering zu halten. Dafür sind Testengineers und Testmanager zuständig.

Welche Möglichkeiten gibt es eigentlich zu testen?

Blackbox-Tests

Stell dir vor, du stehst vor einem Automaten, wirfst eine Münze ein und am Ende kommt ein Schokoriegel heraus. Was in der Zwischenzeit passiert, siehst du nicht. Am Ende zählt das Ergebnis: Du hast Schokolade!

So ähnlich funktionieren auch Blackbox Tests. Wenn ich einen Test dieser Art durchführe, weiß ich nicht, was genau im Inneren des Programms passiert, aber ich weiß, was am Ende als Ergebnis herauskommen soll. Denn das Ergebnis, bzw. die unterschiedlichen Ergebnisse wurden vorher festgelegt. Sie werden auch Akzeptanzkriterien genannt.

Damit wir einen neuen Automaten, bzw. neue Software unter die Leute bringen dürfen, müssen alle Akzeptanzkriterien erfüllt sein. Akzeptanzkriterien können alles Mögliche sein: gewünschtes Aussehen, gewünschte Funktionen, gewünschtes Verhalten im Fehlerfall, usw. Apropos Fehlerfall, was passiert, wenn …

• … ich einen Knopf ins Münzfach werfen?
• … ich soviel Münzgeld ins Fach werfe, dass der Automat keines mehr annehmen kann?
• … der Automat kein Wechselgeld mehr hat?

Das sind unterschiedliche Szenarien, die ich durchdenken muss, damit, wenn das schon mit dem Schokoriegel nicht funktionieren sollte, du zumindest dein Geld zurückbekommst. Dabei handelt es sich um sogenannte Fehler- oder Grenzwerttests.

Ich überprüfe also, ob ein System die Funktionsweise hat, die vorher von unseren Projektmanagern definiert wurde.

Whitebox-Tests

Der Whitebox-Test ist das genaue Gegenteil zur Black Box. Hier will ich es ganz genau wissen. Stell dir vor, du stehst wieder vor dem Schokoladen-Automaten. Aber dieses Mal sind alle Bauteile aus Glas. Du siehst ganz genau, wo die Münze langläuft, wie der Auswahlknopf gedrückt wird und ein Schokoriegel aus dem Fach fällt.

Der Whitebox-Test kann nur von Leuten durchgeführt werden, die Ahnung vom Automaten oder im Falle von Software,9 dem geschriebenen Code haben.

Explorativer Test

Explorative Tests kann theoretisch jeder durchführen. Sie sind meine liebste Testmethode. Dabei testest du ein Programm anhand eines "Reiseführers". Dieser Reiseführer gibt verschiedene Szenarien vor,die du durchspielen sollst.

Nehmen wir die Codecamp-Internetseite als Beispiel. Ein mögliches Szenario wäre, in die Rolle eines Bewerbers zu schlüpfen und das zu tun, was er tun würde. Du würdest dich wahrscheinlich erst ein bisschen informieren wollen, klickst dich durch die Homepage und am Ende wirst du, hoffentlich, den "Bewerben" Button klicken und eine Bewerbung abschicken.

Hierbei kommt es nicht nur darauf an, Fehler auf der Seite zu finden, sondern auch festzustellen, ob alles gut benutzbar ist. (Mehr dazu dann in diesem Blogpost)

So sieht mein Arbeitsalltag aus

Im Normalfall fängt mein Tag damit an, dass ich mir die automatisierten Regressionstestsanschaue. Das heißt, ich schaue mir die Ergebnisse von Tests an, die jeden Morgen durchgeführt werden. Dazu erhalte ich automatisiert eine Übersicht über Fehler, die nach dem letzten Update aufgekommen sind.

Wenn mir auffällt, dass etwas nicht richtig funktioniert, versuche ich den Fehler nachzustellen und kontaktiere dann die zuständigen Entwicklerteams, um mit ihnen zu besprechen, wie wir weiter vorgehen.

Danach setze ich mich häufig selbst an die Testautomatisierung. Dabei erstelle ich auf Softwareebene Tests, die dann automatisch ausgeführt werden.

Wir haben dafür eine eigens entwickelte Software, mit deren Hilfe ich das umsetzen kann. Ein automatisierter Test könnte z.B. so aussehen:

Klicke in das Textfeld > Gebe in das Textfeld „Test“ ein > Drücke auf „Abschicken“.

Das Tool führt genau diese Befehle aus. Wenn unterschiedliche Testfälle einmal erstellt sind, muss ich sie nur anpassen, wenn sich etwas an der Software ändert.

Wir tauschen uns auch regelmäßig untereinander zu neuen Features in unserem Testautomatisierungstool, Neuigkeiten vom Testmanagement und Anforderungen der Product Owner aus.

Als Tester brauche ich immer einen Überblick darüber, was andere Entwicklerteams im Projekt gerade bearbeiten oder abgeschlossen haben. Das ist vor allem für die Testautomatisierung wichtig, damit ich diese an die neuen Gegebenheiten anpassen kann.

Auch unser Testautomatisierungstool wird immer weiterentwickelt. Mit dem Team, das sich darum kümmert, stehe ich regelmäßig im Austausch.

Zuletzt kontrolliere ich, ob sich etwas an unseren Bugtickets geändert hat. Bugtickets sind Fehler in der Software, für den wir in unserem Ticketsystem ein Ticket angelegt haben.

So behalten wir stets den Überblick über alle Vorgänge. Wenn die Entwickler einen Bug (Fehler) behoben haben, kontrolliere ich, ob die Umsetzung korrekt war, oder ob sich vielleicht durch die Behebung des Bugs ein neuer Fehler eingeschlichen hat.

Funfact: Weißt du eigentlich, warum der Bug „Bug“ heißt? Der Begriff geht auf Grace Hopper, eine Computerpionieren, zurück. Eine Motte verursachte 1945 eine Störung in einem der ersten Computer. Die Motte überlebte den von ihr selbst verursachten Fehler leider nicht, wurde aber in das Notizbuch von Grace Hopper eingeklebt, mit dem Hinweis darunter:“First actual case of bug being found.” (Das Erste mal das tatsächlich ein “Ungeziefer” gefunden wurde”).

Dass wir den Begriff auch im Deutschen verwenden, hat u.a. psychologische Gründe. Bug klingt weniger negativ als “Fehler”, Wer kann einem schon Böse sein, wenn man einen kleinen Bug findet. Das der Fehler die ganze Produktion lahm legen kann, muss niemand Wissen😉

Zu meinen Aufgaben gehört es außerdem Stories, die wir im Team umgesetzt haben, abzunehmen. Wir überlegen uns, bevor wir eine neue Arbeit anfangen, gemeinsam was umgesetzt werden soll, das wird Story genannt. Die Entwickler setzen dann diesen Vorgang um.

Ich schaue mir dann die Umsetzung an und gebe Rückmeldung, ob die Story ordentlich bearbeitet wurde, oder ob nachgebessert werden muss. So können wir schon die gröbsten Fehler gleich am Anfang verhindern.

Meine Aufgaben als Test-Engineer bleiben auch weiterhin spannend

Meine Aufgabe als Test-Engineer macht mir großen Spaß. Ich erhalte dabei unterschiedliche Einblicke in die Software, an der wir gerade arbeiten. Dabei versuche ich eine Balancezwischen Kunden, Entwicklerteams und der notwendigen Sicherheit zu finden. Und manchmal versuche ich einfach nur die Software kaputtzumachen. Aus Testgründen natürlich 😉. Viele neue Themen stellen uns Softwaretester allerdings vor Herausforderungen. Zum Beispiel Künstliche Intelligenz oder Virtual Reality. Daher ist es wichtig weiter am Ball zu bleiben und sich bezüglich der neuen technischen Anforderungen weiterzubilden. Denn nur so kann ich als Tester für die Nutzer eine Software zur Verfügung stellen, die sicher und gut zu bedienen ist.