Wer ist zuständig? So eliminieren Sie Gatekeeping und steigern die Qualität

Jonny Steiner, Produktmarketingmanager

Wir sind sicher, dass Sie ein solches Szenario schon einmal erlebt haben: Sie laufen irgendwo in der Öffentlichkeit herum und treffen zufällig auf eine jüngere Person, die ein T-Shirt Ihrer Lieblingsband trägt. Vielleicht ist Ihre erste Reaktion etwa so: „Wow, ein Nirvana-T-Shirt? Ich frage mich, ob sie Nirvana-Lieder kennen.“ Klingt bekannt? Dann herzlichen Glückwunsch, Sie haben Gatekeeping-Potenzial! Wir sagen „Potenzial“, denn auf keinen Fall sollten Sie auf die Leute zugehen und sie über ihr Recht, ein Nirvana-T-Shirt zu tragen, befragen. Das ist eine Lektion fürs Leben, die Ihnen dieser Blogbeitrag kostenlos vermittelt.

Aber genug mit den Allgemeingültigkeiten, wir sind hier, um das Gatekeeping in Bezug auf Qualitätssicherungs- und Testteams zu besprechen. In der Welt der Softwareentwicklung ist ein Gatekeeper eine Person, die die Kontrolle darüber hat, wann eine Software oder ein Update für die Produktion bereit ist. Das bedeutet, dass in diesem Szenario der Gatekeeper die gesamte Verantwortung für die Softwarequalität trägt. Oft wird diese Rolle von einem engagierten Mitglied des Test- oder Qualitätssicherungsteams übernommen.

Wer Releases die Releases?

Oft werden Tester gefragt, wann sie ihre Zustimmung dazu geben release. Tester und Entwickler äußern oft ihre Frustration, wenn sie an Projekten gearbeitet haben, bei denen die Qualitätssicherung den Schlüssel dazu in der Hand hatte release. Die Übertragung dieser Verantwortung auf ein Team kann zu Streitigkeiten und Verzögerungen führen.

In gewisser Weise sind die Testteams stolz auf diese Auszeichnung, da sie ihnen viel Macht in die Hand gibt. Es stellt sich jedoch die Frage, warum Qualitätssicherungs- oder Testteams eine Genehmigung genehmigen müssen release überhaupt. Sicherlich nicht der Versuch, die Qualitätssicherungs- oder Testteams zu belästigen. Wir alle wissen, dass diese Teams unter schwierigen Bedingungen mit guter Natur und Souveränität ihr Bestes geben.

Andererseits wird den Testern die Verantwortung übertragen, das letzte Wort zu haben releaseDas übt großen Druck auf sie aus.

Schauen wir uns einige der negativen Konsequenzen an, die sich daraus ergeben, dass die Qualitätssicherung Ihr Gatekeeper ist:

• Alle Engpässe – Entwicklungsteams bestehen in der Regel aus fünf Personen, wobei eine Person als „Tester“ bezeichnet wird. Das lässt sich ganz einfach rechnen, wenn man eine Person für Tests und Qualität verantwortlich macht führen zu Engpässen.
• Die Hauptverantwortung tragen – Eine Person dafür verantwortlich machen releases bedeutet, dass andere Teammitglieder in der falschen Annahme agieren, dass alle Mängel in der Qualitätssicherung aufgedeckt werden. Vielleicht noch schlimmer: Es gibt ihnen auch die Möglichkeit, keine Verantwortung für Fehler zu übernehmen, die in die Produktion gelangen, weil sie einfach die Qualitätssicherung dafür verantwortlich machen können.
• Niemand ist perfekt, nicht einmal Tester – Am besten stützen Sie nicht Ihr gesamtes release Prozess auf der Suche nach einer Person alle die Käfer. Sie sind Menschen, und Sie auch, und Menschen machen Fehler.
• Rückkopplungsschleifen - Im Gatekeeper-Modell, wenn ein Entwickler seinen Teil in der abgeschlossen hat verarbeiten, Sie übergeben es dem Tester oder der Qualitätssicherung und fahren dann mit ihrem nächsten Projekt fort. Wenn jedoch das unvermeidliche Feedback kommt in, Sie müssen einen Kontextwechsel zurück zur vorherigen Funktion durchführen. Das kann zu einem Durcheinander von halb begonnenen und gestoppten Projekten führen.

Die Alternative zum Gatekeeping ist Gatebreaking

Es gibt Möglichkeiten, Tests durchzuführen, die sicherstellen, dass Sie sicher sind release Qualitätsanwendungen ohne die Notwendigkeit eines Gatekeepings. Wenn Sie die Arbeit der Qualitätssicherung dem gesamten Entwicklungsteam übertragen, machen Sie alle für die Qualität verantwortlich. Die Qualitätssicherung kann weiterhin für das Testen verantwortlich sein, aber es müssen noch weitere Tests durchgeführt werden und andere Teammitglieder können helfen.

• Entwickler können ihre Arbeit abdecken, indem sie ihre eigenen Unit-Tests schreiben.
• Produktmanager können die Staging-Umgebungen überprüfen, um sicherzustellen, dass neue Funktionen wie ausgeführt funktionieren.
• DevOps Manager können CI-Systeme verwenden, um Tests zu überwachen, während jeder neue Code festgeschrieben wird.

