Get best of the week

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

Der Tester hat viele Möglichkeiten, die Qualität des Produkts zu verbessern und das Team komfortabler zu machen. Die Hauptsache ist, alle Änderungen mit dem Team zu besprechen und nur das zu implementieren, was für alle bequem und nützlich ist.

Mein Name ist Victoria Dezhkina. Ich bin verantwortlich für das Testen einer Reihe von Produkten in der Big Data-Direktion der X5 Retail Group. Im letzten Teil des Artikels begann ich darüber zu sprechen, wie wir die Prozesse im Produktteam "Automatisierungssystem für die Beschaffung eines Einzelhandelsnetzwerks" geändert haben. Produktfreigaben verzögerten sich ständig um mehrere Tage und kamen oft roh heraus. Wir haben die Reihenfolge des Codelayouts und der Aufgabenplanung geändert, wodurch wir den Freigabezyklus um mehrere Tage verkürzen konnten. Wir mussten jedoch noch das optimale Format für das Festlegen und Akzeptieren von Aufgaben erarbeiten, Testpunkte im Freigabezyklus festlegen und lernen, Probleme zur Behebung von Fehlern zu priorisieren.



Das Format der Formulierung und Annahme von Aufgaben und Mängeln


Die Methode zum Festlegen der Aufgabe bestimmt weitgehend, wie schnell und korrekt sie erledigt wird. Sie können Aufgaben auf verschiedene Arten beschreiben, z. B. mithilfe von User Stories, die die Anforderungen des Endbenutzers des Systems widerspiegeln. Es klingt ungefähr so: "Der Benutzer möchte einen Bericht erhalten, indem er die grüne Taste drückt."

Der Nachteil dieses Ansatzes ist, dass er nicht erklärt, was „unter der Haube“ dieser Lösung sein wird. User Stories lassen Entwicklern zu viel Freiheit und manchmal wird es zu einem Problem: Das Team erfindet das Rad neu oder sägt etwas zu Mühsames. Und da unter Bedingungen einer schnellen Entwicklung fast nie genug Zeit für eine vollständige Dokumentation bleibt, erhalten Sie mit diesem Ansatz kryptischen Code, der die Integration neuer Entwickler in das Produkt erheblich erschwert.

Wir haben verschiedene Entwurfsoptionen für Aufgaben und Fehler besprochen und uns für einen „hybriden“ Ansatz entschieden: Anwendungsfall + technische Teilaufgaben. Der Geschäftskunde schreibt den Anwendungsfall, dh er beschreibt die Optionen für die Verwendung der neuen Funktionalität, und der Analyst mit dem Tester ist auf dieser Grundlage technisch Unteraufgaben für Entwickler. In der Beschreibung der Aufgabe in Jira fügen wir den Anwendungsfall hinzu, aus dem sie erstellt wurde, oder einen Testfall, mit dem Sie den Fehler reproduzieren können, während der Name und die Beschreibung der Hauptaufgabe "lesbar" bleiben.

Sehen wir uns zum Beispiel an, was in dem Fehler mit dem Namen "Der Benutzer versteht nicht, wie die Fehler, die bei der Auswahl einer Kaufrate auftreten" behandelt werden. Die Aufgabenbeschreibung enthält:

  • ein Fall, in dem Sie den Fehler reproduzieren können;
  • reales und erwartetes Ergebnis;
  • Unteraufgaben für das Backend und das Frontend mit klaren Anweisungen, die Entwickler beheben müssen. "Backend: Geben Sie für diese API die entsprechende Antwort an das Frontend" + eine Matrix von Optionen, die zeigt, welche Antworten in jeder der möglichen Situationen sein sollten. "Frontend: Geben Sie für diese API abhängig von der Antwort von hinten den entsprechenden Fehlertext aus" + Optionsmatrix.

Wenn der Entwickler seine Unteraufgabe beendet hat, schließt er sie einfach. Wenn alle Unteraufgaben geschlossen sind, wird der Fehler erneut getestet. Wenn zusätzliche Probleme festgestellt werden, wird die entsprechende Unteraufgabe erneut erstellt.

Die entsprechende Regel zur Fehlerbeschreibung wird erhalten :

  1. Erstellen Sie eine Aufgabe mit einer Beschreibung eines Funktionsproblems, einem Fall zur Reproduktion des Fehlers und einem Link zur Historie, bei deren Überprüfung ein Fehler gefunden wurde.
  2. . : , , API , use case . , , API, , , , , , .

