Hallo!  Ich freue mich, Ihnen mitteilen zu können, wie es mir durch die Implementierung einer System-QA-Rolle gelungen ist, unseren Release-Flow um 20 % zu verbessern.  Da es sich bei meinem Unternehmen um ein typisches Produktunternehmen handelt, werden die Teams nicht nach Produkten, sondern nach Komponenten aufgeteilt. Dadurch ist es uns einerseits gelungen, leistungsstarke Teams mit „Wissensträgern“ zu bilden. Andererseits sind die Rollen innerhalb der Einheiten relativ isoliert, und unterschiedliche Hard Skills und Fachkenntnisse erzwingen ihre Grenzen. Beispielsweise muss ich manchmal einen Tester vom Backend-Team zum Frontend versetzen oder umgekehrt.  Dies führte dazu, dass es eine Frage der effektiven Orchestrierung innerhalb der QA-Teams und des Managements der teamübergreifenden Interaktion gab. Was sich natürlich letztendlich auf den Release-Flow auswirkte.   Freigabefluss vor Änderungen  Vor den Änderungen sah unser Release-Flow so aus:   Eine   ist ein Dokument, das die detaillierten Anforderungen, Erwartungen und Spezifikationen für eine bestimmte Funktion, ein bestimmtes System, ein bestimmtes Produkt oder ein bestimmtes Projekt innerhalb eines Unternehmens darlegt. Es dient als Brücke zwischen Geschäftsinteressenten und den Entwicklungs- oder Implementierungsteams und stellt ein klares Verständnis davon sicher, was erreicht werden soll und wie es mit den allgemeinen   übereinstimmt. Es sollte detaillierte Szenarien enthalten, die beschreiben, wie Benutzer mit der Funktion interagieren. Der Feature Owner (FO) hat die Aufgabe, Geschäftsanforderungen zu formulieren. Business Requirements Specification (BRS) Geschäftszielen  Eine   ist ein umfassendes Dokument, das detailliert beschreibt, was ein Softwaresystem leisten soll. Zum Beispiel, wie und welche Befehle interagieren, über welches Protokoll und welche Daten übertragen werden. Wenn das Team, das an der Funktion arbeitet, eine grafische Benutzeroberfläche verwendet, sollte das SRS Layouts der zu entwickelnden Funktion enthalten. Der Feature-Architekt ist für das Schreiben von SRS verantwortlich. Softwareanforderungsspezifikation (SRS)    – eine Reihe von Fällen, die ein Feature-Eigentümer prüft, bevor er ein Feature akzeptiert. Nachdem die Dokumente beschrieben sind, fahren wir mit der Implementierung der Funktion fort. Wenn das erste Team die Entwicklung und das Testen seines Teils der Funktion abgeschlossen hat, wird er an das zweite Team übertragen. Das zweite Team führt die Integration/Entwicklung/Tests durch und gibt sie an die nächste Einheit weiter. Und so weiter, bis alle an der Feature-Entwicklung beteiligten Komponententeams diesen Fluss durchlaufen. FO validiert die Funktion und sendet sie an die Veröffentlichung. Qualitätsaktionsplan (QAP)   Probleme mit dem Freigabefluss  Es scheint also alles in Ordnung zu sein – Dokumente, Anträge, Annahmefälle. Dabei sind wir jedoch auf folgende Schwierigkeiten gestoßen:   Probleme seitens der Qualitätssicherung:  Die Anforderungsprüfung beginnt erst nach der Entwicklung. Bereits von Entwicklern umgesetzte Aufgaben werden mit ihren Anforderungen an das QA-Team übergeben. Aber wie wir wissen, kann es bei den Anforderungen zu Fehlern kommen.  Es dauert ziemlich lange, das für einen Fehler verantwortliche Team zu finden, da nicht immer klar ist, welche Fälle bereits von anderen Teams getestet wurden.  Keine Wiederverwendung von Testartefakten. Im Rahmen des Testens einer Funktion bereiten QA-Teams ähnliche Testdatensätze vor. Aufgrund der Isolation und engen Spezialisierung der Teams konnten sie diese Daten jedoch nicht untereinander übermitteln.   Probleme seitens FO:  Aufgrund der vielen Funktionen nimmt das Schreiben von QAP viel Zeit in Anspruch.  Die Validierung der Funktion erfolgt nach der Entwicklung durch alle Teams. In unserem Fall verlängert dies aufgrund vieler Integrationsprobleme den Release-Flow erheblich.  Auch die Vorbereitung der Testumgebung ist aufgrund der Komplexität des Produkts und des Umfangs der Integrationen zwischen den Teams präzise. Verschiedene Teams testen ihre Komponenten gleichzeitig, was das Risiko einer Verfälschung, Änderung oder Löschung von Daten erhöht.   System-QA im aktualisierten Release-Flow  Um eine effektive teamübergreifende Interaktion zwischen QA-Teams zu erleichtern und den Release-Fluss zu reduzieren, haben wir die Rolle der System-QA eingeführt.  Dies trug dazu bei, den Arbeitsaufwand in Form des Schreibens von Abnahmefällen mit FO zu verringern und das Schreiben von Testszenarien zu beschleunigen, Zwischentests der Funktionskomponente vor der Weitergabe an das nächste Team einzuführen und auch die zeitaufwändige Arbeit der Testvorbereitung zu verlagern Umgebung bis hin zur Systemqualitätssicherung, wobei alle Nuancen und Anforderungen der Teams an Integrationen und Testdaten berücksichtigt werden.  Die System-QA ist zu einem Bindeglied zwischen den technischen und geschäftlichen Anforderungen für jede Funktion und dem Produkt als Ganzes geworden.  Onboarding für System-QA  Um den gesamten Release-Zyklus zu verstehen, müssen System-QAs verstehen, wie ein bestimmter Release-Zyklus in jedem Team funktioniert. Das Onboarding dauert in der Regel etwa drei Monate, da die Systemqualitätssicherung zwei bis drei Wochen in jedem Team verbringt, um deren spezifische Release-Zyklen zu verstehen.  Ergebnisse des neuen Prozesses  Wir testen jetzt die BRS/SRS-Anforderungen von Feature-Eigentümern und Architekten. Eine frühzeitige Fehlererkennung führt zu Kosteneinsparungen für das Unternehmen.  Wir haben einen teamübergreifenden QA-Bereich eingerichtet, in dem jedem Feature Testartefakte zugeordnet werden – Geschäftsanforderungen, technische Anforderungen, Akzeptanzfälle, Fälle anderer Teams, Testdaten. Dies hat allen QA-Teams erheblich geholfen, in einem einzigen Kontext zu sein und Daten effektiv wiederzuverwenden.  Der Prozess der Fehlerlokalisierung wurde beschleunigt, da die Qualitätssicherung des Systems über Testfallsätze aller Teams verfügt.  Da die Qualitätssicherung des Systems Abnahmefälle für jedes Team schreibt, ist dies ein hervorragender Hinweis zur Beschleunigung und Verbesserung der Testqualität.  Der Integrationsprozess ist schmerzlos geworden, da die Funktion nach jedem Befehl durch Akzeptanzfälle validiert wird.  Nachdem ein erheblicher Teil der Last vom FO entfernt wurde, beschleunigte sich die Akzeptanz von Features und die Vorbereitung eines Integrationsstandes mit Testdaten.  Insgesamt wurde der Release-Flow um 15–20 % beschleunigt und die Anzahl der Integrationsfehler um fast die Hälfte reduziert, da wir sie jetzt sowohl beim Schreiben von BRS- und SRS-Anforderungen als auch bei Teamintegrationen im Rahmen der Feature-Entwicklung erkennen.  Viel Spaß und produktives Testen!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

QA Head

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Produktivität steigern: Ein Leitfaden zur Implementierung einer neuen QS-Rolle für schnellere Releases

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps