Seine Augen leuchten, wenn er über seine Arbeit im Testing spricht – mit einer Mischung aus Begeisterung und methodischem Ernst. Aron fühlt sich am DJ-Mischpult bei Live-Auftritten genauso wohl wie an der Computertastatur. Er weiss den Wert seines Teams zu schätzen, das treffend „Digital Experience“ heisst. Um seine Welt zu erklären, beginnt er bei Schritt 1 – den Definitionen.

QA vs. Testing

Während Testing und Qualitätssicherung (Quality Assurance, QA) oft synonym verwendet werden, liegt der Fokus von QA auf der Schaffung und Pflege eines zuverlässigen Systems zur Gewährleistung hochwertiger Ergebnisse. Testing hingegen beschäftigt sich mit dem Finden und Beheben von Fehlern im Code. Ziel des Testings ist es, sicherzustellen, dass der Code wie beabsichtigt funktioniert und die Anforderungen erfüllt.

Zusammengefasst: Qualitätssicherung ist das übergeordnete Konzept, bei dem Tests als tragende Säulen fungieren. Der Fokus von Open Systems liegt auf der End-to-End-Qualitätssicherung der gesamten SASE-Technologie, selbst bei Codeänderungen während Updates oder Patches.

QA im Open Systems Customer Portal

Die Ingenieure des Digital Experience-Teams, die für das Testen neuer Portalfunktionen verantwortlich sind, tragen bei Open Systems eine grosse Verantwortung. Das ist Teil ihres Jobs. Denn alles muss getestet werden – und das Team hat es sich zur Aufgabe gemacht, Kollegen aus den Bereichen Netzwerk und Sicherheit zu unterstützen, statt selbst zum Engpass zu werden.

Eine nahtlose Erfahrung für Nutzer und Entwickler wird durch End-to-End-Qualitätssicherung gewährleistet – ein absolutes Muss, da der SASE Service von Open Systems auf End-to-End-Betriebsabläufen basiert, nicht auf einer Ansammlung von Einzellösungen. Mit den entwickelten Services arbeiten Entwickler selbst in der Praxis und verbringen etwa 20 Prozent ihrer Zeit mit Anrufen im Customer Support von Mission Control. So erleben sie ihren Code hautnah, erhalten wertvolles Feedback und finden reale Lösungen für reale Probleme.

Nahtlos

Klingt gut und wird in der IT of genutzt. Aber was bedeutet es konkret? Das Cambridge Dictionary definiert „nahtlos“ als „ohne plötzliche Änderungen, Unterbrechungen oder Schwierigkeiten“. Es impliziert Kontinuität, Konsistenz und Zugänglichkeit. Mit anderen Worten: Eine nahtlose Erfahrung ist intuitiv und befriedigend.

Nahtlos: ohne plötzliche Änderungen, Unterbrechungen oder Schwierigkeiten.

Werfen wir einen Blick auf das Customer Portal als Beispiel für User Interface (UI)-Testing.

Seite „Inventar“ im Customer Portal.

Abbildung 1: Seite „Inventar“ im Customer Portal.

Das Customer Portal – oft als „Single Pane of Glass“ bezeichnet – ist die wichtigste Anlaufstelle für Kunden. Es bietet Transparenz über Netzwerke und Anwendungen und ermöglicht präzise Kommunikation mit dem 24x7 Operations Center. Das Portal bietet Berichte und Tools für Support, Implementierung und Verwaltung der globalen IT-Sicherheit und Verfügbarkeit. Es umfasst ein Ticketsystem, Statistiken zur Performance von Anwendungen, Netzwerken und Geräten, Anzeige von Protokollen, Konfigurationsdetails und Übersichten sowie Self-Service-Funktionen. Die grösste Herausforderung des Digital Experience-Teams besteht darin, End-to-End-Tests in hoher Qualität sicherzustellen und gleichzeitig neue Portalfunktionen schnell und skalierbar umzusetzen.

Testing 101

Testing ist eine komplexe Aufgabe – nicht nur wegen der schieren Anzahl an Tests, sondern auch wegen der Notwendigkeit, die Ergebnisse im Blick zu behalten, Abhängigkeiten zu verstehen und zu wissen, welche Tests bereits durchgeführt wurden und welche noch ausstehen. Hinzu kommt das Reporting, das anderen Teams Transparenz bieten soll.

