Akzeptanzkriterien für Randfälle

Ich bin Produktbesitzer in einem agilen Team. Wenn ich PO-Abnahmetests durchführe, mache ich mir normalerweise Notizen, um einige Randfälle auszuprobieren. Es ist nicht ungewöhnlich, dass ich etwas entdecke und es dann an die Entwickler zurückgebe. Ich werde von einem der Entwickler zurückgedrängt, wenn ich seine Geschichten ablehne. Er sagt, es sei unfair, da ich die Randfälle und die Reaktion des Programms in den Akzeptanzkriterien nicht spezifiziere, da er dazu neigt, nur das zu codieren, was ich in der Geschichte beschreibe. Ich habe ihn ermutigt, mich zu fragen, während er beim Codieren auf Edge-Cases stößt, aber er ist der Meinung, dass es nicht seine Aufgabe ist, die Edge-Cases zu durchdenken. Es ist meins und ich sollte neue Geschichten für den nächsten Sprint schreiben.

Zu meiner Verteidigung kenne ich sein Design für die Story erst, nachdem er es implementiert hat. Daher ist es schwierig, alle Möglichkeiten zu durchlaufen (wird sich die Konfiguration in einer DB- oder Eigenschaftendatei befinden?). Nehmen wir der Einfachheit halber an, wir haben eine Geschichte, um einer Taschenrechner-App eine Unterteilung hinzuzufügen. Wäre es in der idealen SCRUM-Welt meine Aufgabe, den Akzeptanzkriterien ein "Handle Divide by Zero-Szenario" hinzuzufügen, oder sollte er diese Fälle während der Entwicklung durcharbeiten, damit die App nicht am 5/0 implodiert? Um klar zu sein, in diesem Fall würde ich nicht akzeptieren, wenn die App am 05.0. Schwer abstürzt, aber ich würde bestehen, wenn sie protokolliert, DIV0 druckt oder auf andere Weise, um den Fehler zu behandeln ... nur solange dies nicht der Fall ist nicht abstürzen.

Ich denke, die Antwort ist, dass Sie beide über Ihre eigenen Randfälle nachdenken sollten. Er als Entwickler sollte datenspezifische Randfälle behandeln, wie z. B. den Absturz der App aufgrund einer bestimmten Benutzereingabe. 5/0 fällt sicherlich in diesen Teil des Spektrums. Der Entwickler sollte nach Ihnen fragen, was Ihrer Meinung nach eine angemessene Fehlermeldung wäre, wenn die im Rahmen der Benutzerinteraktion eingegebene Eingabe zu etwas Ungültigem führt.

Ihr Teil des Spektrums ist die geschäftliche Seite der Dinge. Wie soll sich der Rechner verhalten, wenn das Benutzerkonto die Schaltfläche Teilen nicht verwenden darf? Wie soll es sich verhalten, wenn das Konto die Mod-Operation verwenden darf, aber keinen Zugriff auf die Teilungsfunktion hat?

Die wichtige Botschaft, die Sie meiner Meinung nach vermitteln müssen und die von allen Teammitgliedern akzeptiert wird, ist, dass Sie alle im selben Team sind. Wenn das Produkt nicht vollständig ist, ist das Produkt nicht vollständig und das Team ist schuld, kein bestimmtes Mitglied.

Das Team muss zusammenarbeiten, anstatt die Einstellung / das Mantra "Nicht mein Job, nicht meine Verantwortung" zu haben.

Akzeptanzkriterien sind:

• Geschäftsakzeptanz
• Akzeptanz der Qualitätssicherung

In der Regel beantwortet die Geschäftsakzeptanz die Frage:

• Tut die implementierte Funktion das, was ich möchte?

Die Funktion hat eine Reihe von Anforderungen, die geschäftsorientiert sind. Wenn ich beispielsweise auf diese Schaltfläche drücke, erwarte ich, dass diese Aktion ausgeführt wird. Es werden die erwarteten Geschäftsszenarien und das erwartete Verhalten aufgelistet, jedoch nicht alle möglichen Fälle.

Es wird erwartet, dass die Geschäftsanforderungen vor einer Iteration definiert werden, damit die Qualitätssicherung alle technischen Anforderungen für nicht geschäftliche Anforderungen entwickeln kann. Die Qualitätssicherung sollte nach Bedarf sowohl destruktive als auch Randfälle entwickeln.

Beide Anforderungssätze sollten vor Beginn einer Story-Arbeit überprüft werden, damit eine formale Schätzung und Verpflichtung für die Arbeitseinheit erfolgen kann. Sobald dies erledigt ist, können die Features / Storys bearbeitet werden. An diesem Punkt ist jedem klar, was sowohl aus geschäftlicher als auch aus technischer Sicht zu liefern ist.

