Ich verstehe, dass die Qualitätssicherung theoretisch vom ersten Tag eines Sprints an mit den Entwicklern „zusammenarbeiten“ sollte. Aber wie funktioniert es eigentlich im wirklichen Leben? Lassen Sie mich zwei Szenarien vorstellen -
Szenario 1 , in dem eine Story 3 Tage Entwicklungszeit benötigt – Angenommen, es handelt sich um einen komplizierten Bericht mit zeitaufwändiger Datenbankeinrichtung und Domänenlogik usw., dessen Codierung 3 Tage dauert. Da der Entwickler vor 3 Tagen nichts Sinnvolles zum Testen liefern kann und angenommen, dass es nur 4 Stunden dauert, alle relevanten Testfälle zu schreiben, was wird von der Qualitätssicherung erwartet, bis der Bericht zum Testen bereit ist?
Szenario 2 , in dem Geschichten klein genug sind, um in Stunden abgeschlossen zu werden - Betrachten wir einen Anmelde-/Registrierungsbildschirm. Es kann winzige Geschichten geben, in denen sich Benutzer anmelden können, Benutzer sich registrieren können, die Funktion „Passwort vergessen“ usw. Ein Entwickler kann jede dieser Geschichten in Stunden fertigstellen und an die QA weitergeben und mit der nächsten Geschichte, aber der nächsten, fortfahren könnte die vorherigen kaputt machen. Wenn beispielsweise der Entwickler die Anmeldefunktion fertigstellt und die QA mit dem Testen beginnt und dann der Entwickler mit der Arbeit an der Funktion „Passwort vergessen“ beginnt, kann die Anmeldung auf unerwartete Weise unterbrochen werden, da die Funktionen tatsächlich verwandt sind. Wenn die Qualitätssicherung darauf wartet, dass alle zugehörigen Storys abgeschlossen sind, landen wir bei Szenario 1 oben.
In einer perfekten Welt kann erwartet werden, dass QA nichts tut, wenn es tatsächlich nichts zu tun gibt, und es als Teil der Kosten akzeptieren. Aber in der realen Welt werden PMO und andere Gruppen, die die Ressourcennutzung verfolgen, sicherlich darauf hinweisen, dass es sich um ein schlechtes Projektmanagement oder Schlimmeres handelt. Wie funktioniert das alles in realen Szenarien? Wie wendet man Scrum am besten in solchen Szenarien an?
Sie geraten in einen Anwendungsfehler, indem Sie Entwicklung und QA als separate Aktivitäten behandeln. In einem agilen Team stellen Praktiken wie testgetriebene Entwicklung (TDD), verhaltensgetriebene Entwicklung (BDD) oder akzeptanztestgetriebene Entwicklung (ATDD) sicher, dass die Qualität eingebaut wird, indem zuerst die Tests geschrieben werden .
Mit anderen Worten, das Rot/Grün/Refactor-Muster bedeutet, dass die Qualitätssicherung einbezogen werden sollte, bevor überhaupt Code geschrieben wird! Selbst in Teams, in denen Einzelpersonen eher I- als T-Form sind, sollten Entwickler und Tester durch Pair Programming und kontinuierliche Integration die ganze Zeit Hand in Hand arbeiten.
Entwickler und Tester sollten aktiv zusammenarbeiten, anstatt parallel oder nacheinander zu arbeiten. Selbst wenn Ihr Unternehmen dem Trugschluss der 100 %-Auslastung zum Opfer fällt, gibt es immer Dinge, die Tester in einem agilen Team tun müssen, darunter:
Ich empfehle Ihnen in keiner Weise, Ihre Prozesse zu überdenken. Ich weise nur darauf hin, dass es immer viel Test- und Qualitätssicherungsarbeit zu tun gibt, selbst wenn kein neuer Code oder neue Funktionen vorhanden sind.
Es ist auch kluges Geld für das Projekt, in Cross-Training-Entwickler und -Tester zu investieren. Viele Entwickler können davon profitieren, etwas über Testtechniken zu lernen, damit sie besser testbaren Code schreiben können. Ebenso können Tester davon profitieren, mehr über die Entwicklung zu lernen, was sie zu besseren Testern und umfassenderen Ressourcen macht.
Neben der „Agilisierung“ von Projekten „entwickelt“ sich die Rolle der QA erheblich weiter.
Ich sehe Todds Szenario (+1!) als Zielzustand für ein ausgereiftes QA-Team. Ich hoffe, Ihr Team schafft es direkt dorthin. Es gibt jedoch Fälle, in denen das QA-Team weniger ausgereift ist und zwischendurch einige Reifeschritte benötigt.
In einer perfekten Welt kann erwartet werden, dass QA nichts tut, wenn es tatsächlich nichts zu tun gibt, und es als Teil der Kosten akzeptieren.
Es gibt keine ideale Welt, in der jemand absolut nichts tut .
Abraham Lincoln wird mit diesen Worten zitiert
„Wenn ich fünf Minuten Zeit hätte, um einen Baum zu fällen, würde ich die ersten drei damit verbringen, meine Axt zu schärfen.“
Das ist es, was jede QA, unabhängig davon, wie ausgereift ein Prozess oder ein Team ist, tun sollte, während sie es nicht tut ... nun, QA.
Wie funktioniert das alles in realen Szenarien? Wie wendet man Scrum am besten in solchen Szenarien an?
QA ist nicht länger ein Team, das für die Ausführung von Testfällen verantwortlich ist. Die QA ist dafür verantwortlich, die Funktionsweise der Anwendung genau zu verstehen und die potenziellen Anwendungsfälle vorherzusehen, die fehlschlagen könnten und die dem Entwickler möglicherweise nicht bekannt sind. In der Vergangenheit wurde dies stark von (Funktions-) Analysten durchgeführt. Dies kann nicht mehr der Fall sein. In einigen Aspekten wird erwartet, dass QA zur Referenz für funktionales Wissen wird. Es ist umstritten, aber es ist wichtig, dies zu berücksichtigen.
Python wird heutzutage zu einer der nützlichsten Sprachen. Entwickler verwenden mehr Python für die Datenanalyse als für die Webentwicklung. Sie wissen, wer auch davon profitieren könnte, wenn er die Grundlagen der Datenanalyse kennt? Ja, Qualitätssicherung.
Wenn Sie die Schritte eins und zwei anwenden, haben Sie möglicherweise bereits ein Team, das in das QA-Team von Todd's passt.
Sie haben gefragt, wie die Zusammenarbeit aussieht, und das ist die wichtige Frage. In Scrum muss es keine QA-Phase geben. Praktiken wie 3-Amigos-Meetings, Test Driven Development, Behavior Driven Development und Pairing bedeuten, dass die Mitglieder des QA-Teams die ganze Zeit mit dem Team zusammenarbeiten können. Soweit wir können, wollen wir das Lean-Prinzip von Build Quality In anwenden, anstatt es nachträglich zu überprüfen, und dafür brauchen wir die QA-Perspektive während des gesamten Prozesses.
Die agile Denkweise und Arbeitsweise unterscheidet sich stark von der traditionellen Denkweise und Arbeitsweise. Dieser Satz zeigt "PMO und andere Gruppen, die die Ressourcennutzung verfolgen, werden es sicherlich als schlechtes Projektmanagement und Schlimmeres bezeichnen." dass Ihr Unternehmen einen langen Weg hat, bis Sie sich agil nennen können. Ich empfehle Ihnen, das Agile Manifest als Teamaktivität zu lesen und herauszufinden, was es für Sie als Team bedeutet.
Eine andere Sache, die Sie zu vermissen scheinen: Testen und QA sind nicht dasselbe . Beim Testen analysieren wir Software mit dem Ziel, Fehler zu finden, die wir bereits eingebaut haben. QA steht für alle Aktivitäten, die wir mit dem Ziel durchführen, Software vor eingebauten Fehlern zu schützen – keine Fehler, keine Notwendigkeit, sie zu beheben! Ich habe einen Artikel darüber geschrieben.
In agilen Teams kann der Tester beide Rollen übernehmen – Fehler finden (Testen) und Regeln aufstellen, die Software schützen (QA). Zum Testen braucht man eine Software, für QA braucht man keine Software.
Im wirklichen Leben könnte der Agile-Tester-Tag Aktivitäten wie diese beinhalten:
Ich hoffe, es hilft.
Können sie die Dinge zum Testen vorbereiten, damit sie, wenn die Geschichten/Bugs von den Entwicklern fertiggestellt sind, zum Testen bereit sind? Einrichten von Servern, Datenbanken oder Daten, damit sie sofort einsatzbereit sind, wenn es Zeit zum Testen ist.
Wir haben mehrere Kunden, alle mit ihrer eigenen Datenbank. Unser QA-Team weiß, welche Geschichten/Bugs bestimmte Clients betreffen, wenn der Sprint beginnt. Daher erstellt unser QA-Team Datenbanksicherungen für diese spezifischen Kunden und bereitet Testdatenbanken in unserer Testumgebung vor.
Ich fand diesen Artikel interessant: https://www.352inc.com/blog/what-does-qa-do-on-the-first-day-of-a-sprint/
Ermutigen Sie Ihre QA-Person, sich neue Fähigkeiten anzueignen, um Geschichten in die QA zu verschieben. Optionen > beinhalten:
Programmieren lernen
Machen Sie etwas Designarbeit
Führen Sie einige Benutzertests durch
Servereinrichtung und -verwaltung
Alle Punkte, die Sie in Ihrer Frage anführen, sind gültig, aber diese Probleme können durch sorgfältige Zusammenarbeit innerhalb des Scrum-Teams gelöst werden.
Ein Beispiel für ein Gespräch während der Sprintplanung:
„Einige dieser Geschichten werden ein paar Tage brauchen, um sich zu entwickeln, bevor sie zum Testen bereit sind. Aber ein paar der anderen Geschichten sind ziemlich schnell fertig. Warum machen wir nicht zuerst ein paar der kleineren Geschichten, damit die Tester haben sie etwas zu tun? Dann können sie an der ersten großen Geschichte arbeiten, wenn sie bereit sind.“
Auch:
„Ich mache mir Sorgen, dass viele unserer Stories voneinander abhängig sind. Das wird das Planen von Tests wirklich schwierig machen. Sollen wir die Stories umgestalten, um sie unabhängig zu machen, damit das Testen reibungsloser abläuft?“
Und:
„Dieser Sprint wird ziemlich wenig testen. Warum verwenden wir nicht die verfügbare zusätzliche Zeit, um unsere automatisierte Regressionsabdeckung zu erweitern?“
Wenn das Scrum-Team reift, kann es durchaus Praktiken wie testgetriebene Entwicklung und verhaltensgetriebene Entwicklung übernehmen. Sie können auch Cross-Training zwischen Entwicklern und Testern erhalten, damit die Teammitglieder T-förmige Kompetenzprofile haben .
Mit mehr Erfahrung und verbesserten Arbeitspraktiken wird das Team immer besser darin, Entwicklung und Testen in Einklang zu bringen. Letztendlich wird es kaum einen Unterschied zwischen dem geben, was als Codieren und was als Testen gilt.
Das sehr Kritische, was ich zu Beginn der obigen Antwort sagen wollte, war folgendes:
Wenn Ihre Entwickler einen mehrstufigen Entwicklungsfortschritt beginnen müssen, der so komplex ist, dass sie ihn neben „Benutzergeschichten“ in Meilensteine unterteilen möchten, dann schlage ich vor, dass sie Tests erstellen, während sie den Code entwickeln. (Sowie alle notwendigen "Stubs" und so weiter.) Der Meilenstein ist erreicht, wenn alle ihre Tests bestanden sind, und sie gehen von diesem Punkt aus weiter, während sie ständig überprüfen, ob die Tests weiterhin bestanden werden, damit sie sofort wissen, ob sie gerecht sind etwas kaputt gemacht. Von Zeit zu Zeit können sie einen ihrer Tests zurückziehen. Ich präsentiere diese getrennt von den Aktivitäten eines QA-Teams, das sich darauf konzentriert, „was endlich draußen sichtbar sein wird“. All dies – „testgetriebene Entwicklung“ – könnte durchaus in den Zuständigkeitsbereich des Entwicklungsleiters fallen,
Es gibt hier zwei Ebenen der „Zusicherung“ gleichzeitig – beide sehr ähnlich und doch sehr unterschiedlich. Aber der Projektleiter muss jederzeit wissen, was auf beiden Ebenen vor sich geht. Und die beiden Ebenen sollten sich unterscheiden!
Meiner Meinung nach sind die beiden Ebenen also (noch) nicht voneinander getrennt. Wenn dies der Fall wäre, dann wäre ganz klar ein „Release-Candidate-Release-Prozess vom Entwicklungsteam“ vorhanden, und es gäbe keine Frage, woraus der „von der QA zu genehmigende Code“ bestand.
Der spezifische Grund, warum "die beiden Ebenen (noch) nicht unterschiedlich sind", ist genau wie im herausgeschnittenen Absatz angegeben: In einem Softwareprojekt jeder Größe muss es zwei unterschiedliche Ebenen geben. Das QA-Team, das vollständig auf Ebene zwei arbeitet, sollte nicht an den internen (aber sehr notwendigen) Prozessen beteiligt sein – oder in irgendeiner Weise davon beeinflusst werden – die möglicherweise unten auf Ebene eins stattfinden. Aber die Entwicklungsteams sollten auch niemals „Kandidaten“ bis zur Qualitätssicherung der Stufe 1 freigeben, bis sie sich sicher sind.
Mein Verdacht ist, dass das Entwicklungsteam von einem Meilenstein, den nur es selbst kennt, zum nächsten "vorauseilt" und irgendwie erwartet, dass das QA-Team ein Ziel bewertet, das sich unter seinen Füßen bewegt. Offensichtlich ist das Unsinn.
Außerdem sehe ich aus Ihrer Beschreibung, dass sich die Funktionalität, die Ihr QA-Team testen soll, nicht auf einem Zweig mit stabiler Versionskontrolle befindet, der von zukünftigen Entwicklungsaktivitäten nicht betroffen sein wird. Entwickeltes Material sollte den QA-Zweigen hinzugefügt und markiert werden, damit die QA immer gegen ein sich nicht bewegendes Ziel testet.
Aber auch: Wenn Sie sagen, dass "eine zukünftige Geschichte eine frühere kaputt macht ", dann würde ich sagen, dass Sie ein viel größeres Task-Breakdown-Problem haben. "Stories" sollen darstellen, was ein hypothetischer Benutzer sieht, aber sie sollten auch das Verhalten der freizugebenden Anwendung widerspiegeln, nicht einen Zwischenschritt.
„Geschichten“ müssen zu den tatsächlichen Arbeitsabläufen und Meilensteinen Ihrer Entwicklungsteams zusammengesetzt werden – sie stimmen möglicherweise nicht genau überein, weil „Geschichtenerzähler nicht unbedingt wissen, wie es funktioniert“. Was Ihren Entwicklungsplan tatsächlich vorantreibt, sollte ein manchmal paralleles Streben nach abgeschlossenen Funktionen sein, die dann sinnvoll getestet werden können, sodass eine „Regression“ von diesem Status „Tests bestanden“ nicht zu erwarten ist. Es ist möglich, dass ein einzelnes Entwicklungs-Workflow-Inkrement „einen Teil einer Geschichte“ oder „einen Teil mehrerer Geschichten“ vervollständigt. In der Praxis wird dies durch die Architektur der Anwendung – insbesondere einer Legacy- Anwendung – vorgegeben.
Code511788465541441