Get best of the week

So organisieren Sie Tests, um Produktfreigaben zu beschleunigen und zu stabilisieren. Teil 1

Wenn keine Teamarbeit vereinbart wird, kommt es ständig zu Kollisionen zwischen einzelnen Prozessteilnehmern und ganzen Teams, und Unternehmensprodukte oder Microservices innerhalb desselben Produkts stören sich gegenseitig, indem gemeinsame Ressourcen und Infrastrukturen verwendet werden. Das Ergebnis sind dauerhafte Ausfälle, Konflikte und Verlangsamungen. Schnelle und vorhersehbare Veröffentlichungen unter solchen Bedingungen sind nicht erreichbar.

Mein Name ist Victoria Dezhkina. Ich teste in der Abteilung für Entwicklung und Wartung von Big-Data-Produkten der X5 Retail Group. Ich werde Ihnen sagen, wie wir den Testprozess in einem unserer Produktteams geändert haben, um die Vorbereitung von Releases um fast die Hälfte zu beschleunigen und das Team von Stress zu entlasten. Jetzt führen wir diesen Ansatz zum Testen in anderen Produkten des Unternehmens ein.



Die Big Data-Direktion der X5 Retail Group entwickelt derzeit 13 Produkte, von denen sich 4 in der Monetarisierungsabteilung befinden, wo die Produkte auf den ausländischen Markt ausgerichtet sind. Jeder Fehler, ob es sich um einen Produktfehler oder eine verspätet veröffentlichte Funktion handelt, hat wirtschaftliche Auswirkungen und führt zum Verlust von Kunden . In der Tat sind dies interne Teams, die auf dem ausländischen Markt verdienen und nach den Regeln kleiner Unternehmen in einem großen Unternehmen spielen.

Alle unsere Produkte unterscheiden sich erheblich in ihren Zielen und erfordern daher unterschiedliche Entwicklungs- und Testansätze. Sie haben jedoch viele Gemeinsamkeiten: Sie verwenden dieselbe Infrastruktur (Kubernetes, Greenplum, Testserver), und Entwickler aus verschiedenen Produktteams ersetzen sich manchmal für eine Weile Urlaube.

In einer solchen Situation nimmt die Rolle von Vereinbarungen stark zu: Wenn ein Teil des Teams nicht weiß, was der andere tut, und jedes Team seine eigenen Regeln hat, treten unvermeidlich Probleme auf.

Beispielsweise verwenden zwei Produkte dieselbe Lasttestinfrastruktur, und beide müssen dringend Tests durchführen. Ohne sich gegenseitig zu benachrichtigen, tun sie dies gleichzeitig, wodurch sie falsche Ergebnisse erhalten, weil das DBMS "festgelegt" hat und aufgrund dessen es nicht klar ist. Sie wollten Zeit bei den Verhandlungen sparen, dadurch verloren sie viel Zeit ohne Ergebnis.
Datenverlust ist nicht ausgeschlossen. Angenommen, eines der Produkte belegt einen kostenlosen Testserver, ohne dass jemand darüber gewarnt wird. Offiziell gilt die Hardware als kostenlos, sodass ein anderes Produkt dort eingeht und versehentlich alle Testdaten des ersten löscht. Dies sind natürlich keine Benutzerdaten, sondern nur Tests, aber immer noch ein ziemlich unangenehmer Fall.

Es gibt möglicherweise einfach nicht genügend Arbeitskräfte, wenn die Arbeit nicht im Voraus geplant ist. Zum Beispiel arbeiten Stresstests in unserer Direktion jetzt in einem Serviceformat, dh wir wählen auf Anfrage den geeigneten Spezialisten für Teams aus. Wenn mehrere Teams ohne Vorwarnung an einem Tag Lasttests verlangen, sind möglicherweise überhaupt nicht genügend Tester vorhanden.

Es scheint, dass der einfachste Ausweg in einer solchen Situation darin besteht, einheitliche Regeln für die Interaktion für alle Produkte festzulegen. Das Problem ist jedoch, dass alle Produkte unterschiedlich sind. Einige von ihnen sind für interne Benutzer bestimmt, dh für Spezialisten aus anderen Abteilungen des Unternehmens, z. B. Dienstleistungen zur Preisgestaltung oder zur Untersuchung der Nachfrage. Der andere Teil wurde für externe Benutzer entwickelt - zum Beispiel für Lieferanten. Diese Produkte haben völlig unterschiedliche Architekturlogiken und Qualitätskriterien.

