Eine schnelle und effiziente Softwareentwicklung ist heute ohne ausgefeilte Arbeitsabläufe nicht denkbar: Jede Komponente wird zum Zeitpunkt der Installation auf die Baugruppe übertragen, das Produkt steht nicht im Leerlauf. Vor zwei Jahren haben wir gemeinsam mit M.Video begonnen, einen solchen Ansatz in den Entwicklungsprozess des Einzelhändlers einzuführen, und heute entwickeln wir ihn weiter. Was sind die Zwischensummen? Das Ergebnis hat sich voll ausgezahlt: Dank der vorgenommenen Änderungen konnte die Veröffentlichung von Releases um 20-30% beschleunigt werden. Willst du ein paar Details? Willkommen in unserer Backstage.

Von Scrum nach Kanban

Zunächst wurde eine Änderung der Methodik implementiert - der Übergang von Scrum, dh dem Sprint-Modell, zu Kanban. Bisher sah der Entwicklungsprozess folgendermaßen aus:



Es gibt einen Entwicklungszweig, es gibt Sprints für fünf Teams. Sie codieren in ihren eigenen Entwicklungszweigen, Sprints enden am selben Tag und alle Teams kombinieren die Ergebnisse ihrer Arbeit am selben Tag mit dem Hauptzweig. Danach werden fünf Tage lang Regressionstests durchgeführt, dann wird der Zweig an die Pilotumgebung und anschließend an die produktive Umgebung übergeben. Vor dem Start der Regressionstests dauerte es jedoch 2-3 Tage, um den Hauptzweig irgendwie zu stabilisieren und Konflikte nach dem Zusammenführen mit den Befehlszweigen zu beseitigen.

Was ist der Vorteil von Kanban? Die Teams warten nicht auf das Ende des Sprints, sondern kombinieren ihre lokalen Änderungen nach Abschluss der Aufgabe mit dem Hauptzweig, wobei jedes Mal nach Kollisionskonflikten gesucht wird. Am festgelegten Tag werden alle Assoziationen mit dem Master blockiert und Regressionstests gestartet.



Infolgedessen ist es uns gelungen, ständige Verschiebungen von Begriffen nach rechts, Regressionen, zu beseitigen
nicht verzögert, Release-Kandidat wird pünktlich geliefert.

Allgegenwärtige Automatisierung

Natürlich reichte es nicht aus, nur die Methodik zu ändern. Im zweiten Schritt haben wir zusammen mit dem Einzelhändler das Testen automatisiert. Insgesamt werden rund 900 Szenarien getestet, die nach Priorität in Gruppen unterteilt sind.

Etwa 100 Szenarien sind die sogenannten Blocker. Sie sollten auch während eines Atomkrieges auf der Website - dem M.Video-Onlineshop - arbeiten. Wenn einer der Blocker nicht funktioniert, gibt es große Probleme auf der Site. Zum Beispiel enthalten Blocker einen Mechanismus zum Kaufen von Waren, Anwenden von Rabatten, Autorisieren, Registrieren von Benutzern, Aufgeben einer Kreditbestellung usw.

Etwa 300 weitere Szenarien sind kritisch. Dazu gehört beispielsweise die Möglichkeit, Produkte mithilfe von Filtern auszuwählen. Wenn diese Funktion nicht funktioniert, ist es unwahrscheinlich, dass Benutzer Waren kaufen, selbst wenn die Mechanismen des Kaufs und der direkten Suche im Katalog funktionieren.

Andere Szenarien sind Dur und Moll. Wenn sie nicht arbeiten, sammeln die Leute negative Erfahrungen mit der Website. Dies umfasst viele Probleme von unterschiedlicher Bedeutung und Sichtbarkeit für den Benutzer. Zum Beispiel ging das Layout (Major), die Beschreibung des Bestands (Minor) wird nicht angezeigt, der automatische Vorschlag für Passwörter im persönlichen Konto (Minor) funktioniert nicht, die Wiederherstellung (Major) funktioniert nicht.

Zusammen mit M.Video haben wir das Testen von Blockern um 95% der verbleibenden Szenarien automatisiert - um etwa 50%. Warum ist etwa die Hälfte nicht automatisiert? Es gibt viele Gründe und verschiedene. Es gibt Szenarien, die a priori nicht automatisiert werden können. Es gibt komplexe Integrationsfälle, deren Vorbereitung manuelle Arbeit erfordert, z. B. das Anrufen der Bank und das Stornieren eines Kreditantrags, die Kontaktaufnahme mit der Verkaufsabteilung und das Stornieren von Bestellungen in einer produktiven Umgebung.
Die Automatisierung von Regressionstests reduzierte ihre Dauer. Aber wir gingen weiter und automatisierten Rauchprüfungen für Blocker nach jeder Zusammenführung der Befehlszweige mit dem Hauptzweig.

