Hinweise darauf, dass die Auflösung des QA-Teams möglicherweise doch eine falsche Entscheidung war

• Nach der Optimierung im DevOps-Stil, die Engpässe bei Releases, Deployments, Image-Management und Rollbacks reduziert hat, blieb im Software-Delivery-Prozess das Testen als langsamster Punkt übrig
• Die Branche begann, nicht das Testen selbst, sondern das QA-Team als Engpass zu sehen; obwohl die Erwartungen an die Rolle stiegen, folgten schlechtere Bedingungen, mehr Vertragsarbeit, Offshoring und Stellenabbau
• Die Auflösung von QA-Organisationen demotivierte erfahrene QA-Fachkräfte, und weil Entwickler Qualitätsarbeit nicht selbstverständlich mitübernahmen, verschärfte sich das Problem minderwertiger Software
• Qualitätsmanagement ist reale Arbeit, die benannt und zugewiesen werden muss, etwa Fehlerverfolgung, Klassifizierung, Untersuchung, Qualitätssicherung als Fürsprecherrolle und End-to-End-Tests
• Wenn Qualitätsarbeit nicht organisiert wird, werden diejenigen, die Probleme finden und aufräumen, nicht belohnt, während die, die schnell bauen und Dinge kaputtmachen, wiederholt belohnt werden

---

Der Engpass, der nach der DevOps-Optimierung übrig blieb

• DevOps-Praktiker haben die Theory Of Constraints angewendet, um Software-Delivery-Pipelines und Praktiken stark zu optimieren
• Manuelles Release-Management, Deployments, Image-Management und Produktions-Rollbacks wurden zu Zielen der Automatisierung
• Auf dem Weg vom Produkt-Backlog bis zur Auslieferung von Code an Kunden wurden Aktivitäten mit geringem Wert als Engpässe behandelt, die man entfernen oder optimieren sollte
• Dadurch blieb im Software-Delivery-Prozess das Testen als langsamster Teil übrig
  • Testen ist auch der Grund, warum Continuous Delivery überhaupt existiert
  • Tests lassen sich schneller machen, automatisieren und parallelisieren
  • Wenn in einer Praxis die wertvollste Aktivität der Engpass ist, gilt das als Hinweis darauf, dass der Zustand bereits nahe am Optimum ist

Die Branche sah QA-Teams als Engpass

• Die Gewohnheit zur Optimierung wurde über das Testen selbst hinaus auch auf die QA-Rolle angewendet
• Es gab Bestrebungen, Integrations- und End-to-End-Tests auf Unit-Tests zu reduzieren, um sie stärker parallelisieren zu können
• Auf personeller Ebene wurden auch Menschen, denen man mangelnde Coding-Fähigkeiten zuschrieb, in funktionsbezogene Einheiten abgeschoben
• Die Branche begann zu meinen, nicht das Testen, sondern das QA-Team könne der Engpass sein
  • Die Erwartungen an die QA-Rolle stiegen
  • Die Gehälter sanken oder stiegen im Vergleich zu anderen Rollen nicht
  • Die Rolle wurde in Vertragsarbeit umgewandelt und offshored
  • Entscheidungen zur Reduzierung von QA-Engineer-Stellen häuften sich

Der Teufelskreis durch die Verkleinerung der QA-Rolle

• Die Menschen, die in QA blieben, gerieten zunehmend in eine schlechtere Lage
  • Wer gut genug coden konnte oder von den Bedingungen erschöpft war, verließ QA
  • Andere betrachteten die verbleibenden QA-Kräfte als „Leute, die nicht gut genug sind, um aus diesem Bereich herauszukommen“
  • Auch die Zahl der Menschen sank, die QA neuen Absolventen als Berufsfeld empfahlen
• Unternehmen trennten sich von QA nach dem Muster: „Diese Funktion behalten wir nicht mehr, kümmert euch selbst darum“
• Dieser Prozess war für Menschen, die eine QA-Karriere aufgebaut hatten, respektlos und demotivierend
• Die Auflösung von QA verschärfte das Problem minderwertiger Software, und viele Organisationen wussten nicht mehr, wer bei der Softwarequalität eigentlich was tun sollte
• Selbst Organisationen, die eine QA-Funktion beibehielten, hatten Schwierigkeiten, ihren Platz in einem bereits beschädigten Feld zu finden

„Tester entlassen“ war nicht die Lösung

• Der „eine seltsame Trick“ für schnellere Softwareauslieferung war nicht, Tester zu entlassen
• Die Zerstörung des QA-Bereichs kommt einem der schlimmsten Managementfehler überhaupt nahe
  • Es war eine Entscheidung, die etwas zerstörte, das sich über Jahrzehnte entwickelt hatte
  • Die Auswirkungen können jahrelang unbemerkt bleiben
  • Wenn eine Organisation das Problem tatsächlich spürt, kann es wiederum Jahre dauern, bis eine sinnvolle Erholung möglich ist