Produkte in verschiedenen Bereitschaftsstadien akzeptieren ebenfalls nicht denselben Ansatz: In einem frühen Stadium, in dem ein Produkt Ideen testet, besteht die Priorität darin, die Funktionalität für den Benutzer und das Fehlen von Bedrohungen für die Unternehmenssicherheit zu verstehen. Wenn ein Produkt unterstützt wird, stehen andere Anforderungen an erster Stelle: Benutzerkomfort, Stabilität der vorhandenen Funktionalität, schnelle Reaktion auf Fehler und vollständige Einhaltung der Sicherheitsrichtlinien des Unternehmens.

Diese beiden Faktoren - gemeinsame Arbeit auf demselben Gebiet und einzigartige Produktmerkmale - stellen uns vor die Aufgabe: Regeln zu entwickeln, die es den Teams ermöglichen, sich nicht gegenseitig zu stören, aber gleichzeitig Tester und Entwickler nicht an Hand und Fuß bindenund sie werden die Entwicklung verschiedener Produkte nicht auf eine Vorlage reduzieren und alle Vorteile von Agilität und einen Produktansatz im Keim ersticken.

Ich werde ein paar Worte darüber sagen, warum Tester eine führende Rolle bei der Schaffung von Standards für die Interaktion in Produktteams spielen. Tatsache ist, dass wir aufgrund der Besonderheiten unserer Arbeit das gesamte Produkt sehen, während sich Entwickler normalerweise auf einen kleinen Bereich konzentrieren. Wir sind die ersten, die Probleme bemerken und Lösungen für sie anbieten, aber die endgültige Lösung wird gemeinsam mit den Entwicklern erarbeitet.

Wir haben bereits geschrieben, wie diese kollektive Arbeit abläuft : In der Anfangsphase müssen wir buchstäblich ein einziges Wörterbuch zusammenstellen, um nicht verwirrt zu werden. Dies ist jedoch nur der Anfang. Als nächstes müssen wir uns auf eine Masse sehr unterschiedlicher Nuancen einigen.

Ich werde Ihnen am Beispiel eines unserer Produkte erzählen - eines Beschaffungsautomatisierungssystems für ein Vertriebsnetz. Seine Aufgabe ist es, den Betrieb aller Prozesse von dem Moment an sicherzustellen, in dem das Geschäft bestimmte Waren benötigt, bis zu dem Moment, in dem er sie erhält.

Welche Prozesse haben sich in unserem Produkt geändert?


Als wir am Produkt ankamen, sollten die Veröffentlichungen alle zwei Wochen veröffentlicht werden, aber sie waren fast immer einige Tage zu spät, und der Veröffentlichungstag bedeutete immer, dass wir definitiv bei der Arbeit bleiben und bis zum letzten Mal die vorhandene Version stabilisieren würden. Es war notwendig, etwas zu ändern.

Es ist wichtig zu beachten, dass Veränderungen eine häufige Ursache sind. Was auch immer ihr Initiator, der Tester oder die Entwickler selbst sein mögen, sie können nicht ohne die Zustimmung des gesamten Teams und der starken Verbündeten auskommen. Änderungen müssen vom gesamten Team besprochen werden, um so viele Ideen wie möglich zu sammeln und mögliche Risiken nicht zu verpassen. Der Liefer- und Produktmanager unseres Produkts und vor mir haben systematisch daran gearbeitet, die Prozesse sowohl auf technischer als auch auf Produktseite zu verbessern. Nachdem ich ins Team gekommen war, untersuchte ich den Prozess von der Testseite und gemeinsam erarbeiteten wir eine vereinbarte „Strategie der Veränderungen“. Der erste Punkt war eine Änderung im Layout des Codes.

Code-Layout


Das Berechnungsverfahren ist eines der Hauptprobleme der Teamentwicklung, und hier gibt es sehr unterschiedliche Probleme. Beispielsweise hat ein Team nur einen Zweig mit einem Code, und die Fehlerkorrektur hört hier nicht auf. Oder es gibt mehrere Zweige, aber Aufgaben mit überlappenden Funktionen können gleichzeitig in der Testumgebung angezeigt werden. Infolgedessen können Tester den Fehler nicht lokalisieren oder einige der neuen Funktionen überprüfen, die durch den Fehler einer der Aufgaben blockiert wurden. Und über verzweifelte Entwickler, die es nicht für schlecht halten, die kleinen Dinge auf dem Produkt schnell zu reparieren, ohne andere zu warnen, werde ich im Allgemeinen nichts sagen.