Wir haben uns auch geweigert, AC (Akzeptanzkriterien) für unser Produkt zu bilden, da wir in der Planungsphase nicht nur diskutieren, was wir entwickeln und testen, sondern auch wie.

Was hat es gegeben? Dieser Ansatz ermöglichte es uns jederzeit zu verstehen, was mit der Funktionalität des Benutzers nicht stimmte, in welchem ​​Stadium die Arbeit am Defekt durchgeführt wurde, und je nach Belastung auf der Vorder- und Rückseite die Unteraufgaben auf unterschiedliche Weise dem gleichen Defekt zuzuordnen.

Daher versteht das gesamte Team bereits vor Beginn der Entwicklung, welcher Teil jeder Aufgabe sich persönlich auf sie auswirkt, und am Ende enthält jede Aufgabe Informationen: wie sie entwickelt wurde, wie sie getestet wurde, ob Dokumentation vorhanden war und was während des Entwicklungsprozesses darin korrigiert wurde.

Dieser Ansatz wird nur für unser Produkt verwendet, da er sich für uns als am bequemsten herausgestellt hat. Andere Produkte der X5 Big Data-Direktion verwenden ihre eigenen Schemata: zum Beispiel User Stories mit AC.

Es scheint, dass unsere Option überhaupt nicht zur Beschleunigung der Entwicklung beiträgt, da mehr Schritte erforderlich sind, um loszulegen. Aber das ist nicht so.

Wir haben den Prozess so organisiert, dass die Tests parallel zur Entwicklung durchgeführt wurden. Dank dessen sitzt der Entwickler nicht untätig, während der Tester arbeitet und die Aufgabe so weit wie möglich lokalisiert.Außerdem sehen wir immer, welcher bestimmte Entwickler an der Aufgabe gearbeitet hat und wie sie implementiert wurde. Dadurch können wir in Zukunft verstehen, welcher der Entwickler mit neuen ähnlichen Problemen schneller fertig wird. Die Logik ist einfach: Je weniger ein Entwickler Dinge tut, die nicht direkt mit dem Schreiben von Code zusammenhängen, desto besser und die genaueste Lokalisierung eines Fehlers ermöglicht ein tieferes Nachdenken über mögliche Verbindungen und Probleme, die durch einen bestimmten Fehler verursacht werden.

Es kann sich auch die Frage stellen, ob die Regeln, die wir in unserem Produkt festgelegt haben, die Bildung einheitlicher Test- und Entwicklungsstandards in der Abteilung nicht beeinträchtigen. Eigentlich nicht: Die allgemeinen Regeln der Abteilung legen fest, was die Aufgabe in einem bestimmten Entwicklungsstadium enthalten soll, und wir erfüllen diese Anforderungen, wir arbeiten die Aufgabe einfach in früheren Phasen aus.

Testmomente


Wir haben lange über die Frage diskutiert, in welchem ​​Stadium Tests durchgeführt werden sollen. Anfangs gab es die Idee, jede einzelne Aufgabe in der lokalen Niederlassung zu überprüfen, aber mit diesem Ansatz wäre es unmöglich zu überprüfen, wie diese Aufgaben zusammenarbeiten, und ihre Konflikte würden erst in der Phase der zusammengestellten Version aufgedeckt, wenn es zu spät ist, etwas zu ändern.

Daher haben wir vereinbart, jede Aufgabe einzeln, jedoch auf einem Prüfstand zu testen. Zuerst wollten wir mehrere Aufgaben gleichzeitig ausführen, aber oben habe ich Ihnen bereits gesagt, welche Risiken diese Idee birgt. Einer nach dem anderen viel schneller. Dies ist ein bekannter Effekt: Die Reduzierung der Anzahl paralleler Aufgaben verlangsamt nicht, sondern beschleunigt den Prozess. In Kanban gibt es beispielsweise ein WIP-Limit (WIP ist in Arbeit), das die Anzahl der Aufgaben begrenzt, die von jeder Rolle gleichzeitig gelöst werden können.