• Die Teile der QA-Rolle, die ursprünglich kaputt waren, sind weiterhin ungelöst geblieben
• Eine echte Aufgabenverteilung fand nicht statt, und Entwickler übernehmen QA-Arbeit ohne zusätzliche Vergütung, Anerkennung oder passende Anreizstrukturen nicht freiwillig
• Einige Menschen, die mit hochfunktionalen QA-Teams gearbeitet haben, können Teile ihres Verhaltens nachahmen, aber neuere Engineers und Manager erkennen oft nicht, was fehlt
• Das Grundprinzip lautet: Qualitätssicherung ist Arbeit
  • Wie bei anderer Arbeit scheitert es, einfach anzunehmen, dass „irgendjemand“ sie schon machen wird
  • Sie als unsichtbare Arbeit liegenzulassen, führt ebenfalls zum Scheitern

Aufgaben, die für das Management von Softwarequalität nötig sind

• Fehlerverfolgung

  • Es braucht eine Möglichkeit, mit der Nutzer Bug-Informationen einsenden können und Entwickler Bugs erfassen können
  • Bugs sind einzelne Tickets, die beschreiben, was schiefgelaufen ist und wie schwerwiegend es ist
  • Sie beschreiben nicht die eigentliche Behebungsarbeit
  • Sie sollten den Fehler, Schritte zur Reproduktion und die Auswirkungen enthalten
  • Die meisten Entwicklungsteams, mit denen zusammengearbeitet wurde, haben solche Fehler in letzter Zeit nicht verfolgt
  • Gründe wie „Wird sowieso nicht behoben“, „Nicht mein Job“ oder „Neue Features werden belohnt“ rechtfertigen keine schlechte Qualitätsresultate
  • Schon die Pflege einer Bug-Liste ist Arbeit

• Triage und Priorisierung

  • Bug-Triage ist der Prozess, eingehende Bugs zuzuweisen, zu priorisieren, zu ordnen, zu klassifizieren und Dubletten zu entfernen
  • Konsistente Kriterien für hohe, mittlere und niedrige Schweregrade helfen einer Organisation
  • Früher nannte man das „Bug-Hygiene“
  • Auch die Entscheidung, welches Team für einen bestimmten Bug zuständig sein sollte, ist Arbeit
  • Gut funktionierende Organisationen können auf externen Druck oder Restrukturierungen besser reagieren
  • Selbst bei Entlassungen steuern sie Qualitätsverluste schrittweise
  • Bei organisatorischen Umbauten übergeben sie bestimmte Bug-Kategorien an neue Teams
  • Bugs in eingestellten Funktionen werden gesammelt geschlossen
  • Zu sagen, ein Team ohne jeden externen Stress oder Umbau könne den Triage-Prozess ignorieren, ist fast schon ein Witz

• Fehleruntersuchung

  • Reproduzierbarkeit ist ein wichtiger Teil des Bug-Managements
  • Jemand muss einen Bericht wie „Ich wollte ein Kinoticket kaufen, aber es ging nicht“ in etwas verwandeln wie „Ein Zeichenkodierungsproblem bei Kunden mit nicht-englischen Zeichen im Namen hat den Kaufablauf unterbrochen“
  • Fragen wie „Wie oft ist dieses Problem aufgetreten?“ oder „Welche Auswirkungen hat es auf Nutzer?“ müssen von realen Menschen mit Zeitaufwand beantwortet werden
  • Fehleruntersuchung bedeutet, technische Sorgfalt auf den Bug-Backlog anzuwenden

• Eine Rolle mit Fokus auf Qualität

  • Es hat echten Wert, wenn es im Unternehmen Menschen gibt, die auf die Qualität des Endprodukts fokussiert sind
  • Qualität kann die Aufgabe aller sein, muss aber gleichzeitig auch die Aufgabe von jemandem sein
  • In der Spannung zwischen Qualität und Geschwindigkeit braucht es Menschen, die Qualität vertreten
  • Bei Testwerkzeugen, Testqualität und Testplanung braucht es Beteiligte mit klaren Ansichten und dem Anspruch, es so gut wie möglich zu machen

• End-to-End-Tests

  • Eines der größten und häufigsten Probleme in vielen Engineering-Organisationen ist Systemverantwortung
  • Die zunehmende Architekturkomplexität entstand mit dem Ziel, Teams und Anwendungen klein zu halten, und das kann eine vernünftige Strategie sein
  • Das Ergebnis ist jedoch, dass an den wichtigsten Stellen einer Anwendung Lücken entstehen
  • Durchschnittliche Teams nutzen und verifizieren das Produkt auf End-to-End-Ebene nicht mehr, weil es zu schwierig ist
  • Es muss sichergestellt werden, dass jemand innerhalb der Organisation das Produkt tatsächlich benutzt, bevor es veröffentlicht wird

Organisatorische Probleme, wenn Qualitätsarbeit ignoriert wird

