it-swarm.dev

Wie man Tests in Scrum-Sprints anpasst und wie man User Stories in Scrum schreibt

Ich bin der 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/iterative SDLC. Die BAs schreiben Anforderungsdokumente, übergeben sie an dev und test, dev beginnt mit der Entwicklung und wird in Iterationen zum Testen freigegeben. Tester brauchen viel Zeit, um eine Version zu testen, mit der Entwickler die Entwicklung fortsetzen, aber auch Fehlerbehebungen für die aktuelle Version. Ich habe ein paar Fragen

  1. In einem Sprint mit etwa 5 Geschichten, wann veröffentlichen Sie zum Testen? Ist es, sobald eine Geschichte von einem Entwickler fertiggestellt wurde oder nachdem alle Geschichten fertiggestellt wurden, aber vor dem Ende des Sprints, um dem Test die erforderliche Zeit zum Testen zu geben?.
  2. Wenn der BA User Stories schreibt, was sollte das Detail sein? Traditionell dauert es lange, eine Spezifikation mit allen UI-Layouts, Verhaltensweisen, Texten usw. zu schreiben, die finalisiert werden müssen. Ich denke, meine Frage ist, wie man Geschichten schreibt, die implementierbar und testbar sind.
  3. Unser Testteam ist nicht technisch. Wie wichtig es ist, automatisierte UI-Tests für Scrum durchzuführen. Die Benutzeroberfläche basiert auf WPF.

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

bearbeiten: Mit Iterationen meine ich, dass wir bei 100 Anforderungen die Tests freigeben können, wenn wir 30, 35, 35 Anforderungen erfüllt haben, anstatt zu warten, bis alle 100 Anforderungen erfüllt sind.

15
softveda

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 schreiben ihre eigenen Tests, getrennt von diesem anderen Team. Sie müssen dieses andere "Test" -Team als Ihre Kunden behandeln.

Im Sprint ... wann veröffentlichen Sie zum Testen?

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 alles andere in der Organisation frei.

Ich denke, meine Frage ist, wie man Geschichten schreibt, die implementierbar 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 richtige Menge an Details zu erhalten. Es ist eine Teamleistung, die richtigen Informationen von BA an den Rest des Teams zu bringen.

Wie wichtig es ist, automatisierte UI-Tests für Scrum durchzuführen.

Wesentlich. Vollständig erforderlich für jede UI-Entwicklung. Die Entwickler müssen alle Tests selbst durchführen vorher es wird dem "Testteam" übergeben. Wenn es eine Benutzeroberfläche gibt, müssen sie diese testen. Wenn keine Benutzeroberfläche vorhanden ist, sind keine automatisierten UI-Tests erforderlich. Tests sind erforderlich, und eine Benutzeroberfläche muss getestet werden. Automatisierte Tests sind derzeit die beste Vorgehensweise.


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

11
S.Lott

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 durchgeführt werden sollten. Wenn ein Entwickler eine User Story beendet hat, sollte die QS-Ressource bereits ihre Testfälle vorbereitet haben und an diesem Punkt mit dem Testen beginnen. Wenn ihre Testfälle bestanden sind, akzeptieren sie die User Story und fahren mit der nächsten fort. Sobald alle User Stories abgeschlossen und akzeptiert wurden, ist der Sprint beendet und Sie beginnen mit dem nächsten. Dies alles hängt natürlich 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 Regressionstests so schnell und schmerzlos 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 nach Rolle geschrieben werden. Es drückt ein Bedürfnis aus der Sicht des Benutzers aus. Wenn die Software derzeit alle Aspekte dieses Bedürfnisses erfüllt, wird die User Story ganz natürlich erfüllt. User Stories können aus untergeordneten User Stories und zuweisbaren Aufgaben bestehen. In Aufgaben können sich mehrere User Stories überschneiden.

  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 von Unit Logics für alle Business Logic wichtiger ist. Die meisten Softwareentwicklungsteams scheinen keine 100% ige Abdeckung von Business Logic zu erreichen. Meiner Meinung nach wäre das Testen automatisierter Benutzeroberflächen eine Verschwendung wertvoller Zeit, die zum Schreiben weiterer Komponententests für BL verwendet werden könnte. Es ist ein Luxus, der meiner Meinung nach kein Bedürfnis ist.

