Den Widerstand des Entwicklerteams gegen die vom QA-Ingenieur vorgeschlagenen Lösungen ansprechen?

Mein Problem ist, dass ich Probleme identifiziere und den Entwicklern sage, wie sie sie beheben können

Ich denke, Sie überschreiten den Rahmen Ihrer Position, und ich bin nicht überrascht über die Reaktion, die Sie erhalten. Ihre Aufgabe ist es nicht , Entwicklern zu sagen, wie sie Dinge reparieren können. Ich bin schon lange in diesem Geschäft und hatte noch nie einen QA-Mitarbeiter, der mir gesagt hat, wie man Code schreibt. Aber andererseits habe ich noch nie mit QA-Leuten gearbeitet, die sich Code ansehen. Das liegt außerhalb des Geltungsbereichs der QA.

Wenn Sie zu einem Entwickler kommen, der darüber spricht, wie er Funktionen zum Reduzieren höherer Ordnung verwenden sollte und so weiter, kann ich Ihnen genau sagen, was ihm durch den Kopf geht: „Wenn Sie so gut im Programmieren sind, warum programmieren Sie dann nicht? ?" Ihr ganzer Beitrag hat eine solche Einstellung. Wenn du so gut bist und sie so schlecht, warum arbeitest du dann immer noch dort?

Wie Sie sagten, besteht die Hauptaufgabe der Qualitätssicherung darin, Probleme zu identifizieren. Sie tun dies durch Tests und Analysen. Alle Informationen, die Sie hinzufügen können, die bei der Lösung des Problems helfen würden, sind immer gut. Aber seien Sie vorsichtig mit Lösungsvorschlägen. Denken Sie daran, Ihre Aufgabe ist es, Probleme zu identifizieren, nicht Lösungen. Alle Entwickler erwarten von QA so viele Informationen wie möglich, um ein Problem zu lösen. Wenn Sie wissen, wie Sie das Problem beheben können, geben Sie auf jeden Fall Details an. Aber wenn Sie nur eine Meinung haben, dann stellen Sie klar, dass es sich um eine Meinung und nicht um eine Richtlinie handelt. Schreiben Sie „Ich denke, das liegt daran, dass XYZ bei jeder Anfrage ein Token benötigt“ oder „Ich vermute, wir lassen das Token weg.“

Den Widerstand des Entwicklerteams gegen die vom QA-Ingenieur vorgeschlagenen Lösungen ansprechen?

Als „Engineer in Test“ verfügen Sie wahrscheinlich über mehr Programmierkenntnisse als die meisten QA, insbesondere in Ihrer aktuellen Arbeitsumgebung, basierend auf Ihrer Frage. Sie benötigen Programmierkenntnisse, um automatisierte Tests durchzuführen, und das erweckt den falschen Eindruck, dass diese Fähigkeiten von den Entwicklern akzeptiert und respektiert werden.

Indem Sie jedoch Vorschläge machen, wie die Probleme behoben werden können, überschreiten Sie Ihre beruflichen Grenzen. Sie haben begrenzte Informationen und Einblicke in den gesamten Entwicklungsprozess. Die Leute, die den Code schreiben, müssen für Lösungen verantwortlich sein, also lassen Sie sie ihre Arbeit machen.

Eine nicht-technische Analogie, die ich gerne verwende, ist diese: Wenn Sie einen Dachdecker beauftragen, Ihr Dach zu ersetzen, stellen Sie Fragen und beobachten ihn, um sicher zu sein, dass er gute Arbeit leistet. Aber wenn Sie auf das Dach steigen und anfangen, dem Dachdecker zu sagen, wie er "die Dinge besser machen könnte" oder was auch immer, sind Sie zu weit gegangen und werden Ihren Dachdecker wahrscheinlich wütend machen. Runter vom Dach und hör auf, dem Typen zu sagen, was er tun soll.

Konzentrieren Sie sich auf den Aufbau Ihrer Systeme und die Identifizierung von Entwicklerfehlern. Lassen Sie sie Lösungen für die von Ihnen identifizierten Probleme identifizieren und auswählen.

Ich denke, Sie müssen Ihre Kommunikation mit der Entwicklung in zwei Teile aufteilen:

• Formelle Berichte über erkannte Fehler.
• Informelle Vorschläge von Ihnen an die Entwickler, wie diese behoben oder verhindert werden können, und informelle Vorschläge von den Entwicklern an Sie, wie Sie die Software testen können.

Sie sollten versuchen, eine gute Arbeitsbeziehung mit den Entwicklern aufzubauen. Das mag durch deine Art und Weise, wie du angefangen hast, erschwert worden sein, also ziehe dich für ein paar Monate zurück. Beginnen Sie, indem Sie sie um Rat fragen: „Ich denke, wir sollten mehr Belastungstests für Komponente X durchführen. Welche Art von Arbeitsbelastung könnte sie überlasten? Gibt es schwierige Bereiche, die zusätzliche Tests erfordern?“ die Annahme von Ratschlägen wird normal und unwichtig.