• Es kann die Reaktion geben: „Wir sind agil, lean und dynamisch, deshalb müssen wir so etwas nicht tun“
• Schaut man genauer hin, findet diese Arbeit in der Organisation wahrscheinlich bereits statt, aber sie wird äußerst schlecht ausgeführt
• In anderen Bereichen wie Autos, Banken oder bei Ärzten ist es keine gute Erfahrung, zu hören: „Wir machen keine Qualitätssicherung“
• Wenn Qualitätsaktivitäten nicht erkannt und organisiert werden, führt das zu sehr schlechten Zuständen
• Die gewissenhaftesten Mitarbeitenden werden am bittersten
  • Sie sehen Qualitätsprobleme und beheben sie oft
  • Sie bekommen dafür keine Anerkennung
  • Wenn sie Qualitätsbedenken äußern, gelten sie als Leute, die das Tempo bremsen wollen
  • Sie sehen, wie Menschen, die „schnell handeln und Dinge kaputtmachen“, wiederholt belohnt werden
  • Sie haben das Gefühl, wütend das Chaos anderer aufräumen zu müssen
• In solchen Organisationen wird schon die Haltung, sich zu kümmern, zum Karrierenachteil

[GN⁺]

Meinungen auf Hacker News

• Zu Beginn meiner Karriere, Ende der 1970er, arbeitete ich bei IBM Hursley Park in der Product Assurance, also der QA-Organisation. Um das von mir betreute Produkt, ein Textverarbeitungssystem, zu testen, baute ich Code und Hardware und führte Testfälle gegen das zu testende System aus.
  Die gefundenen Probleme gaben wir nur mit einer allgemeinen Beschreibung an das Entwicklungsteam weiter, damit es nicht die Testfälle passend macht, sondern die Bugs behebt. Wenn wir also drei Bugs bei Zeilenumbrüchen mit Bindestrich-Wörtern und beim Löschen per Backspace fanden, behob das Entwicklungsteam vier Bugs in diesem Bereich, aber nur zwei der tatsächlich von uns gefundenen. So konnten wir die Zahl der verbleibenden echten Bugs statistisch abschätzen.
  In Organisationen ohne QA-Team führten wir das Konzept eines Sniff-Tests ein. Das ist meist eine etwa einstündige Session, in der beliebige Personen im Unternehmen oder in der Abteilung eine neue Funktion ausprobieren; auch wenn die Funktion als fertig gilt, sind Randbedingungen fast immer kaputt. Wenn man in jedes Feld "" eingibt und absendet, die UI nur mit der Tastatur bedient oder einfache Bedingungen wie große Schriftarten oder 110 % Browser-Zoom ausprobiert, treten oft Probleme zutage; inzwischen überrascht mich das nicht mehr.

  • Bei uns im Unternehmen nennen wir so etwas Bug Bash, und auch gemessen an der Zahl der gefundenen Defekte ist es normalerweise sehr produktiv.
    Bei der Entwicklung kleiner Features testen meist nur die Programmierer, und deren Vorgehen kann sich von der tatsächlichen Nutzung durch Endanwender unterscheiden; deshalb ist es besonders nützlich.
  • Die Strategie, den Entwicklern die Quelle der automatisierten Tests zu verbergen, ist interessant. So scheint man sie dazu bringen zu können, sich auf die eigentliche Problemlösung zu konzentrieren, statt Tests zu deaktivieren oder nur auf die Tests hin zu optimieren.
  • Bei Microsoft nannte man das früher bug bash, und mein Startup hat diese Idee übernommen. Das ganze Unternehmen wurde ermutigt, sich einen Nachmittag dafür freizuhalten, und es gab sogar Preise für die Bugs mit der größten Wirkung oder die interessantesten Bugs.
  • Ich frage mich, wem es wirklich nützt, in einer Stunde 100 Bug-Tickets zu erzeugen. Wenn es viele Duplikate gibt, reichen schon zehn unterschiedliche Bugs, um deutlich zu zeigen, dass die Funktion ernsthaft schlecht ist; danach fühlt es sich nur noch an, als würde man weiter auf Trümmern herumklopfen.
  • Die Methode, exakte QA-Testfälle zu haben, den Entwicklern aber nur vage Beschreibungen zu geben, ist ziemlich clever. So etwas habe ich zum ersten Mal gesehen, und auch dass man damit die Zahl der verbleibenden Bugs abschätzen kann, ist beeindruckend.