Nachdem wir die Tests automatisiert hatten, konnten wir die Verzögerungen nach Abschluss der Zuordnungen zum Hauptzweig endlich beseitigen.

Gurke zur Rettung

Um den Erfolg zu festigen, hat unser Team die Tests selbst überarbeitet. Bisher waren dies Tabellen: Aktion → erwartetes Ergebnis → tatsächliches Ergebnis. Zum Beispiel habe ich mich mit einem solchen Benutzernamen und Passwort auf der Site angemeldet. erwartetes Ergebnis: alles ist in Ordnung; Das tatsächliche Ergebnis ist auch in Ordnung. Ich gehe zu anderen Seiten. Dies waren umständliche Szenarien.

Wir haben sie in die Gherkin-Notation übersetzt und einige der Schritte automatisiert. Nehmen wir die gleiche Autorisierung auf der Site an. Das Skript ist jetzt wie folgt formuliert: " Als Benutzer der Site habe ich mich mit den Autorisierungsdaten angemeldet und der Vorgang war erfolgreich ." Darüber hinaus werden der " Benutzer der Site " und " mit den Autorisierungsdaten angemeldet " in separaten Tabellen aufgeführt. Jetzt können wir unabhängig von den Daten schnell Testfälle ausführen.

Was ist der Wert dieses Schritts? Angenommen, ein Tester testet ein Projekt. Es ist ihm egal, wie er Tests schreibt, er kann Überprüfungen sogar in Form einer Checkliste durchführen: "Die Autorisierung wird überprüft, die Registrierung wird überprüft, der Kauf wird per Karte überprüft, der Kauf wird von Yandex überprüft. Geld wird überprüft - ich bin gutaussehend." Eine neue Person kommt und fragt: Haben Sie sich per E-Mail oder über Facebook angemeldet? Infolgedessen wird die Checkliste zu einem Skript.

Fünf Teams arbeiten im Projekt, und jedes Team hat mindestens zwei Tester. Zuvor schrieb jeder von ihnen Tests, wie es ihm gefiel, und daher konnten Tests nur von ihren Autoren unterstützt werden. Bei der Automatisierung war alles langweilig: Entweder müssen Sie separate Automatisierungsingenieure einstellen, die den gesamten Testzoo in eine Skriptsprache übersetzen, oder Sie müssen die Automatisierung als Phänomen vergessen. Gurke half dabei, alles zu ändern: Mit Hilfe dieser Skriptsprache haben wir „Cubes“ erstellt - Autorisierung, Warenkorb, Zahlung usw. -, aus denen Tester nun verschiedene Skripte sammeln. Wenn Sie ein neues Skript erstellen müssen, schreibt eine Person es nicht von Grund auf neu, sondern ruft einfach die erforderlichen Blöcke in Form von Autotests auf. Gherkin-Notationen haben alle Funktionstester geschult und können nun unabhängig voneinander mit der Automatisierung interagieren, Skripte unterstützen und Ergebnisse analysieren.

Wir haben hier nicht aufgehört.

Funktionsbausteine

Angenommen, Release 1 ist die Funktionalität, die sich bereits auf der Site befindet. In Release 2 wollten wir einige Änderungen an Benutzer- und Geschäftsszenarien vornehmen. Infolgedessen funktionierte ein Teil der Tests nicht mehr, da sich die Funktionalität änderte.

Wir haben das Testspeichersystem strukturiert: Wir haben es in Funktionsblöcke unterteilt, z. B. "persönliches Konto", "Kauf" usw. Wenn nun ein neues Benutzerskript eingeführt wird, werden die erforderlichen Funktionsblöcke mit Häkchen markiert.

Dank dieser Funktion können Entwickler nach der Kombination mit dem Hauptzweig die Arbeit nicht nur von Blockern, sondern auch von Skripten überprüfen, die sich auf den Themenbereich beziehen, auf den sich die vorgenommenen Änderungen auswirken.

Die zweite Konsequenz ist, dass es viel einfacher geworden ist, die Tests selbst zu warten. Wenn sich beispielsweise in Ihrem persönlichen Konto, bei der Bestellung und bei der Lieferung etwas geändert hat, müssen wir nicht das gesamte Regressionsmodell schütteln, da die geänderten Funktionsblöcke sofort sichtbar sind. Das heißt, die Testsuite auf dem neuesten Stand zu halten, ist schneller und daher billiger geworden.

Das Problem mit den Ständen

Früher hat niemand die Leistung von Ständen vor der Abnahme getestet. Zum Beispiel geben sie uns einen Prüfstand, auf dem wir mehrere Stunden lang Regressionstests durchführen. Sie fallen, verstehen, reparieren, führen erneut Tests durch. Das heißt, wir verlieren Zeit beim Debuggen und bei wiederholten Läufen.

