Warum können Qualitätssicherungsexperten nicht Fachwissen austauschen und neue Arbeitsweisen vorschlagen?

Es könnte daran liegen, wie Sie diese Änderungen vorschlagen.

Es hat wahrscheinlich nichts mit Ihrer Position (QA) per se zu tun, sondern mehr mit der Tatsache, dass ein neuer Typ hereinkommt und allen sagt, dass das, was sie tun, falsch ist (obwohl sie noch nicht lange genug dabei sind). um zu verstehen, warum es so gemacht wird).

Darüber hinaus könnten Sie sogar als Bedrohung angesehen werden, insbesondere wenn Sie das obere Management in diese Entscheidungen einbeziehen. Man könnte sehen, dass Sie um Respekt und Anerkennung ringen, weil Sie all diese neuen Ideen für das Team zur Verfügung stellen, was wiederum die anderen Teammitglieder im Vergleich dazu schlechter aussehen lässt.

Mein Rat ist, die folgenden zwei Dinge der Reihe nach zu tun:

1. Verstehen Sie , warum der aktuelle Prozess so ist, wie er ist. Wenn Sie diesen Schritt ausführen, werden Sie vielleicht sogar erkennen, dass Ihre „Verbesserung“ es entweder nicht wert ist oder vielleicht sogar schädlich ist. Gehen Sie niemals davon aus, dass Sie Recht haben, bevor Sie nicht ausreichend recherchiert haben, um festzustellen, ob Sie Recht haben .
2. Arbeiten Sie mit dem Team zusammen, um „Ihre Idee“ in die Idee des Teams umzuwandeln . Sie müssen sicherstellen, dass Sie alle Eigentumsansprüche entfernen, die Sie möglicherweise auf den neuen Prozess haben. Auf diese Weise wird es, anstatt „die Idee des Neuen“ zu sein, „eine Verbesserung unseres Prozesses“ sein.

Jeder im Team kann Vorschläge machen, wie das Team seine Leistung verbessern kann, auch neue Teammitglieder mit QA-Hintergrund. Es sprechen jedoch zwei Dinge dagegen, dass Ihre Ideen akzeptiert werden.

1. Veränderung ist schwer. Wenn Ideen nicht durch Autorität (entweder formell oder informell) unterstützt werden, fällt es dem Team oft leichter, die neue Idee abzulehnen, als die vorgeschlagene Idee umzusetzen. Als neues Teammitglied hattest du nicht die Zeit, eine informelle Autorität aufzubauen, indem du zeigst, dass du immer das beste Interesse des Teams in deinem Herzen hast.
2. Nach meiner Erfahrung gehören Personen mit QA-Hintergrund nicht zu den Vorreitern bei der Übernahme agiler Methoden/Denken. Wenn das Team schlechte Erfahrungen mit einem QA-Mitglied gemacht hat, das versucht hat, die Prozesse wieder auf ein formalisierteres, wasserfallartiges Format anstatt auf ein relativ kostenloses agiles Format umzustellen, dann akzeptiert das Team Ihre Verbesserungsideen möglicherweise weniger, weil sie befürchten Sie, dass Sie sich auch von Agile zurückziehen möchten. Diese Angst ist völlig unabhängig davon, in welche Richtung Ihre Ideen das Team tatsächlich führen würden.

Vielen Dank, dass Sie als neues Teammitglied den Mut haben, Bedenken zu äußern und Verbesserungen vorzuschlagen. Es gibt einige gute Gedanken in den anderen Antworten.

Ein Teil Ihres Kommentars an Bart spricht Bände: „Es gibt eine Person, die das nicht tut. Sie ist die Projektmanagerin.“ Wenn sie mit einer klassischen Command-and-Control-Denkweise arbeitet, könnte das das Grundproblem sein. Möglicherweise fehlt es an einem vollständigen agilen Mindset.

Ihr Frust ist verständlich. Informieren Sie sich weiter über die Gruppe. Verstehen Sie die aktuelle Vorgehensweise und das Warum dahinter. Bauen Sie weiterhin Beziehungen zu den anderen Teammitgliedern auf. Teile deine Gedanken. Beeinflussen Sie, was Sie können.

Die Dinge sollten sich verbessern. Wenn nicht, dann müssen Sie eine Entscheidung treffen.

Der Input aller Teammitglieder sollte ernst genommen werden. Es ist falsch, eine einzelne Person oder Rolle für Teamergebnisse verantwortlich zu machen.

Als Software Quality Engineer (seit ca. 10 Jahren) berate ich seit jeher Teams mit großem Erfolg, wie sie ihre Prozesse verbessern können.

Er sagte, es sei nicht die Verantwortung der QA, Prozesse hinzuzufügen oder irgendetwas vorzuschlagen, weshalb das Team es nicht mag. Sie sehen dich als Herausforderung.

Ich muss dieser Bemerkung klar widersprechen und hoffe, dass ich erklären kann, warum ich denke, dass dies in der Verantwortung der Qualitätssicherung liegt. Beginnen wir mit den drei Aspekten der Softwarequalität :

