Haftungsausschluss: Dies ist eine Übersetzung eines Artikels . Alle Rechte liegen beim Autor des Originalartikels und der Firma Miro.
Ich bin ein QS-Ingenieur in Miro . Lassen Sie mich über unser Experiment erzählen, teilweise Testaufgaben an Entwickler zu übertragen und die Rolle des Testingenieurs in QS (Qualitätssicherung) umzuwandeln.
Zunächst kurz über unseren Entwicklungsprozess. Wir haben tägliche Releases für die Client-Seite und 3 bis 5 wöchentliche Releases für die Server-Seite. Das Team besteht aus mehr als 60 Personen, die auf 10 Functional Scrum-Teams gespuckt wurden.
Ich arbeite im Integrationsteam. Unsere Aufgaben sind:
- Integration unseres Service in externe Produkte
- Integration externer Produkte in unseren Service
Zum Beispiel haben wir Jira integriert. Jira-Karten - visuelle Darstellung von Aufgaben, daher ist es nützlich, mit Aufgaben zu arbeiten, die Jira überhaupt nicht öffnen.
Wie das Experiment beginnt
Alles beginnt mit einem trivialen Problem. Wenn jemand von Testingenieuren krankgeschrieben war, wurde die Teamleistung erheblich beeinträchtigt. Das Team arbeitete weiter an Aufgaben. Als der Code erreicht war, wurde die Testphase angehalten. Infolgedessen erreichten neue Funktionen die Produktion nicht rechtzeitig.
Mit Test Engineer in den Urlaub zu fahren, ist eine komplexere Geschichte. Er / sie muss einen anderen Testingenieur finden, der bereit ist, zusätzliche Aufgaben zu übernehmen und Wissen auszutauschen. Von zwei Testingenieuren zur richtigen Zeit in den Urlaub zu fahren, ist kein Luxus.
Wir haben begonnen zu überlegen, wie wir dieses Problem lösen können. Wir finden heraus, dass die Hauptursache darin besteht, dass die Testphase ein Engpass ist. Lassen Sie mich einige Beispiele dafür nennen.
Fall 1: Aufgabe Tischtennis
Es gibt mich und Entwickler. Jeder hat seine eigenen Aufgaben. Entwickler haben eine Aufgabe erledigt und senden sie mir zum Testen. Soweit diese neue Aufgabe eine höhere Priorität hat, schalte ich sie ein. Ich habe Fehler gefunden, sie in Jira ausgelöst und die Aufgabe zur Behebung an den Entwickler zurückgesendet.
Ich wechsle zurück zu früheren Aufgaben. Entwickler wechseln von aktuellen Aufgaben zu zurückgegebenen Aufgaben zurück. Nach den Korrekturen gibt der Entwickler die Aufgabe zum erneuten Testen an mich zurück. Ich habe wieder einen Defekt gefunden und die Aufgabe wieder zurückgegeben. Dies könnte lange dauern.
Infolgedessen steigt der kumulierte Zeitaufwand für Aufgaben in wenigen Zeiträumen und damit für die Markteinführung, was für uns als Produktunternehmen von entscheidender Bedeutung ist. Es gibt nur wenige Gründe, warum die Anstrengungen zunehmen:
- Die Aufgabe wechselt ständig zwischen Testingenieur und Entwickler
- Warten Sie auf Test Engineer oder Developer
- Entwickler und Testingenieur müssen häufig den Kontext zwischen Aufgaben wechseln, was zu zusätzlichen Zeit- und Energieverlusten führt.
Fall 2: Die Aufgabenwarteschlange wird angehoben
In unserem Scrum-Team gibt es einige Entwickler. Sie schicken mir regelmäßig Aufgaben zum Testen. Das bildet eine Aufgabenwarteschlange, die ich basierend auf Prioritäten fortsetze.
So arbeiten wir seit ungefähr einem Jahr. In dieser Zeit wächst jedoch das Unternehmen. Die Anzahl der Projekte und Entwickler wurde erhöht und damit die Anzahl der zu testenden Aufgaben. Gleichzeitig war ich immer noch der einzige Testingenieur in unserem Scrum-Team und konnte meine Leistung nicht rechtzeitig steigern. Infolgedessen verlängerten die immer mehr Aufgaben, die zum Testen und Ping-Pong-Prozess in der Warteschlange standen, auch die Wartezeit.
Plötzlich wurde ich krank. Die Lieferung neuer Funktionen von unserem Scrum-Team an die Produktion wurde vollständig eingestellt.
Welches Team sollte in dieser Situation vorgehen? Es ist möglich, Test Engineer für ein anderes Team um Hilfe zu bitten. Ein anderer Testingenieur befindet sich jedoch nicht im Kontext und hat keinen Wissenstransfer im Voraus erhalten, was sich negativ auf Qualität und Zeitplan in beiden Teams auswirkt.
Das Ergebnis aus beiden Fällen im selben - Teams sind auch abhängig von Testingenieuren:
- Die Geschwindigkeit des Teams wird durch die Geschwindigkeit des Testingenieurs begrenzt.
- Die Anzahl der Entwickler kann nicht erhöht werden, ohne Testingenieure hinzuzufügen, da es nicht sinnvoll ist, die Entwicklung zu beschleunigen, wenn alle entwickelten Aufgaben zum Testen in der Warteschlange stehen.
- Während der Testingenieur die Aufgabe nach dem Entwickler überprüft, nimmt die Verantwortung des Entwicklers für eine Qualität ab.
- Wenn der Testingenieur nicht verfügbar ist, leidet der Lieferprozess.
Fügen wir Testingenieure hinzu?
Die offensichtliche Idee - erhöhen wir die Anzahl der Testingenieure. Das könnte bis zu einem bestimmten Moment funktionieren: Die Anzahl der Aufgaben wird zunehmen, aber es ist unmöglich, die Anzahl der Testingenieure kontinuierlich zu erhöhen. Es wird zu teuer und ineffizient sein.
Effizienter ist es, Geschwindigkeit und Qualität mit den aktuellen Ressourcen zu halten. Aus diesem Grund haben wir beschlossen, ein Experiment zu starten, mit dem Teams Funktionen mit eingebetteter Qualität erstellen können, bei denen Risiken und Eckfälle angenommen werden. Wir haben dieses Experiment "Tester in QS umwandeln" genannt, weil es um die Umwandlung einer Rolle von Affentestern geht, die nach Fehlern suchen, in QA, die die SDLC-Phasen bewusst beeinflussen und Qualität liefern.
Lassen Sie uns die Entwicklungsprozesse verbessern
Versuchsziele:
- Entfernen Sie die Abhängigkeit des Teams von Testingenieuren, die nicht an Qualität und Timing verlieren.
- Verbesserung der Qualitätssicherung durch QAs und Teams.
Der erste wichtige Schritt bestand darin, die Denkweise des Teams zu ändern. Alles wurde erwartet, dass Testingenieure sich ausschließlich um die Qualität kümmern und dafür verantwortlich sind.
Unsere Idee war, dass zusätzliche Anstrengungen bei der Vorbereitung und Überprüfung von Aufgaben dazu beitragen, die Anzahl der Ping-Pong-Iterationen zu verringern. Daher wird es möglich sein, neue Funktionen für die Produktion bereitzustellen, die akzeptable Geschwindigkeits- und Qualitätsniveaus beibehalten oder diese sogar verbessern.
Mein Scrum-Team hatte zusammen mit Testingenieuren anderer Teams einen neuen Prozess erstellt. Wir haben diesen neuen Prozess ein halbes Jahr lang entsprechend bearbeitet und in dieser Zeit treten nur wenige Probleme auf. Der Prozess sieht nun so aus:
- Präsentation zur Aufgabenstellung.
- Technische Lösung und Testszenario.
- Entwicklung und Verifikation.
- Lassen Sie los
Aufgabenstellung
Der Product Owner legt eine Aufgabenerklärung für ein Team vor. Das Team analysiert die Aufgabenstellung, um Eckfälle aus technischer und produktbezogener Sicht zu ermitteln. Wenn Fragen zur Klärung oder Untersuchung angezeigt werden, wird dies als separate Aufgabe mit dedizierter Zeit in einem Sprint verfolgt.
Technische Lösung
Als Ergebnis der Analyse entsteht eine technische Lösung, die von einem oder wenigen Entwicklern erstellt wird. Alle relevanten Teamkollegen zusammen mit der Qualitätssicherung müssen dies überprüfen und vereinbaren. Die technische Lösung enthält den Zweck der Lösung, die betroffenen Funktionsblöcke des Produkts und die Beschreibung der geplanten Codeänderungen.
Eine solche technische Lösung ermöglicht es, basierend auf den Erfahrungen der relevanten Teilnehmer des Entwicklungsprozesses eine leichtere und geeignetere Lösung zu finden. Mit einer detaillierten technischen Lösung ist es einfacher, Blockierungsprobleme zu erkennen und zu vermeiden und die Codeüberprüfung einfacher durchzuführen.
Hier ist ein Beispiel für einige Blöcke in Technical Solution:
Aufgabenbeschreibung
Werden neue Entitäten oder Ansätze in das System eingeführt?
Wenn ja, werden diese zusammen mit einer Erklärung beschrieben, warum es unmöglich ist, Aufgaben mit aktuellen Ansätzen zu lösen.
Ändern sich die Interaktionen von Servern innerhalb eines Clusters? Werden neue Clusterrollen eingeführt?
Ändert sich das Datenmodell?
Für Server geht es um Objekte und Modelle.
Wenn das Datenmodell komplex ist, kann es als UML-Diagramm oder Textbeschreibung dargestellt werden.
Ändert sich die Client-Server-Interaktion?
Ändert die Beschreibung. Wenn es sich um eine API handelt, können wir sie dann veröffentlichen? Vergessen Sie nicht die Behandlung von Ausnahmen, dh protokollieren Sie die richtigen Gründe.
Testszenario
Parallel dazu erstellen Entwickler oder QS Testszenarien unter der Annahme von Eckfällen und potenziellen Problempunkten. Wenn es vom Entwickler erstellt wurde, muss die Qualitätssicherung es auf Vollständigkeit überprüfen. Wenn das Testszenario von der Qualitätssicherung erstellt wird, muss der Entwickler überprüfen und bestätigen, dass klar ist, wie die einzelnen Punkte implementiert werden. Das Team bewertet auch Testszenarien auf Richtigkeit.
Zum Erstellen und Aufbewahren von Testszenarien verwenden wir HipTest.
Entwicklung und Verifikation
Der Entwickler erstellt einen Anwendungscode basierend auf der technischen Lösung und unter der Annahme von Eckfällen und Testszenarien. Bestehen der Codeüberprüfung und Überprüfung der Funktion anhand von Testszenarien. Fügt den Zweig zum Master zusammen.
In dieser Phase unterstützt die Qualitätssicherung den Entwickler. Helfen Sie beispielsweise bei der Reproduktion komplexer Testfälle, der Konfiguration der Testumgebung, der Durchführung von Belastungstests und der Beratung zur Bereitstellung großer Funktionen für die Produktion.
Freigabe der erledigten Funktionalität
Dies ist eine letzte Phase. Hier muss das Team möglicherweise Aktionen vor und nach der Veröffentlichung bereitstellen. Zum Beispiel neue Funktionen für Beta-Benutzer aktivieren.
Für Entwickler war ein neuer Entwicklungsprozess erforderlich, der den Testprozess stärker einbezog.
Daher war es wichtig, dass ich ihnen als QS alle notwendigen Werkzeuge zur Verfügung stelle und sie mit den Grundlagen der Funktionsprüfung studiere. Zusammen mit den QAs anderer Teams haben wir eine Liste der erforderlichen Dokumentationen zusammengestellt, fehlende Testanweisungen erstellt und vorhandene, für Entwickler nicht offensichtliche Dinge aktualisiert.
Anschließend haben wir Entwicklern Zugriff auf alle Testtools und Testumgebungen gewährt und begonnen, Tests gemeinsam auszuführen. Am Anfang wollten Entwickler keine Verantwortung für die Testergebnisse übernehmen, da niemand nach ihnen verifizierte. Es war ungewöhnlich. Jeder Entwickler hatte nur Testszenario, Funktionen, die vom Entwickler erstellt wurden, und die Schaltfläche Zusammenführen. Aber sie haben sich schnell angepasst.
Ergebnisse des Experiments
Es ist ein halbes Jahr seit Beginn des Experiments vergangen. Es gibt eine grafische Darstellung der Fehlermenge pro Woche. Die Anzahl aller entdeckten Fehler wird durch die rote Farbe dargestellt. Die Anzahl der behobenen Fehler wird durch Grün dargestellt. Die gelbe Linie ist ein Beginn des Experiments.
Es ist sichtbar, dass die rote Linie mit Ausnahme von Hecht zu Beginn des Experiments auf dem gleichen Niveau bleibt.
Die Anzahl der Fehler hat sich nicht erhöht und daher haben wir das aktuelle Qualitätsniveau beibehalten.
Zusammen mit dieser durchschnittlichen Zeit, die für die Aufgabe aufgewendet wurde, verringerte sich die Zeit um 2%: 12 Stunden und 40 Minuten vor dem Experiment vs. 12 Stunden 25 Minuten danach. Das bedeutet, dass wir es geschafft haben, die Geschwindigkeit zu halten.
Infolgedessen besteht in einem Team keine harte Abhängigkeit mehr von der Qualitätssicherung. Wenn ich krank werde oder in den Urlaub fahre, wird sich das Team ohne Geschwindigkeits- und Qualitätsverluste weiterentwickeln.
Betrachten wir Experiment als erfolgreich, obwohl Geschwindigkeit und Qualität gleich bleiben? Ja, wir tun dies, weil wir gleichzeitig QS-Kapazitäten für die bewusste Arbeit an Produkt- und QS-Strategien freigesetzt haben. Zum Beispiel für Erkundungstests, die Erhöhung der Abdeckung von Funktionstests und die Beschreibung von Prinzipien und Regeln für die Erstellung von Testdokumentationen in allen Teams.
Wir haben auch in anderen Teams eine Einstellung zu Saatgutversuchen. Zum Beispiel testet die Qualitätssicherung in einem Team jetzt nicht, was in der Pull-Anfrage des Entwicklers beschrieben ist, da der Entwickler dies möglicherweise selbst überprüfen kann. In einer anderen Team-Qualitätssicherung werden Pull-Anforderungen überprüft und nur komplexe und nicht offensichtliche Eckfälle getestet.
Was ist vor dem Start eines Experiments zu beachten?
Es ist ein komplexer und langer Weg. Es konnte nicht sofort implementiert werden. Es erfordert Vorbereitung und Geduld. Es verspricht keine schnellen Siege.
Seien Sie bereit für Team widerstandsfähig. Es ist nicht nur eine Möglichkeit zu behaupten, dass Entwickler von nun an die Funktionalität überprüfen werden. Es ist wichtig, sie darauf vorzubereiten, Ansätze zu entwickeln und die Vorteile des Experiments für Team und Produkt zu beschreiben.
Geschwindigkeitsverlust am Anfang ist unvermeidlich. Zeit für den Wissenstransfer für Entwickler, für das Erstellen fehlender Dokumentationen und für Änderungen in einem Prozess ist dies eine Investition.
Es gibt keine Silberkugel Ähnliche Prozesse werden beispielsweise in Atlassian implementiert, dies bedeutet jedoch nicht, dass es möglich ist, es so wie es ist in Ihrem Unternehmen zu implementieren. Es ist wichtig, das Experiment an die Kultur und die Besonderheiten des Unternehmens anzupassen.