Wo und wie kommt V&V im agilen Kontext zum Einsatz?

Ich bin einem Unternehmen beigetreten, das den Wasserfallansatz verlässt, um ein SAFe (scaled agile framework) für die Entwicklung zu implementieren. Ich bin Teil des Qualitätssicherungsteams. Bevor wir ein Anforderungsregister und feste Gates hatten, waren Verifizierung und Validierung einfach, da die Verifizierung durch die Verwendung der gut geschriebenen Architektur, FRs und NFRs und die Validierung durch Testen mit Anwendungsfällen und Zeigen/"Vorveröffentlichung" für den Kunden erfolgte.

Jetzt bin ich wirklich verwirrt, da wir kein Anforderungsregister mehr haben und ich nicht weiß, was aufgrund der vagen und just in time Akzeptanzkriterien, die wir in Features und User Stories haben, getestet werden sollte. Und die Architektur/UX ist erst am Ende eines Features verfügbar ...

Beispiel für das, was wir haben :

Epic : Tool zum Erstellen von Kochrezepten

Feature1 : Zutatenauswahl-Tool

  • Akzeptanz cr1: Webanwendung
  • Akzeptanz cr2: Verwendung von Zutaten aus doc1
  • Akzeptanz cr3: Basic authN und authZ

User story1 : Als Benutzer möchte ich mich bei meiner Anwendung anmelden können

  • Akzeptanz cr1: Anmeldung mit E-Mail und Passwort möglich

...

Für mich sind AC1 und AC3 des Feature1 zu vage und ich weiß nicht, wie ich sie testen soll. Sie könnten alles bedeuten. Ich weiß wirklich nicht, wie ich altes V&V hier anwenden soll.. und es scheint auch unmöglich zu sein, Systemtests / E2E-Tests durchzuführen, wenn ich diese Funktionen/Geschichten bekomme ... bis die Entwicklung abgeschlossen ist, weiß ich wirklich nicht, welche Testfälle Ich sollte schreiben.

Ich weiß auch nicht, ob sich der Benutzer anmelden können soll und welche Daten er angeben soll. Weiß auch nicht, was ist, wenn der Benutzer neue Zutaten hinzufügen möchte.

Können Sie mir helfen zu verstehen, wie ich das System wie im vorherigen Ansatz verifizieren/validieren kann? Ich weiß, dass das ein ganz großes Thema ist, aber ich finde dazu im Internet keine Informationen, nur Theorie ohne oder unvollständige Praxisbeispiele

Wenn Sie Beispiele machen könnten, wäre das großartig, danke!

Antworten (2)

Können Sie mir helfen zu verstehen, wie ich das System wie im vorherigen Ansatz verifizieren/validieren kann?

Agil bedeutet nicht vage. Ganz ehrlich, Sie haben Recht. Diese Akzeptanzkriterien, mit denen Sie Probleme haben, sind einfach schlecht. Das hat nichts mit Agilität zu tun. Akzeptanzkriterien sollten überprüfbar sein. Wenn Sie als QA-Person nicht wissen, wie man es testet, wie sollte jemand es wissen? Es heißt Akzeptanzkriterien , damit sie validiert und akzeptiert werden können . Deine Beispiele können das nicht.

Der einzige Ausweg besteht darin, bessere Akzeptanzkriterien zu schreiben. Vielleicht kann derjenige, der sie für Ihre neuen agilen Geschichten geschrieben hat, die Leute fragen, die sie vorher geschrieben haben, wie es geht. Ich würde sagen, die Akzeptanzkriterien sind wahrscheinlich die einzige Sache, die sich nicht wirklich geändert hat, außer vielleicht dem Namen. Sie können nicht vage sein, oder sie funktionieren nicht.

Es ist nicht deine Schuld. Jemand hat das Kind mit dem Bade ausgeschüttet. Ich schätze, die Leute, die die Geschichten in Agile schreiben, sind neu darin oder einfach überarbeitet mit all den Veränderungen, die sie durchmachen.

