Vor anderthalb Jahren haben wir das Testteam zerstört: Wir haben die Regression aufgegeben, E2E-Autotests an Selenium übertragen, um Entwickler zu unterstützen, und sind zu Teams gegangen, die Funktionen zur Verhinderung von Fehlern im Keim gesehen haben. In rosigen Träumen schien es uns nützlicher zu sein: QS-Arbeit an Qualität, Tests beginnen früh, und Entwickler schreiben selbst Autotests, und niemand stört sie.
Aber so
Was sind die Konsequenzen erster und zweiter Ordnung?
Ray Dalio in Principles hat das Konzept der "Konsequenzen zweiter Ordnung". Dies sind nicht offensichtliche Konsequenzen unserer Entscheidungen, die wir oft nicht vorhersagen können. Zum Beispiel wurde in den 60er Jahren des 20. Jahrhunderts in China ein Krieg mit Spatzen begonnen. Spatzen aßen Getreide, und damit sie aufhörten, es zu essen, begann China, nach Vögeln zu suchen. Während der Jagd töteten die Chinesen massenhaft fast zwei Milliarden Vögel.
Infolge des Völkermords an Spatzen nahm die Ernte nach einem Jahr zu. Dies sind Konsequenzen erster Ordnung. Aber es gab niemanden, der Insekten, Heuschrecken und Raupen vermehrte, was dazu führte, dass noch mehr Getreide zerstört wurde, was in den folgenden Jahren zu einer massiven Hungersnot in China führte. Dies sind Konsequenzen zweiter Ordnung.
Die Konsequenzen erster Ordnung sind direkte Konsequenzen unserer Entscheidungen und liegen immer an der Oberfläche. Konsequenzen zweiter Ordnung sind subtil und oft langfristig. Um sie zu verstehen, müssen Sie die Situation denken und simulieren. Zum Beispiel:
- Wenn Sie Entwickler für die Anzahl der Codezeilen bezahlen, gibt es mehr Code, aber die Qualität ist schlechter. Mit der Zeit werden die Leute anfangen zu schummeln und immer mehr schlechten Code zu produzieren, um mehr Geld zu bekommen. Dies sind Konsequenzen zweiter Ordnung.
- Wenn Sie anfangen zu trainieren, tut es zuerst weh und dauert lange. Aber nach einer Weile (von einer Woche bis zu Monaten) wird eine Gewohnheit entstehen und Gesundheit und Aussehen werden sich verbessern. Dies sind Konsequenzen zweiter Ordnung.
- Wenn Sie sich jeden Freitag wie ein Schwein betrinken, ist Freitagabend gut. Aber der Samstagmorgen wird schlecht - das sind Konsequenzen zweiter Ordnung. Und wenn Sie dies jahrelang regelmäßig tun, entwickelt es sich möglicherweise zu Alkoholismus und Leberzirrhose. Aber das sind schon Konsequenzen dritter Ordnung und "eine ganz andere Geschichte"
Wir hatten ein QS-Team und haben es "zerstreut"
Jetzt werde ich Ihnen erzählen, wie wir die Konsequenzen sowohl der ersten als auch der zweiten Ordnung empfunden haben. Wir hatten ein gemütliches, engagiertes Team von Testern mit 7 Personen: 4 von ihnen schrieben Autotests und 3 testeten sie manuell. Irgendwann beschlossen wir, uns aufzuteilen und in Teams zu verteilen. Warum?
Weil die Entwickler zu spät Feedback erhalten haben.
Die Fehler befanden sich in dem Stadium, in dem die gesamte Entwicklung „abgeschlossen“ war, alles „integriert“ war und überprüft werden musste, ob das Produkt zur Veröffentlichung bereit war. Es gab keine Abnahmetests , sie wurden von Produktanalysten durchgeführt, die keine Testfähigkeiten hatten. Darüber hinaus befanden sich Tester und Entwickler in verschiedenen Welten und interagierten wenig.
Die offensichtliche (damalige) Lösung besteht darin, sich in Teams aufzuteilen , die an bestimmten Funktionen (Teilen) des Systems arbeiten, um Fehler im Keim zu vermeiden. Wir wollten unseren Job nicht aufgeben und beschlossen, unsere Funktionen an die Entwickler zu übertragen. Wir haben über Autotests nachgedacht - wir werden sie den Entwicklern übergeben und sie werden sich ohne Probleme selbst testen.
Zunächst beschlossen sie, die Hypothese mit einem "Experiment" an uns selbst zu testen: Wir werden die kritischen Szenarien der Regression mit automatischen Tests abdecken und die manuelle Regression ablehnen. Wenn die Anzahl der Hotfixes und Release-Rollbacks aufgrund der Erfahrung nicht dramatisch zunimmt, kann das Experiment als erfolgreich angesehen werden. Und so geschah es - es gab keine Hotfixes mehr. Gelöst - nicht einverstanden.
Hinweis . Das Unternehmen hat ein Produkt namens Restaurant. Es beinhaltet alle Dienstleistungen und unseren Monolithen. Ziel des Produkts ist es, die Arbeit aller Restaurantmitarbeiter so weit wie möglich zu automatisieren und zu optimieren. Unsere Arbeit konzentriert sich jetzt mehr auf die Fehlervermeidung. Jetzt sind wir QS im Produkt "Restaurant": Wir entwickeln die Eigenschaften des Produkts und beteiligen uns an allen Phasen der Aufgabenentwicklung.
Konsequenzen erster und zweiter Ordnung
Direkte Konsequenzen . Wie erwartet haben wir uns von Anfang an mit der Entwicklung von Aufgaben befasst, um an Züchterrechten, Planungen, Workshops teilzunehmen und Test-Know-how zu vermitteln. Wir sind den Entwicklungsteams näher gekommen oder eher ein Teil davon, und unsere Probleme waren auch die Probleme des Teams. Das Fachwissen in Bezug auf Tests, Qualitätssicherung und umfassende Kenntnisse des Systems begann in den Teams zu wachsen. Wir wiederum begannen, in die Arbeit der Entwickler einzutauchen und ihre Schmerzen zu verstehen.
Was wir nicht geplant haben, sind Konsequenzen zweiter Ordnung .
Niemand bestimmt die Qualität des Produkts . Dieses Problem hat zwei Seiten:
- Qualität in Bezug auf Prozesse;
- Qualität der Autotests und der Pipeline.
In unserem engagierten QS-Team haben wir die Qualität gesteigert. Wir waren die letzten, die das Produkt vor den Benutzern gesehen und verstanden haben, wie sie es sehen. Wir diskutierten Änderungen und Verbesserungen am Team Retro und kamen mit Vorschlägen an die Entwicklungsteams, um gemeinsam zu entscheiden, ob sie eingeführt werden sollten. Wir haben Autotests überwacht und an ihrer Stabilität gearbeitet.
Nachdem wir uns in Teams verteilt hatten, verschwand alles irgendwo. Im Entwicklungsteam sind wir Teil des Teams,
Alle Ideen zielten nur darauf ab, den Zustand des Teams zu verbessern - wir haben alles getan, um ein Qualitätsmerkmal zu veröffentlichen, kein Qualitätsprodukt. Infolgedessen gibt es keine grundlegend starken Lösungen mehr, die die Produktqualität auf ein neues Niveau heben können.
Die Kompetenz, Autotests zu schreiben, ist verschwunden - Autotests begannen sich zu verbiegen und fielen häufiger, ohne den Code zu ändern. Als das Team aufgelöst wurde, begannen manuelle Tester gerade erst, die Grundlagen der Automatisierung zu verstehen. Es stellte sich heraus, dass weder die Tester noch die Entwickler über Fachwissen verfügten. Darüber hinaus wurden die Fachkenntnisse verwirrt, als die Personen, die diese Tests geschrieben haben, zu Entwicklung, Produktmanagement übergingen und jemand kündigte.
Wir wussten nicht zuverlässig, welche Autotests wir haben, was sie abdecken, wir wussten nicht, wie sie sich entwickeln, entwickeln, hinzufügen oder entfernen - alles wurde der Gnade der Entwickler überlassen. Als es daher notwendig war, einige Informationen in Autotests zu finden, war es dieselbe Aufgabe, die Sie ohne einen Entwickler nicht herausfinden können.
Zusätzliche Arbeit für Entwickler . Es ist schwer, Entwickler zu sein. Wenn sie früher Produktcode geschrieben haben, der „magisch“ überprüft wurde und in die Produktion geht, müssen sie jetzt selbst Tests schreiben, bearbeiten und stabilisieren. Bei PBR legen wir fest, welche Szenarien von Tests abgedeckt werden sollen, und die Entwickler wählen die Stufe der Autotests selbst aus.
Die Entwickler haben mehrere Phasen durchlaufen, um den
Negation... Alle Dodo IS-Versionen werden von Entwicklern gerollt. Sie organisieren den Prozess, kommunizieren mit dem Lasttest-Team, sehen sich die Protokolle an und überwachen während der Freigabe. Die Entwickler, die die Version mit dem roten Test konfrontiert hatten, versuchten nicht, den Grund herauszufinden, sondern starteten die Pipeline einfach neu, bis sie 5-7-10 Mal grün wurde. Dies liegt daran, dass kein Vertrauen in Autotests bestand.
Die maximale Anzahl von Neustarts, die ich gefunden habe, ist 44 Mal !!! Es scheint mir, dass die Regel, die wir für einen der Retro-Artikel „Nicht mit roten Tests veröffentlichen“ übernommen haben. Wenn der Test rot ist, finden Sie heraus, wo das Problem liegt. Wenn das Problem in den Tests liegt, beheben Sie es oder unterschreiben Sie es und erstellen Sie eine Karte, um den Test zu entsperren und dem Backlog hinzuzufügen. "
Wut : Die Entwickler haben bei unseren Tests geschworen, sie sagten, dass sie
Es gab keine Verhandlungen oder Depressionen, die Akzeptanz kam sofort : Entwickler können jetzt E2E-UI- und API-Tests selbst schreiben, stabilisieren und verbessern.
Die Anzahl der verkauften Bugs begann zu steigen . Unkritische Fehler begannen in die Produktion einzudringen. Dafür gibt es mehrere Gründe:
- Unsere Autotests decken nicht alle Funktionen ab, sondern nur die kritischen. Und es gibt keine manuellen Regressionstests mehr.
- Es gab nicht genügend QS-Ingenieure für alle Teams. Die Teams hatten keine Testkompetenzen, daher achteten sie nicht auf das Testen
Infolgedessen haben wir versehentlich Fehler in der Produktion gefunden. Sie sind nicht kritisch, aber wie viele von ihnen im Allgemeinen wurden nicht vorgestellt.
Wie lösen wir diese Probleme?
Vielleicht hätte ein anderes Team alle nicht offensichtlichen Konsequenzen vorhersagen können, aber wir konnten es nicht. Nachdem einige Monate die Konsequenzen erkannt hatten, trafen wir eine Entscheidung und begannen, sie zu beseitigen.
Erstellt eine Restaurant-QA-Gilde oder Community of Practice, die alle Restaurant-QAs enthält. Das Ziel der Community ist es, die Qualität des gesamten Produkts zu verbessern und allen Produktteams gute Testpraktiken zu vermitteln. Dies ist eine Ausbildung, die die Vorteile eines engagierten QS-Teams vereint, und wir profitieren auch davon, QA im Entwicklungsteam zu sein.
Wir treffen uns einmal pro Woche: Wir teilen Ergebnisse, Entdeckungen und planen, gemeinsam an der Qualität zu arbeiten. Wir vergeben auch mehrere Slots pro Woche für die Arbeit an Gildenaufgaben. Zum Beispiel beenden wir unseren Assistenten-Bot für Freisetzer.
Pflicht... Die Gilde deckt teilweise das Problem des Mangels an Qualitätsbesitzern und Autotests ab. Da die Gilde jedoch keine starken Kompetenzen in Entwicklung und Automatisierung besitzt, traf unser CTO eine willensstarke Entscheidung und organisierte eine Aufgabe in der Pipeline.
Jetzt können Entwickler den Pipeline-Prozess systematisch verbessern: Stabilisieren, Probleme finden, die Releases verzögern, und beheben. Ein Entwickler aus dem Entwicklungsteam wird für einen Monat Eigentümer der Pipeline und verbessert sie systematisch. Nicht freigeben, sondern verbessern - das macht die Freigabe und Unterstützung von Tests einfach und mühelos. Nachdem sich die Produktmetriken verbessert haben, haben wir diese Vermittlung entfernt, können sie jedoch jederzeit zurückgeben. (Beim Schreiben eines Artikels haben wir ihn zurückgesandt, da der Hinweis die Stabilität beeinträchtigt.)
Kurse... Wir schließen das Problem mangelnder Kompetenzen mit Kursen für manuelle Tester und arbeiten mit Entwicklern mit Erfahrung in der Automatisierung zusammen.
Zusätzliche Arbeit für Entwickler . Sie können nichts dagegen tun, die Entwickler haben gerade das Stadium der Annahme von Autotests erreicht. Jetzt schreiben sie selbst E2E-Tests, wenn untergeordnete Tests ein Feature nicht abdecken können, und stabilisieren die Pipeline. Wie es in intelligenten Büchern heißt, ist es eine gute Praxis, wenn das gesamte Team sowie Entwickler und Tester Tests schreiben können. Bei unserer Wanderung zur Seite sahen wir die Mikrodienste des Monolithen. Es gibt weniger Tests im Monolithen und immer mehr in separaten Repositorys wird die Pipeline stabiler.
Wir untersuchen das Produkt... Wir lösen Probleme mit Fehlern in der Produktion, indem wir das Produkt auf Inkonsistenzen mit dem erwarteten Verhalten untersuchen. Wir haben wöchentliche Erkundungstests geplant. Und wir bringen Fehler in den Rückstand zum Product Owner.
Was würden wir jetzt tun?
Die Nichtberücksichtigung von Konsequenzen zweiter und dritter Ordnung hat zu schlechten Entscheidungen geführt. Es ist besonders gefährlich, wenn die erste und nicht die beste Option eine bereits bestehende Tendenz verstärkt. Aber jetzt, mit all den gesammelten Erfahrungen, hätten wir anders gehandelt.
Zum Beispiel könnte der Verlust von Kompetenzen behoben werden, indem sie gebeten werden, die Kompetenz einige Monate vor dem Übergang von Personen mit Automatisierungskompetenz mit allen QS-Ingenieuren in einem Produkt oder Entwicklern aus Teams zu teilen. Und auf einmal besser für alle.
Es gibt keine Möglichkeit, das Problem der zusätzlichen Arbeit für Entwickler zu kompensieren, aber Sie könnten den Schmerz beim Schreiben von Tests verringern, indem Sie es nicht vor eine Tatsache stellen, sondern:
- Zeigen Sie den Wert von Tests explizit an.
- Unterrichten Sie Entwickler, diese Tests zu schreiben, zu verbessern und zu warten.
- ( ), .
Als wir getrennte Wege gingen, haben wir nicht einmal über diese Probleme nachgedacht. "Im Nachhinein" scheint es, wie kann es sein, darüber nachzudenken, elementar zu sein. Aber im Nachhinein sind wir alle stark - versuchen Sie, die Zukunft vorherzusagen.
Die Konsequenzen zweiter oder dritter Ordnung für mich können die Konsequenzen erster Ordnung für erfahrenere Menschen sein, die solche Entscheidungen oft getroffen und die Ergebnisse solcher Entscheidungen gesehen haben.
Es gibt zu viele Unsicherheiten und Variablen, die die Ergebnisse beeinflussen.
Es ist wichtig, die Konsequenzen nicht vorherzusagen, sondern zumindest zu wissen, was sie sein könnten. Bevor Sie eine Entscheidung treffen, ist es wichtig, über die wahrscheinlichen Folgen nachzudenken und Informationen über Fälle in anderen Unternehmen zu lesen, um zumindest eine Vorstellung vom Ausmaß möglicher nicht offensichtlicher Folgen zu erhalten.
Jeder, der lernt, die Konsequenzen der zweiten (und sogar dritten) Ordnung von Entscheidungen vorherzusagen, kann die Menschheit retten oder zerstören. Oder verdienen Sie mehr Geld als Scrooge McDuck - zumindest durch Kursschwankungen.
Wie soll ich jetzt versuchen, die Konsequenzen vorherzusagen?
Ich habe Artikel zu diesem Thema gelesen und für mich mehrere Regeln abgeleitet, die nach Angaben der Autoren dazu beitragen, solche Konsequenzen vorherzusagen. Ich werde versuchen, sie zu benutzen:
- Bevor Sie eine Entscheidung treffen, stellen Sie sich die Frage "Was wird als nächstes passieren?" und fügen Sie der Frage Zeitfenster hinzu. Was wird in 10 Minuten, 10 Monaten oder 10 Jahren passieren?
- Trainieren Sie Ihr Denken in Bezug auf solche Konsequenzen, indem Sie über verschiedene Situationen nachdenken. Was sind zum Beispiel die Konsequenzen der ersten zweiten oder sogar dritten Ordnung, wenn die ganze Welt auf Elektroautos umstellt oder zum Beispiel ein bedingungsloses Grundeinkommen einführt. In dieser Übung gibt es keine richtigen Antworten, aber Sie können darüber nachdenken.
- Denken Sie daran, dass der erste Gedanke in Ihrem Kopf die erste Ordnung ist. Ist immer.
Wenn Sie beim Ändern der Organisation des Testteams oder anderer Teams auf andere Probleme gestoßen sind, schreiben Sie in die Kommentare. Es ist interessant zu wissen, mit welchen Problemen Sie konfrontiert waren und wie Sie sie gelöst haben.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .