Ich habe unserem neuen Scrum-Team kürzlich einen QA-Tester hinzugefügt. Der Tester verfügt über viel Erfahrung im automatisierten Testen und ist in der Lage, Skripte, Light Coding usw. zu erstellen. Er wird Automatisierungstools wie Selenium verwenden, um den QA-Prozess zu unterstützen. Allerdings ist mir etwas unklar, wo ich die Grenze in seinen Verantwortlichkeiten ziehen soll. Wie integriere ich QA in das Whiteboard?
1) Rolle und Verantwortlichkeiten
2) QA auf dem Scrum Whiteboard
Meiner Erfahrung nach kümmert sich das Qualitätssicherungspersonal normalerweise um System- und Akzeptanztests, daher denke ich, dass dies ein guter Anfang wäre. Dies beinhaltet sowohl manuelle als auch automatisierte Tests des Systems gegen die Anforderungen (funktional und nicht-funktional). Angesichts dessen, wie Sie den Hintergrund der Person beschreiben, klingt es so, als wäre dies eine angemessene Reihe von Verantwortlichkeiten für ihn. Aus diesem Grund, ja, er wäre die Person, die entscheidet, ob und wann eine implementierte Anforderung erledigt ist.
Ich persönlich würde in jeder Phase des Lebenszyklus, von den Anforderungen bis zur Freigabe, einen Qualitätssicherungsspezialisten einbeziehen. Dies würde bedeuten, dass Sie Ihre Anforderungen überprüfen, um sicherzustellen, dass es sich um gute Anforderungen handelt, und um frühzeitig Testfälle aus Designs (mit Schwerpunkt auf Testbarkeit und Korrelation von Designentscheidungen mit Anforderungen) und Dokumentation (insbesondere der an den Kunden gelieferten) zu erstellen ), Code und Tests sowie freigegebene Materialpakete.
Er könnte auch an der Messung der Produktqualität durch die Verwendung geeigneter Messungen und Metriken beteiligt sein. Dazu gehören zyklomatische Komplexität, Testabdeckung, Halstead-Komplexität , Fehler, Codezeilen und so weiter. Er könnte dann für jede Iteration darüber berichten und Module mit hoher Komplexität (was darauf hinweist, dass ein mögliches Refactoring angebracht ist), mit geringer Testabdeckung (was darauf hinweist, dass möglicherweise mehr Einheiten- oder Integrationstests erforderlich sind) und Fehlerdichte identifizieren. Da er auch etwas Erfahrung mit dem Schreiben von Code hat, wäre er in der Lage, sich die Codebasis anzusehen, sie zu verstehen und ihren Zustand auf eine Weise zu kommentieren, die sowohl für ein technisches als auch für ein nicht-technisches Publikum angemessen ist, selbst wenn er es nicht ist nicht aktiv entwickeln.
Andere Aufgaben würden variieren und hängen vom Team, dem Projekt, dem Zeitplan und der Arbeitsbelastung des Einzelnen ab. Sie müssen sicherstellen, dass er seine Aufgaben auch tatsächlich im Laufe einer normalen Woche erledigen kann, da Überstunden in der agilen Community allgemein als Anti-Pattern angesehen werden.
Was die Verwaltung der QA in Ihrem Projektverfolgungssystem betrifft, hängt dies davon ab, womit Ihr Team vertraut ist. Wenn ein Entwickler in so etwas wie Kanban das Gefühl hat, dass die Funktion implementiert und vom Entwickler getestet wurde, wird sie in die Qualitätssicherung verschoben. Sie können sich jedoch dafür entscheiden, nur ein Produkt-Backlog, ein Sprint-Backlog und eine Reihe abgeschlossener Elemente zu verwalten. In diesem Fall würde es im Sprint-Backlog bleiben, bis QA es als „erledigt“ bezeichnet, woraufhin es auf abgeschlossen verschoben wird und Sie Ihre Punkte erhalten. Möglicherweise entwickelt Ihr Team ein anderes System, das besser funktioniert, solange es für Ihre Arbeitsweise sinnvoll ist und nicht jeden bei seiner Arbeit behindert.
Claytons Antwort war knapp. Ich würde jedoch noch weiter gehen und sagen, dass jedes Team, das QA aus dem Team ausschließt oder die QA-Spezialisten als Bürger zweiter Klasse innerhalb des Scrum-Teams behandelt, den Sinn der Scrum-Methodik und die Funktionsweise agiler Praktiken wie XP völlig verfehlt hat .
Die Kernkonzepte hinter jeder agilen Methodik laufen auf Sichtbarkeit und kontinuierliche Kommunikation hinaus . Wenn Ihre QA-Teammitglieder nicht mit den Entwicklern zusammenarbeiten, erhalten Sie am Ende Code, der irgendwann im Prozess über den Haufen geworfen wird.
Selbst wenn Sie ein Team haben, in dem die einzelnen Mitglieder nicht funktionsübergreifend sind, sollte das Team als Ganzes es sein. QA sollte bei jedem Schritt aktiv eingebunden werden. Zum Beispiel:
Sobald Sie anerkannt haben, dass QA Teil des Teams ist, müssen die Aufgaben der QA genauso sichtbar sein wie die übrige Arbeit am Projekt. Keine unsichtbare Arbeit – niemals!
Wenn Sie Sprint-Aufgaben auf einem Kanban-Board verfolgen, müssen Sie auch die QA auf dem Board verfolgen. Ob es einer eigenen Spalte bedarf, ist ein Umsetzungsdetail, das das Team selbst bestimmen und durch Retrospektiven verfeinern kann. Viele Teams finden eine separate Swimlane oder Spalte für QA einen Mehrwert, aber das ist sicherlich keine Voraussetzung .
Alles andere in der ursprünglichen Frage ist ein Prozess, den das Team als Ganzes (einschließlich der QA-Mitglieder) für sich selbst definieren und kontinuierlich verfeinern muss. Solange es eine „Definition of Done“ gibt, auf die sich das gesamte Team geeinigt hat, spielen die Implementierungsdetails keine Rolle.
Scrum-Teams bestehen aus funktionsübergreifenden Mitgliedern. Es ist gefährlich, eine Person als QA-Person (oder DBA oder Sicherheitsexperte usw.) zu kategorisieren. Sie sollten danach streben, diese Person in das Team zu integrieren, damit sie ihr Fachwissen mit anderen als Teammitglied und nicht als spezialisierte Ressource teilen kann .
Das gesamte Team ist dafür verantwortlich, ein akzeptables Maß an Codeabdeckung zu bestimmen, welche Art von Tests durchgeführt werden und was zur offiziellen Definition von Done beiträgt. Überlassen Sie es dem Team zu bestimmen, wie der Testaufwand auf dem Board angezeigt wird. Sie sollten ihre Informationsstrahler zu ihrem eigenen Vorteil nutzen.
Meiner Erfahrung nach funktioniert es am besten, QA-Mitglieder als Beobachter im SCRUM-Team zu haben, aber keine Mitglieder. Ein gutes SCRUM-Team ist normalerweise klein (3-4 Mitglieder, aber 2 sind auch üblich) und ziemlich austauschbar (dh Bill gerät mit seiner User Story in Verzug, die eine höhere Priorität hat als meine, also höre ich mit meiner auf und helfe ihm ). Darüber hinaus ist es nicht fair, QA-Mitglieder nach Story Point-Entwicklungsgeschichten zu fragen. Meiner Erfahrung nach funktioniert es am besten, separate QA-SCRUM-Teams zu haben, die 1 Sprint hinter dem Entwicklungsteam arbeiten. Dies erfordert jedoch eine Verpflichtung zur Qualität von der Entwicklung, da der Code solide genug sein muss, dass es nicht sehr häufig ist, Entwickler zurückzurufen, um Fehler zu beheben. Ich habe herausgefunden, dass es am besten funktioniert, jeden Entwickler zu erstellen, um eine Wiki-Seite für seine User Story zu erstellen und seine Tests zu beschreiben (hoffentlich automatisiert, seine Auswirkung auf die Testabdeckung und Find Bugs). Dieses Wiki ist Teil von "done done" und wird im Code-Review überprüft.
Wenn Sie während des Sprints nicht testen, ziehen Sie Ihr Team zurück, um Fehler zu beheben, anstatt sich auf den nächsten Sprint zu konzentrieren. Es ist zwingend erforderlich, dass Scrum-Teams über eine QA-Ressource verfügen und das Testen während des Sprints und so früh wie möglich beginnt. Es ist kein Scrum, wenn Sie nach dem Sprint noch Tests und Fehlerbehebungen haben.
MrHinsh - Martin Hinshelwood