Hallo, danke für deine Antwort! Ja, sicher wirken sich diese Änderungen stark auf den Prozess aus. Aber jedes Mal, wenn ich versuche, dem Team zu sagen, dass diese ACs breit gefächert sind, antworten sie mit etwas wie „Wir können jetzt nicht an alles denken, sonst sind wir ein Wasserfall, das werden wir vielleicht mehr Details in den User Stories, aber nicht jedes Detail". Ist das etwas Richtiges? Ein Feature mit breiten Akzeptanzkriterien und User Stories, die mit diesen Akzeptanzkriterien mit wenig mehr Details verknüpft sind? Sollten die User Stories außerdem vollständig definiert sein, wenn das Feature geschrieben wird?
Stellen Sie sicher, dass Sie dies in Ihrer Retrospektive mit dem gesamten Team besprechen können – bitten Sie Ihren Scrum Master, sicherzustellen, dass dies abgedeckt wird. Erklären Sie, warum die vagen ACs die Lieferfähigkeit des Teams behindern . Sobald die Entwickler verstehen, dass es sich um ein Problem des gesamten Teams handelt, bitten Sie um Ideen zur Verbesserung der Situation. In unserem Team gehören klare ACs zur Definition von ready : Eine Story darf nicht ohne sie in einen Sprint eingeplant werden, und wir prüfen das, wenn der Entwickler das Ticket zur Bearbeitung abholt. Vielleicht könnte das für dich funktionieren.
@Dev Nein, das vorherige vollständige Schreiben aller Benutzergeschichten wäre in der Tat ein Wasserfall unter einer anderen Wortvorlage. Aber eine Story muss vollständig sein (einschließlich Akzeptanzkriterien), bevor sie in einen Sprint kommt, um daran gearbeitet zu werden. Wenn es unvollständig und vage ist, wenn jemand es implementieren muss, ist es kaputt. Ich stimme Toby hier zu ... halte eine Definition bereit und überprüfe diese, bevor du an einem Gegenstand arbeitest. Vage, nicht testbare ACs sind etwas, das die Geschichte zurück auf das Reißbrett bringen sollte.
Danke Jungs! Ich freue mich sehr über dieses Gespräch. Ich stimme zu, ich werde sicherstellen, dass ich mit dem Team eine Vereinbarung über die Definition von bereit habe. @nvoigt in Bezug auf den Prozess, sagen Sie, dass wir für diesen PI einige Funktionen planen und sie gute ACs haben. Wenn wir sie in Benutzergeschichten aufteilen, sollte jede von ihnen mit einer AC der Funktion zusammenhängen? Ich frage das, weil das Beispiel hier nicht so aussieht scaledagileframework.com/story . Nochmals vielen Dank für Ihre Zeit.
AC in einer Geschichte sollte sich auf die Geschichte beziehen und nur mit der vollständigen Geschichte testbar sein, nicht mit dem gesamten Feature. Der Link, den Sie gepostet haben, unter "Bestätigung" sehen die Beispiele für Akzeptanzkriterien sehr schön und testbar aus. Vielleicht sollten Sie diese als Beispiele verwenden, wenn Sie mit Ihrem Team sprechen.
  1. Hier ist ein Link, der beschreibt, wie man gute Akzeptanzkriterien schreibt. Einige Höhepunkte:
  • Jedes Akzeptanzkriterium ist unabhängig prüfbar.
  • Akzeptanzkriterien müssen ein klares Pass/Fail-Ergebnis haben.
  • Es konzentriert sich auf das Endergebnis – Was. Nicht der Lösungsansatz – Wie.
  • Beziehen Sie – je nach Bedarf – sowohl funktionale als auch nicht-funktionale Kriterien ein.
  • Teammitglieder schreiben Akzeptanzkriterien und der Product Owner überprüft sie. Es bestätigt, dass die PO und das Team ein gemeinsames Verständnis der User Story haben.

  1. Agile gibt „Funktionierende Software vor umfassender Dokumentation“ den Vorrang . Sie müssen sich also an den Gedanken gewöhnen, dass es kein Anforderungsregister, keine gut geschriebene Architektur usw. geben wird.

  2. Sie sollten als vollwertiges Mitglied des Entwicklerteams am Backlog Refinement und Sprint Planning teilnehmen. Ergreifen Sie die Initiative und tragen Sie dazu bei, gute und überprüfbare Akzeptanzkriterien zu entwickeln. Versetzen Sie sich in die Lage des Benutzers und visualisieren Sie, wonach typische Benutzer suchen und was sie in der Benutzeroberfläche tun.

Hallo, danke für deine Antwort
Ja, ich weiß, dass wir mehr in diese Ereignisse involviert sein sollten, aber ich kämpfe immer noch mit dem Mangel an Dokumentation. Ist es in Agile möglich, ein Dokument zu haben, das die Bedürfnisse des Kunden zusammenfasst? Ich frage das, weil ich oft mitten in der Entwicklung zu einem Projekt hinzugefügt wurde und ich keine Möglichkeit hatte, zu überprüfen, was der Kunde gefragt hat, wenn ich nicht alle Funktionen und Benutzergeschichten (Hunderte davon) durchgegangen bin. Und das ist ein Problem für mich als QA-Teammitglied. Danke nochmal
@Dev, die einzige Dokumentation, von der in Agile abgeraten wird, ist die Dokumentation, die niemals von irgendjemandem gelesen wird (mit Ausnahme der armen Seele, die sie pflegen muss).
Danke, Bart
Wo und wie kommt V&V im agilen Kontext zum Einsatz?
AntwortenHierDatenschutz-Bestimmungen1y, 0v