Hallo, mein Name ist Maksim Plavchenok, ich arbeite für Bercut, ich mache Integrationstests. Im September haben mein Team und ich einen wichtigen Meilenstein überschritten: Wir haben als Ergebnis von Integrationstests für die Veröffentlichung einer neuen Version der Abrechnung für einen Mobilfunkbetreiber keine Fehler erhalten. Wir gingen zwei Jahre lang dorthin; Ich möchte Ihnen heute sagen, wie wir unser Ziel erreicht haben.
Keine Fehler basierend auf den Ergebnissen von Integrationstests - hier geht es darum, neue Funktionen auf der Grundlage einer Geschäftsakzeptanz auf der Betreiberseite zu testen. Ein paar Worte darüber, wie dieser Test funktioniert.
Wir veröffentlichen sechsmal im Jahr planmäßig neue Versionen unserer Abrechnungssoftware. Versandtermine sind im Voraus bekannt. Zum Zeitpunkt dieses Schreibens haben wir bereits Veröffentlichungstermine für das gesamte nächste Jahr geplant.
Diese Besonderheit ist mit dem Wettlauf der Mobilfunkbetreiber um die Markteinführungszeit verbunden. Das Hauptprinzip: Der Abonnent sollte regelmäßig neue Abrechnungsfunktionen erhalten. Zahlungen über ein Smartphone, Speichern einer Nummer beim Wechsel eines Betreibers, die Möglichkeit, nicht genutzten Datenverkehr zu verkaufen - Updates können unterschiedlich sein.
"Wir wissen möglicherweise nicht genau, was wir in einem Jahr veröffentlichen werden, aber wir wissen genau, wann das Update veröffentlicht wird." Aufgrund dessen ist es möglich, den gewünschten Aktualisierungsrhythmus beizubehalten.
Auf der Seite der Abrechnungsentwicklung sind etwa 70 Personen an der Freigabe beteiligt. Dies sind 5-6 Teams mit jeweils eigener Spezialisierung: Analyse, Entwicklung (mehrere Teams), Funktionstests, Integrationstests.
Ja, wir haben einen Wasserfall in Abrechnungsprojekten. In der aktuellen Geschichte geht es jedoch nicht darum, wie wir das Entwicklungsparadigma von Wasserfall zu Agil radikal verändert haben oder umgekehrt. Jeder Entwicklungsansatz hat seine eigenen Vorteile und ist unter den richtigen Bedingungen gut. Ich möchte diese Diskussion außerhalb des Rahmens dieses Artikels belassen. Heute möchte ich über die evolutionäre Entwicklung sprechen: Wie wir uns bei der Akzeptanz von Releases im Rahmen des bestehenden Entwicklungsansatzes in Richtung Null Fehler bewegt haben.
Unbehaglichkeitszone
Zu Beginn der beschriebenen Geschichte vor zwei Jahren hatten wir folgendes Bild:
- Teams am Ende der Entwicklungskette waren überfordert; "Es ist Zeit, dem nächsten Team etwas zu geben, und das vorherige hat gerade seinen Teil der Arbeit begonnen."
- Der Kunde konnte nach unseren Testzyklen rund 70 Fehler feststellen.
Fehler, die gemäß den Ergebnissen von Integrationstests gefunden werden konnten, können geringfügig („ein Teil der Nachricht wird als Bindestrich angezeigt“) oder sogar kritisch („es gibt keinen Übergang zu einem anderen Tarif“) sein.
Wir haben uns entschlossen, diese Ausrichtung zu ändern: Wir haben uns ein Ziel gesetzt - null Fehler bei der Geschäftsakzeptanz für die neue Funktionalität.
Nach einem Jahr konnten wir die Anzahl der Fehler auf 10-15 und bis Mitte 2020 auf 2-3 reduzieren. Und im September haben wir das Ziel Null erreicht.
Dies gelang uns aufgrund von Verbesserungen in mehreren Bereichen: Tools, Fachwissen, Dokumentation, Zusammenarbeit mit einem Kunden, einem Team. Verbesserungen von unterschiedlicher Bedeutung: Es ist wichtig, die Besonderheiten und Prozesse des Kunden zu kennen, eine neue Skala für die Beurteilung der Komplexität von Aufgaben zu wählen, und die Arbeit mit Teammotivation ist von entscheidender Bedeutung. Aber das Wichtigste zuerst.
Wachstumspunkte
Das Hauptwerkzeug für Integrationstests ist der Prüfstand. Dort wird die Aktivität des Teilnehmers emuliert.
Geteilte Stände
Dumps aus der Produktion werden auf Prüfstände gerollt, damit Sie unter Bedingungen testen können, die dem Kampf so nahe wie möglich kommen.
Der Haken ist, dass die Deponien auf unseren Ständen und auf den Ständen des Kunden unterschiedlich sein können. Der Bediener erstellt einen Dump, gibt ihn an uns weiter, wir testen neue Funktionen, fangen Fehler und beheben sie. Wir geben dem Kunden die fertige Funktionalität, Kollegen auf der anderen Seite beginnen mit dem Testen. Unsere und ihre Deponien können sich in ihrer Relevanz unterscheiden: Wir haben im Juli den Betreiber getestet - zum Beispiel im August.
Die Unterschiede sind nicht kritisch, aber es gab sie immer noch. Dies führte dazu, dass beim Testen auf Kundenseite Fehler auftreten konnten, die wir nicht hatten.
Was wir getan haben: Wir waren uns einig, dass die zum Testen verwendeten Datenschemata dieselben sein werden, und im Allgemeinen werden wir einen gemeinsamen Standpunkt vertreten.
Die Dump-Verzögerung bleibt bestehen, aber wir haben die Infrastruktur konfiguriert, auf der diese Verzögerung minimal ist. Aufgrund dessen konnten wir die Anzahl der Fehler reduzieren, die durch Unterschiede zwischen Test- und Produktionsumgebung verursacht wurden.
Überprüfen Sie die Einstellungen vor dem Testen
Wenn wir dem Bediener eine neue Version der Software zum Testen auf Kundenseite geben, müssen wir die Einstellung vornehmen. Konfigurieren Sie neue Funktionen und passen Sie möglicherweise die alte weiter an.
Um Sie über die erforderlichen Einstellungen zu informieren, haben wir die Dokumentation geschrieben. Nur hier könnten Handbücher Informationen mit Verzerrungen vermitteln. Die Dokumentation wurde von Menschen geschrieben, von Menschen gelesen, und in der Kommunikation von Menschen gibt es ein Missverständnis.
Dies ist die Besonderheit unserer Software: An die Einstellungen werden hohe Anforderungen an Flexibilität und Verfügbarkeit gestellt. Die Einstellungen sind komplex und ohne zusätzliche Kommunikation war es nicht immer möglich, alle notwendigen Informationen allein durch Dokumentation zu vermitteln.
Infolgedessen konnten die Einstellungen nicht immer korrekt durchgeführt werden, was zur Erkennung von Fehlern beim Testen auf der Bedienerseite führte. Bei der Analyse haben wir festgestellt, dass es sich nicht um Softwarefehler, sondern um Einstellungen handelt. Solche Fehler verschwenden wertvolle Zeit.
Was wir getan haben: Wir haben ein Verfahren zur Überprüfung der Einstellungen auf Kundenseite eingeführt, bevor wir an den Ständen des Bedieners getestet haben.
Die Vorgehensweise ist wie folgt: Der Kunde wählt die Fälle aus, die wir am konfigurierten Stand zeigen. Wir führen Tests durch. Wenn es Fehler gibt, werden wir diese umgehend korrigieren. Wenn nicht, ist der Test bestanden.
Dieser Ansatz ermöglichte es uns, die Anzahl der Fehler zu reduzieren, die mit falschen Einstellungen während des Integrationstests verbunden sind.
Zusätzliche Mitteilungen zur Dokumentation
Das Überprüfen der Einstellungen vor dem Testen sowie das Beschreiben dieser Einstellungen in den Handbüchern ist ein Beispiel für zusätzliche Kommunikation rund um die Dokumentation. Es gab andere.
Zum Beispiel haben wir es so gemacht, dass zu jedem Zeitpunkt immer ein Spezialist an unserer Seite war, an den sich der Kunde mit Fragen zur Dokumentation und zum gesamten System wenden konnte. So etwas wie eine spezielle technische Support-Linie mit unseren hochqualifizierten Spezialisten.
Unsere technischen Redakteure haben Workshops organisiert, um Kundenmitarbeiter über die neuen Funktionen zu informieren.
Der Prozess der Übermittlung von Unterlagen wurde weniger diskret und kontinuierlicher: Neue Informationen, Klarstellungen und Empfehlungen konnten nun nach dem „Versand“ der Haupthandbücher in Teilen gesendet werden. wie es erscheint oder auf Anfrage.
All dies ermöglichte es, den Kunden besser über die neue Funktionalität zu informieren und dadurch die Anzahl der Fehler bei Integrationstests zu reduzieren.
Expertise in der Arbeit mit Systemen von Drittanbietern
Um die Abrechnung zu entwickeln, müssen wir in der Lage sein, den Verkehr zu verfolgen. Hierfür gibt es separate PCRF-Systeme. Anrufe werden in einer Datenbank, SMS an derselben Stelle und Datenverkehr in einer anderen Datenbank gezählt. und es gibt spezielle Software, die all dies synchronisiert.
Gleichzeitig sind PCRF-Systeme proprietäre Software von Drittanbietern. Das heißt, eine Black Box: Wir senden Daten dorthin, wir erhalten etwas zurück, aber wir können nicht kontrollieren, was im Inneren passiert. Außerdem können wir dort nichts ändern.
Diese Ausrichtung begrenzte unsere Fähigkeit, verkehrsbedingte Fehler zu lokalisieren und zu beheben.
Was wir getan haben: Wir haben eine separate interne PCRF-Wissensbasis eingerichtet. Jeder Vorfall, jede Anpassungsoption, jeder Einblick - alles wurde vom Team aufgezeichnet und geteilt.
Infolgedessen wurden wir gute Benutzer des PCRF-Systems, wir können es anpassen und verstehen, was es tun sollte. Dies spart Zeit bei einfachen Vorfällen. Bei komplexen Fällen wenden wir uns natürlich immer noch an die Systementwickler, um Hilfe zu erhalten.
Mehr Stände
Ein weiteres Merkmal beim Testen der Abrechnung von Mobilfunkbetreibern ist, dass benutzerdefinierte Skripte im Laufe der Zeit erweitert werden können. Das vollständige Skript, das wir testen möchten, kann mehrere Tage oder sogar Wochen dauern.
Es ist schwierig, während der Testphase Tage oder Wochen zu warten. Um solche Szenarien zu testen, ist es meistens einfach an der Zeit, sich in der Datenbank zu entspannen.
Um die Zeit zurückzuspulen, müssen Sie alle Sitzungen außer Ihren eigenen schließen. Wir bekommen eine Situation, in der bedingt 20 Tester zwei Prüfstände beantragen können und jeder die Zeit zurückspulen möchte. Dies ist die Warteschlange. Und die Warteschlange ist die Wahrscheinlichkeit, dass wir zum vereinbarten Versanddatum der Software möglicherweise keine Zeit haben, alles ordnungsgemäß zu überprüfen.
Was wir getan haben: Für jeden Tester einen eigenen Stand einrichten.
Dies ermöglichte es uns, die Fehler zu beseitigen, die aufgrund von „spät kam ich an den Stand, hatte keine Zeit“ aufgetreten waren.
Virtualisierung
Die Standvorbereitung ist kein schneller Prozess. Sie müssen eine Verbindung zum Netz des Betreibers herstellen, den Zugriff anfordern, und das ist noch nicht alles. Der gesamte Vorgang kann bis zu mehreren Wochen dauern. Der Kampf um die Verkürzung der Standzeit für den Stand war eine wichtige Richtung, um das Ziel der Null Fehler zu erreichen.
Was wir getan haben: Virtualisierung aktiviert.
Durch das Kopieren virtueller Maschinen mit allen erforderlichen Einstellungen, vorinstallierte Software und die Automatisierung dieses Prozesses konnte die Zeit für die Vorbereitung des Standes auf „innerhalb eines Tages“ verkürzt werden.
Planung
Fehler aus Integrationstests sind auch das Ergebnis von Fehlkalkulationen in der Release-Planung. Wir haben viel geschwungen, zum Zeitpunkt des festen Veröffentlichungstermins war nicht alles pünktlich.
Was wir getan haben: Führen Sie für jede Entwicklungsphase Zwischenfristen ein. „Wenn Sie das Enddatum kennen, kennen Sie jedes Zwischenprodukt“ - dieses Prinzip hat uns geholfen, die Bewegungsgeschwindigkeit in Richtung des Veröffentlichungsziels besser zu steuern.
Support und Release parallel
Zu Beginn unserer Reise gab es eine Situation, in der die "Schulden" der letzten Veröffentlichung mit der nächsten Veröffentlichung in Konflikt standen. Nach der Annahme kamen Fehler auf Kundenseite an, und alle gingen, um sie zu beheben.
Gleichzeitig wurde der Release-Zeitplan nicht verschoben. Infolgedessen konnten wir zu dem Zeitpunkt, als es Zeit war, die nächste Version in Angriff zu nehmen, weiterhin an der vorherigen arbeiten.
Aufgrund der Trennung von zwei Gruppen vom Team konnte die Situation geändert werden: Wer wird Fehler bei der Annahme beheben und wer wird die neue Version termingerecht behandeln?
Die Teilung war bedingt: nicht unbedingt die Hälfte dort, aber die Hälfte hier. Wir könnten nach Bedarf Menschen zwischen Gruppen transferieren. Von außen könnte es so aussehen, als hätte sich nichts geändert: Hier ist eine Person aus dem Team, die während des Sprints sowohl Fehler als auch neue Funktionen herausgearbeitet hat. Tatsächlich war die Auswahl einzelner Gruppen eine Verbesserung gegenüber der Kategorie "Jetzt können wir ausatmen". Der Fokus jeder Gruppe und die Parallelisierung der Arbeit zwischen den Gruppen haben uns sehr geholfen.
Chronologisch gesehen war dies einer der ersten Wachstumspunkte, die wir postmortal formuliert haben. Und hier kommt meine Geschichte zu dem Teil über das Hauptinstrument.
Hauptwerkzeug
Die Verbesserung, die uns am meisten geholfen hat, sind ehrliche Postmortems.
Jemand nennt es eine Retrospektive, jemand - eine Analyse der Ergebnisse; In unserem Team steckte das Wort "postmortem" fest. Alle in diesem Artikel beschriebenen Verbesserungen wurden an Postmortems erfunden.
Das Prinzip ist einfach: Es gab eine Veröffentlichung, man muss zusammenkommen und ehrlich darüber diskutieren, wie alles gelaufen ist. Es klingt einfach, aber es gibt Fallstricke bei der Implementierung. Nach einer „erfolglosen“ Veröffentlichung haben die Teammitglieder die Stimmung „Es gibt keine Zeit, mit Sprachen zu kratzen, Sie müssen etwas tun“. Jemand kann zu Postmortems kommen und schweigen (und daher einige der potenziell nützlichen Informationen nicht liefern).
Seit zwei Jahren auf dem Weg zum Ziel von Null Fehlern haben wir eine Reihe von Prinzipien für die Durchführung von Postmortems entwickelt.
- Stellen Sie das komplette Bild zusammen
Wir laden eine erweiterte Teilnehmerliste ein. Entwickler, Tester, Analysten, Manager, Führungskräfte - jeder, der den Wunsch hat, sich zu äußern. Organisatorisch ist es nicht immer möglich, alle, alle zusammenzubringen. Es ist in Ordnung, es funktioniert auch so. Es geht nicht darum, die Teilnahme von Kollegen mit dem Wortlaut „Hier in unserem Team fassen wir die Ergebnisse zusammen, die Sie in Ihren zusammenfassen“ zu leugnen. Arbeiten mit Ständen, Code, Prozessen, Interaktion - wir bemühen uns, keinen Aspekt aus den Augen zu verlieren.
- Ergreifen Sie nicht alles auf einmal
Ok, als Ergebnis des Postmortems haben wir 30 Wachstumspunkte erzielt. Wie viel muss man zur Arbeit mitnehmen? Vielleicht können wir es bis zum nächsten Mal klären? Das Format „Pick 2-3“ hat bei uns am besten funktioniert. In dieser Situation gibt es einen Fokus, und die Bemühungen der Leute im Team sind nicht diffus. Es ist besser, weniger, aber vollständig als viel zu tun, aber nicht daran zu denken.
- Sei nicht schlau mit dem Format
Es gibt viele Ansätze zur Durchführung von Postmortems. Moderationspraktiken, Techniken aus Design Thinking und Lateral Thinking, Goldratts Technik und andere angesehene Experten. Nach unserer Erfahrung reicht der gesunde Menschenverstand aus, um anzufangen. Wir haben die Probleme aufgeschrieben, gruppiert, mehrere Cluster ausgewählt, den Rest beiseite geschoben (siehe vorherigen Punkt), diskutiert und den Plan festgelegt. Wenn es ein gemeinsames Ziel gibt, ist es nicht so schwierig, eine gemeinsame Sprache zu finden.
- Mach dich an die Arbeit
Vielleicht das Hauptprinzip auf dieser Liste. Egal wie vielversprechend und überzeugend die Liste der Verbesserungen auf der Grundlage der Ergebnisse des Postmortems ist, wenn sie nicht funktioniert, ist alles umsonst. Wir waren uns einig, dann machen wir es. Ja, es gibt andere dringende Angelegenheiten. Wir haben aber auch ein Ziel und wollen diesem näher kommen.
Postmortem kann sehr schmerzhaft sein. Selbst auf konstruktive Weise über Misserfolge zu sprechen, ist nicht einfach. Aber es lohnt sich, gegen die Beschwerden anzukämpfen. Ich bin sicher, dass wir ohne Postmortem nicht in der Lage gewesen wären, all die Dinge zu entwickeln, die dazu beigetragen haben, das Ziel von null Fehlern in der Veröffentlichung zu erreichen.
Das wichtigste Werkzeug
Postmortem ermöglicht es Ihnen, Mittel zu finden, um das Ziel zu erreichen. Wenn Sie es jedoch betrachten, kann dies als Folge eines übergeordneten Prinzips bezeichnet werden.
Das wichtigste Instrument ist die Beteiligung des Teams.
Die Beteiligung hat eine instrumentelle Seite. Zum Beispiel:
- Wenn wir Überstunden machen, ist der Chef neben dem Team und hilft mit seinen Händen.
- Wenn Sie das Team aufmuntern, indem Sie den Fortschritt verfolgen, können Sie visuelle Metriken finden (es ist nicht schwierig für die Anzahl der Fehler).
Und weiter im gleichen Sinne.
Engagement hat auch eine schwer zu formalisierende Seite - die Fähigkeit, Ihren Glauben an den Erfolg mit dem Team zu teilen. Schließlich haben mein Team und ich nicht nur die Broschüre mit den Unternehmenswerten durchgesehen, sondern dort „stärker zusammen“ gesehen und entschieden, dass, Bingo, eine Lösung gefunden wurde. Wir haben Beispiele dafür gesehen, wie herausfordernde Ziele durch gemeinsame Kräfte erreicht werden können. Wir hatten Leute in unserem Team, die an Erfolg glaubten und versuchten, diesen Glauben ihren Kollegen zu vermitteln. Der Rest ist eine Frage der Technologie.
Menschen sind das Wichtigste.
Es gab viel mehr in der Veröffentlichung in Richtung des Ziels von null Fehlern. Die Arbeiten zur Verbesserung der Dokumentation, zur Erhöhung der Geschwindigkeit und Qualität der Beantwortung von Kundenfragen sind unterschiedlich. Dieses Mal habe ich versucht, nur einige Beispiele zu nennen und über die Grundprinzipien zu sprechen.
Das Team und ich haben noch viel zu tun im Kampf um Release-Qualität und Time-to-Market-Optimierung. Machen Sie das Ergebnis bei Integrationstests regelmäßig und fehlerfrei reproduzierbar, automatisieren Sie die Regression.
Wie diese Ziele erreicht werden können, bleibt abzuwarten. Aber was wir jetzt sicher wissen: Wir werden definitiv Postmortems erstellen und Wachstumspunkte basierend auf Motiven implementieren. Und wir werden versuchen, die Chancen des beteiligten Teams zu nutzen.
Ich hoffe, einiges davon könnte auch für Sie hilfreich sein.