Get best of the week

So verbessern Sie die Leistung agiler Teams durch Tests

Die agile Entwicklung zielt darauf ab, neue Funktionen schnell und mit der richtigen Häufigkeit bereitzustellen und einen konstanten Strom von Änderungen sicherzustellen. Ein flexibler Ansatz ermöglicht es dem Team, ein hohes Tempo zu halten. Aus diesem Grund leiden häufig die Qualität des Codes und die Stabilität des Produkts. Wie kann dieses Problem gelöst werden, ohne das Team in einen engen Rahmen zu bringen und ohne die Vorteile agiler Methoden zu verlieren? Hilfe kommt von Testern. Mein Name ist Denis Dubovoi, ich leite die Testabteilung bei der Big Data-Direktion der X5 Retail Group und in diesem Artikel werde ich Ihnen erklären, wie das Erscheinungsbild von Testern zur Verbesserung der Arbeitsqualität unserer Entwickler beigetragen hat.



Regeln durch Testen erstellen


Agile Teams vernachlässigen oft die Qualität. Dies ist teilweise auf die Tatsache zurückzuführen, dass herkömmliche Testmethoden nicht in einen „flexiblen“ Kontext passen, teilweise auf die Priorität der Geschwindigkeit gegenüber der Qualität. Die Hauptaufgabe des agilen Teams besteht darin, die Funktionen, die ein Geschäftskunde benötigt, schnell zu implementieren. Dies gilt insbesondere in der Phase der Produktentwicklung, in der die Funktionalität buchstäblich durch Ausprobieren bestimmt wird und Entwickler das Produkt für aktuelle Anforderungen schnell neu erstellen müssen. In einer solchen Situation entscheidet das Team oft folgendermaßen: Wir werden den Tester später anrufen, wenn wir das MVP / die erste Arbeitsversion / Zen lernen - weil es einfach nicht versteht, wie man flexible Tests organisiert. Das Ergebnis sind häufig Unterbrechungen der Lieferzeiten, Fehler in der Demo und am schlimmsten in der PROM-Umgebung.

In unserem Fall war die Situation sehr ähnlich: Die Abteilung für Big Data-Produktentwicklung der X5 Retail Group besteht seit 2 Jahren, und zunächst wurde die Qualität der Produkte nur von den Entwicklern selbst aufrechterhalten - es gab keine spezielle Rolle als QS-Spezialist, und die Testabteilung und der erste Tester im Produkt erschienen erst vor einem Jahr, als die Produkte bereits gestartet waren.

Heute sind bereits 15 Personen in der Testabteilung: 11 Tester begleiten die Produkte in Teams, zwei Personen entwickeln die Richtung der Lastprüfung und zwei weitere - die Richtung der Testautomatisierung. In vielen Produktteams sind Tester zu einem Katalysator für wichtige Änderungen geworden: Ihre Ankunft hat den Entwicklungsprozess rationalisiert und die Freisetzungsstabilität verbessert. Zu diesem Zweck haben wir Tester nach dem folgenden Schema mit bereits arbeitenden Teams verbunden:

1. Tauchen Sie ein in den Prozess


In der ersten Phase müssen wir verstehen, wie das Team jetzt arbeitet, wie die Rollen darin verteilt sind und wie Informationen ausgetauscht werden. Der Tester hilft beim Testen, eher in Form einer "Qualitätskontrolle", und bewertet gleichzeitig die Reife des Teams und die Prozesse im Team - dazu gibt es eine kleine "Heat Map" der Reife, von der ein Beispiel unten zu sehen ist. Darauf können Sie sehen, wie verschiedene Richtungen (Entwicklung, Test, DG, DevOps, Support) in jedem unserer Produkte entwickelt werden.


Maturity Heat Map

Tester sammeln zusammen mit den Entwicklern die Bewertung der Prozessreife und bewerten die vom Team verwendeten technologischen und methodischen Praktiken. Infolgedessen können wir auf der Heatmap sehen, was und in welchem ​​Bereich es möglich ist, für jede Phase des Produktlebens (Prototyp, Pilot, Industrie) eine eigene Vorgehensweise zu verbessern - beispielsweise um die Praxis von Unit-Tests in der Entwicklung zu entwickeln oder API-Prüfungen in Tests zu automatisieren.

2. Wir geben Verbesserungsvorschläge




Nachdem Sie herausgefunden haben, wie das Team lebt, können Sie über die ersten Empfehlungen zur Verbesserung seiner Arbeit nachdenken. Hier halten wir uns an die folgende Logik: Tester sind keine dedizierte Funktion, die für einen bestimmten Bereich verantwortlich ist, wir sind Teil des Teams und können den gesamten Prozess beeinflussen. Um den Start von Verbesserungen zu erleichtern, beginnen wir mit den grundlegenden Dingen:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • Wir reparieren die Sprintphasen und einen der kritischen Punkte - den Punkt „Code Freeze“.

Wir haben uns die Phasen vor dem Testen und ein wenig den Test selbst angesehen, aber es gibt auch einen technischen Teil mit der Wartung von Prüfständen und der Arbeit mit Testdaten und einen industriellen Teil mit Produktunterstützung. Tester sind in all diesen Phasen irgendwie involviert - wir versuchen, T-Shape-Spezialisten zu gewinnen, die den gesamten Produktionsprozess und nicht nur ihre unmittelbare Funktion sehen.

3. Wir präsentieren unsere Verbesserungen den Teamleitern und Stakeholdern und konzentrieren uns darauf, welche Probleme diese Verbesserungen lösen werden


Der Prozess wird einfacher, wenn Sie die Unterstützung des Teams in Anspruch nehmen. Es ist wichtig, dass Sie Ihre Idee „verkaufen“, um zu zeigen, welchen Gewinn Ihre vorgeschlagenen Änderungen bringen. Zum Beispiel mögen die oben genannten Akzeptanzkriterien für den Analysten wie zusätzliche Arbeit aussehen, aber wenn das Team versteht, welche Zeitersparnis es erhalten wird - und dies von Stunden bis Tagen, was zur Verfeinerung der Aufgabe erforderlich sein kann -, wird die Verbesserung viel einfacher.

In einigen Fällen können Sie über den Eigentümer des Produkts handeln. Beispielsweise fehlt dem Produkt die Überwachung (z. B. technisch, mit Protokollen und schönen Grafiken), und es ist keine Zeit zum Konfigurieren vorhanden, da dies keine Produktaufgabe ist. In diesem Fall können Sie sich an das Produkt wenden und genau erklären, welche Vorteile die Überwachung bietet (es wird nicht sofort stabiler, aber die Geschwindigkeit der Problemlokalisierung nimmt zu), und ihn bitten, dafür Ressourcen zuzuweisen.
Parallel zur Standardisierung der Arbeit in Produktteams werden Testansätze entwickelt, die die Qualität der Produkte sicherstellen, z. B. die Bewertung und Aufbereitung der erforderlichen Testdatenmengen, die Entwicklung eines Testmodells, die Bildung von Punkten für die zukünftige Automatisierung usw.

Es besteht immer die Möglichkeit, dass das Team die vorgeschlagenen Änderungen nicht akzeptiert, egal wie vernünftig sie Ihnen erscheinen mögen. In jedem Einzelfall ist es notwendig, eigene Ansätze zu formulieren und nach einer individuellen Art der Überzeugung zu suchen. Die Produkte sind sehr unterschiedlich und die Ansätze, die in einem Produkt funktionieren, funktionieren in einem anderen überhaupt nicht.

