Qualität liegt in der Verantwortung des Teams. Unsere QS-Erfahrung

Ich arbeite als QS-Ingenieur bei Miro . Ich erzähle Ihnen von unserem Experiment, einen Teil der Testaufgaben an Entwickler zu übertragen und die Rolle des Testers in die Rolle der Qualitätssicherung (QS) umzuwandeln.

Zunächst kurz zu unserem Entwicklungsprozess. Wir haben tägliche Client-Releases und 3 bis 5 Server-Releases pro Woche. Das Entwicklungsteam besteht aus mehr als 60 Mitarbeitern, die in 10 funktionale Scrum-Teams unterteilt sind.

Ich arbeite im Integrationsteam, dessen Aufgabe es ist, unseren Service in externe Produkte und externe Produkte in unseren Service zu integrieren. Zum Beispiel haben wir den Jira Task Tracker integriert . Jira-Karten - eine visuelle Anzeige von Aufgaben, die Sie bequem auf dem Brett bearbeiten können, ohne auf Jira einzugehen.

Wie hat das Experiment begonnen?

Alles begann mit einem alltäglichen Problem. Als einer der Tester auf die Krankenliste ging, wurde die Leistung des Teams stark reduziert. Das Team arbeitete weiter an den Aufgaben, aber der Code erreichte die Testphase und die Aufgabe wurde angehalten. Infolgedessen erreichte die neue Funktionalität die Produktion nicht rechtzeitig.

Die Abreise des Testers in den Urlaub ist eine andere Geschichte. Er muss im Voraus einen der Tester finden, der bereit ist, seine Aufgaben zusätzlich zu seinen eigenen zu übernehmen, zuzustimmen, in Aufgaben einzutauchen. Gleichzeitig machen zwei Tester Urlaub, was ein unzulässiger Luxus ist.

Wir begannen darüber nachzudenken, wie wir das Problem lösen könnten, und stellten fest, dass das eigentliche Problem darin bestand, dass der enge Hals der Entwicklungsprozesse getestet wurde. Ich werde Ihnen ein Beispiel für mehrere Geschichten zeigen.

Die erste Geschichte: endloses Rollback von Aufgaben

Es gibt auch einen Entwickler. Jeder hat seine eigenen Aufgaben. Der Entwickler hat eine der Aufgaben erledigt und mir zum Testen gegeben. Da diese Aufgabe eine höhere Priorität hat als meine aktuellen, wechsle ich zu ihr. Ich finde Fehler, bekomme alles in Jira und gebe es dem Entwickler zur Überarbeitung zurück.

Ich kehre zu den Aufgaben zurück, die verschoben werden mussten. Der Entwickler wechselt von neuen Aufgaben zu der Aufgabe, die ich zurückgegeben habe. Er korrigiert Fehler und gibt mich zum Testen zurück. Ich finde wieder Fehler und gebe die Aufgabe erneut zurück. Dieser Prozess kann sehr lange dauern.



Infolgedessen erhöht sich die Gesamtarbeitszeit für die Aufgabe um ein Vielfaches, gefolgt von einer Verlängerung der Markteinführungszeit. Dies ist für uns als Lebensmittelunternehmen von entscheidender Bedeutung. Es gibt mehrere Gründe, die für die Aufgabe aufgewendete Zeit zu verlängern:

1. Die Aufgabe wechselt ständig zwischen Entwicklung und Test.
2. Die Aufgabe wartet im Leerlauf auf einen Tester oder Entwickler.
3. Entwickler und Tester müssen regelmäßig zwischen Aufgaben wechseln, was zusätzliche Zeit und Energie erfordert.

Die zweite Geschichte: eine wachsende Reihe von Aufgaben

Unser Scrum-Team hat mehrere Entwickler. Sie reichen mir regelmäßig ihre Aufgaben zum Testen ein. Eine Reihe von Aufgabenformularen, für die ich Aufgaben erledige, basierend auf Prioritäten.