9
maple_shaft
  1. In Scrum sollten Sie am Ende jedes Sprints ein potenziell versandfähiges Software-Inkrement erstellen. Infolgedessen fördert Scrum das Konzept eines gesamten Teams oder eines funktionsübergreifenden Teams, bei dem jede Fähigkeit vorhanden sein muss, um eine bestimmte User Story zu erledigen im Team.

    In meinem aktuellen Projekt haben wir Tester in die Teams eingebettet, da eine vollständig getestete Geschichte Teil unserer Definition von erledigt ist. Während der ersten Tage eines Sprints, während Entwickler mit der Arbeit an den ersten User Stories beginnen, bereiten die Tester Testszenarien vor und richten einige Testdaten ein. Sobald der Entwickler für eine der User Stories fertig ist, wird er getestet.

  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 starren Plan, der sich im Verlauf des Sprints unweigerlich als falsch herausstellt. Umgekehrt führt eine User Story, die vom Product Owner nicht klar definiert und ausgedrückt wurde, zu einer gesättigten Kommunikationsbandbreite zwischen den Entwicklern und der Bestellung während des Sprints und zu Verzögerungen bei der Entwicklung, während die PO nach der Hälfte des Sprints Entscheidungen über User Stories trifft .

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

  3. Nach meiner Erfahrung sind automatisierte UI-Tests extrem zeitaufwändig und extrem 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 gehe.

4
guillaume31

Das Arbeiten in immer kürzeren Iterationen verteuert all diese Übergaben immer mehr. Sie können diese Kosten reduzieren, indem Sie einer dummen, einfachen Regel folgen: Halbieren Sie die Chargengrößen, ändern Sie Ihre Arbeitsweise, um dies zu vereinfachen, 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 Geschichten zu schreiben und dann alle 5 Geschichten zu testen, beträgt die Stapelgröße 5 Geschichten. Schneiden Sie das in zwei Hälften. Arbeiten Sie im nächsten Sprint zuerst an den drei dringendsten Geschichten 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 werden mehr Leute gemeinsam an jeder Geschichte arbeiten. Versuchen Sie also mehr Pairing und prüfen 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 daher die Programmierer und Tester im nächsten Sprint, früher zu diskutieren, wie eine der Storys im "ersten Stapel" getestet werden kann "Damit die Programmierer weniger wahrscheinlich einen Fehler machen, den ein Tester mit einem Test leicht fangen kann.

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

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

Übrigens: Damit die Tester ihre Bearbeitungszeit 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, werden Sie herausfinden, wann Sie diese Probleme beheben müssen. Fügen Sie keine Automatisierung hinzu, nur weil ein Buch sagt, dass Sie sie brauchen.

Ich hoffe das hilft dir.

2

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

In einem Sprint mit etwa 5 Geschichten, wann veröffentlichen Sie zum Testen? Ist es, sobald eine Geschichte von einem Entwickler fertiggestellt wurde oder nachdem alle Geschichten fertiggestellt wurden, aber vor dem Ende des Sprints, um dem Test die erforderliche Zeit zum Testen zu geben?.

Für jede große User Story sollte sie in viele Unteraufgaben unterteilt werden. Wenn die Unteraufgaben vollständig vom Entwickler ausgeführt werden, sollten sie sofort zum Testen an QC freigegeben werden. Der Fehler sollte nach dem Testen für diese Unteraufgaben behoben werden.

Wenn der BA User Stories schreibt, was sollte das Detail sein? Traditionell dauert es lange, eine Spezifikation mit allen UI-Layouts, Verhaltensweisen, Texten usw. zu schreiben, die finalisiert werden müssen. Ich denke, meine Frage ist, wie man Geschichten schreibt, die implementierbar und testbar sind.

In Scrum sollten User Stories in einem beliebigen Format vorliegen, solange die die Storys umgebenden Konversationen stattfinden und nicht erwartet werden, dass sie abgeschlossen oder statisch sind. Eine kleine Geschichte, einfach User Story genannt, ist gut verstanden und kann innerhalb eines Sprints implementiert werden. Die Priorität einer Story kann auf dem ROI, dem Geschäftswert oder dem basieren, was der Benutzer sonst noch für wichtig hält. Dies sind Aktivitäten von PO.

Unser Testteam ist nicht technisch. Wie wichtig es ist, automatisierte UI-Tests für Scrum durchzuführen. Die Benutzeroberfläche basiert auf WPF

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

0
Danh