Als Ergebnis haben wir fünf Punkte festgelegt, an denen Tester aktiv am Entwicklungsprozess beteiligt sind:

  • In der Dokumentationsphase. Wir stellen sicher, dass es keine Probleme gibt, die im Widerspruch zur Logik dessen stehen, was bereits getan wurde, und legen die Details der Implementierung jeder Aufgabe fest.
  • In der Phase der Problemstellung. Wir sprechen mit dem Analysten über alle möglichen Fälle im Zusammenhang mit der Aufgabe und berücksichtigen sie bei der Gestaltung der Aufgabe
  • In der Planungsphase. Wir sprechen darüber, wie sich die geplante Implementierung auf die zugehörige Funktionalität auswirken kann und welche Probleme sie mit sich bringen kann. Wir koordinieren alle kritischen Mängel mit dem Produkt und ergänzen den Sprint.
  • In Vorbereitung auf die Veröffentlichung. Wir überprüfen iterativ jede Aufgabe auf einem Prüfstand und am Tag vor der geplanten Veröffentlichung sammeln wir alle Aufgaben zusammen und prüfen sie auf einem Prüfstand.
  • Nach der Veröffentlichung. Wir überprüfen, wie die Veröffentlichung auf dem Produkt funktioniert.

Zu Beginn, als wir alle zwei Wochen Veröffentlichungen hatten, sah das Arbeitsschema folgendermaßen aus:



Es wurde (Veröffentlichung einmal pro Woche):



Regeln für die Interaktion der Backend - Test - Frontend - Verbindung


Wenn viele verschiedene Daten zwischen dem Backend und dem Frontend in der API gesendet werden, ist nicht immer klar, warum sie benötigt werden und wie sie interagieren. Aus diesem Grund können am Frontend Fehlfunktionen auftreten. Beispielsweise wird die Berechnungsnummer Demand cal von hinten übertragen. Nominell ist dies ein Parameter, aber acht weitere Felder sollten vom Hintergrund „angezogen“ werden, um die Berechnung damit durchzuführen. Wenn Sie sie nicht zusammen mit der Kalkulationsnummer weitergeben, wird dieser Vorgang nicht am Frontend ausgeführt.

Um solche Situationen zu vermeiden, haben wir begonnen, die übergebenen Parameter zu beschreiben und sie in den Kommentaren zur Unteraufgabe für die Entwicklung der API in Jira anzugeben, in der erläutert wurde, welche Daten die Vorder- und Rückseite austauschen. Wir haben versucht, alle APIs im Swagger-Framework zu beschreiben, aber mit seiner Hilfe beim automatischen Generieren der Dokumentation war es nicht möglich, das Frontend zu übertragen, was genau das Backend mit den übergebenen Parametern macht. Daher waren wir uns einig, dass, wenn es sich um einen Parameter handelt, der nicht nur auf der Rückseite steht, sondern andere Parameter verwendet, es notwendig ist, seinen Zweck in der Aufgabe zu beschreiben.

Wir haben auch begonnen, die Bezeichnung von Variablen so zu steuern, dass in derselben API alle Felder standardisiert wurden. Unser Produkt besteht aus Microservices und jeder kann seine eigenen Feldnamen haben. In einem Feld mit dem Namen des Lieferanten kann Lieferant sein, in einem anderen - Lieferanten-ID, im dritten Namen usw. Bei der Übertragung dieser Daten auf eine Komponente des Frontends können Schwierigkeiten auftreten. Daher haben wir alle Parameter durchgesehen und begonnen, alle Variablennamen zu standardisieren. Zu diesem Zweck haben wir eine Übersichtstabelle aller aktuellen Bezeichnungen, eine Tabelle aller Frontkomponenten und der von ihnen verwendeten Variablen (mit denen der Front-End-Entwickler sehr geholfen hat) zusammengestellt und verglichen. Jetzt erhalten alle neuen APIs Standardvariablennamen, und alte APIs werden korrigiert, wenn Aufgaben für deren Abschluss anfallen.

Beschleunigen Sie die Fehlerbehebung


In der Phase der Aufgabenstellung legt der Geschäftskunde die Prioritäten fest - er weiß am besten, was und in welcher Reihenfolge für die Entwicklung des Produkts benötigt wird. Nach der Einführung in dev legt der Tester jedoch Prioritäten fest, wenn Aufgaben zur Behebung von Fehlern vorliegen.

Manchmal müssen die Prioritäten dieser Aufgaben dringend geändert werden. Beispielsweise stellen wir einen geringfügigen Fehler im Back-End fest, ohne den das Front-End-Team nicht mit der Behebung beginnen kann.