Für eine effiziente und effektive Qualitätssicherung ist eine klare Struktur erforderlich. Man kann sie sich wie eine Pyramide vorstellen: Die Basis bilden Unit-Tests – zahlreich und schnell auszuführen. Darauf folgen weniger, aber komplexere Komponententests. An der Spitze der Pyramide stehen die End-to-End-Tests (E2E), die am seltensten und zugleich am anspruchsvollsten sind und zudem mehr Rechenleistung erfordern.

Eine Testpyramide veranschaulicht die relative Anzahl und Geschwindigkeit der verschiedenen Testarten.
Abbildung 2: Eine Testpyramide veranschaulicht die relative Anzahl und Geschwindigkeit der verschiedenen Testarten.

Testing ist unverzichtbar

Bevor wir uns dem „Wie“ widmen, sei das „Warum“ betont:

Testing ist keine Option – es ist eine Notwendigkeit

Das Ziel der Ingenieure ist ein pflegeleichter und erweiterbarer Code, der sicher verändert (refactored) werden kann.[1].

So lassen sich Produktionsprobleme vermeiden, und Codeänderungen werden sicherer und angenehmer.

Eine Testing-Kultur zu pflegen bedeutet, Software so zu entwerfen, dass Sie Tests einfach schreiben können. Grosse Funktionen sind schwer zu testen, daher ist es sinnvoll, sie in kleinere, überschaubare Einheiten aufzuteilen.

Dieser Ansatz wird als Continous Integration (CI) bezeichnet. Dabei werden inkrementelle, häufige Änderungen routiniert in den vollständigen Code integriert, um diese unmittelbar zu testen und zu validieren.

Portal-Bestandteile fürs Testing

Im Customer Portal stellt die kleinste Einheit einer Webseite – etwa ein Link oder ein Icon – eine Unit dar.

Zusammenhang zwischen einzelnen Bestandteilen einer Customer-Portal-Seite mit Testing
Abbildung 3: Zusammenhang zwischen einzelnen Bestandteilen einer Customer-Portal-Seite mit Testing

Eine Komponente ist eine Ansammlung von Units, jedoch immer noch ein kleiner Bestandteil einer Webseite – beispielsweise ein Listeneintrag, der den Servicenamen, den Standort und den Status der bereitgestellten Service-Delivery-Plattform anzeigt. Dies ist ein Kandidat für einen Komponententest.

Die gesamte Webseite , inklusive URL, ist in der Regel Gegenstand eines End-to-End-Tests.

Wie wird getestet?

Die Pyramide aus Unit-, Komponenten- und End-to-End-Tests ist bei Open Systems ein zentraler Ansatz. Zudem hängt die Installation von Releases und Patches von den Umgebungen der Kunden ab. Sie haben die Wahl, frühzeitig als Early Adopter einzusteigen und wertvolles Nutzerfeedback aus der Praxis zu liefern, das zur Weiterentwicklung der Servicefunktionen dient. Alternativ können sie auf die allgemeine Verfügbarkeit (GA-Release) warten oder als Late Adopter agieren, insbesondere wenn kritische Systeme aufrechterhalten werden müssen.

Unit-Tests – immer durchführen

Unit-Tests prüfen isolierte Funktionalitäten oder Methoden. Mit anderen Worten: Die Ingenieure konzentrieren sich auf einzelne Komponenten und testen diese, ohne auf das restliche System angewiesen zu sein.

Ein Unit-Test bezieht sich speziell auf eine einzelne Codeeinheit, was bedeutet, dass er unabhängig von anderen Codeeinheiten (oder Services) sein muss. Im Gegensatz zu anderen Tests, die mehrere Units abdecken können, prüft der Unit-Test, ob die betreffende Unit wie gewünscht funktioniert – und nicht, wie eine Unit in Zusammenarbeit mit anderen Units funktioniert. Es kann vorkommen, dass der Code seine Unit-Tests besteht, weil er auf Mikroebene das „richtige“ tut, jedoch auf Makroebene möglicherweise nicht den Anforderungen entspricht.