Um all dies zu vermeiden, mussten wir die Anzahl der Zweige und Umgebungen bestimmen und uns auf das Verfahren zum Testen des Codes einigen.

Der einfachste Weg wäre, den Prozess in zwei Zweige mit "sauberem" und "schmutzigem" Code aufzuteilen. Aber wir mussten viele Bedingungen erfüllen:

  • « », « »
  • ,
  • .

Wir haben 2 Stunden damit verbracht, ein neues Arbeitsschema zu diskutieren, und sind zu folgendem Ergebnis gekommen: Wir starten drei Zweige, von denen zwei (Release und Master) mit sauberem Code versehen sind. Im "Master" ist die aktuelle Produktversion, im "Release" - Funktionen, die zur Einführung bereit sind. In Dev findet das Testen statt, hier sind Aufgaben für den Test bereit, die Entwicklung findet lokal statt. Der Rollout für jeden Zweig erfolgt in Absprache mit dem Tester. Hier ist es:



Was hat uns das beim Testen gebracht:

  • Die Testzeit für jede Aufgabe wurde um 20% reduziert. Es war nicht mehr erforderlich, die Prüfung erneut zu starten, wenn eine neue Aufgabe ohne Vorwarnung zum Test eingeführt wurde, neue Aufgaben die Prüfung bereits erledigter Aufgaben nicht blockierten und sich die Zeit für die Lokalisierung von Fehlern beschleunigte.
  • Bis zum geplanten Tag der Korrektur der Version blieben 1-2 Aufgaben anstelle von 4 deaktiviert (dh die Zeit, um sie zu überprüfen, wurde halbiert).
  • Die Zeit für Integrationstests und Freigabekandidatentests wurde von 6 Stunden auf 2 Stunden reduziert (Zählen des Wiederholungstests).
  • Die Anzahl der in der Freisetzungsphase gefundenen Fehler hat abgenommen. Zuvor fanden wir in der ersten Release-Version mehr als 10, jetzt jedoch nicht mehr als 4. Die Zeit für das erneute Testen hat sich um 2 Stunden verkürzt.
  • Parallel zum Testen bestand die Möglichkeit, die Entwicklung fortzusetzen.

Die Gesamtzeit, die wir für das Testen aufgewendet haben, um die Einführung des Produkts zu verzögern, wurde um 8 Stunden reduziert. Nur 2 Stunden, um ein neues Schema für die Arbeit mit dem Team zu besprechen - und es gelang, einen ganzen Arbeitstag zu sparen, der früher alle zwei Wochen verbracht wurde. Nicht schlecht?

Aber die Probleme blieben.

  • , .
  • - , , .
  • .
  • , .

Fazit: Wir haben am Veröffentlichungstag weiter gearbeitet.

Wir versammelten uns wieder. Ein Teil der Probleme wurde gelöst, indem der Entwicklungsprozess verfeinert und CI hinzugefügt wurde:



Wir haben die automatische Einführung in allen Umgebungen für fast einen Monat eingerichtet, dies führte jedoch zu einer Beschleunigung der Zeit um fast 2 Arbeitstage. Das Team hat sich schon lange darauf konzentriert, der Vertriebsleiter und die Entwickler selbst waren daran beteiligt, aber bisher ist es ihnen nicht gelungen, zwei Dinge zu erreichen: Die Einführung in alle Umgebungen ist einheitlich und gleichzeitig bleibt die Versionskontrolle erhalten. Das automatische Rollout verstieß entweder gegen das Hauptprinzip des Testens „Zu jedem Zeitpunkt muss der Tester wissen, was sich in jeder Umgebung befindet“ oder verlangsamte Entwickler, die die Entwicklung der Aufgabe ohne die Erlaubnis zum Rollout des Tests nicht abschließen konnten.

Dies ist ein schwieriges Dilemma. Ignorieren Sie das erste Prinzip, und anstatt zu beschleunigen, wird die Vorhersagbarkeit von Releases und irrtümlich entleerten Aufgaben stark beeinträchtigt. Wenn beispielsweise ein Fehler bereits in Verbindung mit einer „sauberen Aufgabe“ behoben wird, wird beim Ausrollen einer festen Aufgabe mit Sicherheit die fehlerhafte Aufgabe erkannt. Daher müssen Sie entweder auf die Korrektur des Fehlers der zugehörigen Aufgabe warten, das Veröffentlichungsdatum verschieben oder den bereits behobenen Fehler erneut beheben.