• Vor 15 bis 20 Jahren arbeitete ich bei zwei Unternehmen, die in erstklassige QA-Teams investierten, und diese Teams waren ihr Geld wirklich wert. QA fand zuverlässig Bugs, an die Entwickler nicht dachten, weil sie dem Problem zu nahe waren, und die Produkte wurden Weltklasse.
  Entscheidend war, dass in beiden Unternehmen von oben festgelegt war, dass das QA-Team die endgültige Befugnis über Releases hatte.
  Heutige Unternehmen glauben, es sei besser, wenn Entwickler automatisierte Tests nutzen und sich übermäßig um Code Coverage kümmern, aber ich habe zu viele Produkte mit 100 % Code Coverage gesehen, die objektiv nicht funktionierten. Das heißt nicht, dass automatisierte Tests schlecht sind, sondern dass es problematisch ist, menschliche QA-Tester abzuschaffen.

  • Bei hervorragenden QA-/QE-Organisationen war es ähnlich. Die Befehlskette, die entschied, ob ein Production-Release zertifiziert wird, war eine andere als in der Entwicklung, und auch die Anreizstruktur war anders.
    Das QE-Team eines Unternehmens, bei dem ich kürzlich war, schrieb enorme Mengen Code, um Tests auszuführen; es hatte mehr Codezeilen als die zu testenden und zu zertifizierenden Module.
  • Code Coverage findet keine Bugs in Code, den man nicht geschrieben hat, aber hätte schreiben sollen. Coverage ist nur eine von mehreren Metriken, und es ist töricht, sie wie das einzige Kriterium zu behandeln.
    Trotzdem habe ich einmal gehört, wie ein Testmanager eines großen, allseits bekannten Softwareunternehmens erklärte, man habe 100 % Coverage erreicht, also sei das Testteam erledigt.
  • Die Anweisung, dass QA die letzte Entscheidungsmacht hat, reicht nicht; es braucht eine QA-Kultur.
    Selbst mit dieser Befugnis blieb es in Unternehmen ein Chaos, in denen QA überwiegend aus schlecht bezahlten Vertragskräften bestand, die nur taten, was man ihnen sagte.
  • Ich habe Entwickler gesehen, die Tests ohne Assertions oder Tests mit nur assertTrue(true) schrieben. Immer grün, und die Coverage liegt bei 100 %.
    Dieselben Leute fragten oft, warum sie Tests schreiben sollten, wenn sie stattdessen neue Features bauen könnten; dann kam ein Senior-QA-Mensch und machte alles kaputt. Einmal fand er heraus, dass das Backend stirbt, wenn man eine Minute lang 50-mal F5 drückt, weil es Datenbankanfragen ausführt und mit outOfMemory abstürzt.
  • Ich mag gründliche QA-Leute wirklich. Dass ich mich als Entwickler zu sehr darauf verlasse, dass sie das finden, was ich übersehe, ist ein Antipattern; aber wenn ich Angst habe, meinen Code auch nur eine Minute laufen zu lassen, haben sie Spaß daran.
    Sie sind stolz darauf, Randbedingungen zu finden, die weit über die Spezifikation hinausgehen, und das ist den Aufwand wert. So wie ein gutes Typsystem Vertrauen in Änderungen gibt, gibt auch hervorragende QA Entwicklern Vertrauen. Besonders bei interaktiven Apps wie Spielen ist es schwierig, den gesamten Parameterraum allein mit Unit- und Integrationstests abzudecken.

• Es ist eine bittere Wahrheit, dass die gewissenhaftesten Mitarbeiter in einer Organisation am verbittertsten werden. Sie sehen Qualitätsprobleme, beheben sie oft selbst, bekommen aber keine Anerkennung, und wenn sie Qualitätsbedenken äußern, gelten sie als Leute, die das Tempo bremsen wollen.
  Die „Move fast and break things“-Fraktion wird weiter belohnt, während die, die sich kümmern, hinterher aufräumen und immer wütender werden. Für sie fühlt sich das Sich-Kümmern selbst wie ein großer Karrierenachteil an, weil es das tatsächlich ist.
  DBAs und Infrastrukturorganisationen sitzen im selben Boot wie QA, und ich hoffe, dass das Pendel bald zurückschwingt.

  • Man sollte einfach vom Schiff springen und das Unternehmen untergehen lassen. Je schneller es untergeht, desto besser; gute Dinge werden möglich, wenn man schlechte Unternehmen nicht künstlich stützt.
  • Die Art, wie das Pendel meiner Meinung nach zurückschwingt, lautet: Wer es gebaut hat, betreibt es auch. Wenn man nicht will, dass der On-Call-Pager klingelt, sollte man ihn nicht zum Klingeln bringen.
  • Am Ende hängt es vom Kunden ab. Die Frage ist, ob er wegen Bugs und Ausfällen geht oder wegen glänzender neuer Features bleibt.
  • QA und Tests sind wichtig, aber ich weiß nicht, ob man Leute überzeugen kann, die nur auf den Gewinn schauen. Weil die Auslieferung über das Internet so einfach geworden ist, wird der Ansatz „schnell veröffentlichen und später patchen“ wohl bleiben.
    Die Rechnung lautet: Wenn Nutzer Bugs melden und Updates über das Internet erhalten können, warum dann viel Geld und Zeit investieren? Seit Spiele und Software von physischen Medien zu Downloads übergegangen sind, scheinen Patches billiger zu sein. Natürlich führt das zu schrecklichen Sicherheitsproblemen und schlechter User Experience, aber solange die Leute oben den Gewinn maximieren, kümmert sie das kaum.
  • Gewissenhafte Ingenieure haben nicht immer recht; Kontext und Balance sind nötig. Manchmal liegen sie richtig, aber ihre Art der Vermittlung ist kaputt, und manchmal sind sie schlicht am falschen Ort.
    Wenn man ein POC-SaaS-Produkt baut, braucht man keine Qualität auf dem Niveau eines Avionik-Mikrocontrollers. Jeder Kompromiss bringt Risiken und Kosten mit sich, und gute Ingenieure sollten den Unterschied kennen.