F.I.R.S.T.-Prinzipien

Die Prinzipien von Unit-Tests folgen dem F.I.R.S.T.-Ansatz:

  • Fast: Unit-Tests müssen schnell sein, da es Tausende pro Projekt geben kann.
  • Isolated or independent: Ein Unit-Test muss in sich geschlossen sein und darf nicht von anderen Tests abhängig sein. Er muss dem Prinzip „Arrange, Act, Assert“ folgen.
    • Arrange: Bereiten Sie die im Test verwendeten Daten für den Test vor. Sie beschreiben die Voraussetzungen vor Beginn des Tests.
    • Act: Führen Sie den Test durch.
    • Assert: Legen Sie das erwartete Ergebnis fest.
  • Repeatable: Unabhängig davon, wie oft oder wo Sie den Test durchführen, muss das Ergebnis immer gleich sein.
  • Self-validating: Ein Test muss ein eindeutiges Ergebnis liefern („Ja“ oder „Nein“, niemals „Vielleicht“)
  • Timely and thorough: Typischerweise werden Code und zugehörige Tests zeitnah erstellt, sodass Entwickler die Feinheiten des Codes vollständig berücksichtigen können. Der Code muss unmittelbar nach seiner Erstellung getestet werden. Jeder Anwendungsfall, einschliesslich Edge Cases, sollte abgedeckt sein, um Einblicke in die Grenzen der User Experience zu gewinnen.

Beispiel

Stellen wir uns vor, wir sind im Bereich der Lkw-Beladung und möchten eine Funktion testen, die Kisten hinzufügt:

Funktion Kiste hinzufügen Arrange

Daten vorbereiten

Act (Test durchführen) Assert

Erwarteten Wert festlegen

 

A + B = C

 

Eingabe A = 1

Eingabe B = 2

 

Kiste hinzufügen(1 + 2)

 

C = 3

 

Für Edge Cases müssen wir auch testen: Was passiert, wenn A = 0 und B = –2?

Diese Szenarien zeigen oft potenzielle Probleme auf, die in Zukunft auftreten könnten.

Regressionstests

Um Serviceunterbrechungen zu vermeiden, legt das Digital Experience-Team grossen Wert auf Regressionstests. Diese stellen sicher, dass neue Codeänderungen die bestehende Funktionalität nicht beeinträchtigen.

Open Systems verwendet das Tool Jest, das für seine Geschwindigkeit und einfache Einrichtung bekannt ist. Heutzutage sind visuelle Regressionstests möglich und äußerst nützlich, um die visuellen Aspekte des Customer Portals zu überprüfen. Sie gewährleisten, dass Nutzer weiterhin eine hochwertige Erfahrung geniessen und das UX-Team in den Entwicklungsprozess eingebunden bleibt.

Der Zweck von Jest besteht darin, komplexe Funktionen mit reiner Logik zu validieren. Hier sind einige Richtlinien, die die Ingenieure bei Open Systems für das Schreiben solcher Tests verwenden:

  • Schreiben Sie Jest-Tests für verschiedene Szenarien.
  • Führen Sie Regressionstests durch, um Ihren Code während der Entwicklung kontinuierlich zu validieren.
  • Priorisieren Sie das Schreiben von Jest-Tests, wann immer dies möglich ist, da sie schnell sind und nur minimalen Aufwand erfordern.
  • Priorisieren Sie das Auslagern von Logik in dedizierte Funktionen, die auf diese Weise getestet werden können.

Komponententests – regelmässig durchführen

Die Isolierung und das Testing von Komponenten für das Kundenportal wird bei Open Systems mit Cypress durchgeführt, einschliesslich Screenshot-Vergleichen. Dies ermöglicht es den Ingenieuren, Komponenten isoliert zu testen und sicherzustellen, dass diese (die Komponenten) mit unterschiedlichen Eigenschaften (Props) und Zuständen korrekt funktionieren. Bei dieser Art des Testings ist es besonders wichtig, nicht mit Code ausserhalb der Komponente zu interagieren. Aus diesem Grund ist es notwendig, „Fake-Objekte“ wie simulierte Props und Zustände zu erstellen.

