Sollten wir dedizierte Tester im Team haben oder das Testen liegt in der gegenseitigen Verantwortung des Entwicklungsteams

Wir haben derzeit mehrere Scrum-Teams mit 3 bis 6 Entwicklern und 1 dedizierten Tester in jedem Team.

Sollten wir ein Scrum-Team wie dieses haben ODER alle Entwickler haben und sie können die Testverantwortung gegenseitig teilen?

Ist diese Meinung relevant, oder ist es möglich, eine verbindliche Antwort zu geben?

Antworten (4)

In einem Scrum-Team unterscheidet man am besten zwischen Rollen und Fähigkeiten .

Jedes Scrum-Team braucht eine Testfunktion , aber nicht unbedingt Testerrollen .

Das gesamte Scrum-Team übernimmt die Verantwortung für die Qualität. Das bedeutet mehr als nur testen, es bedeutet auch:

  • Automatisierte Regressionstests
  • Aufrechterhaltung der Codequalität
  • Einsatz von Continuous Integration
  • Versuchsforschung

Es gibt zweifellos Fähigkeiten, um ein guter Tester zu sein, und einige werden darin besser sein als andere. Wir können jedoch versuchen, dieses Wissen durch Mentoring und Schulungen im Scrum-Team zu teilen. Aus diesem Grund sprechen wir davon, T-förmige Fähigkeitsprofile in einem Scrum-Team zu haben.

Guter Artikel. Sie schlagen also vor, einen Tester mit fundierten Kenntnissen verschiedener Testmethoden und andere Entwickler zu haben, um von ihnen zu lernen oder ihnen zu helfen?
Eine Mischung aus beidem. Denken Sie daran, dass es Zeiten geben wird, in denen der Tester nicht verfügbar ist (Urlaub, Krankheit), daher lohnt es sich, so viel Wissen wie möglich zu übertragen. Aber wenn Ihr Tester begabt ist, Probleme zu finden, suchen Sie nach dem Team, um ihn nach Möglichkeit zu unterstützen.

Auch wenn es wichtig ist, die Testverantwortung im gesamten Team zu teilen, brauchen Agile-Teams immer noch engagierte Tester, insbesondere jetzt, wo der Schwerpunkt auf Automatisierung liegt. Wenn Sie keine engagierte Person haben, die sich ausschließlich auf Qualität konzentriert, könnte dies für Ihr Team eine Katastrophe bedeuten.