Wir haben ungefähr ein Jahr lang gearbeitet, aber in dieser Zeit ist das Unternehmen erheblich gewachsen: Die Anzahl der Projekte und Entwickler und damit die Anzahl der Testaufgaben hat zugenommen. Gleichzeitig war ich immer noch der einzige Tester in unserem Team und konnte meine Geschwindigkeit nicht vervielfachen. Infolgedessen sammelten sich immer mehr Aufgaben in der Testwarteschlange an, und der Prozess der Übertragung von Aufgaben zwischen dem Entwickler und dem Tester verlängerte die Wartezeit.

Plötzlich wurde ich krank. Die Lieferung neuer Funktionen von unserem Produktionsteam wurde vollständig eingestellt. Was sollte ein Team in einer solchen Situation tun? Sie können den Tester um Hilfe von einem anderen Team bitten. Mit hoher Wahrscheinlichkeit wird er jedoch nicht in unsere Besonderheiten eintauchen, was sich negativ auf die Qualität und das Timing beider Teams auswirkt.

Die Schlussfolgerung aus beiden Geschichten ist dieselbe - die Teams hängen zu sehr vom Tester ab:

• Die Leistung des gesamten Teams wird durch die Leistung des Testers begrenzt.
• Die Anzahl der Entwickler kann nicht erhöht werden, ohne das Personal der Tester zu erhöhen.
• Eine Erhöhung der Entwicklungsgeschwindigkeit ist nicht sinnvoll, wenn alle Aufgaben zum Testen in die Warteschlange gestellt werden.
• Während die Arbeit des Entwicklers vom Tester überprüft wird, verringert sich das Verantwortungsbewusstsein des Entwicklers für die Qualität.
• Wenn es keinen Tester gibt, leidet der Prozess der Ausgabe neuer Funktionen.

Lassen Sie uns das Personal der Tester erhöhen?

Der naheliegendste Gedanke ist, das Personal der Tester zu erhöhen. Dies wird funktionieren, aber nur bis zu einem bestimmten Punkt: Die Anzahl der Aufgaben wird ständig zunehmen, und es ist unmöglich, die Anzahl der Tester unendlich zu erhöhen - irgendwann wird es teuer und ineffizient. Fedor Ovchinnikov , CEO von Dodo Pizza, hat gut über das Thema "Ressourcendenken" geschrieben (können Sie das Problem nicht lösen? Stellen Sie einen anderen Mitarbeiter ein).

Es ist viel effizienter, die Geschwindigkeit und Qualität der Entwicklung innerhalb der aktuellen Ressourcen aufrechtzuerhalten. Aus diesem Grund haben wir beschlossen, ein Experiment zu starten, mit dem Teams sofort Funktionen erstellen können, wobei alle Risiken und Grenzsituationen berücksichtigt werden. Sie nannten es Transform-Tester in QA, weil es um die Umwandlung einer der Rollen im Team geht: von einem Affentester, der Fehler durch den Entwickler identifiziert, bis zu einem QA-Ingenieur, der die Qualität in allen Phasen des Entwicklungsprozesses bewusst sicherstellt.

Lassen Sie uns die Entwicklungsprozesse verbessern

Ziele des Experiments:

• Beseitigung der Abhängigkeit des Teams von Testern, jedoch ohne Qualitäts- und Zeitverlust.
• Verbessern Sie die Qualitätssicherung durch QS-Ingenieure in Teams.

Der erste Schritt bestand darin, das Denken des Teams zu ändern. Jeder ist daran gewöhnt, dass der Tester für die Qualität des Teams verantwortlich ist.

Unsere Hypothese war, dass eine Verlängerung der Zeit zum Vorbereiten und Testen von Aufgaben dazu beitragen würde, die Anzahl der Iterationen bei der Arbeit an einer Aufgabe zu verringern. Dies wiederum ermöglicht es, neue Funktionen in die Produktion zu bringen, ohne an Geschwindigkeit und Qualität zu verlieren, und möglicherweise schneller und mit besserer Qualität.

Gemeinsam mit dem Team und mit Testern anderer Teams haben wir ein neues Arbeitsschema entwickelt. Während das Team ein halbes Jahr daran arbeitet, haben wir die Schwierigkeiten und Probleme berücksichtigt, die auf dem Weg entstanden sind, und heute sieht es so aus:

1. Präsentation der Produktion.
2. Technische Lösung und Testszenario.
3. Entwicklung und Verifikation.
4. Lassen Sie los