• Funktionale Qualität : Darauf konzentrieren sich die meisten Qualitätssicherungen, z. B. Testen aus der Benutzerperspektive.
• Strukturelle Qualität : Darauf sollte sich Agile QA konzentrieren, wenn Sie mich fragen. Aus dem Agile-Manifest: "Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Agilität.". Bringen Sie Entwicklern bei, testbaren Code zu erstellen und sicher umzugestalten, mit dem Ziel, Software zu erstellen, die Änderungen nicht widersteht.
• Prozessqualität : Von der Anforderungserfassung bis zur Produktlieferung. Eigentlich sollte das gesamte SDLC eine QA-Verantwortung sein. Es gibt so viel zu verbessern, so viele Risiken zu minimieren. Die Konzentration auf agiles Risikomanagement hilft, Einfluss zu gewinnen, da es eine klare Aufgabe der Qualitätssicherung ist, Risiken im Prozess für den Wettbewerbsvorteil der Benutzer und Sponsoren zu beseitigen.

Diese drei Aspekte sind gleich wichtig. Wenn Sie nur ein Funktionstester sind, ist es schwierig, in den anderen Qualitätsaspekten für das Sehen respektiert zu werden. Strukturelle Qualität könnte eine Verantwortung der Entwickler sein, aber oft fehlt ihnen das Wissen und die Dringlichkeit, um hier Verbesserungen vorzunehmen. Die Prozessqualität könnte die Hauptverantwortung eines Scrum Masters sein, aber sie konzentrieren sich oft auf das Projektmanagement und nicht auf die Produktqualität. Auch wenn der Scrum Guide dies beschreibt: „Während jeder Sprint-Retrospektive plant das Scrum-Team Wege zur Steigerung der Produktqualität , indem es die Definition von „Done“ entsprechend anpasst.“ Also JA, es gibt viele Überschneidungen mit anderen Rollen, aber immer noch genug Raum für die QA, auf die sie sich konzentrieren kann.

Wenn ich in einem neuen Unternehmen anfing, würde ich Einzelgespräche zum Status Quo führen und/oder Schulungen mit allen Mitarbeitern (CEO, Manager, Key-User, Key-Stakeholder, Entwickler, Product Owner und Scrum Master) durchführen, um ihnen den Unterschied zwischen zu erklären diese drei Qualitätsaspekte, interne vs. externe Qualität und vielleicht die Quadranten des agilen Testens und welche Fähigkeiten dies mit sich bringt. Zeigen Sie, dass Sie über umfassende Kenntnisse in allen Aspekten der Softwareentwicklung verfügen. Dies wird Ihnen dabei helfen, Vorschläge zu akzeptieren, die Sie großartig machen, und sich selbst als DER Qualitätsmann oder das Qualitätsmädchen darzustellen.

Was ich über die Jahre gelernt habe:

• Handeln Sie selbstbewusst, aber mit Respekt. Glauben Sie wirklich, was Sie befürworten.
• Beschreiben oder visualisieren Sie das Problem. Lassen Sie das Team eine Lösung finden. Schlagen Sie Lösungen nur vor, wenn sie Sie fragen. Dies erleichtert die Übernahme von Änderungen. Noch besser, lassen Sie das Team eine Forschungsaktivität durchführen, nicht eine einzelne Person.
• Kulturelle Veränderungen sind langsam, das kann bis zu drei oder mehr Jahre dauern. Diejenigen, die sich oft, aber leise wiederholen, neigen dazu, dieses Rennen um den Kulturwandel zu gewinnen. Große Aufregung zu machen ist nie eine gute Strategie für den kulturellen Wandel.
• Als Scrum Master haben Sie mehr Einfluss. Sich über Agile und agiles Testen zu informieren, kann der erste Schritt auf diesem Weg sein. Ich arbeite seit 2009 in einer Doppelrolle (QA + Scrum Master). Scheint für mich großartig zu funktionieren.

Anregungen:

• Bitten Sie den Scrum Master oder Agile Coach, Ihnen bei der Umsetzung einer Verhaltensänderung zu helfen. Lassen Sie sie dem Team die Probleme beschreiben.
• Nutzen Sie Retrospektiven und wiederholen Sie ernsthafte Prozessprobleme, die Sie sehen. Versuchen Sie, nicht in Lösungen zu sprechen. Erklären Sie das WARUM, nicht das Was und Wie. Genauso wie bei perfekten User-Stories. :)
• Als letzten Ausweg zitiere ich immer gerne Martin Fowler : "Wenn Sie Ihre Organisation nicht ändern können, ändern Sie Ihre Organisation!"

Unabhängig davon, was es ist, ist es nicht so, wie eine Softwareorganisation arbeiten sollte. Der Erfolg in und für eine Organisation hängt von vielen Faktoren ab und einer davon ist Partizipation.

Es besteht auch die Möglichkeit, dass Sie sich des Gesamtbildes nicht bewusst sind. Was Sie vorschlagen, scheint aus Ihrer Sicht eine Lösung zu sein, erfordert jedoch möglicherweise ein Änderungs- und Übergangsmanagement oder den Fall, dass Einsätze für Sie nicht transparent sind. Ich denke, sie haben Ihre Empfehlungen ernst genommen, da die Aktion bereits da ist. Also, egal wer was macht, dein Einsatz zahlt sich aus und du solltest dich darüber freuen.

Aber wer mehr als 5 Jahre in der Führungsetage ist, wird hier leicht einen Fehler entdecken. Ihre Organisation scheint ein Initiativkiller zu sein. Sie sollten annehmen, dass Menschen bereit sind, zur Verbesserung der Organisation beizutragen. Wenn es daran liegt, dass Sie QA sind, müssen Sie aufhören zu denken und anfangen, nach besseren Möglichkeiten zu suchen.

Das QA-Team sollte die Autorität haben, zumindest Verbesserungen vorzuschlagen, aber dann hängt es wirklich davon ab, wie die Organisation Qualität definiert hat.