Die Geschichte wird endgültig akzeptiert, sobald die Mitglieder des Geschäfts- und Qualitätssicherungsteams die Geschichte abzeichnen. Dies sollte während der Iteration sowohl für die Akzeptanz des Geschäfts als auch für die Akzeptanz der Qualitätssicherung geschehen. Dies ist die Definition von done (DoD), die signalisiert, dass zusätzliche Story-Arbeiten gestartet werden können.

Alle neuen Erkenntnisse können als Fehler oder zusätzliche Story-Spikes protokolliert werden. In einer perfekten Welt würde dies niemals passieren, aber in Wirklichkeit gibt es normalerweise eine gewisse "Entdeckung", die bei der Arbeit an einem Feature / einer Story auftritt. Das ist natürlich.

Das Team sollte zusammenarbeiten (Unternehmen, Qualitätssicherung, Entwickler), um alle nebulösen Entdeckungsanforderungen zu ermitteln. Wenn dies agil ist, sollten alle am selben Tisch sitzen, um die Kommunikation und die schnelle Lösung eventuell auftretender Fragen zu fördern. Es sollte ungefähr so ​​aussehen:

QA:

"Hey, Entwickler, wir sollten dieses spezielle Szenario behandeln. Ich habe festgestellt, dass bei der Eingabe dieser Daten eine Fehlermeldung angezeigt wird."

DEV:

"Das war in keiner Anforderung abgedeckt, aber wir können einige zusätzliche Funktionen hinzufügen, um dies abzudecken. OK, Hey Business Person, wie soll sich die Anwendung für diesen Fall verhalten?"

GESCHÄFT:

"Lassen Sie uns unsere Standardfehlermeldung anzeigen und den Benutzer für dieses Szenario erneut versuchen lassen. Wie viel zusätzlicher Aufwand wird dann sein?"

DEV:

"Es wird einfach sein, nur ein oder zwei zusätzliche Stunden. Ich kann mich für diese Iteration verpflichten. QS Bitte aktualisieren Sie Ihre Akzeptanzkriterien für dieses Szenario, wir brauchen keine zusätzliche Geschichte dafür. Danke!"

Oder wenn es viel Arbeit ist, wird dem Rückstand eine neue Geschichte hinzugefügt. Das Team kann die ursprüngliche Story weiterhin akzeptieren, da sie alle ursprünglichen Anforderungen erfüllt, und die Spike-Story in der nächsten Iteration aufgreifen.

Das Schreiben von Software, die sich angesichts falscher oder mehrdeutiger Eingaben robust verhält, ist ein wesentlicher Bestandteil der Arbeit eines Softwareentwicklers.

Wenn Ihre Entwickler dies nicht so sehen, fügen Sie zusätzliche nicht funktionale Anforderungen in die Anforderungsspezifikation ein, in der diese Anforderung explizit angegeben ist, und geben Sie Ihren Entwicklern ein Beispiel für Ihren Testprozess, damit sie diesen Prozess selbst anwenden können, bevor Sie ihr endgültiges Dokument einreichen Code zur Überprüfung.

Abnahmetests sollten ohnehin ein wesentlicher Bestandteil jedes Anforderungsdokuments sein. Wenn eine Anforderung nicht auch ihre Kriterien für die Annahme angibt, ist sie nicht wirklich eine Anforderung. Es ist ein Wunsch.

Was hier passiert ist, ist, dass Sie Wert entdeckt haben . Der Eingabewert wurde nicht berücksichtigt, als die Story (und die Akzeptanzkriterien) geschrieben wurden oder als der Code geschrieben wurde. Wenn es nicht Teil der Akzeptanzkriterien ist, haben Sie nicht wirklich eine Grundlage, um die Geschichte abzulehnen.

Was wir in meinem Team tun würden, ist:

1. Erstellen Sie einen Fehler, der das erwartete und tatsächliche Verhalten detailliert.
2. Aktualisieren Sie die Akzeptanzkriterien, damit die neu gefundene Anforderung dokumentiert wird.
3. Priorisieren Sie den Fehler zusammen mit allen anderen Geschichten und Fehlern in der nächsten Iteration.

Der Vorteil hierbei ist, dass Sie überlegen müssen, ob die Behebung dieses Fehlers das nächstwichtigste ist. Es kann wichtig genug sein oder nicht, um es zu beheben, aber es ist wichtig, dass sein Wert berücksichtigt wird.