Sie können einfach mit der Umsetzung dieser Praxis beginnen.

Beginnen Sie mit einer Sitzung, bevor die Entwicklungsarbeit für eine neue Funktion beginnt. Auf diese Weise können die Entwickler und Tester in den Sprint einsteigen und verstehen, was sie tun müssen, um nachzuweisen, dass die Arbeit gemäß den Abnahmekriterien abgeschlossen wurde. Da die Arbeit im Voraus besprochen wird, wird die Arbeitsbelastung gleichmäßig auf das Team verteilt und da die API-Tests von den Entwicklern geschrieben werden, kann die Qualitätssicherung an UI- und Funktionstests arbeiten.

Wenn das Projekt voranschreitet und das Team ein Problem findet, das angegangen werden muss, kann es untereinander oder zwischen Teams darüber diskutieren. Wenn die Qualitätssicherung beispielsweise einen Fehler entdeckt, kann sie ihn den Produktentwicklungsteams mitteilen, um zu sehen, ob es sich um etwas handelt, das sofortige Aufmerksamkeit erfordert, oder ob es warten kann.

Noch besser: Je mehr Menschen sich an einem Projekt beteiligen und an Tests teilnehmen, desto mehr kommt es zu einer Shift-Left-Mentalität, bei der Tests so früh wie möglich im Prozess durchgeführt werden. Niemand muss auf eine bestimmte Zeit warten, um mit dem Testen zu beginnen, es wird einfach zu einem Teil der täglichen Routine der Menschen. Langfristig soll dies dazu beitragen, das Risiko gegen Ende des Entwicklungszyklus zu minimieren

Letztendlich führt es zu mehr Tests, was zu einer besseren Abdeckung führt, da interdisziplinäre Teams miteinander kommunizieren können, anstatt in ihren eigenen, isolierten Teams zu bleiben. Wenn isolierte Teams in Ihrem Unternehmen ein Problem darstellen, können Sie es sogar den Produktbesitzern und Stakeholdern zur Sprache bringen. Die Förderung der Kommunikation und Zusammenarbeit ist bei der Bewältigung einer Gatekeeping-Situation äußerst wichtig.

Die Ergebnisse sehen dann so aus:

• Geteilte Verantwortung - Da es keinen Verantwortlichen gibt, übernimmt das gesamte Team die Verantwortung für die Bereitstellung qualitativ hochwertiger Software.
• Tschüss Engpässe – Es ist nicht mehr eine einzelne Person, die gegen die Welt antritt. Da jeder testet, gelangen neue Versionen und Apps schneller in die Produktion.
• Verschärfung der Feedbackschleife – Kein Kontextwechsel mehr, wenn ein Fehler entdeckt wird. Mängel werden frühzeitig im Prozess entdeckt und behoben, wodurch Produktionsverzögerungen vermieden werden.

Gatekeeping in der Qualitätssicherung ist ein Relikt

In einigen Organisationen kommt es immer noch vor. Der Qualitätssicherung wird die Verantwortung für ein Projekt übertragen release und hält die Schlüssel dazu release. Diese schädliche Praxis übt Druck auf die Tester aus und führt zu schlechten Beziehungen zwischen isolierten Teams, da diese getrennt auf ein Ziel hinarbeiten, an dem sie nicht zusammenarbeiten.

Bei der Praxis des QS-Gatekeeping gibt es zwei negative Hauptszenarien:

1. Verzögerte Projekte – Da die Qualitätssicherung bestimmte kleine Probleme vorher blockiert release.
2. Mängel in der Produktion – Wann immer ein Fehler durchsickert, ist die Qualitätssicherung der Sündenbock, da sie als für die Qualität insgesamt verantwortlich angesehen wird.

Um diese antiquierte – und ehrlich gesagt antikollaborative – Methode der Entwicklung und des Testens abzuschaffen, müssen die Teams alle Projektbeteiligten während der Entwicklung an den Tests arbeiten lassen, anstatt die Qualitätssicherung für alles verantwortlich zu machen. Sie müssen auch nach links wechseln und früh und häufig testen. Dieses Grundverständnis wird Organisationen dabei helfen, ein System zu schaffen, in dem jeder seinen Beitrag leisten und die Gesamtqualität verbessern kann releases wird sich auch verbessern.

Qualität als Ziel und als Konzept muss eine der Grundlagen des Arbeitsablaufs eines Teams sein. Es muss auch etwas sein, an dem jeder, der an einem Projekt beteiligt ist, teilhaben kann. Wenn Sie bemerken, dass in Ihrem Unternehmen Silobildung oder mangelnde Zusammenarbeit zwischen Teams auftritt, sollten Sie dies denjenigen zur Sprache bringen, die in der Lage sind, dies zu ändern. Wenn sich ein QA-Team auf das Gatekeeping konzentriert, wird die Gesamtqualität Ihrer App darunter leiden, und das ist schade, denn das Wort steht buchstäblich im Titel.