Erklärung des Problems

Der Product Owner legt dem Team die Erklärung des Problems vor. Das Team analysiert die Formulierung, um Grenzsituationen auf technischer und Produktseite zu identifizieren. Wenn es Fragen gibt, die weiter untersucht werden müssen, wird eine separate Aufgabe festgelegt, für die im Sprint Zeit zugewiesen wird.

Technische Lösung

Das Ergebnis der Analyse der Formulierung des Problems ist eine technische Lösung, bei der es sich um einen oder mehrere Entwickler handelt. Alle relevanten Mitarbeiter des Unternehmens, einschließlich der Qualitätssicherung, müssen mit der technischen Lösung vertraut sein und dieser zustimmen. Die technische Lösung beschreibt das Problem, das wir lösen, die Funktionsblöcke des betroffenen Produkts und den vorgeschlagenen Plan für Änderungen am Code.

Mit dieser Lösung können Sie eine einfachere und bessere Lösung identifizieren, die auf den Erfahrungen der relevanten Teilnehmer am Entwicklungsprozess basiert. Mit einer detaillierten technischen Beschreibung ist es einfacher, Blockierungsprobleme zu erkennen und zu vermeiden. Es ist einfacher, eine Codeüberprüfung durchzuführen.

Hier ist ein Beispiel für einige Blöcke einer technischen Lösung:

Aufgabenbeschreibung

Werden dem System neue Entitäten oder Ansätze hinzugefügt?
In diesem Fall werden sie beschrieben und erklärt, warum es unmöglich ist, das Problem im Rahmen bestehender Ansätze zu lösen.
Ändert sich die Serverinteraktion innerhalb des Clusters? Werden neue Clusterrollen hinzugefügt?

Ändert sich das Datenmodell?

Für den Server sprechen wir über Objekte und Modelle.
Wenn das Datenmodell komplex ist, können Sie es in Form eines UML-Diagramms oder als Textbeschreibung darstellen.

Ändert sich die Interaktion zwischen Client und Server?

Beschreibung der Änderungen. Wenn dies eine API ist, kann sie an externe Benutzer weitergegeben werden? Vergessen Sie nicht die Fehlerbehandlung - d. H. Geben Sie den richtigen Grund an.

Testszenario

Parallel dazu erstellt der Entwickler oder die Qualitätssicherung ein Testszenario, das alle möglichen Stellen berücksichtigt, an denen Probleme aufgetreten sind. Wenn der Entwickler dies tut, gibt er das Skript unbedingt an die Qualitätssicherung weiter, die es auf Vollständigkeit und Vollständigkeit überprüft. Wenn es sich bei dem Skript um eine Qualitätssicherung handelt, muss der Entwickler bestätigen, dass er versteht, wie die einzelnen Elemente ausgeführt werden können. Das Team bewertet das Skript auch auf Richtigkeit.

Zum Zusammenstellen und Speichern von Skripten verwenden wir HipTest.

Entwicklung und Validierung

Der Entwickler beginnt mit dem Schreiben von Code basierend auf einer technischen Lösung und berücksichtigt alle möglichen Situationen, die in der Testdokumentation beschrieben sind. Besteht eine Codeüberprüfung und vergleicht den Code mit Testszenarien. Erzeugt die Zusammenführung im Master.

Zu diesem Zeitpunkt bietet die Qualitätssicherung dem Entwickler die erforderliche Unterstützung. Es hilft beispielsweise beim Abspielen komplexer Fälle, beim Einrichten einer Testumgebung, beim Durchführen von Lasttests und informiert Sie über die möglichen Nuancen bei der Ausgabe großer Funktionen an die Produktion.

Freigabe der fertigen Funktionalität

Dies ist die letzte Phase. Hier muss das Team möglicherweise Aktionen vor und nach der Veröffentlichung ausführen, z. B. die Aufnahme neuer Funktionen für Beta-Benutzer.

Dokumentation und Tools

Das neue Arbeitsschema erforderte ein stärkeres Eintauchen der Entwickler in den Testprozess. Als Qualitätssicherung war es mir daher wichtig, ihnen alle notwendigen Werkzeuge zur Verfügung zu stellen und die Grundlagen des Funktionstests zu vermitteln. Zusammen mit der Qualitätssicherung anderer Teams haben wir eine Liste der erforderlichen Dokumentationen erstellt, die fehlenden Testanweisungen erstellt und die vorhandenen unter Berücksichtigung von Dingen fertiggestellt, die für Entwickler nicht offensichtlich waren.

Dann gaben wir Entwicklern Zugriff auf alle Testtools und Testumgebungen und begannen, gemeinsame Tests durchzuführen. Anfangs wollten die Entwickler keine Verantwortung für die Testergebnisse übernehmen, da sonst niemand etwas für sie überprüfte, was für sie ungewöhnlich war. Jeder Entwickler hatte nur ein Testskript, die von ihm entwickelte Funktionalität und die Schaltfläche Zusammenführen. Aber nach und nach gewöhnten sie sich daran.

Versuchsergebnisse

Seit Beginn des Experiments sind sechs Monate vergangen. Die Grafik zeigt die Statistik der Anzahl der Fehler pro Woche in unserem Team. Die rote Farbe zeigt die Anzahl aller vom Team gefundenen Fehler an, die grüne die Anzahl der behobenen Fehler.



Es ist ersichtlich, dass der Pegel der roten Linie bis auf den Burst zu Beginn des Experiments auf dem gleichen Pegel blieb. Es gibt keine Fehler mehr, was bedeutet, dass wir das aktuelle Qualitätsniveau beibehalten haben.

Gleichzeitig verringerte sich die durchschnittliche Arbeitszeit für Aufgaben nur um 2%: Vor Beginn des Experiments waren es 12 Stunden 40 Minuten, nach - 12 Stunden 25 Minuten. So konnten wir die aktuelle Arbeitsgeschwindigkeit bei Aufgaben beibehalten.

Infolgedessen ist unser Team nicht mehr stark von der Qualitätssicherung abhängig. Wenn ich krank werde oder in den Urlaub fahre, wird das Team ohne Geschwindigkeits- und Qualitätsverlust weiterarbeiten.

Betrachten wir das Experiment als erfolgreich, obwohl die Indikatoren für Zeit und Qualität gleich geblieben sind? Ja, wir glauben, weil wir die Geschwindigkeit und Qualität der Arbeit beibehalten und QS-Zeit für bewussteres Arbeiten an Produktqualität und Entwicklungsprozessen frei gemacht haben. Um beispielsweise Forschungstests durchzuführen, die Abdeckung von Funktionstests zu erhöhen und die Prinzipien und Regeln für die Entwicklung der Testdokumentation in allen Teams zu beschreiben.

In anderen Teams haben wir den Samen des Experiments ausgesät. Beispielsweise testet QA in einem der Befehle jetzt nicht, was der Entwickler in der Pull-Anforderung beschrieben hat, da der Entwickler dies selbst sehen kann. In einem anderen Team analysiert die Qualitätssicherung die Anforderungsänderungen und überprüft nur komplexe und nicht offensichtliche Fälle.

Dinge, die Sie vor Beginn eines Experiments beachten sollten

Dies ist ein komplexes und langwieriges Experiment. Es wird nicht per Fingerklick implementiert, Sie müssen sich sorgfältig darauf vorbereiten und nicht auf schnelle Ergebnisse warten.

Seien Sie auf die Negativität des Teams vorbereitet. Sie können nicht einfach sagen, dass die Entwickler jetzt die Funktionalität testen. Es ist notwendig, sie darauf vorzubereiten, Ansätze zu entwickeln und den Wert des Experiments für das Team und das Produkt zu erklären.

Der Geschwindigkeitsverlust beim Start ist unvermeidlich. Die Zeit, um Entwickler zu schulen, die fehlende Dokumentation zu schreiben und Prozesse neu zu erstellen, braucht Zeit, die für das Experiment gespendet werden muss.

Es gibt keine fertige Lösung. Ähnliche Prozesse werden beispielsweise in Atlassian implementiert, dies bedeutet jedoch nicht, dass Sie sie auch unverändert in Ihren eigenen implementieren können. Die Anpassung an die Unternehmenskultur und die Besonderheiten der Teams ist wichtig.