Das Problem wurde einfach gelöst: Sie haben insgesamt 15 API-Tests geschrieben, die die Konfiguration der Stände überprüfen, die in keiner Weise mit der Funktionalität zusammenhängen. Tests sind unabhängig von der Build-Version und überprüfen nur alle Integrationspunkte, die für die Übergabe von Skripten kritisch sind.

Dies hat viel Zeit gespart. In der Tat hatten wir vor der Automatisierung 14 Tester, die Überprüfungen waren umständlich und langwierig, es gab Skripte für fast den gesamten Arbeitstag, bestehend aus 150 Schritten. Und hier testen Sie, und irgendwann beim 30. bis 40. bis 110. Schritt stellen Sie fest, dass der Stand nicht funktioniert. Wir multiplizieren die verlorene Arbeitszeit mit 14 Personen und sind entsetzt. Und nach der Einführung der Automatisierung und des Testens von Ständen ist es uns gelungen, die Anzahl der Tester zu halbieren und Ausfallzeiten zu beseitigen, was dem Hauptbuchhalter viel Freude bereitete.

Kirschen auf dem Kuchen

Die erste Kirsche ist Bugflow. Formal ist dies der Lebenszyklus eines Fehlers, aber tatsächlich einer Entität. Zum Beispiel arbeiten wir in Jira an diesem Konzept. Ein zusätzlicher Status ermöglichte es uns, Releases zu beschleunigen.

Im Allgemeinen sieht der Prozess folgendermaßen aus: Sie haben einen Vorfall gefunden, zur Arbeit gebracht, abgeschlossen, zum Testen übergeben, getestet und geschlossen.



Wir verstehen, dass der Defekt geschlossen wurde, das Problem behoben wurde. Und sie fügten einen weiteren Status hinzu: "Für Regressionstests." Dies bedeutet, dass nach der Analyse Szenarien, die kritische Fehler erkennen, zum Regressionssatz von 900 Szenarien hinzugefügt werden. Wenn sie nicht da waren oder wenn sie nicht genügend Details hatten, haben wir sofort eine Rückmeldung über den Zustand des Produktiven oder Piloten.



Das heißt, wir verstehen, dass es ein Problem gibt, und aus irgendeinem Grund haben wir es nicht berücksichtigt. Das Hinzufügen eines Bug-Check-Skripts spart jetzt viel Zeit.

Wir haben auch eine Retrospektive auf Testebene eingeführt. Es sieht so aus: Sie haben eine Tablet-Versionsnummer, die Anzahl der darin enthaltenen Fehler, die Anzahl der Blocker und anderer Skripte sowie die Anzahl der Auflösungen zusammengestellt. Gleichzeitig haben wir die Anzahl der ungültigen Auflösungen geschätzt. Wenn Sie beispielsweise 15 ungültige Fehler von 40 Fehlern erhalten, ist dies ein sehr schlechter Indikator. Tester verschwenden nicht nur ihre Zeit, sondern auch die Zeit der Entwickler, die an diesen Fehlern arbeiten. Die Jungs begannen darüber nachzudenken, beschäftigten sich damit und führten das Verfahren zur Überarbeitung von Fehlern durch erfahrenere Tester ein, bevor sie sie an die Entwicklung schickten. Und sie haben es sehr gut gemacht.

Daher wird ständig nachgedacht und daran gearbeitet, die Qualität zu verbessern. Alle Fehler des Produkts werden analysiert: Für jeden Fehler wird ein Test erstellt, der sofort in den Regressionssatz aufgenommen wird. Wenn möglich, ist dieser Test automatisiert und wird regelmäßig ausgeführt.

Ergebnisse

Ursprünglich war geplant, die Häufigkeit von Veröffentlichungen zu erhöhen und die Anzahl der Fehler zu verringern, aber das Ergebnis übertraf die Erwartungen etwas. Ein vernünftig aufgebauter Automatisierungsprozess ermöglichte es, die Anzahl der automatisierten Tests in kurzer Zeit zu erhöhen, und die Analyse fehlender Fehler ermöglichte es dem Entwicklungs- und Testteam, Skripte optimal zu priorisieren und sich auf die wichtigsten zu konzentrieren.

Automatisierungsergebnisse:

• Bis zu 4 Tage (anstelle der vorherigen 10) reduzierten die Dauer der Regressionstests.
• Das manuelle Testteam nahm um 50% ab.
• Von 30 bis 35 auf 25 Tage wurde die Zeit bis zur Markteinführung verkürzt - von dem Moment an, in dem ein Feature in den Rückstand des Teams einging, bis es in den Piloten eintrat.

Testautomatisierungsteam, Jet Infosystems