QA und Testen

Wir integrieren Tests in den frühesten Phasen. Wenn der Architekt Module entwirft - legt er die Testbarkeit fest. Wenn der Entwickler Code schreibt - schreibt er sofort auch die Tests. Wenn die QA die Aufgabe erhält - kennt sie den Kontext, die Architektur und die Ziele.

Der Einstiegspunkt der QA ist nicht das Code-Review, sondern die Aufgabenstellung. Das reduziert die Anzahl der Bugs und beschleunigt die Behebung von Fehlern.

Wir gestalten den Prozess so, dass jede Phase logisch an die vorherige anschließt und wichtige Aspekte des Systems überprüft.

Zuerst deckt der Entwickler die zentrale Geschäftslogik mit Unit-Tests ab. Diese Tests sind schnell und decken die Schlüsselberechnungen und Regeln ab. Danach werden Integrationsprüfungen durchgeführt – sie helfen zu überprüfen, ob der Dienst korrekt mit der Datenbank, den Warteschlangen und externen APIs interagiert.

Anschließend wird eine manuelle Überprüfung hinzugezogen. Der QA-Spezialist prüft die Schnittstellen, das Verhalten in Browsern und komplexe Fälle, in denen Automatisierung möglicherweise ineffektiv sein könnte. Danach folgt die Regression – das erneute Testen zuvor funktionierender Szenarien. In der Pre-Release-Phase stellen wir sicher, dass Updates die Kompatibilität nicht beeinträchtigen und das System Belastungen standhält.

Nach der Veröffentlichung werden Monitoring-Tools aktiviert: wir überwachen die Protokolle, Fehler und Metriken, um rechtzeitig zu reagieren, falls etwas schiefgeht.

Jede Änderung im Code löst eine Kette von Prüfungen aus. Zuerst werden die Tests ausgeführt: Unit-Tests, Integrations- und e2e-Tests. Dann werden Linter und statische Analysen hinzugezogen, um sicherzustellen, dass der Code den Standards des Teams entspricht. Danach vergleichen die Frontend-Bauten und Regressionstests die Ergebnisse mit früheren Versionen.

Wenn alles erfolgreich ist, kann der Code gemergt werden. Wenn nicht, stoppt CI. Dies schließt das Einpflegen von nicht funktionalen Änderungen in die Produktion aus und beschleunigt das Debugging.

Wir verwenden verschiedene Arten von Tests, von denen jeder für seine eigene Zuverlässigkeitsstufe verantwortlich ist.

Unit-Tests überprüfen einzelne Funktionen und Module. Sie werden schnell ausgeführt und schützen die grundlegende Geschäftslogik. Integrationstests zeigen, wie Teile des Systems miteinander interagieren: zum Beispiel und Dienst und Datenbank. End-to-End-Tests reproduzieren das Verhalten des Benutzers — vom Einloggen bis zur Bestellung.

Darüber hinaus führen wir manuelle Überprüfungen durch. Dies hilft sicherzustellen, dass die Benutzeroberfläche korrekt funktioniert, alles wie vorgesehen aussieht und das System gegenüber ungewöhnlichen Szenarien stabil ist.

Um wichtige Szenarien nicht zu verpassen, gestalten wir die Überprüfung in verständlichen und reproduzierbaren Formaten:

• PHPUnit, Cypress, Playwright, Vitest — für automatische Tests auf allen Ebenen: vom Backend bis zur Benutzeroberfläche.
• Postman und Newman — für das Testen und die Automatisierung von APIs.
• Sentry, Prometheus, Grafana — um Fehler, Metriken, Ausfälle und Leistung zu überwachen.
• Loki, Jaeger, Graylog — für das Loggen und die Nachverfolgung von Anfragen in verteilten Systemen.

Alle Werkzeuge sind in CI/CD integriert. Wenn ein Test fehlschlägt, erfahren wir sofort davon.

Vor der Veröffentlichung führen wir eine umfassende Kontrolle durch:

• Wir überprüfen, dass alte Funktionen weiterhin wie erwartet funktionieren (Regression).
• Wir führen Migrationen im Stand durch und rollen sie zurück, um die Zuverlässigkeit sicherzustellen.
• Wir vergleichen die Leistungskennzahlen vor und nach den Änderungen.
• Wir überprüfen, dass externe Dienste, mit denen wir integrieren, weiterhin verfügbar und versioniert sind.

Die endgültige Entscheidung liegt bei QA. Ohne seine Bestätigung geht die Aufgabe nicht in die Veröffentlichung.

