So passen Sie Tests in Scrum-Sprints an und schreiben User Stories in Scrum

Ich bin Leiter des Entwicklungsteams eines neuen Projekts in meinem Unternehmen. Dies ist das erste Projekt, bei dem das Unternehmen Scrum einsetzen wird. Wir haben einen Wasserfall / iterativen SDLC. Die BAs schreiben die Anforderungsdokumente, übergeben sie an dev und test, beginnen mit der Entwicklung und werden sie in Iterationen zum Testen freigeben. Tester brauchen viel Zeit, um eine Version zu testen, mit der Entwickler ihre Entwicklung fortsetzen, aber auch um Fehler für die aktuelle Version zu beheben. Ich habe ein paar Fragen

1. In einem Sprint mit 5 Geschichten, wann wirst du zum Testen freigeben? Ist dies der Fall, sobald eine Story von dev fertiggestellt wurde oder nachdem alle Storys fertiggestellt wurden, aber bevor der Sprint beendet ist? Geben Sie dem Test die erforderliche Testzeit.
2. Wenn der BA User Stories schreibt, was soll das Detail sein? Herkömmlicherweise dauert es lange, bis eine Spezifikation mit dem gesamten UI-Layout, -Verhalten, -Text usw. fertiggestellt ist. Ich denke meine Frage ist, wie man Geschichten schreibt, die umsetzbar und testbar sind.
3. Unser Testteam ist nicht technisch. Wie wichtig ein automatisierter UI-Test für Scrum ist. Die Benutzeroberfläche basiert auf WPF.

Ich habe solide Entwicklungserfahrung mit agilen Methoden (TDD, Code Reviews, Refactoring usw.), bin aber neu in Scrum.

Bearbeiten: Mit Iterationen meine ich, dass wenn es 100 Anforderungen gibt, wir zum Testen freigeben können, wenn wir 30, 35, 35 Anforderungen abgeschlossen haben, anstatt zu warten, bis alle 100 Anforderungen abgeschlossen sind.

Wenn das Testen von der Entwicklung getrennt ist, haben Sie zwei separate Scrum-Teams. Es ist eine schlechte Idee, eine Hand zur anderen arbeiten zu lassen.

Ihre Entwickler müssen ihre eigenen Tests schreiben, getrennt von diesem anderen Team. Sie müssen dieses andere "Test" -Team als Ihre Kunden behandeln.

In einem Sprint ... wann gibst du es zum Testen frei?

Wenn der Sprint beendet ist. Total fertig. Das bedeutet, dass Sie Ihre eigenen Unit-Tests durchgeführt haben und sicher sind , dass es funktioniert. Nachdem Ihr Entwicklungsteam fertig ist, geben Sie es für andere Teams zum "Testen" oder "Bereitstellen" oder für andere Vorgänge in der Organisation frei.

Ich denke meine Frage ist, wie man Geschichten schreibt, die umsetzbar und testbar sind.

Das ist von Team zu Team unterschiedlich. Der BA ist Teil des Entwicklungsteams. Daran muss man als Team (BA plus Entwickler) arbeiten, um die richtigen Details zu erhalten. Es ist eine Teamanstrengung, die richtigen Informationen von BA an den Rest des Teams zu bringen.

Wie wichtig ein automatisierter UI-Test für Scrum ist.

Wesentlich. Vollständig erforderlich für jede UI-Entwicklung. Die Entwickler müssen alle Tests selbst durchführen, bevor sie dem "Testteam" übergeben werden. Wenn es eine Benutzeroberfläche gibt, müssen sie diese testen. Wenn keine Benutzeroberfläche vorhanden ist, ist kein automatisierter UI-Test erforderlich. Das Testen ist erforderlich, und eine Benutzeroberfläche muss getestet werden. Automatisiertes Testen ist die derzeitige Best Practice.

Endeffekt. Ein separates "Test" -Team und ein BA, der jedes Detail schreibt, sind für Scrum keine optimale Organisation. Scrum bedeutet, dass Sie sowohl Ihre Organisation als auch Ihre Prozesse überdenken müssen.

Die meisten Antworten, die ich geben werde, beziehen sich auf eine agile Methode der Softwareentwicklung im Vergleich zu einer iterativen Wasserfallmethode. Scrum ist zufällig eine beliebte Agile-Implementierung.