Der automatische Roll-out ist keine Person, Sie werden dem nicht zustimmen. Daher haben wir das Problem mit den verbleibenden Fehlern auf eine andere Art und Weise gelöst - einen speziellen Planungsansatz und das Hinzufügen eines weiteren Standes.

Planung für Entwicklung und Test


Bei der Planung diskutierten das Team und ich zunächst, ob den Entwicklern die Aufgabe klar war, wie lange es dauern würde und ob wir in den Sprint passen würden. Der Tester schätzte, wie lange der Test dauern würde.

Gleichzeitig haben wir die möglicherweise auftretenden Fehler überhaupt nicht besprochen: Wir haben sie nicht im Voraus vorausgesehen und nicht in die Liste der möglichen Aufgaben aufgenommen. Als diese Fälle während des Testprozesses herauskamen, wurden sie als separate Aufgabe hinzugefügt, sie brauchten Zeit, um das Release-Volumen zu erarbeiten und zu erhöhen, und manchmal wurden sie nur im Release-Kandidaten gefunden, als sie den Roll-out auf unbestimmte Zeit verschoben hatten. Wir versammelten uns zu dritt - einem Tester, einer Lieferung und einem Produkt - und überlegten uns ein neues Interaktionsschema.

Jetzt sprechen wir alle möglichen Fehler aus, bevor wir mit der Entwicklung beginnen. Ich wurde ein langweiliger Student, der in der Planungsphase alles und jeden fragt: "Was passiert, wenn der Drittanbieter-Service ausfällt?", "Und wenn wir null, aber nicht 0 bekommen?", "Was ist, wenn wir nicht alle Daten erhalten?" "," Und wenn die Pechenegs angreifen? " und so weiter, aber jetzt waren wir zu allem bereit.

Wir haben auch darüber gesprochen, wie wir diese oder jene Aufgabe implementieren und wie wir sie testen werden. Dies ermöglichte es, die Initiative zu reduzieren (zum Beispiel die Erfindung aller Arten von Fahrrädern) und gab jedem Teammitglied ein Verständnis dafür, was seine Kollegen taten. Dies ermöglichte es uns übrigens, die Akzeptanzkriterien (AC) aufzugeben.

Um zu verhindern, dass die Diskussion im neuen Format zu umständlich wird, haben wir dies nicht zwei Wochen im Voraus, sondern eine Woche lang begonnen.

Das neue Code-Layout und die Aufgabenplanung waren nur die ersten Schritte. Im nächsten Teil des Artikels, der morgen veröffentlicht wird, werde ich ausführlich darüber sprechen, wie wir eine ganze Reihe von Prozessen im Team verändert haben:

  • Das Format zum Einstellen und Akzeptieren von Aufgaben und Fehlern: Sie haben User Stories für den für uns bequemeren Hybrid „Anwendungsfall + technische Aufgabe“ hinterlassen.
  • Testmoment: Im Release-Zyklus wurden 5 Punkte festgelegt, zu denen Tester den Prozess der Produkterstellung aktiv steuern.
  • Die Regeln für die Interaktion zwischen der Backend-Testing-Frontend-Verbindung: Wir haben ein Schema entwickelt, mit dem wir alle Daten überprüfen können, die zwischen dem Backend und dem Frontend übertragen werden.
  • Beschleunigung der Arbeit zur Behebung von Fehlern: Festgelegte Regeln für die Priorisierung von Debugging-Aufgaben, um Entwickler nicht erneut abzulenken.

Diese Maßnahmen ermöglichten es uns, den Veröffentlichungszyklus von 2,5 Wochen auf 1 zu verkürzen . Die Geschwindigkeitssteigerung mag gering erscheinen, aber die Hauptleistung war, dass unsere Veröffentlichungen stabiler und vorhersehbarer wurden - wir hatten die Möglichkeit, Veröffentlichungen "auf Befehl" einzuführen: Wir können zusammenkommen Rollen Sie jeden Tag Aufgaben aus und bis zum Abend ist alles fertig und debuggt.

More articles:


All Articles