Wir verwenden das Standardpaket testing und die Bibliothek testify für bequeme Assertions. Unit-Tests in Go sind eine schnelle und zuverlässige Möglichkeit, sicherzustellen, dass die Geschäftslogik korrekt funktioniert. Wir halten uns an eine lesbare Benennungsweise (TestXxx_WhenYyy_ShouldZzz) und überprüfen sowohl normale als auch Grenzfälle des Verhaltens des Systems — zum Beispiel leere Felder, Maximalwerte oder unerwartete Daten.

Wenn es notwendig ist, die Interaktion zwischen Diensten, Datenbanken oder Nachrichtenbrokern zu überprüfen, verwenden wir httptest, dockertest und Testkonfigurationen mit temporären Containern. Dies ermöglicht es, PostgreSQL, Redis, Kafka und andere Abhängigkeiten in einer isolierten Umgebung zu betreiben. Wir führen das System unter Bedingungen aus, die den realen so nahe wie möglich kommen, jedoch ohne die Verwendung von echten Benutzerdaten.

Um einzelne Teile des Systems zu testen, ohne das gesamte übrige zu beeinträchtigen, setzen wir anstelle der echten Komponenten spezielle Stubs ein — sie simulieren das Verhalten, führen jedoch keine echten Aktionen aus. Dafür verwenden wir die Werkzeuge gomock und mockery. Da alle Abhängigkeiten über Schnittstellen verbunden sind, können wir beispielsweise die Datenbank oder API einfach durch einen simplen Mock ersetzen, der vorhersehbare Antworten liefert. Dies ermöglicht es, sich auf die Überprüfung der Logik des Codes zu konzentrieren, anstatt auf die Funktionsweise des gesamten Systems.

Wir entwerfen Module so, dass sie bequem stückweise getestet werden können. Das bedeutet: Die Logik ist separat ausgelagert, Abhängigkeiten lassen sich leicht austauschen, und das Verhalten kann isoliert reproduziert werden.

Um zu verstehen, wie gut unser Code durch Tests geschützt ist, überprüfen wir seine „Abdeckung“ — das heißt, welche Teile des Codes tatsächlich durch Tests durchlaufen werden. Dafür nutzen wir:

• go test -coverprofile=coverage.out — erstellt eine spezielle Datei, in der ersichtlich ist, welcher Prozentsatz der Codezeilen während der Tests ausgeführt wurde;
• go tool cover -html=coverage.out — öffnet eine benutzerfreundliche farbliche Visualisierung: getestete Zeilen sind hervorgehoben, ungetestete — nicht.

So sehen wir sofort, wo Schwachstellen geblieben sind, und können die notwendigen Prüfungen hinzufügen.

Ziel dieser Abdeckung ist es, Risikozonen und Wachstumspunkte zu identifizieren. Wenn sie abnimmt, überarbeiten wir die Architektur oder verstärken die Tests.

phpunit ist das Hauptwerkzeug, das wir für die automatische Überprüfung des Codes in Laravel verwenden. Es hilft uns sicherzustellen, dass die wesentlichen Teile des Systems — wie zum Beispiel Dienste, Formulare, Validierung und Geschäftslogik — wie vorgesehen funktionieren. Wir schreiben Tests, die überprüfen, ob eine Funktion die gewünschte Aktion ausführt: zum Beispiel, dass eine Bestellung tatsächlich erstellt wird, der Benutzer eine Benachrichtigung erhält und das Formular einen Fehler bei falschen Daten zurückgibt. Wir speichern die Tests in denselben Ordnern wie den Hauptcode und halten die gleiche Struktur von Projekt zu Projekt ein. Dies ermöglicht es jedem Entwickler, sich schnell zurechtzufinden: wo sich die benötigten Tests befinden, wofür sie verantwortlich sind und wie sie zur Überprüfung ausgeführt werden können. Dies macht den Testprozess transparent und wartungsfreundlich.

Wir überprüfen die Funktionsweise der Schlüsselelemente der Anwendung — Routen, Middleware und Datenbankmigrationen. Das hilft sicherzustellen, dass Benutzeranfragen die richtigen Routen durchlaufen, alle Prüfungen durchgeführt werden und die Struktur der Datenbank den Erwartungen entspricht. Um die Tests von realen Daten und externen Prüfungen unabhängig zu machen, verwenden wir withoutMiddleware() — es schaltet alle Middleware aus, und RefreshDatabase — es setzt die Datenbank vor jedem Test zurück. Dies gibt uns einen „sauberen“ Zustand und erhöht die Zuverlässigkeit der Tests. Wir prüfen nicht nur Standard-Szenarien, sondern auch Grenzfälle: leere Felder, sehr lange Werte, fehlerhafte Daten — damit die Anwendung robust mit allen Eingabedaten umgeht.