1. In einem typischen Scrum gibt es keine separate Testphase, da formale Tests während des gesamten Sprints stattfinden sollten. Wenn ein Entwickler eine User Story beendet, sollte die QS-Ressource bereits seine Testfälle vorbereitet haben und an diesem Punkt mit dem Testen beginnen. Wenn ihre Testfälle erfolgreich sind, akzeptieren sie die User Story und wechseln zur nächsten. Sobald alle User Stories abgeschlossen und akzeptiert wurden, ist der Sprint beendet und Sie beginnen mit dem nächsten. Dies hängt natürlich alles von der kontinuierlichen Integration ab, sodass Entwicklungsänderungen sofort für die Qualitätssicherung verfügbar sind. Die weitere Entwicklung sollte den TDD-Richtlinien folgen, um sicherzustellen, dass die Regressionstests so schnell und schmerzfrei wie möglich sind.

2. Es ist eine gute Idee für BAs, User Stories zu schreiben, aber für eine detailliertere und spezifischere Kontrolle können User Stories formale Anforderungsdokumente begleiten. Die User Story sollte aus der Perspektive eines einzelnen Benutzers pro Rolle geschrieben werden. Es drückt ein Bedürfnis aus Sicht des Benutzers aus. Wenn also die Software derzeit alle Aspekte dieses Bedürfnisses erfüllt, wird die User Story erfüllt. Benutzergeschichten können aus untergeordneten Benutzergeschichten und zuweisbaren Aufgaben bestehen. Es kann zu Überlappungen bei Aufgaben für mehrere User Stories kommen.

3. Automatisierte UI-Tests können eine gute Sache sein, aber ich persönlich bin der Meinung, dass mehr Aufwand für TDD-Methoden und eine 100% ige Abdeckung aller Business Logic-Tests wichtiger ist. Die meisten Software-Entwicklungsteams scheinen nicht in der Lage zu sein, Business Logic zu 100% abzudecken. Meiner Meinung nach wäre automatisiertes Testen der Benutzeroberfläche eine Verschwendung wertvoller Zeit, die verwendet werden könnte, um weitere Komponententests für BL zu schreiben. Es ist ein Luxus, der meiner Meinung nach nicht nötig ist.

1. In Scrum soll am Ende jedes Sprints ein potenziell versendbares Software-Inkrement erstellt werden . Infolgedessen fördert Scrum das Konzept eines ganzen Teams oder eines funktionsübergreifenden Teams, bei dem jede Fähigkeit, die erforderlich ist, um eine bestimmte User Story zu erstellen, im Team vorhanden sein muss.

   In meinem aktuellen Projekt haben wir Tester in die Teams eingebettet, da eine vollständig getestete Story Teil unserer Definition von „erledigt“ ist. Während die Entwickler in den ersten Tagen eines Sprints an den ersten User Stories arbeiten, bereiten die Tester Testszenarien vor und richten einige Testdaten ein. Sobald der Entwickler für eine der User Stories fertig ist, testen sie ihn.

2. Dies ist eine der größten Schwierigkeiten bei Scrum IMO. Sie müssen die richtige Menge an Spezifikationen finden, um eine implementierbare, testbare User Story zu erhalten. Zu viele Vorabanalysen, Dokumentationen und Spezifikationen führen zu einem strengen Plan, der sich im Verlauf des Sprints zwangsläufig als falsch erweisen wird. Umgekehrt führt eine User Story, die vom Product Owner nicht klar definiert und ausgedrückt wurde, zu einer überfüllten Kommunikationsbandbreite zwischen den Entwicklern und dem PO während des Sprints und zu Verzögerungen bei der Entwicklung, während der PO in der Mitte des Sprints Entscheidungen über User Stories trifft .

   In unserem Fall haben wir den richtigen Detaillierungsgrad für eine User Story definiert: 1 / eine Beschreibung in Form von "als ... ich will ... damit ..." und 2 / eine Reihe von Akzeptanzen Kriterien. Wir machen selten vorher Modelle der Benutzeroberfläche, dies kann während der Sprint-Planung passieren, aber es handelt sich um mehr Skizzen, die anschließend verworfen werden.

3. Nach meiner Erfahrung ist das automatisierte Testen der Benutzeroberfläche äußerst zeitaufwendig und äußerst spröde. Es gibt Möglichkeiten , dies in WPF zu tun, aber ich würde sorgfältig über die Unterhaltskosten solcher Tests mit den Vorteilen nachdenken, bevor ich diesen Weg beschreite.

Das Arbeiten in immer kürzeren Iterationen verteuert all diese Übergaben immer mehr. Sie können diese Kosten reduzieren, indem Sie eine blöde, einfache Regel befolgen: Schneiden Sie die Losgrößen in zwei Hälften, ändern Sie Ihre Arbeitsweise, um es sich bequem zu machen, und wiederholen Sie den Vorgang, bis Sie zufrieden sind.