Früher gingen wir in solchen Situationen sofort zu den Entwicklern und baten sie, die Priorität der Aufgaben zu ändern, was sie jedoch ablenkte. Daher haben wir vereinbart, dass wir uns nur zu bestimmten Zeiten melden - nach dem Einfrieren des Codes bis zu 5 Mal am Tag. Was hat es gegeben? Wir haben aufgehört, die Produktivität von Entwicklern durch plötzliche Anrufe zu verringern, haben Ausfallzeiten beseitigt und die Zeit für den Analysten verlängert, um die Aufgaben zu erledigen.

Darüber hinaus wissen wir aufgrund der Tatsache, dass Aufgaben für Entwickler nicht mehr spontan angezeigt werden, immer, wer welche Last hat, wer früher an einer Aufgabe gearbeitet hat und in der Lage sein wird, diese schneller zu erledigen. Infolgedessen verstehen wir viel besser, ob wir es schaffen werden, die Veröffentlichung termingerecht vorzubereiten oder nicht.

Diese Maßnahmen sind zusammen mit einer einzigen Logik für die Einführung des Codes für dev, release und prod zulässigReduzieren Sie die Korrekturzeit von 3 Tagen auf 3-4 Stunden.

Ergebnisse


In den 9 Monaten der Arbeit an unserem Produkt zur Beschaffungsautomatisierung ist es uns gelungen, den Release-Zyklus von 2,5 Wochen auf 1 Woche zu verkürzen und die Möglichkeit einer täglichen Einführung zu schaffen, wodurch die Stabilität der Releases erheblich erhöht wurde.

Was hat sich geändert:

  1. Wir haben die Notwendigkeit beseitigt, Fehler nach der Entwicklung zu korrigieren, da wir diese Arbeit auf die Stufe der maximalen Vorbereitung von Aufgaben gebracht haben.
  2. Die Korrekturzeit für Mängel wurde von 3 Tagen auf 3-4 Stunden verkürzt.
  3. Wir hatten die Möglichkeit, Releases "auf Befehl" herauszubringen. Jetzt können wir jeden Tag packen, die Aufgaben ausrollen und bis zum Abend ist alles fertig und debuggt.
  4. Wir haben die Transparenz der Prozesse für alle Teilnehmer des Prozesses erhöht: Jetzt verstehen alle Entwickler und Tester des Teams, was gerade passiert, wer mit welchen Aufgaben beschäftigt ist, wie viel Zeit für die Entwicklung und Behebung von Fehlern benötigt wird usw.

BONUS: Es war möglich, den Stress im Team zu reduzieren (ich hoffe), und dank der koordinierten Arbeit des Teams (dank der Lieferung) konnte ich problemlos zur Fernbedienung gehen :-) Bei der Implementierung

dieser Verbesserungen haben wir verschiedene Regeln eingehalten:

  • Tester und Entwickler sitzen im selben Boot (wiederholen Sie es wie ein Mantra!). Das erste, was ein Tester tun muss, ist, mit dem Team auszukommen und herauszufinden, was sie am meisten beunruhigt, und seine Unterstützung in Anspruch zu nehmen. Meine Verbündeten und Partner im Team waren der Vertriebsleiter und die Entwickler.
  • Es gibt keine vorgefertigte ideale Lösung, und sie muss gesucht werden. Der Tester legt niemandem seine Regeln auf, er passt sich dem Team an und ändert damit seine Ansätze, wobei er das Bild einer glänzenden Zukunft im Auge behält und vorsichtig Maßnahmen einführt, um dies zu erreichen.
  • Zu strenge Einschränkungen und Standardisierung sind keine Methode. Wenn Sie es übertreiben, können Teams an Flexibilität verlieren.

Die Interaktionsregeln, die uns geholfen haben, die Entwicklung dieses Produkts zu beschleunigen, können nicht in reiner Form auf andere Produkte der Direktion übertragen werden - sie sind unterschiedlich angeordnet und die Bedürfnisse der Entwickler dort sind unterschiedlich. Das Prinzip beim Erstellen dieser Regeln ist jedoch dasselbe: Legen Sie die Reihenfolge für die Berechnung des Codes fest, finden Sie die optimalen Testpunkte, dokumentieren Sie den Code und die API.

Parallel zur Arbeit in den Produkten entwickeln wir Regeln, die die Interaktion zwischen den Produkten erleichtern sollen, und wir werden dies in den folgenden Materialien erläutern. In der Big Data-Direktion wird daher schrittweise eine Strategie zur Entwicklung der Produktqualität entwickelt.

More articles:


All Articles