Als Softwaretester*in bei Lean Ocean hat man die wichtige Aufgabe, dafür zu sorgen, dass neue Features funktionieren und Fehlerkorrekturen die Fehler wirklich reparieren. Auch als Werkstudent*in ist man dabei ein essentieller Teil des Teams und sehr wichtig für die Produktentwicklung.
ZEIT FÜR EIN STANDUP
Ein typischer Tag fängt mit dem Team-Standup an, immer um 9 Uhr morgens. Hier kommen alle Personen zusammen, die an der Entwicklung eines Produktes beteiligt sind – beispielsweise an AKEYI oder VALYN. Man tauscht sich darüber aus, woran man gerade arbeitet und wo genauere Infos benötigt werden. Diese Treffen sind für das Software-Testing besonders relevant: Hier erfährt man, wie weit die Tickets sind, die gerade bearbeitet werden.
Unsere Softwareentwicklung strukturieren wir in Tickets, die immer ein gewisses Feature oder einen Bug (Systemfehler) repräsentieren. Nachdem die Programmierung eines Tickets abgeschlossen ist, wird es teamintern gereviewt. Sieht alles gut aus, wird der Code vom Verantwortlichen in die Testumgebung ausgeliefert. Hierzu sind nur wenige Klicks notwendig, da wir ein sehr hohes Maß an Automatisierung haben.
JETZT GEHT’S ANS TESTEN!
Nach dem Standup widmet man sich den zu testenden Neuerungen. Darunter könnte ein sehr wichtiges Feature sein, worauf unsere Kunden schon ungeduldig warten! Wegen der hohen Priorität wird das zuerst getestet. Man schaut sich dazu zunächst an, was das Feature können sollte, also was im Ticket gefordert wird. Dabei ist das Mockup besonders wichtig. Was das ist? Das Mockup ist die Vorlage für die Funktion. Wie bei einer richtigen Web-App kann man hin und her klicken und sieht, was passieren soll, wenn man eine bestimmte Aktion tätigt. Ein Mockup kann allerdings nicht alles abdecken. Es sind die Feinheiten, die beim Software-Testing besonders wichtig sind. Dass die Funktionen grob funktionieren, davon geht man erstmal aus – trotzdem werden sie getestet.
Doch was passiert, wenn man in ein knappes Namen-Textfeld einen sehr langen Text eingibt? Führt das schon zu einem Systemfehler? Kann man -10 Kalender buchen? Das wäre ein bisschen doof, ungeachtet dessen, ob es ohne Fehlermeldung durchläuft oder ob eine riesige System-Fehlermeldung erscheint.
Wurden alle Randfälle bedacht? Oder wird eine kleine Komponente vielleicht noch an anderer Stelle genutzt, die während der Programmierung nicht bedacht wurde?
Auch die User Experience und das Design müssen stimmen. Sieht eine Ansicht komischerweise anders aus als andere? Ist die jetzige Implementierung der Funktion stimmig oder wird sich der Nutzer wundern?
All diese und noch viele weitere Fragen stellt man sich beim Testen.
WAS, WENN ETWAS NOCH NICHT SO FUNKTIONIERT, WIE ES SOLL?
Wenn einem auffällt, dass etwas vielleicht nicht ganz optimal ist, wendet man sich erstmal an die Programmierer*innen. Wurde hier bewusst etwas ausgelassen? Wurde einfach etwas übersehen? Nur in seltenen Fällen sind ganz große Änderungen notwendig, für die jemand aus dem Projektmanagement und Design dazu geholt werden sollten.
Wenn eine Funktion Fehler enthält, erstellt man im Ticket einfach einen Kommentar. So kann jeder, der sich für den Stand des Tickets interessiert, einfach reinschauen. Manchmal ist es aber einfacher, kurz mit den Programmierer*innen zu quatschen. Jetzt, zu Corona-Zeiten, ruft man einfach per Videocall an. Man bespricht dann, wo genau das Problem liegt und wie mit dem Ticket verfahren werden soll.
DATENBANKZUGRIFF – NÜTZLICH UND GEFÄHRLICH
Als Software-Tester*in lernt man mit der Zeit, ganz simpel in der Datenbank Änderungen vorzunehmen. Jeder Name, den man über eine Weboberfläche ändern kann, kann nämlich natürlich auch direkt über die Datenbank geändert werden. Dieser Shortcut ist sehr nützlich und man lernt ihn zu lieben.
Nachdem man eine Weile beim Testing mit der Datenbank zu tun hatte, kann es auch mal vorkommen, dass man in der Datenbank des Production-Systems Änderungen vornehmen soll. Das Production-System bezeichnet die Version der Web-App und Datenbank, die wirklich von den Kunden genutzt wird. Hier sollte man also Samthandschuhe tragen! Änderungen sind notwendig, wenn wir für Datensätze noch keine Verwaltungsoberfläche entwickelt haben. Zuerst einmal probiert man die Änderung im Testsystem aus, um sicherzustellen, dass man wirklich nichts kaputt machen wird. Dann kann man die Änderung im Production-System vornehmen.
KONTINUIERLICHE VERBESSERUNG
Es ist Mittag und du hast alle zu testenden Tickets entweder auf “Bereit fürs Production-System” gestellt oder zurück zur Überarbeitung an die Programmierer*innen gegeben. Tickets, die fertig sind, werden mit wenigen Klicks ins Production-System integriert. Die Vorteile von kontinuierlicher Integration und Auslieferung sind enorm, sprengen jedoch den Rahmen dieses Artikels. Man munkelt, dass genau darüber gerade eine Bachelorarbeit bei Lean Ocean geschrieben wird; Blogartikel wird folgen.
Natürlich kommen jetzt schon die ersten Tickets, die du zur Überarbeitung zurückgegeben hattest, wieder ins Testing. Im Optimalfall läuft nun alles picobello.
Irgendwann nachmittags ist absehbar, dass keine weiteren Tickets mehr zu testen sind. Und weil du bei dieser Sonne sowieso lieber am Kanal wärst, machst du heute früher Feierabend. Ciao!
