TL;DR
- Verzichten Sie standardmäßig auf ein separates QA-Team
- Stellen Sie Engineers ein, die Tests auf der richtigen Ebene schreiben und den Qualitätsaspekt verantworten
- QA kann manchmal sinnvoll sein, wenn sie sorgfältig angewendet wird, wie unten beschrieben
Einleitung
Ich habe gerade einen sehr schönen Beitrag von Regina Gerbeaux und Case Sandberg über “Setting up an engineering team structure for success” gelesen.
Es ist ein großartiger Artikel und empfehlenswert. Aber es gibt eine Sache, der ich völlig widerspreche:
“I think the best thing to do is to have a dedicated QA Engineer. Senior and staff level engineers are able to go 50% faster at shipping features if they don’t have to worry about writing tests. Bugs coming in could get a test case written by a QA engineer, and there is still confidence that any fix by an engineer solves the problem."
Was? Senior Engineers schreiben keine Tests? QA übernimmt die gesamte Testarbeit?
Das klingt für mich extrem falsch - und ich habe diesen Ansatz nicht nur einmal scheitern sehen. Schauen wir uns einige Muster von QA-Abteilungen an. Einige dieser Muster führen zum Scheitern - während andere gut funktionieren.
Fehlermuster von QA-Abteilungen
Die unwartbare E2E-Testsuite
Die QA-Abteilung erstellt eine riesige Automatisierungssuite als End-to-End (E2E) Test. Dies geschieht mit Frameworks wie Selenium, Playwright, Cypress und anderen.
Diese Testsuite klingt nach einer großartigen Idee! Man sollte schließlich alles automatisieren.
Der Nachteil ist, dass diese E2E-Testsuite sehr schwer zu warten ist. Oft führen kleine Änderungen in der Benutzeroberfläche dazu, dass große Teile der Suite fehlschlagen.
Das Debugging von Testfehlern kostet QA viel Zeit. Die Wartung der E2E-Suite wird zum Vollzeitjob.
Noch schlimmer - die meisten E2E-Fehler sind keine echten Probleme, sondern “nur” Dinge, die bei neuen Stories geändert wurden oder geringfügige UI-Änderungen darstellen.
Diese False Positives lassen trotzdem Ihre Deployment-Pipeline fehlschlagen.
Engineers werden dann wütend, weil die E2E-Tests flaky sind und ihre Zykluszeit zerstören. Als “Lösung” wird die E2E-Testsuite in der Pipeline an den Rand gedrängt. Die neue Software wird trotzdem deployed - obwohl die E2E-Tests rot sind. Autsch.
Ich habe dieses Muster mehrfach in verschiedenen Unternehmen beobachtet. Die E2E-Testsuite war zu groß, flaky, unwartbar und erzeugte viele Fehlalarme.
Die Schlussfolgerung ist klar: Eine große E2E-Testsuite scheint ein klares Anti-Pattern zu sein.
Engineers werden faul
Ich bin selbst Engineer und Mensch. Wenn jemand meine Arbeit übernimmt, werde ich faul und delegiere einfach. Und wenn - wie Regina schrieb - QA alle Tests für die Engineers übernimmt, macht das etwas mit den Engineers.
Aber QA kann nicht auf der gleichen Ebene testen wie Engineers. QA testet normalerweise auf der E2E-Testebene (Spitze der Testpyramide). Engineers machen alles darunter (Unit- und Integrationstests).
Wenn Engineers aufhören, Tests zu schreiben, weil QA das Testen übernimmt, passieren drei Dinge:
- Eine große E2E-Testsuite wird aufgebaut - wie oben beschrieben: ein klares Anti-Pattern.
- Spaghetti-Code galore! Fehlende Unit-Tests bedeuten auch potenziell schlechte Architektur, die zu Spaghetti-Code und unwartbarer Software führt. Autsch.
- Wenn die Entwickler sich ausschließlich auf E2E-Tests verlassen, wird das Debugging von Bugs extrem schwierig. E2E-Tests sagen Ihnen nur, dass etwas nicht stimmt. Aber sie sagen Ihnen nicht, welche Komponente oder Klasse für den Bug verantwortlich ist. Unit-Tests würden helfen, weil sie genau auf das Problem hinweisen können. E2E-Tests? Nicht so sehr.
Deshalb erwarte ich von Engineers, dass sie ordentliche Unit- / Integrationstests schreiben und “Qualität” zu ihrer Verantwortung machen. Das ist auch eine absolute Voraussetzung für Continuous Delivery - ohne dass jemand “Ihren Code manuell prüfen oder nachträglich Tests hinzufügen muss”.
QA als Produktabnahme-Tester
Ich habe auch manchmal gesehen, dass QA vom Produkt zur Abnahme von Tickets genutzt wird.
In meiner Welt ist es der Product Manager, der die Tickets schreibt und die Akzeptanzkriterien definiert. Der Product Manager hat auch eine klare Vorstellung davon, wie eine Story aussehen und sich anfühlen sollte.
Sobald die Engineers eine Story fertiggestellt haben, prüft der PM die fertige Story. Hakt die Checkboxen der Akzeptanzkriterien ab und prüft auch, ob es richtig aussieht und sich richtig anfühlt. Falls nicht, kann das Feature vom Team nachgebessert werden.
Manchmal wird die Abnahme eines Tickets an QA delegiert.
Die Product Manager schreiben Akzeptanzkriterien und definieren UX/UI-Aspekte. Sobald das Ticket fertig ist, kommt QA und prüft die Akzeptanzkriterien. Der Product Manager würde das Ticket nicht abnehmen oder auch nur ausprobieren.
Autsch.
Das ist sehr ineffizient, da QA eine enorme Zeit braucht, um jedes Ticket zu verstehen. Und QA steckt nicht im Produktprozess und weiß nicht, wie das Feature aussehen und sich anfühlen sollte.
Manchmal beschweren sich Ihre Product Manager, dass sie nicht genug Zeit haben, um “alles” zu erledigen. Dann ist es umso wichtiger sicherzustellen, dass sie ein gutes Zeitmanagement haben und sich auf die wichtigsten und dringendsten Aufgaben konzentrieren. Ein Ticket abzunehmen ist im Kern das, was ein Product Manager tun sollte.
Drei Muster, die QA zum Funktionieren bringen
Zu wissen, was nicht funktioniert, ist wichtig - aber viel wichtiger ist: Was funktioniert, wenn es um QA geht? Gehen wir vier QA-Muster durch, die bei mir funktioniert haben!
Metriken, Qualitäts-KPIs und Post-Mortems
Das QA-Team ist verantwortlich für die Überwachung der Softwarequalität in der Abteilung. Darum geht es beim Q.
Einige konkrete Beispiele:
- Wenn ein Software-Release viele Bugs hatte, ist es die Verantwortung der QA, ein Post-Mortem zu erstellen. Das stellt sicher, dass die gleichen Probleme nicht wieder auftreten. Das ist ein weicher Ansatz für “Qualität”, aber sehr wichtig. Engineers sollten zur Rechenschaft gezogen werden. Fehler können und sollen passieren. Aber der gleiche Fehler sollte nur einmal passieren.
- Normalerweise haben Abteilungen wiederkehrende Meetings wie ein Show and Tell oder Team-Lead-Meetings. In einem dieser Meetings wird QA anwesend sein und aktuelle Qualitäts-KPIs hervorheben. Diese Qualitäts-KPIs könnten zum Beispiel die Anzahl der Bugs, Kundensupport-Anfragen oder DORA-Metriken wie Zykluszeit und Release-Frequenz sein. Wenn die Metriken sich verschlechtern, liegt es in der Verantwortung der QA, diese Probleme hervorzuheben.
Teams unterstützen, wenn große Features live gehen, und exploratives Testen
In meiner Welt können das Engineering-Team plus die Produktperson eines Teams entscheiden, ob ein Feature live gehen kann. Die Engineers schreiben Unit- und Integrationstests. Product prüft die Akzeptanzkriterien und den Gesamteindruck des neuen Features. Wenn sowohl Engineering als auch Product grünes Licht geben, kann das Feature live gehen. In 99% der Fälle ohne jegliche Beteiligung der QA.
Aber manchmal ist es sinnvoll, QA einzubeziehen. Zum Beispiel wenn das Feature wirklich groß ist und viele verschiedene Bereiche der Anwendung betrifft. Dann ist es sinnvoll, die Produktabnahme durch einen separaten QA-Schritt zu ergänzen.
Automatisierung - für wenige kritische Pfade
Während eine riesige E2E-Testsuite ein Anti-Pattern ist, wie oben beschrieben - ist Automatisierung wichtig.
Eine Best Practice ist eine kleine Anzahl von E2E-Tests, die nach jedem Deployment ausgelöst werden und die kritischen Pfade der Anwendung prüfen. Login / Logout und ähnliche Dinge.
Das hilft normalerweise, die meisten Probleme im Voraus zu erkennen. Der Schlüssel ist, die E2E-Suite klein und wartbar zu halten.
Zusammenfassung
Die meisten QA-Teams sind eine Verschwendung von Geld, Zeit und machen Ihre Engineers und Produktleute faul. Ein separater QA-Schritt mit Hin und Her zwischen QA und Engineering und Product wird Ihre Zykluszeit zerstören.
Verzichten Sie standardmäßig auf ein dediziertes QA-Team.
Wenn Sie die richtigen Engineering-Fähigkeiten einstellen, brauchen Sie QA überhaupt nicht. Entgegen Reginas Meinung am Anfang dieses Artikels - bringen Sie Ihre Engineers dazu, Tests auf der richtigen Ebene zu schreiben - ansonsten werden schlechte Dinge passieren.
Aber manchmal kann ein kleines, dediziertes QA-Team auf großartige Weise helfen:
- Um Ihre Engineers durch die Beobachtung von Qualitätsmetriken und Post-Mortems auf Trab zu halten
- Bei explorativem Testen zu helfen, wenn große Features live gehen
- E2E-Tests zu erstellen, die den kritischen Pfad Ihrer Anwendung nach dem Deployment testen
Ihre Erfahrungen können variieren…
Mehr
- Bild oben vom großartigen Dipesh Shrestha