Isolierte Komponententests mit Cypress

Der Zweck von Cypress besteht darin, sicherzustellen, dass Komponenten und ihre Varianten testbar sind und korrekt funktionieren. Richtlinien für Komponententests bei Open Systems:

  • Verwenden Sie Cypress-Komponententests für isolierte Komponenten.
  • Entwickeln Sie Komponenten mit Props, um eine einfache Manipulation zu ermöglichen.
  • Streben Sie stateless Komponenten an, indem Sie die Nutzung von Hooks und Kontexten vermeiden.
  • Halten Sie Logik für Datenabruf ausserhalb der Komponente; verarbeiten Sie innerhalb der Komponente nur Props.
  • Nutzen Sie Screenshots sparsam zur Validierung von Designs; greifen Sie stattdessen auf andere, weniger ressourcenintensive Assertions von Cypress zurück.
  • Globale Schwellenwerteinstellungen: reichen normalerweise aus, könnten jedoch bei Änderungen an Screenshots überprüft werden.

E2E-Tests – selektiv ausführen

End-to-End-Tests simulieren reale Nutzerinteraktionen und schaffen Vertrauen, dass die Anwendung in realen Szenarien wie erwartet funktioniert. Diese Tests sind besonders wichtig für externe Elemente wie URL-Parsing, Datumssimulation, Link-Validierung und Navigation. Aufgrund ihrer Komplexität und Laufzeit sollten E2E-Tests sparsam verwendet werden. Daher liegt der Fokus darauf, gründliche Tests auf Ebene der Unit- und Komponententests durchzuführen, bevor E2E-Tests zum Einsatz kommen.

Richtlinien für E2E-Tests bei Open Systems:

  • Begrenzen Sie E2E-Tests auf eine Testinstanz pro Seite, um den Aufwand zu minimieren und sich auf höherwertige Interaktionen zu konzentrieren.
  • Verwenden Sie Cypress-E2E-Tests, um eine Seite zu besuchen und spezifische Verhaltensweisen wie Laden, Vorhandensein von Komponenten, URL-Validierung und Nutzerinteraktionen zu testen.
  • Stellen Sie sicher, dass die Ansicht nach dem Abrufen und Manipulieren von Daten korrekt funktioniert.
  • Verwenden Sie TypeScript-Datenquellen (Fixtures), um häufige Änderungen an Datenstrukturen zu berücksichtigen.
  • Mocken Sie globale Daten nur, wenn diese auf jeder Seite verwendet werden. Andernfalls mocken Sie nur seitenbezogene Daten.
  • Kategorisieren Sie verschiedene Varianten einer Ansicht in spezifische Testtypen wie Komponenten- oder Unit-Tests, um die Skalierbarkeit der Test-Suite sicherzustellen.

Fehlgeschlagene Tests – Produktion schützen

Das zentrale Konzept zur Qualitätssicherung besteht darin, Software so zu entwickeln, damit Tests einfach geschrieben werden können. Es lohnt sich, die Grundlagen wie Logikfluss, Kosten und User Experience korrekt umzusetzen. Dies bedeutet, Unit-Tests Priorität einzuräumen. Der Fokus auf ein „molekulares Konzept“, bei dem so viele stateless Komponenten wie möglich entwickelt werden, stellt sicher, dass alles auf individueller Ebene getestet wird und der Bedarf an ressourcenintensiven End-to-End-Tests reduziert wird.

Jede Entwicklungsumgebung ist so einzigartig wie jede Geschäftsumgebung. Dieses Gleichgewicht gilt auch für die Qualitätssicherung, bei der das Testsetup von der Reife des Codes und der Entwicklungsgeschwindigkeit abhängt.

Die Ingenieure bei Open Systems versuchen bewusst, das Tests „fehlschlagen“. Denn fehlgeschlagene Tests schützen die Produktion. Und die Ingenieure ziehen es vor, dass Tests fehlschlagen, anstatt dass die Produktion versagt.

[1] refactoring = Umstrukturierung von Code mit dem Ziel, ihn durch viele kleine Änderungen zu verbessern, ohne seine ursprüngliche, beabsichtigte Funktionalität zu verändern.