IT-Konferenz für Software-Entwicklung, -Architektur, KI, Datenbanken, DevOps, Agile und Management
API-Testing: Mist, schon wieder fehlgeschlagen?
Talk mit Sonja Wegner
Der Traum von den unendlichen Weiten der Daten ist schnell ausgeträumt, wenn wir unsere APIs nicht im Griff haben. Dabei ist es egal, ob wir uns APIs zwischen unseren Services, zwischen Frontend und Backend oder zu Fremdsystemen anschauen – ohne Testautomatisierung geht gar nichts. Schlecht geschriebene Integrationstests mit selbst erfundenen Testfällen für unsere APIs können richtig nerven: Wir rufen die APIs auf und hoffen, dass genau das zurückkommt, was wir erwarten. Das geht auch anders:
Wir werfen einen Blick auf andere Testansätze und schauen zum Beispiel auf
- Contract Based Testing
- Black Box Testing der OpenAPI Spec
- Trace-basiertes Testing
Zusätzlich schauen wir kritisch auf’s Test-Setup: Wo brauchen wir Mocks oder Stubs, wo echte Daten? Und wie setzen wir die endlich einfach auf?
Die Rollen und insbesondere deren Zuständigkeiten sind in Scrum recht klar geregelt: Der Product Owner sorgt für das „Was“, der Scrum Master für das „Wie“ und die Developer für die eigentliche Umsetzung. Solange es sich dabei um ein internes Projekt mit einem komplett internen Team handelt, sind damit bereits die zentralen Fragen beantwortet. Ein wenig differenzierter zu betrachten sind allerdings Teams mit mehreren Parteien wie etwa beim Einsatz von Dienstleistern. Muss etwa zwingend der Kunde den Product Owner stellen oder kann dieser auch auf der Seite des Dienstleisters stehen? Falls alle Developer vom gleichen Dienstleister bereitgestellt werden, würde diese Konstellation sicherlich einige Kommunikationswege verkürzen. Allerdings hat ein Product Owner auf der Seite eines Dienstleisters sicher nicht die gleichen Verbindungen zu den Stakeholdern (Nutzer, Geldgeber, …) des Produkts wie ein interner Product Owner – wie also könnte er ihre Anforderungen dann gut vor dem Team vertreten? Ähnliche Fragen stellen sich auch für den Scrum Master und das Development-Team. In den meisten Fällen gibt es für verschiedene Konstellationen jeweils Vor- und Nachteile – und zwar sowohl für den Kunden als auch für den Dienstleister. Wichtig bei der Entscheidung für eine dieser Konstellationen ist außerdem die Art des Projekts, der Kreis der Stakeholder, das zur Verfügung stehende Budget, der Zeitrahmen und noch einiges mehr.
Dieser Vortrag beleuchtet verschiedene dieser Varianten und zeigt Vorteile, Nachteile und Risiken auf.