Sobald Sie diese Beziehung haben, versuchen Sie beiläufig zu erwähnen, dass Sie glauben, dass eine bestimmte Gruppe von Testfehlern durch eine Designänderung als Gruppe behoben werden könnte.

Ich möchte zunächst sagen, dass ich in einem sehr ähnlichen Bereich mit fast ähnlichen Zielen arbeite: IT Audit. Wenn ich Sie richtig verstehe, sind Sie frustriert, weil Sie das Gefühl haben, dass andere Ihren Rat nicht beachten und Ihr Chef Sie nicht unterstützt, indem er auf Beziehungen statt Kompetenz besteht.

Wenn Sie möchten, dass die Leute Ihnen zuhören und Ihr Feedback ernst nehmen, möchten Sie ihnen zunächst sagen, wie es ihnen bei ihrer Arbeit zugute kommt, wenn Sie Ihnen zuhören. In Ihrem Fall besteht der Vorteil in weniger Fehlern und besser funktionierendem Code, der die Geschäftsziele eher erfüllt. Kontinuierlich schlechten Code zu schreiben und sich zu weigern, sich zu verbessern, wenn sich die Gelegenheit bietet, zeugt von Verachtung, Aggression und fast Arroganz in gewissem Sinne, da sie es besser wissen. Wenn es fortgesetzt wird, garantiert ein solches Verhalten fast die Kündigung aufgrund von Inkompetenz und Unfähigkeit, gut mit anderen zusammenzuarbeiten.

Ich schlage vor, dass Sie das Positive annehmen – dass diese Entwickler nicht versuchen, aus Trotz feindselig zu sein. Höchstwahrscheinlich verstehen sie nicht, warum Sie wollen, dass sie sich ändern . Gehen Sie davon aus, dass die Menschen vernünftig sind, dass sie, so sehr sie auch nicht kooperieren wollen, ihren eigenen Job aufgrund dieses Konflikts nicht gefährden werden. Besprechen Sie mit diesen Entwicklern, wenn alle Parteien ruhig sind, und erklären Sie Ihren Denkprozess – warum Sie möchten, dass sie sich so ändern wie Sie und wie sie davon profitieren

Ihr Chef ist auch hier unvernünftig, indem er auf Beziehungen statt Kompetenz besteht. Ich bin völlig anderer Meinung. Ihre Arbeit wirft ein gutes oder schlechtes Licht auf Ihren Chef. Wenn Ihr Chef alle Verantwortlichkeiten abstreitet, setzt er seinen eigenen Job aufs Spiel. Indem er nicht anerkennt, dass Kompetenz und Mehrwert durch Prozessverbesserung das sind, wonach er und seine Teammitglieder (Sie selbst) letztendlich beurteilt werden, zeigt er ein bemerkenswert schlechtes Urteilsvermögen. Die Situation ist unangenehm, aber den Kopf in den Sand zu stecken, löst das Problem nicht.

Ihre Arbeit dient als Kontrolle über die Arbeit anderer und Sie müssen das aufgrund dieser Tatsache akzeptieren - Es wird immer Menschen geben, die Sie nicht mögen. Nehmen Sie die Straße und sehen Sie das Feedback nicht als persönlichen Angriff, egal wie unangenehm es ist. Wachsen Sie sich ein dickeres Fell und lernen Sie, nicht auf die Anfeindungen / Unprofessionalität anderer zu reagieren - Langfristig wird Ihnen diese Praxis gute Dienste leisten.

Ich stimme dieser Antwort zu, eine klare Trennung zwischen Berichten über Probleme (Ihre Aufgabe) und informellen Vorschlägen zu deren Behebung vorzunehmen . Dazu füge ich einen weiteren Ansatz hinzu: Stellen Sie Fragen .

Ich bin ein technischer Redakteur und oft dafür verantwortlich, die Grenzfälle in einer Schnittstelle herauszufinden, bevor ich sie dokumentiere, denn wie wir alle wissen, ist keine Spezifikation jemals zu 100 % vollständig. Manchmal entdecke ich ein Verhalten, das, sagen wir mal, nicht ganz wünschenswert ist – es ist kontraintuitiv, oder es ist widersprüchlich, oder es ist teuer. Ich habe in meiner Karriere ziemlich gute Arbeit geleistet, indem ich erklärt habe, was meiner Meinung nach passieren würde und was ich stattdessen gesehen habe, warum es mich interessiert (wenn es nicht aus dem Kontext ersichtlich ist), alle Spekulationen, die ich über die Ursache habe, mit anderen teile und um Input oder Hilfe gebeten habe . Sie können schließlich einen Vorschlag machen oder einen Samen pflanzen, ohne jemandem zu sagen, was er tun soll.