Viele Teams sind zuversichtlich, dass sie ihre Arbeit selbst organisieren können, und manchmal ist dies auch der Fall. Es gab Fälle, in denen es bei unserer Teilnahme darauf ankam, die wichtigsten Überprüfungspunkte zu empfehlen, und dann hat das Team alles auf Codeebene perfekt implementiert, und wir blieben einfach in der Nähe und waren immer bereit zu helfen. Aber öfter passiert es anders: Unser Mitarbeiter kommt ins Team, und die Entwickler beginnen scherzhaft, von den vom Tester festgestellten Fehlern zu „weinen“, und freuen sich, dass die Fehler vor der Demo oder der industriellen Veröffentlichung gefunden wurden.

Was hat sich geändert


Änderungen in den Produktteams verliefen unterschiedlich und wirkten sich auf verschiedene Aspekte des Prozesses aus. In einem der Teams wurde das Testen zunächst zu einem Engpass: Es dauerte einige Zeit, und nicht jeder verstand, was zu diesem Zeitpunkt geschah. Als Experiment haben wir Entwickler mit dem Ausführen von Tests verbunden, wodurch sie die Arbeit von Testern erleben und sogar das Produkt als Ganzes sehen konnten - keine separate Funktion zum Beispiel zum Erstellen eines Berichts, sondern den gesamten Weg von der Benutzerautorisierung im Produkt und der Durchführung von Geschäftsvorgängen bis zum endgültigen Entladen Bericht. Deshalb haben wir die Beteiligung des gesamten Teams verstärkt, den Testprozess transparent gemacht und die Bedeutung dieser Maßnahme gezeigt, und die oben beschriebene Praxis wurde regelmäßig.

Bei einem anderen Produkt hat sich der Release-Zyklus mit unserer Hilfe geändert. Zunächst wurde vereinbart, dass die Ergebnisse des Sprints am Freitagnachmittag getestet wurden und das Produkt am Montag bereits den Kunden erreichte. Das Ende des Freitags und nur der Anfang des Montags blieben zum Testen und Beheben kritischer Fehler übrig. Infolgedessen kam die neue Version häufig als "roh" heraus oder Entwickler mussten am Wochenende dringend Fehler beheben. Nach einigen schwierigen Verschiebungen in der Lieferung verschob das Team die Lieferung des Sprints immer noch auf Mittwoch (reduzierte die Länge des Sprints nicht, sondern verschob den Zeitplan einfach um zwei Tage). Jetzt hat das Team Zeit, die Lieferung in einer entspannten Atmosphäre zu überprüfen und zu korrigieren.



Die endgültige Entscheidung, ob geändert werden soll oder nicht, liegt beim Team: Sie ist für das Produkt und dessen Ausgabe verantwortlich, weshalb sie die bequemste Option für sich selbst wählt. Ziel unserer Arbeit ist es nicht, Programmierern unsere Ansätze aufzuzwingen, sondern maximale Informationen über mögliche Risiken zu geben und für das Produkt geeignete Verbesserungen und Maßnahmen anzubieten.

Was unsere Testabteilung im vergangenen Jahr geschafft hat:

  • In 7 Produkten der Big Data-Abteilung der X5 Retail Group wurden regelmäßige Funktionstests durchgefĂĽhrt, von denen 2 ohne kritische Kommentare stabile Versionen im PROM erreicht haben. Organisierte regelmäßige BelastungsprĂĽfung von 3 Produkten.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

Änderungen sind immer komplex, aber sie sind notwendig, wenn wir für unsere Produkte rooten. Und es sind Tester, die einen wesentlichen Beitrag zur Sicherung der Produktqualität leisten können.
In den folgenden Artikeln werden meine Kollegen und ich darüber sprechen, wie wir bestimmte Produkte testen, eine Teststrategie auswählen, Tools (z. B. Allure Enterprise Edition - ein praktisches Tool zum Verwalten von Tests, Berichten und sogar zum Verwalten von Autotests) und wie automatisierte Tests in implementiert werden Pipeline und welche Entwicklungsoptionen wir sehen (Test Driven Development, wenn Sie darüber nachdenken, ist dies nur eine der möglichen Optionen).

More articles:


All Articles