• Das Kernproblem von QA-Teams ist dasselbe wie bei IT-Teams oder Verwaltungsorganisationen: Wenn sie ihre Arbeit gut machen, sieht es so aus, als würden sie nichts tun.
  Deshalb geraten sie oft in die Lage, ihre Arbeit „rechtfertigen“ zu müssen, was meist daher kommt, dass man sich übermäßig auf Kennzahlen verlässt. Wie bei Goodharts Gesetz versteht man nicht, wofür eine Kennzahl ein Stellvertreter ist und was der eigentliche Zweck der Arbeit ist.
  Schlechte QA-Teams suchen übertrieben nach Kleinigkeiten, damit es so aussieht, als hätten sie etwas zu sagen; gute QA-Teams prüfen Qualität und trainieren zugleich die Mitarbeitenden darin, höhere Qualität zu liefern.
  Ich habe das Gefühl, dass es insgesamt an Training mangelt. Der Artikel „Das 95. Perzentil ist gar nicht so beeindruckend“, der neulich auf der Frontpage war (https://news.ycombinator.com/item?id=38560345), sagte ebenfalls, dass es in jedem Bereich leicht sei, zu den obersten 5 % zu gehören, weil die meisten Ausführenden nicht aktiv trainieren oder Feedback bekommen.
  Unternehmen sollten vielleicht nicht wie Amateursportteams, sondern wie Profiteams kontinuierlich trainieren. Auch beim Recruiting sollte die Frage weniger lauten: „Ist diese Person bereits ein Top-Performer?“, sondern: „Können wir diese Person zu einem Top-Performer machen?“ Dass jemand in einer früheren Umgebung erfolgreich war, bedeutet weniger, als man denkt, wenn die neue Umgebung deutlich anders ist.

  • Das 95. Perzentil kann eher das Ergebnis davon sein, unnötige Fehler zu reduzieren, als das Ergebnis enormer Anstrengung, und trotzdem ist das kulturelle Meme weit verbreitet, es als ungeheuer schwierige Leistung abzutun.
    Unter Artikeln zur Softwarequalität gibt es viele Kommentare, die eine weitverbreitete Gleichgültigkeit von Engineers als selbstverständlich ansehen. Es hängt von der Situation ab, aber Menschen scheinen ziemlich gut darin zu sein, sich einfach dem lokalen Optimum ihrer Organisation anzupassen und die Initiative abzugeben. Es ist nicht vollständig ihre Schuld, aber unschuldig sind sie auch nicht.
  • In DevOps-Teams sehe ich immer wieder das Muster, „die Arbeit rechtfertigen zu müssen“. Meist verbringt die am besten bezahlte oder erfahrenste Operations-Person viel Zeit damit, Brände zu löschen, die durch ihre eigene Unfähigkeit oder Fehler entstanden sind, und wirkt deshalb so, als würde sie etwas tun.
    Wenn man wiederkehrende Aufgaben durch Automatisierung beseitigt, verschwindet die Stelle dieser Person; aber wenn man es richtig macht, denkt das Management, sie sitze den ganzen Tag herum und tue nichts. Daher gibt es wenig Anreiz, es richtig zu machen.
  • Wenn man mit neuen Entwicklern arbeitet, kann man sie schon mit grundlegenden Tests wie Doppelklicks, führenden Leerzeichen oder dem Android-Zurück-Button häufig ins Stolpern bringen. Nachdem ein paar Tickets zurückgewiesen wurden, lernen sie solche Dinge, und danach treten dieselben Probleme kaum noch auf.
    Da man nicht nach der Zahl gefundener Bugs bewertet wird, gibt es auch keinen Druck, dumme Bugs krampfhaft zu finden, nur um die Zahlen zu erhöhen.
  • „Wenn man sie so trainiert, gehen sie für mehr Geld woandershin“ habe ich bei fast jedem Unternehmen gehört. Sinnvolles Training war immer ein Kampf bergauf.
    Für gutes Training braucht es innerhalb der technischen Rollen genug Menschen mit Breite und Qualität. Sie müssen nicht alle neuesten Technologien kennen, aber sie müssen Bullshit erkennen und benennen können. FAANG ist da keine Ausnahme.

• Wie auch in diesem Artikel angesprochen, ist der eigentliche Kernpunkt, dass QA für Geschäftsbereiche und obere Führung fast immer wie eine Kostenstelle aussieht.
  Ich habe die Hypothese, dass man besser nicht in Organisationen arbeitet, die als Kostenstelle wahrgenommen werden. Boni, Anerkennung und Respekt gehen immer an die Seite, die Geld verdient; Kostenstellen müssen mit weniger Leuten mehr Arbeit übernehmen, bekommen die Schuld für Fehlschläge zugeschoben und werden als Erste gekürzt, wenn das Unternehmen schrumpft. Für IT gilt dasselbe.
  Wegen dieses Teufelskreises ist eine QA-Karriere zwangsläufig immer schwieriger als der Weg in die Entwicklung mit ähnlichen Fähigkeiten. Hervorragende Leute brennen aus und gehen so schnell wie möglich weg, und diese Struktur verstärkt sich selbst.

  • Selbst als Mobile-App-Entwickler sollte man meiner Meinung nach darauf achten, keine kostenstellenartigen Arbeiten zu übernehmen.
    Accessibility, Observability, gutes Logging, Verbesserungen an der Testinfrastruktur, CI/CD-Anpassungen, Stabilität sowie besseres Linting und Analyzer-Issues sind alle wichtig, aber belohnt wird man dafür, schnell Features auszuliefern.
    Dieses Jahr habe ich zu viel Zeit in solche Arbeiten gesteckt, weil ich dachte, dass Team und App sie brauchen, und jetzt mache ich mir Sorgen um die Leistungsbeurteilung zum Jahresende. Jetzt verstehe ich, warum andere diese Arbeiten gemieden haben, und nächstes Jahr will ich mich stärker auf sichtbarere Feature-Releases konzentrieren. Die Bugs in der App tun mir leid, aber ich brauche meinen Job, um die Hypothek abzuzahlen.
  • Dem Gefühl der Kostenstelle stimme ich zu, aber meiner Erfahrung nach ist es etwas nuancierter.
    Manche Organisationen schätzen den Wert, den QA/QC bringt, wirklich. In der Fertigung habe ich das deutlicher gesehen als in Software; ich vermute, weil Software grundsätzlich abstrakter ist und Verschwendung schwerer nachzuverfolgen ist.
    Wirklich gute QA machen nicht Menschen, die den einfachen Weg suchen, sondern Menschen, die an die Mission von QA glauben. Letztlich heißt das: Wert entsteht, wenn Organisationen und Einzelpersonen den QA-Geist ernsthaft annehmen; viele Orte tun es nur pro forma.
  • In einem Frontend-Plattform-Team arbeite ich an Performance-Verbesserungen, CI-Design und Process Engineering, aber Anerkennung und Beförderungen zu bekommen ist viel schwieriger als für Leute, die Features ausliefern, die sich direkt als Geld auf dem Bankkonto niederschlagen.
    Das ist trotzdem in Ordnung. Mir macht es Spaß und es beruhigt mich, Dinge besser und robuster zu machen. Das Kaputtmachen überlasse ich den Zynikern.
  • Ich habe mein ganzes Leben fast nur in Kostenstellen gearbeitet, aber ich möchte es gegen nichts anderes eintauschen.
    Es ist in Ordnung, wenn Boni und Ähnliches an andere Gruppen gehen. Ich werde als technische Fachkraft gut genug bezahlt, und viele dieser geldverdienenden Rollen hätten mich, selbst wenn ich sie tatsächlich gut gemacht hätte, wirklich unglücklich gemacht.
  • Deshalb arbeite ich nicht in der IT-Abteilung eines traditionellen Unternehmens.

• Softwarequalität, Wartbarkeit von Code und gutes Design sind nur wichtig, wenn man vorhat, lange in diesem Unternehmen zu arbeiten.
  Wenn man nach ein paar Jahren zur nächsten Firma wechseln will, ist der optimale Weg, sichtbare Arbeit zu machen, schnell aufzusteigen und diesen Lebenslauf zu nutzen, um einen besser bezahlten Job zu bekommen. Wenn das Projekt ein paar Jahre später zerbricht oder unwartbar wird, ist das egal, denn dann ist man schon nicht mehr da.
  Startups funktionieren nach demselben Muster. Das überall eingravierte Growth Mindset ist genau dieses Muster. Wenn das Produkt in fünf Jahren unwartbar ist, kann man bis dahin schon den Exit geschafft und ausgecasht haben.
  Ich mache solchen Leuten nicht exakt Vorwürfe. Es sind Praktiken, die Unternehmen selbst einsetzen, und die Leute spielen nur nach diesen Regeln. Ich mag es nicht und hasse es wirklich, aber ich verstehe es.
  Der interessante Teil ist, wenn Manager und Executives sich über Fluktuation, mangelndes Commitment zum Unternehmen und Quiet Quitting beschweren. Es ist, als würden sie selbst das Gift kosten, das sie geschaffen haben.

  • Es kann eine rationale Haltung sein, dass ein Startup damit rechnet, dass das Produkt in fünf Jahren möglicherweise unwartbar ist. Die meisten Startups überleben keine fünf Jahre und scheitern.
    Wenn man nach fünf Jahren mit technischer Schuld noch am Leben ist, ist das für viele Startups eher ein gutes Problem. Denn es bedeutet immerhin, dass man fünf Jahre durchgehalten hat.

• QA-Engineers sind in der Regel auch sehr gut im Debugging. Sie fassen Pipelines, Source- und Testverzeichnisse an und befassen sich mit fast allen Aspekten von Anwendungsentwicklung und Deployment.
  Als ich QA Lead war, habe ich oft Software Engineers gesehen, die täglich in Slack klagten, aber Pipeline-Fehlermeldungen nicht lesen wollten. Auch bei der Pipeline-Optimierung ignorierten sie das Grundproblem und versuchten tagelang, die daraus entstehenden Symptome mit Vermutungen zu lösen, als wären es magisch unerklärliche Probleme.
  Die in diesem Beitrag beschriebene Geringschätzung gegenüber QA-Engineers ist keine Übertreibung. Selbst Unternehmen mit QA-Organisation haben oft keine so strengen Interviewprozesse wie Engineering-Organisationen, weshalb QA-Engineers geringer bewertet werden.
  Die einzigen SWEs, die QA respektierten, waren diejenigen, die selbst einmal in QA gearbeitet hatten. Die Geringschätzung war so allgegenwärtig, dass ich schließlich in die Engineering-Organisation zurückging und versuchte, mit meiner Seniorität als Principal Engineer oder über Managementrollen etwas zu ändern, aber ich scheiterte. Engineering konnte nicht über die eigene Arroganz hinausblicken, und Leadership half auch nicht.
  Der neue CTO des Unternehmens, bei dem ich vor meiner Entlassung gearbeitet hatte, sagte, man könne den Bedarf an QA durch Automatisierung beseitigen, nannte aber kein einziges Beispiel dafür, was das bedeuten sollte. So gering war der Respekt von oben für die Arbeit, gute Software zu bauen.

• Microsoft scheint das auffälligste Beispiel für dieses Problem zu sein. Nachdem die QA-Teams abgeschafft wurden, haben Bugs in Updates für Windows und Cloud-Produkte spürbar zugenommen.

  • Der Umsatz kommt weiter rein, also war es geschäftlich wohl die richtige Entscheidung … seufz.
    Ich nutze bei der Arbeit viel Microsoft-Software und -Services und würde mir wünschen, dass sie für den Qualitätsverfall in irgendeiner Form einen Preis zahlen müssten.

• Das mag persönliche Erfahrung sein, aber ich habe noch nie ein QA-Team gesehen, das tatsächlich Tests für Engineering schreibt.
  Die QA-Teams, die ich erlebt habe, schrieben Testpläne und führten sie manuell aus oder, seltener, über automatisierte Browser- und Gerätetests. Auch solche Tests haben Wert, aber ich halte sie für weniger wertvoll als Unit-Tests oder Integrationstests.
  In diesem Modell wurde faktisch das Engineering-Team zum QA-Team, während das separate QA-Team oft Dinge, die keine Bugs waren, wie Bugs aufspürte, Rauschen erzeugte und mehr Kosten verursachte, als es Wert lieferte.
  Ich würde gern ein Modell für gut funktionierende QA-Teams kennenlernen. Manuelles Testen ist großartig, hat meiner Erfahrung nach aber Grenzen. Ich will QA-Leute nicht abwerten, sondern teile nur meine Erfahrung.

  • Der Wert von QA liegt meiner Erfahrung nach in der Produktvertrautheit. Gute QA kennt besser als alle anderen, wie das Produkt tatsächlich funktioniert.
    Sie kennt das gesamte für Nutzer sichtbare System umfassender als PMs, Sales oder die meisten Entwicklungsteams und kann genau sagen, was passiert, wenn man welchen Button drückt. Schlechte QA ist zwar tatsächlich eine Quelle von Rauschen, aber schlechte Entwickler, Systemadministratoren sowie 1st- und 2nd-Level-Support sind es ebenso.
  • Gute QA ist für Softwareentwickler das, was ein guter Lektor für einen Autor ist. Sie betrachtet das mit viel Mühe Geschaffene nüchtern und kritisiert es schonungslos.
    Während man es abbekommt, ist es wirklich nervig, aber die Qualität des Ergebnisses wird deutlich besser.
    Früher schrieb QA meist keine Tests, sondern testete den Code manuell und probierte all die seltsamen Dinge aus, von denen man hoffte, dass Nutzer sie nicht tun würden. So fand sie Probleme und Bugs, die sich mit Tests allgemein nur schwer abdecken lassen.
    Heute wälzen wir QA auf die Nutzer ab. Wenn ich mit jungen Entwicklern arbeite, merke ich, dass ihnen das Konzept QA selbst zunehmend fremd wird. Wenn ein Bug in Produktion landet und ich frage: „Wie war es, als du es lokal ausprobiert hast?“, bekomme ich oft seltsame Blicke. Nach dem Motto: Der Type Checker ist durchgelaufen, warum also nicht releasen?
    Heutzutage wird die Effizienz von Programmierern an PRs pro Minute gemessen, also ist das Einführen von Bugs kein Problem, sondern eher gut. Wenn jemand sie in Produktion findet, kann man ein paar Tage später noch einen PR zur Behebung einreichen. QA hätte diesen Ablauf nur gestört.
  • Ich bin QA und schreibe Tests für Engineering; mein genauer Titel ist SDET. Ich kümmere mich nicht nur um Testpläne, sondern auch um Test-Frameworks, Infrastruktur und die Automatisierung dieser Testpläne.
    Jedes Unternehmen implementiert die QA-Funktion anders. Manche überlassen sie den Kunden, andere Entwicklern, Customer Support, manueller QA oder SDETs. Am Ende hängt es davon ab, wie wichtig Leadership Qualität nimmt und wie es QA wahrnimmt.
    Wenn es ein QA-Team gibt, hat es meiner Ansicht nach die größten Erfolgschancen, wenn es früh im Prozess eingebunden wird. Ein gutes QA-Team sollte Bugs finden, bevor Code geschrieben wird. Je später es eingebunden wird, desto später werden auch Bugs gefunden, und desto stärker wird es zwischen „Code complete“ und Release eingequetscht. Ein QA-Team braucht Automatisierungskompetenz, damit es seine Zeit in neue Testfälle investieren kann, statt manuelle Tests immer wieder zu wiederholen.
    Dieser Beitrag trifft ziemlich schmerzhaft. QA wird manchmal wie ein Bürger zweiter Klasse behandelt und aus Diskussionen ausgeschlossen, in denen sie den Kontext bekommen könnte, um ihre Arbeit richtig zu machen. Wenn gute Leute in Entwicklung oder Produktmanagement abwandern, wird es schlimmer, und die Abwärtsspirale gibt es wirklich.
  • Es gibt keine offizielle Standardmethode, eine QA-Organisation zu betreiben, sodass Leute nach der Einstellung oft zu hören bekommen: „Macht einfach mal.“ Dann verstehen andere Organisationen die Bedürfnisse von QA nicht und ignorieren sie.
    Was hier beschrieben wird, ist ein Leadership-Problem, kein Problem der Nützlichkeit von QA.
  • Im klassischen Modell funktionierten die meisten QA-Organisationen wie nutzlose Anhängsel. Das lag sowohl an der Struktur als auch zu einem großen Teil daran, dass QA verdrängt wurde, wenn die Entwicklung in Verzug geriet.
    QA verbrachte Zeit damit, Testinfrastruktur und Testpläne zu bauen, ohne früh eingebunden zu sein, und bekam dann am Ende einen Haufen Code und einen 48-Stunden-Freigabeplan, um unter extremem Druck zu signieren.
    Aber gelegentlich traf man QA-Organisationen, die den Problembereich tief verstanden und die Entwicklung tatsächlich mit vorantrieben. Sie arbeiteten von Anfang bis Ende Seite an Seite mit der Entwicklung, steigerten nicht nur die Qualität, sondern sparten allen Zeit.

• Bei der Entwicklung von FoundationDB lag der Fokus fast schon obsessiv auf Qualität und Tests. Dafür wurde sogar eine Sprache namens Flow entwickelt, um FDB-Cluster beliebiger Größe deterministisch zu simulieren, sie extremen Bedingungen auszusetzen, Verstöße gegen Systemeigenschaften anzuzeigen und den Testlauf, der den Verstoß verursacht hatte, perfekt reproduzieren zu können.
  Jede Nacht liefen zehntausende Testläufe, bis zu dem Punkt, an dem sie ohne neuen Code im Grunde alle grün waren. Tests, die rot wurden, waren fast immer auf kürzlich hinzugefügten Code zurückzuführen und ließen sich daher leicht identifizieren und beheben.
  Dadurch konnte das Team entwickeln, in dem Wissen, dass neu eingebrachte Bugs schnell gefunden würden. Das führte zu einer Geschwindigkeit, mit der man sich nach dem Release selbst gewagte Projekte wie eine Neuschreibung des Transaktionsverarbeitungssystems zutraute. Das Ergebnis war auch eine 10-fache Geschwindigkeitssteigerung.
  Am Ende führte der Fokus auf Qualität zu mehr Geschwindigkeit; beides stand überhaupt nicht im Widerspruch zueinander. Ich halte das nicht für ein isoliertes Phänomen, und deshalb führte es zu einem neuen Projekt, aber das ist eine andere Geschichte.

  • Ist diese Sprache dieses Flow? https://github.com/apple/foundationdb/blob/main/flow/README....