Natürlich müssen Sie noch einen Weg finden, um Entwickler (und sich selbst) zu ermutigen, diese Randfälle im Voraus zu untersuchen. Wenn Ihr Entwicklerteam keine Zeit damit verbringt, Geschichten aufzuschlüsseln, ermutigen Sie es, eine detaillierte Planungssitzung abzuhalten, bevor Sie mit der Arbeit beginnen.

Einige Beobachtungen:

... wenn ich seine Geschichten ablehne

Ich kenne Ihre Arbeitskultur oder Ihren Prozess nicht, aber für mich ist es ein schwerer Schritt, eine Geschichte abzulehnen. Wenn ich der Entwickler wäre, würde ich auch einen Push-Back generieren, da es sich um eine aufgezeichnete Aktion handelt, die sich schlecht auf mich und das Team auswirkt.

Er sagt, es sei unfair, da ich die Randfälle nicht spezifiziere.

Es ist unfair von ihm zu erwarten, dass Sie alle Randfälle kennen. Gleichzeitig ist es unfair, dass Sie das von ihm erwarten. Jede Änderung birgt Risiken, und wenn Probleme entdeckt werden, müssen Sie als Team zusammenarbeiten, um sie zu beheben.

Ich kenne sein Design für die Geschichte erst, nachdem er es umgesetzt hat

Sie sollten das Design nicht kennen müssen. Es kann hilfreich sein, das Design zu kennen, um erste fundierte Vermutungen darüber anzustellen, welche Storys für das Backlog-Management einfacher oder schwieriger sind. Vermeiden Sie es jedoch, den Entwickler in Ihr Design einzuschließen, wenn Sie Geschichten schreiben. Es macht den ganzen Spaß, wenn Sie einfach eine sprachaktivierte Tastatur für die Bestellung sind.

Es hört sich so an, als ob ihr an Prozessverbesserungen arbeiten und Teambuilding betreiben sollt. Einige Dinge, die ich für den Prozess vorschlagen könnte:

• Schlagen Sie vor, dass der Entwickler Zeit in die Story einbezieht, um entdeckte Randfälle zu beheben. Machen Sie es zu einem Teil jeder User Story. Dies ist leicht zu verteidigen, da 0 neue Fehler eingeführt wurden. Das Problem ist, dass der Entwickler dies derzeit nicht plant. Und er hat keine Zeit mehr, wenn Sie Probleme entdecken. Es wird in beiden Fällen einige Zeit dauern, also setzen Sie es in die Geschichte ein, wo es während der Planung sichtbar ist.
• Senden Sie dem Entwickler nach dem Testen (und danke übrigens für das Testen!) Eine Liste der entdeckten Probleme. Die Behebung dieser Probleme widerspricht der Zufriedenheitsbedingung "Behebung von Randfällen".
• Wenn etwas nicht repariert wird oder zu spät entdeckt wird, entscheiden Sie, ob die Story verschoben werden muss, basierend darauf, ob der Anwendungsfall erfüllt werden kann. Bekannte Probleme und Umgehungen treten auf. Sie wurden in Versionshinweisen veröffentlicht und es wurden neue Storys erstellt, um sie zu beheben.
• Wenn es eine bestimmte raue Stelle im Prozess gibt, die einen Pushback erzeugt, ändern Sie Ihren Prozess! Schließlich ist die Prozessverbesserung Teil von Scrum. Wenn Ihr Entwickler beispielsweise verärgert ist, wenn Sie die Story ablehnen, schlagen Sie dem Team eine Änderung des Prozesses vor, damit die Ablehnung keine Korrekturen auslöst. Führen Sie die Tests und Korrekturen durch, bevor Sie fertig und abgelehnt sind.
• Arbeiten Sie mit dem Team und dem, was es produziert hat, zusammen und nutzen Sie es so gut wie möglich. Sie leisten keine perfekte Arbeit und Sie auch nicht. Planen Sie das also ein. Meine Teams waren normalerweise Entwickler, daher haben wir bei jedem Sprint eine ungeplante Support-User-Story für neu auftretende Probleme ... Planung für Unplanbare.

Die Anforderungen sollten klar und präzise sein. Wenn dies nicht der Fall ist, passiert genau das, was Ihnen passiert ist. Es ist Ihre Schuld, und das Schlimmste, was Sie tun können, wenn Sie Anforderungen festlegen, ist, Dinge anzunehmen.

Sie konkretes Beispiel über die Division durch Null. Wenn Sie nicht angegeben haben, dass Sie den Fehler protokollieren möchten, beschweren Sie sich nicht, wenn der Entwickler 100 als Ergebnis druckt.

Aber in solchen Fällen würde ich einfach fehlende Lücken füllen und sie an den Entwickler weitergeben. Schließlich treten Fehler in den Anforderungen auf.