In der Softwareentwicklung hat es sich schon lange etabliert, zwischen Frontend-, Backend- und Fullstack-Entwicklern zu unterscheiden – anders bei Testern. Ein Blick in gängige Jobbörsen zeigt, dass Unternehmen im Wesentlichen zwischen Softwaretestern, Testautomatisierern, Testanalysten und Testmanagern unterscheiden. In vielen Fällen sind die Stellenbeschreibungen schwammig, die Tätigkeitsbeschreibungen überschneiden sich. Doch gerade für Testautomatisierer und Softwaretester bedeutet es einen wesentlichen Unterschied, ob diese im Frontend, im Backend oder in beiden Bereichen arbeiten.
In diesem Artikel schildere ich, inwiefern sich die Arbeit des Testers im Frontend und Backend unterscheidet. Ich schildere, auf welche Herausforderungen der Tester im Frontend und Backend trifft und welche Fähigkeiten er benötigt. Die Darstellung erfolgt subjektiv und basiert vorwiegend auf meinen Erfahrungen, die ich in agilen Entwicklungsteams in der Webentwicklung gesammelt habe.
Testen im Frontend
Wer als Softwaretester anfängt, macht das meistens im Frontend. So war es auch bei mir. Eine übliche User Story beschreibt abstrakt, wie sich die Benutzeroberfläche einer Anwendung bzw. Website verändern soll oder wie neue Komponenten erscheinen sollen. Meist ist eine solche Story angereichert mit Designs, Wireframes oder Screenshots. Je nach Vorarbeit steht das Design so fest, dass ein Prototyp pixelgenau zeigt, wie die Anwendung später auszusehen hat. Für den Tester macht es das recht einfach: Er muss Neuentwicklungen gegen diese Anforderungen prüfen und testet idealerweise auch, wie sich die Software in Grenzbereichen, unter verschiedenen Systemen (z. B. Betriebssysteme oder Browser) oder im Fehlerfall verhält. Kennt er das Projekt bereits, kann er durch Regressionstests feststellen, ob ältere Komponenten und Features auch weiterhin funktionieren.
Manuelles Testen im Frontend
Um das Frontend manuell auf Herz und Nieren zu testen, sind ein Auge für’s Detail, Geduld und Fleiß gefragt. Die technischen Hürden sind eher gering und selbst Backend-Anbindungen lassen sich über das Frontend testen. Letztlich bewegt sich der Tester eben entlang der Benutzerschnittstelle. Und die ist im Idealfall selbsterklärend.
Gleichzeitig hat der Tester mit nicht-funktionalen Anforderungen zu kämpfen: Ist die GUI stimmig, intuitiv, verständlich und nutzerfreundlich? Themen wie Barrierefreiheit können relevant sein. Hinzu kommt, dass ein einmal aufgetretener Fehler nicht immer leicht zu reproduzieren ist. Ich erinnere mich an viele Diskussionen mit Entwicklern, die einem Fehler erst dann nachgehen wollten, wenn sie ihn selbst erwirken konnten. Hier sieht der Entwickler die Beweislast beim Tester: Screenshots, Screenrecordings und detaillierte Beschreibung zur Reproduzierbarkeit werden erwartet.
Das Frontend automatisiert testen
Im Frontend übernimmt der Tester üblicherweise je nach Projekt-Struktur die UI- und/oder End-2-End-Tests. Die hierzu einsetzbaren Technologien unterscheiden sich nicht. Gängige Tools für die programmatische Testautomatisierung des Frontends sind zum Beispiel Selenium und Cypress. Manche Unternehmen setzen auf GUI-basierte Testautomatisierungstools wie Tosca oder Katalon Studio, die kaum oder keine Programmierkenntnisse erfordern. Das Ziel automatisierter Frontend-Tests ist es, funktionale Anforderungen der Anwendung zu testen. Nicht-funktionale Anforderungen zu Design, UX oder Usability muss der Tester manuell testen.
Testen im Backend
User Stories im Backend sind wesentlich abstrakter und meist dem endgültigen Anwendungsfall ferner. Ein Beispiel: Während das Frontend immer etwas abbildet, was irgendwann mal ein Mensch sehen und/oder verwenden wird, dient das Backend oftmals dafür, Schnittstellen bereitzustellen, die andere Systeme oder Services abfragen bzw. konsumieren. Dabei ist nicht grundsätzlich gegeben, dass ein Mensch diese Funktionalitäten selbst verwenden wird, sondern dies im Hintergrund durch die Anwendung geschieht.
Manuelles Testen im Backend
Für den Tester bedeutet das Folgendes: Um ein Backend zu testen, ohne das Frontend zu verwenden, muss er in der Regel Requests an eine API senden. Anschließend prüft er, ob die jeweilige Response der erwarteten Response entspricht. Dies geschieht zum Beispiel über einen API-Client wie Postman. Da eine Response oft lediglich ein Status-Code ist, der dem Tester sowas sagt wie 200 OK oder 404 not found, muss der Tester zusätzlich die Logs des Service heranziehen.
Neben der Weiterentwicklung von APIs wird im Backend oft an Datenbanken gearbeitet. Für einen Tester reicht ein Grundwissen zu SQL (bzw. der jeweiligen Datenbanksprache), um zu testen, ob die richtigen Daten in den richtigen Fällen in der Datenbank abgelegt werden. Zudem kann er prüfen, ob Regeln für die Datenbank, z. B. ein not null constraint, korrekt implementiert wurden.
Automatisiertes Testen im Backend
Anders als im Frontend werden im Backend üblicherweise keine End-2-End-Tests implementiert. Stattdessen lässt sich das Backend umfangreich durch Unit-Tests testen. Ergänzend hierzu kann (und sollte) das Team Integrationstests implementieren, um die Business-Logik zu testen. Je nach Team- und Projektstruktur übernehmen im Backend die Entwickler nicht nur die Unit- sondern auch die Integrationstests.
Als technisch versierter Tester ist es sinnvoll, die Integrationstests selbst zu schreiben. Anders als der Entwickler identifiziert er die Testfälle unvoreingenommen und beschränkt sich bei den Testdaten nicht auf das Offensichtliche.
Ist der Tester weniger technisch versiert, sollte er die Integrationstests zumindest auf Vollständigkeit sowie Redundanz prüfen und die Entwickler bei der Auswahl geeigneter Testdaten zu unterstützen.
Ergänzend ermöglichen API-Clients wie Postman, API-Tests zu schreiben, um insbesondere einfache Regressionstests zu automatisieren.
Mein Fazit nach 7 Monaten Backend-Testing
Für den Einstieg in ein Projekt, ist die Arbeit im Frontend komfortabler. Es ist einfacher, die Software kennenzulernen, Anwendungsfälle zu verstehen und sich in den Nutzer hineinversetzen zu können. Dafür ist es sehr zeitaufwändig, Logik der Software zu testen, die aus dem Backend stammt. Zudem kann es den Tester auf Dauer langweilen, immer und immer wieder dieselbe GUI zu verwenden. Dies ist vor allem bei manuellen Regressionstests der Fall. Insbesondere deshalb ist eine solide Testabdeckung mit automatisierten End-2-End Tests wertvoll.
Auch wenn der Start ins Backend herausfordernd ist, lohnt sich der erste Schmerz. Der Tester taucht schnell tiefer in die technischen Finessen der Software ein und ist dazu gezwungen, die Prozesse und Architektur der Anwendung zu verstehen. Ist diese Hürde genommen, macht das manuelle Testen des Backends insofern viel Spaß, als dass der Diskussionsbedarf darüber, was richtig, was falsch, was gut oder was schlecht ist, deutlich kleiner ist. Soll ein Endpunkt in einem Szenario den Code 200 zurückgeben und tut dies, ist der Testfall erfolgreich. Nachträglich über das Design der Implementierung zu diskutieren, ist eher unwahrscheinlich. Im Frontend hingegen habe ich genau das sehr oft erlebt: Gerade dann, wenn ein Feature fertig ist, wird gerne noch mal über Design und UX diskutiert. Visuelles ist eben sehr subjektiv.
Abschließende Worte
Als Tester wünsche ich mir, mit allen Fassaden einer Anwendung in Berührung zu kommen. Sich mit dem Frontend auseinanderzusetzen hilft dabei, eine bessere Vorstellung von dem Endprodukt zu bekommen. Das Backend zu verstehen und zu testen, eröffnet einen tiefen Blick hinter die Fassade. Bietet sich mir die Chance, beides zumindest zu Teilen abzudecken, ist die Abwechslung am größten und das Verständnis über sinnvolle und notwendige Testfälle nimmt zu.
Hinterlasse eine Antwort