Die Abschaffung des QA-Teams könnte tatsächlich eine schlechte Entscheidung gewesen sein
- Der langsamste Teil der Software-Auslieferung ist das Testen. Continuous Deployment existiert aus gutem Grund, weil Testen dazugehört; dass dies zum Engpass wird, gilt daher als optimierter Zustand.
- Die Gewohnheiten und Verhaltensweisen rund um Optimierung haben in der Branche dazu geführt, das QA-Team als Engpass zu betrachten und es beseitigen zu wollen. Dadurch ist der Respekt für die QA-Rolle gesunken, und es entstehen Probleme dabei, qualitativ hochwertige Software zu produzieren.
- Entwickler verstehen Software-Qualitätsmanagement nicht wirklich. Viele Organisationen wissen nicht, wer die Verantwortung für Softwarequalität trägt, und selbst dort, wo eine QA-Funktion erhalten geblieben ist, fällt es schwer, ihren Platz zu finden.
Was getan werden muss, um Qualität in der Softwarepraxis zu steuern
- Fehlerverfolgung: Es braucht eine Möglichkeit, wie Nutzer Informationen über Bugs liefern können und wie Entwickler Bugs erfassen können.
- Triage: Bug-Triage ist der Prozess, in dem die Zuweisung, Priorisierung, Bereinigung, Klassifizierung und Entdoppelung von Bugs verwaltet wird.
- Fehleruntersuchung: Die Reproduktion von Bugs ist ein wichtiger Teil des Bug-Managements; um das tatsächliche Problem zu erkennen und zu beheben, ist technischer Aufwand nötig.
- Fokus: Es muss im Unternehmen Menschen geben, die sich auf Qualität konzentrieren, und es braucht jemanden, der Qualität vertritt, um das Gleichgewicht zwischen Qualität und Geschwindigkeit zu wahren.
- End-to-End-Testing: Eigentumsprobleme in Systemen entstehen durch komplexe Architekturen, was dazu führt, dass vor dem Produktrelease echte Nutzungstests fehlen.
Meinung von GN⁺
- Die Abschaffung des QA-Teams ist ein Managementfehler, der sich langfristig gravierend auf die Softwarequalität auswirken kann.
- Qualitätssicherung ist ein wichtiger Bestandteil des Softwareentwicklungsprozesses, und sie zu ignorieren oder geringzuschätzen, kann letztlich zum Scheitern führen.
- Dieser Artikel ist interessant, weil er die Bedeutung von QA in der Softwareindustrie neu beleuchtet und die Notwendigkeit eines angemessenen Verständnisses von Qualitätsmanagement sowie einer klaren Rollenverteilung innerhalb von Organisationen hervorhebt.
1 Kommentare
Hacker-News-Kommentare
Ende der 1970er arbeitete ich bei IBM in der Product Assurance und schrieb Testcode sowie baute Hardware für das von mir betreute Produkt, ein Textverarbeitungssystem. Dem Entwicklungsteam wurden die konkreten Testfälle nicht offengelegt; stattdessen erhielten sie nur allgemeine Hinweise zu Problemen, damit sie Bugs selbst beheben konnten. Anhand der Abweichung zwischen den von uns gefundenen Bugs und den vom Entwicklungsteam behobenen Bugs ließ sich die Zahl der verbleibenden Bugs statistisch abschätzen.
In Organisationen ohne QA-Team wurde das Konzept des "Sniff Test" eingeführt. Dabei testet jeder im Unternehmen neue Funktionen für kurze Zeit, meist eine Stunde, in einer konzentrierten Session, was zu vielen Bug-Tickets führte. Dass selbst einfache Tests häufig Probleme verursachen, überrascht inzwischen nicht mehr.
Die zwei Unternehmen, bei denen ich vor 15 bis 20 Jahren gearbeitet habe, investierten in erstklassige QA-Teams, die hervorragend darin waren, Bugs zu finden, an die Entwickler nicht gedacht hatten. Das QA-Team hatte die letzte Entscheidungsgewalt darüber, ob ein Produkt ausgeliefert wird. Heute glauben viele Unternehmen, es sei besser, wenn Entwickler automatisierte Tests schreiben und viel Zeit in Code Coverage investieren, aber ich habe viele Produkte gesehen, die trotzdem in der Praxis nicht funktionierten. Es geht nicht darum, dass automatisierte Tests schlecht wären, sondern darum, menschliche QA-Tester abzuschaffen.
Die gewissenhaftesten Mitarbeiter in einer Organisation sind oft auch die unzufriedensten. Sie erkennen Qualitätsprobleme und versuchen, sie zu lösen, bekommen dafür aber keine Anerkennung und gelten, sobald sie Qualität ansprechen, als Leute, die alles verlangsamen wollen. Während die Menschen, die "schnell handeln und Dinge kaputtmachen", weiter belohnt werden, ärgern sie sich darüber, den Scherbenhaufen aufräumen zu müssen, und haben das Gefühl, dass es ihrer Karriere schaden kann, wenn ihnen Qualität wirklich wichtig ist.
QA wird vom Business und vom Top-Management oft als "Cost Center" betrachtet. Es gibt die These, dass man vermeiden sollte, in einer Abteilung zu arbeiten, die als "Cost Center" gilt, weil Vergütung und Anerkennung immer an diejenigen gehen, die Umsatz erzeugen. QA muss mit weniger Leuten mehr Arbeit leisten, wird für Misserfolge verantwortlich gemacht und ist oft einer der ersten Bereiche, in denen entlassen wird, wenn das Unternehmen schlanker werden soll.
QA-Ingenieure verfügen über hervorragende Debugging-Fähigkeiten. Sie arbeiten an allen Aspekten einer Anwendung, von der Pipeline über den Source Code bis zu den Testverzeichnissen, und erleben oft, dass Softwareingenieure Pipeline-Fehlermeldungen nicht lesen, grundlegende Probleme ignorieren und tagelang nur Lösungen raten. Die Geringschätzung gegenüber QA-Ingenieuren ist im Artikel nicht übertrieben; weil QA-Organisationen oft nicht denselben strengen Interviewprozess wie Engineering-Organisationen haben, werden QA-Ingenieure als minderwertig angesehen.
Meiner persönlichen Erfahrung nach habe ich noch nie ein QA-Team erlebt, das tatsächlich Tests für das Engineering schreibt. Die meisten QA-Teams führen "Testpläne" manuell aus oder, seltener, über automatisierte Browser-/Gerätetests. Diese Arten von Tests sind zwar wertvoll, aber nicht so wertvoll wie "Unit Tests" oder "Integration Tests". In diesem Modell übernimmt eher das Engineering-Team die eigentliche QA-Rolle als ein echtes QA-Team, während das QA-Team seinen Wert oft dadurch mindert, dass es Dinge als Bugs meldet, die keine sind.
Seit Microsoft seine QA-Teams abgeschafft hat, habe ich bei Windows- und Cloud-Produkten mehr Bugs erlebt.