Ich stimme zu, dass die Automatisierung im Mittelpunkt stehen sollte. Aber was könnte der Nachteil sein, wenn Entwickler auch für Automatisierungstests verantwortlich gemacht werden?
Der Nachteil ist, dass Sie sie dazu verpflichten, Vermögenswerte zu verwalten, die nichts zur Verbesserung und zum Wachstum des Produkts beitragen. Automatisierung ist großartig, aber sie trägt nichts zum Kundenerlebnis bei. Entwickler für all diese Assets verantwortlich zu machen, scheint übertrieben zu sein. Und wieder ist die Codeabdeckung eine knifflige Sache, besonders wenn Sie das Szenario „Wächter bewachen die Wächter“ haben und Sie höchstwahrscheinlich einen Rückgang der Testqualität feststellen werden.
Dies bedeutet auch einen Rückgang des ROI Ihrer Automatisierungsbibliothek sowie eine abnehmende Geschwindigkeit der Funktionsentwicklung. Denken Sie daran, dass Entwickler sich hauptsächlich um eine Sache kümmern: das Produkt auszubauen, indem sie regelmäßig kleine Änderungen an der Codebasis vornehmen. Testingenieure kümmern sich hauptsächlich um deklarative Tests, die die Grenzen oder „Kanten“ einer Softwarekomponente validieren. Wenn beispielsweise ein automatisierter Test ausgeführt wird, werden die meisten Codezeilen in einem Softwaremodul ausgeführt. Es ist nicht die beste Idee, dies den Entwicklern zu überlassen, um die Abdeckung (n # von Szenarien) sicherzustellen
Habe es. Diese Idee entstand, weil wir keine qualifizierten Leute zum Testen bekommen, sodass es schwierig wird, Automatisierungstests durchzuführen. Also kamen wir auf diese Idee.
Nun, ich denke, niemand mag diese Antwort, aber es ist die harte Wahrheit.
Wenn sich eine Person ausschließlich auf die Qualität konzentriert, bedeutet dies, dass sich der Rest des Teams nicht (zu sehr) darum kümmern muss ... Es öffnet auch die Tür zum Schuldzuweisungsspiel: "Sie sollten ..." haben, was alles schlecht ist in meinem Buch.
@Ray, die Gesamtqualität liegt in der Verantwortung des Teams. Kaufen Sie keine einzige Person im Team, die sich darauf konzentriert, oder die Verwaltung von Schulden im Zusammenhang mit technischen Entscheidungen, die längerfristige Auswirkungen haben, ist fehlgeleitet. Bedeutet die Anwesenheit eines Business-Analysten, dass sich niemand sonst um geschäftliche Auswirkungen oder Auswirkungen auf einen Benutzer kümmern muss? Bedeutet ein UI-Designer, dass niemand Eingaben oder Feedback zum Format oder zur Benutzerfreundlichkeit einer Webseite oder eines Anwendungsworkflows geben muss? Natürlich nicht.
Bedeutet das Fehlen eines Business Analyst, dass sich niemand um geschäftliche Auswirkungen kümmert ? Natürlich nicht. Solange die erforderliche Abdeckung von Anliegen besteht, muss keine spezifische Fach- und Titelposition besetzt werden.
Die Effektivität des Testens basiert darauf, die Dinge objektiv und unvoreingenommen zu betrachten. Es ist viel besser, ein engagiertes Team zu haben, das sich darauf konzentriert, Fehler zu finden, als einen Entwickler, der sich darauf konzentriert, zu beweisen, dass die SW funktioniert.

Die agile Methodik betrachtet den Entwicklungsprozess als „kollaborativen Prozess“, sodass jede Rolle am Entwicklungsprozess teilnehmen muss.

Die Tester betrachten das Produkt anders als die Entwickler: Im Allgemeinen versuchen die Tester, das Softwareprodukt zum Scheitern zu bringen . Im Gegensatz dazu versuchen Entwickler, das Softwareprodukt bestehen zu lassen . Dieser Unterschied in der Denkmethodik erhöht die Möglichkeit, Fehler frühzeitig zu entdecken.

Durch den Austausch engagierter Testmitglieder aus der Anfangsphase des Produkts erhalten sie ein gutes Verständnis für die geschäftlichen und technischen Aspekte des Produkts.

Die einzige Lösung besteht darin, einen einarmigen Projektmanager einzustellen. So kann er nicht "andererseits..." sagen.

Offensichtlich führt die Tatsache, dass "Entwickler" auch "Tester" sind, zu einem Interessenkonflikt.

Nehmen wir andererseits an, dass eine große Veröffentlichung jetzt fertig programmiert ist. Die „Entwickler“ haben keine Arbeit und die „Tester“ sind überlastet. Sollten die Entwickler also Solitaire auf ihren Computern spielen, bis die Tester fertig sind?

Es gibt also einfach keine absolute Lösung für das Dilemma.

In einem gesunden Team gibt es keinen Interessenkonflikt. Für die Qualität ist das gesamte Team verantwortlich. Das schließt nicht aus, einen Qualitätsexperten im Team zu haben, aber ja. Wenn Sie ein gesundes Team von Fachleuten haben, werden sie alle ein Qualitätsprodukt liefern wollen.
„Interessenkonflikt“ ist vielleicht der falsche Ausdruck. Es ist jedoch schwierig, Ihren eigenen Code zu testen, da Sie ihn auf eine bestimmte Weise betrachten. Die Leute sind im Allgemeinen nicht bereit, ihre Fehler zuzugeben (was für ein gutes Team ungesund ist). Wir haben das Problem umgangen, indem wir zuerst einen anderen Entwickler einen Code-Review machen ließen, dann würde auch ein anderer Entwickler eher diesen Abschnitt testen als derjenige, der den Code geschrieben hat.
Das sind jetzt alles Dinge, denen ich zustimmen kann. Ein Team, dem ich angehörte, erzielte hervorragende Ergebnisse bei White-Box-Tests. Der Peer-Reviewer war auch dafür verantwortlich, die vorgeschlagene Änderung herauszuziehen und zu testen. Haben Sie ihnen eine einzigartige Perspektive gegeben, „wie ich das durchbrechen kann“?
Sollten wir dedizierte Tester im Team haben oder das Testen liegt in der gegenseitigen Verantwortung des Entwicklungsteams
AntwortenHierDatenschutz-Bestimmungen1y, 0v