Hier ist ein Beispiel dafür, was ich meine:

Ich habe einige Sicherheitstests durchgeführt. Ich dachte, dass eine Client-Anfrage nach Daten vom Dienst abgelehnt würde, wenn der Benutzer nicht autorisiert ist, aber ich konnte trotzdem Daten lesen. Insbesondere habe ich einen Client gestartet, einige Daten gelesen, die Autorisierung dieses Benutzers auf dem Server widerrufen und dann einige weitere Daten gelesen, und das hat funktioniert. Prüfen wir nicht jeden Anruf? Wenn wir es zwischenspeichern, geben wir an, wie lange zwischen den erneuten Überprüfungen liegen, oder bleibt das unbestimmt? Ich möchte sicherstellen, dass ich dies in der Verwaltungsdokumentation klar erkläre.

Angenommen, die Antwort lautet, dass der Autorisierungsstatus auf dem Server zwischengespeichert wird und der Entwickler keine weiteren Garantien abgeben möchte. Um das Gespräch fortzusetzen:

Danke; Ich verstehe. Wenn also ein Serveradministrator sicherstellen möchte, dass eine Sperrung sofort wirksam wird, weil es sich möglicherweise um eine Situation mit hohem Risiko handelt, gibt es eine Möglichkeit, den Cache zu leeren? Oder muss er die Sitzung beenden und den Client erneut verbinden?

Was wir hier getan haben, ist, das Problem des Benutzers zu beschreiben und laut darüber nachzudenken, wie er es mit der Software, so wie sie ist, lösen kann. Ein Entwickler, der dachte, dass eine kleine Verzögerung bei der Aktualisierung der Autorisierung keine große Sache ist, könnte noch einmal darüber nachdenken, ob die Antwort darin besteht, eine Clientsitzung neu zu starten – vielleicht ist das zu schwergewichtig. Oder vielleicht ist das vollkommen in Ordnung, und Sie werden lernen, dass Kundensitzungen kurz und kurzlebig sein und oft erneuert werden sollen, in diesem Fall haben Sie etwas über das Design gelernt .

Sie und der Entwickler sind Kollegen mit unterschiedlichen Fachgebieten. Keiner von Ihnen sollte dem anderen vorschreiben, wie er seine Arbeit zu erledigen hat, aber Sie sollten beide offen dafür sein, sich auszutauschen, zu lernen und zusammenzuarbeiten, um die Probleme Ihrer Kunden zu lösen.

Wie bereits angedeutet, könnte die beste Strategie darin bestehen, einen Schritt zurückzutreten und Ihren Eifer einzudämmen, allen zu sagen, wie die Dinge zu beheben sind, und sich stattdessen darauf zu konzentrieren, Lösungen für die Probleme zu identifizieren, zu dokumentieren und zu testen.

Auch in diesem speziellen Fall könnte die Arbeitsplatzkultur dem Dienstalter und der Arbeitsteilung Vorrang vor der Kompetenz einräumen. Sich in einem solchen Umfeld Respekt zu verdienen, kann ein langwieriger Prozess und ein harter Kampf sein, der mehr Zeit und Mühe erfordert, als an einem anderen Arbeitsplatz erforderlich gewesen wäre. Es klingt, als wäre das Management mitschuldig und schätzt den Status quo über Anpassung und Veränderung.

Ich frage mich, ob sich dieses Muster geändert hätte, wenn die Geschäftsanforderungen die Geschwindigkeit der Fehlerbeseitigung vorangetrieben hätten, dh wenn die Fehler offensichtliche und messbare Verzögerungen und Kundenbeschwerden verursacht hätten. Dies wäre schwierig zu beheben, bis sich die Anreize ändern, aber das liegt wahrscheinlich außerhalb Ihrer Kontrolle. Wenn Sie glauben, dass dies auf eine Dysfunktion am derzeitigen Arbeitsplatz hinweist und Sie ohne Hoffnung auf eine Trendwende weiterhin demotiviert, bis hin zur Kündigung, ist es möglicherweise an der Zeit, andere Beschäftigungsmöglichkeiten in Betracht zu ziehen.

Es gibt jedoch eine Reihe von Änderungen an Ihrem Verhalten, die einen Versuch wert erscheinen, bevor Sie die aktuelle Situation als irreparabel abtun. Ich möchte Sie ermutigen, zunächst einen Schritt zurückzutreten und Ihre eigene Herangehensweise an diesen Prozess zu überprüfen und den Rat zu befolgen, nicht zu viele Ratschläge zu den Korrekturen zu geben, es sei denn, Sie werden vom Entwicklerteam dazu aufgefordert.