Um die Geschäftslogik zu testen, ohne von externen Diensten abhängig zu sein, setzen wir stattdessen temporäre Platzhalter ein. Das hilft, die Zuverlässigkeit, die mit Netzwerken, externen APIs und Datenbanken verbunden ist, zu vermeiden.

So funktioniert es:

• Mit Mockery erstellen wir „Stubs“ — Objekte, die sich wie echte verhalten, aber einfach vorher festgelegte Antworten zurückgeben.
• Die Methode Http::fake() ermöglicht es, Aufrufe externer APIs zu imitieren, sodass die Anwendung denkt, sie habe eine Antwort von einem echten Server erhalten.
• Über Factory::new() erstellen wir fiktive Modelle für Tests — z.B. Benutzer, Bestellungen oder Beiträge, ohne etwas in der Hauptdatenbank zu speichern.

Das macht die Tests zuverlässig, schnell und reproduzierbar. Und das Wichtigste — sie sind nicht von Internetzugang oder der Verfügbarkeit externer Dienste abhängig.

Wir überprüfen, dass das System nach bestimmten Aktionen die erforderlichen Ereignisse auslöst und Aufgaben (Jobs) in die Warteschlange zur weiteren Verarbeitung einstellt. Dies ist wichtig für alle Geschäftsprozesse, die im Hintergrund stattfinden – zum Beispiel das Versenden von E-Mails nach der Registrierung. Um diese Aktionen während der Tests nicht tatsächlich auszuführen, verwenden wir Event::fake() – es ermöglicht uns, Ereignisse „abzufangen“ und zu überprüfen, dass sie tatsächlich ausgelöst wurden. In ähnlicher Weise stellen wir mit Queue::assertPushed() sicher, dass die Aufgaben tatsächlich in die Warteschlange gestellt wurden. Dies gibt uns die Gewissheit, dass die Anwendung sich korrekt verhält und auf die Aktionen des Benutzers so reagiert, wie es beabsichtigt ist.

Wir verwenden die Werkzeuge Vitest oder Jest, um die Funktionalität jedes Benutzeroberflächenkomponenten separat zu überprüfen. Das bedeutet, dass wir prüfen, ob der Text korrekt angezeigt wird, wie das Element auf Klicks reagiert, ob die benötigten Klassen aktiviert werden und ob die Anzeigebedingungen greifen. Solche Tests sind nicht mit dem Server oder der Datenbank verbunden — sie überprüfen rein das visuelle und logische Verhalten der Komponente unabhängig von der restlichen Anwendung. Dies ermöglicht es, schnell Fehler in der Anzeige oder Interaktion zu erkennen, ohne Zeit mit einer komplexen Umgebungsanpassung zu verschwenden.

Um sicherzustellen, dass der Benutzer den gesamten Weg in der App komfortabel durchlaufen kann, verwenden wir die Tools Cypress und Playwright. Mit ihrer Hilfe werden Szenarien getestet, die im echten Leben stattfinden: Anmelden, Formular absenden, Profil bearbeiten, Links folgen. Solche Tests starten die Benutzeroberfläche im Browser und durchlaufen Schritt für Schritt die Aktionen des Benutzers, als ob ein lebender Mensch vor dem Computer sitzt. Das hilft zu überprüfen, dass alles wie gewünscht funktioniert: Tasten werden gedrückt, Seiten laden, Daten werden gespeichert, Fehler treten nicht auf.

Während des Testens greifen wir nicht auf echte Server oder externe APIs zu. Stattdessen erstellen wir gefälschte Antworten, die wie reale aussehen und vorab festgelegte Daten zurückgeben. Dies wird als Mocking bezeichnet – wir setzen fiktive Antworten für REST- oder gRPC-Anfragen ein. Dieser Ansatz hilft, unabhängig von der Internetverbindung oder anderen Diensten zu sein und ermöglicht es, Tests schnell und stabil durchzuführen. Bei jedem Testlauf erhalten die Tests dieselben Antworten und arbeiten unter vorhersehbaren Bedingungen.

Wir nutzen die Tools eslint und stylelint, um automatisch zu prüfen, ob im Code Syntaxfehler oder Verstöße gegen die Stilvorschriften vorhanden sind. Dies hilft, den Code sauber und einheitlich zu halten. Wenn die Benutzeroberfläche besonders komplex ist oder visuelle Genauigkeit wichtig ist, fügen wir screenshot-Tests hinzu — sie machen Screenshots und vergleichen sie pixelgenau mit der Referenzversion. Wenn sich irgendwo etwas verschoben oder verschwunden ist, zeigt der Test dies sofort an. Dieser Ansatz hilft uns, visuelle Bugs nicht zu übersehen und das Design stabil zu halten.