Nehmen Sie Ihr 5-stöckiges Sprint-Beispiel. Wenn Ihre Teams daran gewöhnt sind, den Code für alle 5 Storys zu schreiben und dann alle 5 Storys zu testen, beträgt die Stapelgröße 5 Storys. Schneiden Sie das in zwei Hälften. Arbeiten Sie im nächsten Sprint zuerst an den drei dringendsten Storys, und bereiten Sie sie so früh wie möglich zum Testen vor. Während die Tester diese 3 Geschichten testen, kann der Rest die verbleibenden 2 Geschichten zum Testen vorbereiten. Dies wird einige wachsende Schmerzen verursachen. Ändern Sie Ihre Arbeitsweise, um dies komfortabler zu gestalten.

Zum Beispiel arbeiten mehr Leute an jeder Story zusammen. Versuchen Sie also mehr zu paaren und sehen Sie, ob dies Ihnen hilft, stabiler zu arbeiten. Oder vielleicht finden die Tester in Story 2 Probleme, die einige Programmierer ablenken, während sie versuchen, an Story 5 zu arbeiten. Ermutigen Sie die Programmierer und Tester, im nächsten Sprint zu besprechen, wie sie eine der Storys im "ersten Stapel" testen können "Damit die Programmierer weniger wahrscheinlich einen Fehler machen, den ein Tester mit einem Test leicht abfangen kann.

Möglicherweise sind einige Sprints erforderlich, um die großen Probleme zu lösen, die mit dem Testen einer kleinen Menge von Geschichten durch Tester verbunden sind, während die Programmierer an der nächsten Menge von Geschichten arbeiten. Wenn Sie es bequem haben, halbieren Sie die Stapelgröße erneut. Und wieder. Innerhalb eines Jahres oder so wird das Team Geschichten bequem testen, da die Programmierer glauben, dass sie damit fertig sind und wahrscheinlich weniger Fehler auf dem Weg machen. Jede Geschichte wird früher gemacht.

Natürlich können Sie jetzt mit den Chargen, die das Team von den Produktbesitzern erhält oder die das Team an die Betriebsorganisation versendet, dasselbe tun. Und so weiter. An dieser Stelle können Sie sich mit der Frage befassen, wie viele Details die BAs für Geschichten schreiben sollen. Problem.

Übrigens: Damit die Tester ihre Durchlaufzeit verkürzen können, müssen sie eine gewisse Automatisierung anwenden, indem sie lernen, wie man automatisiert, und Programmierer, die ihnen bei der Automatisierung helfen. Wenn Sie versuchen, die Stapelgröße zu reduzieren, erfahren Sie, wann Sie diese Probleme beheben müssen. Fügen Sie keine Automatisierung hinzu, nur weil ein Buch sagt, dass Sie es brauchen.

Ich hoffe das hilft dir.

Ich möchte nur einige Erfahrungen wie folgt teilen und hoffe, dass sie für Sie hilfreich sind.

In einem Sprint mit 5 Geschichten, wann wirst du zum Testen freigeben? Ist dies der Fall, sobald eine Story von dev fertiggestellt wurde oder nachdem alle Storys fertiggestellt wurden, aber bevor der Sprint beendet ist? Geben Sie dem Test die erforderliche Testzeit.

Für jede große User Story sollte sie in viele Unteraufgaben unterteilt werden. Wenn die Unteraufgaben vollständig vom Entwickler ausgeführt wurden, sollten sie sofort für die Qualitätskontrolle zum Testen freigegeben werden. Der Fehler sollte nach dem Testen behoben werden, damit die Unteraufgaben das Testen abschließen.

Wenn der BA User Stories schreibt, was soll das Detail sein? Herkömmlicherweise dauert es lange, bis eine Spezifikation mit dem gesamten UI-Layout, -Verhalten, -Text usw. fertiggestellt ist. Ich denke meine Frage ist, wie man Geschichten schreibt, die umsetzbar und testbar sind.

In Scrum sollten User Storys in jedem Format vorliegen, solange die die Storys umgebenden Konversationen stattfinden und nicht erwartet wird, dass sie abgeschlossen oder statisch sind. Eine kleine Story, die einfach als User Story bezeichnet wird, ist gut verstanden und kann in einem Sprint implementiert werden. Die Priorität einer Story kann sich nach dem ROI, dem Unternehmenswert oder dem, was der Benutzer sonst noch für wichtig hält, richten. Dies sind Aktivitäten von PO.

Unser Testteam ist nicht technisch. Wie wichtig ein automatisierter UI-Test für Scrum ist. Die Benutzeroberfläche basiert auf WPF

Das Anwenden der Automatisierungstests in Scrum ist ziemlich schwierig. Da alle Funktionen unvollständig und nicht wirklich stabil implementiert sind, kann QC den Testfall mit einem Autotest-Tool implementieren. Es sollte für einen Sprint namens Regression durchgeführt werden.