Sollte ich User Stories haben, die sich mit dem Fall befassen, in dem der Benutzer nicht authentifiziert ist?

In meiner Software erwarten viele Dienste, dass der Benutzer vor der Ausführung authentifiziert wird.

In positiven Szenarien habe ich diese Art von Kontext:

Given I am authenticated
When I create meeting X
Then meeting X is well created

Ich bin es gewohnt, für jeden meiner Dienste, der sich mit der Anforderung der Benutzerauthentifizierung befasst, ein symmetrisches Szenario wie dieses zu schreiben:

Given I am not authenticated  //note the 'not' word
When I create meeting X
Then meeting X is not created
And an authentication error should be thrown

Es zwingt den Entwickler, die Überprüfung der Benutzerauthentifizierung an der Spitze der Dienstimplementierung vorzunehmen, um zu verhindern, dass potenzielle „Hacker“ oder bösartiger Code die API (in diesem Beispiel „Meeting-Erstellung“) direkt aufrufen, ohne authentifiziert zu werden.

Ist es eine Praxis, die ich beibehalten sollte?
Liege ich richtig, wenn ich dieses „defensive“ Szenario als eine echte Geschäftsregel betrachte, die ich mit dem „Business“-Team besprechen kann?

Beachten Sie, dass meine Akzeptanztests nicht über den GUI-Teil testen, sondern nur direkt über den Anwendungsfallteil (Dienste / Geschäftsregeln).

Das Erstellen von Tags für Gewürzgurken oder Gurken kann für Fragen wie diese nützlich sein, kann aber leicht in die Technik abgleiten.
"Angenommen, ich bin nicht authentifiziert ... wenn ich Meeting X erstelle": Etwas anderes, worüber Sie nachdenken sollten, ist, warum ein nicht authentifizierter Benutzer sogar versuchen kann, ein Meeting zu erstellen. Dies scheint eher ein UX-Designproblem als ein nützlicher Testfall zu sein. Wie immer YMMV.

Antworten (4)

Kurze Antwort: Ja, es ist völlig in Ordnung, negative Fälle zu berücksichtigen.

Ich bin es gewohnt, das etwas anders zu sehen. Normalerweise ist eine User Story eine Stufe höher wie:

Als Benutzer möchte ich in der Lage sein, eine Besprechung zum Kalender hinzuzufügen, damit ich meinen Zeitplan für den Tag verfolgen kann."

Dann hätte ich beides als Akzeptanzkriterien für diese Geschichte.

Diese Empfehlung ist jedoch eher eine Frage des Stils. Das gefällt mir, weil es sie besser gruppiert, sodass wichtige Geschäftsfälle nicht durch das Raster fallen. Was Sie tun, ist sicherlich nicht falsch.

Scheint, dass Ihr Satz für mich die Bezeichnung eines Features ist, nicht einer User Story. Das Feature zielt darauf ab, sich auf das Ziel zu konzentrieren ("Ich möchte ..."), eine User Story (Szenario) ist ein Weg, um es mit "Gegeben/Wann/Dann" zu erreichen (oder nicht).
Ich habe definitiv eine andere Erfahrung in der Terminologie gemacht, aber es hört sich so an, als wären wir auf derselben Seite – das „Ich möchte“ beschreibt das Ziel und das „Gegeben/Wann/Dann“ beschreibt das erwartete Verhalten darin . Wie auch immer, ich denke, es ist sowohl gut als auch wichtig, dass Sie erwartetes negatives Verhalten berücksichtigen. Ich gehe davon aus, dass Ihre Tester noch mehr aufdecken werden, was berücksichtigt werden muss.

Erfassen Sie Geschäftskonzepte (keine technischen Schritte) in Gherkin

Ist es eine Praxis, die ich beibehalten sollte?

Vielleicht. Negative Testfälle, wie Randbedingungen, sind aus Sicht der Qualitätssicherung gut zu testen. Aus technischer oder Produktmanagement-Perspektive lohnt es sich jedoch zu fragen, warum Sie ein solches eng gefasstes Szenario statt einer umfassenderen Funktion oder einer Szenarioskizze benötigen. Und aus geschäftlicher Sicht sind Details auf niedriger Ebene in Akzeptanztests im Allgemeinen ein Anti-Pattern.

Bringen Sie den Business Case zum Ausdruck

Anstatt zum Beispiel alle möglichen seltsamen Einstiegspunkte als separate Anwendungsfälle zu haben, könnte ein umfassenderes Feature sagen:

Given that a user is not authenticated
When the user performs any action
Then the user is redirected to the login page.

Dadurch wird der reale Business Case besser und klarer erfasst, obwohl Sie sich wahrscheinlich einzelne Schritte oder eine Szenarioskizze wünschen würden, um alle möglichen Einstiegspunkte zu testen und einzelne Fehler effektiver melden zu können.

Der Vorteil dieser Art von Story besteht darin, dass sie die Geschäftslogik viel besser erfasst als eine implementierungszentrierte Story. Andererseits ist ein Fehler innerhalb eines der Schritte viel weniger kommunikativ und erfordert Kenntnisse der zugrunde liegenden Schritte, um bestimmte Fehler einzugrenzen.

Es gibt einen Mittelweg: Senario-Umrisse.

Verwenden Sie Szenarioskizzen

Das Hauptproblem beim Ausdrücken nur der Geschäftsdomäne, ohne auch Kontext oder gezielte Anwendungsfälle zu definieren, besteht darin, dass Sie nicht genau bestimmen können, wo eine Testgruppe fehlschlägt. Hier können die Umrisse von Cucumber-Szenarien helfen.

Zum Beispiel:

Scenario Outline: force authentication on all pages
  Given an unauthenticated user
  When the user connected to the <function> page
  Then the user should be redirected to the login page.

  Examples:
    | function |
    | meeting  |
    | calendar |
    | profile  |
    | launch thermonuclear warheads |

Mit dieser Art von Gliederung ist das Geschäftsziel klar, und Sie haben auch eine Reihe von High-Level-Tests, die unabhängig voneinander bestanden oder nicht bestanden werden können. Die Berichterstattung auf oberster Ebene ist sowohl granular als auch zusammenhängend, während die Art von „Test-Wildwuchs“ vermieden wird, die Sie erhalten würden, wenn Sie negative Szenarien für jedes Verhalten hinzufügen würden.

Zusammenfassung

Das Testen ist eher eine Kunstform als eine Wissenschaft, daher kann Ihre Laufleistung variieren. Agiles Testen sollte jedoch als selbstdokumentierendes Verhalten und nicht als Detail auf niedriger Ebene fungieren, und Akzeptanzkriterien sollten sich mehr auf die Geschäftslogik oder das für den Benutzer sichtbare Verhalten als auf die zugrunde liegenden Implementierungsdetails konzentrieren.

Was unterscheidet sich von meiner Praxis in meiner OP? Die Tatsache, dass ich die Rückgabe eines Fehlers erwähne? klingt zu technisch, auch wenn "abstrakt" ? Ich brauche es, weil meine Akzeptanztests direkt auf Anwendungsfälle abzielen, nicht auf die GUI oder einen "Umleitungs" -Mechanismus.
Der Unterschied besteht, wenn ich das richtig verstehe – zumindest würde ich dafür stimmen – darin, dass Sie diese allgemeine Anforderung an einer einzigen Stelle beibehalten. Dies vereinfacht die Pflege von Anforderungen (stellen Sie sich vor, was passiert, wenn sich diesbezüglich etwas ändert; in Ihrem Fall müssen Sie viele Stellen aktualisieren) und auch die Ableitung von Testfällen oder technischen Anforderungen auf niedriger Ebene.
@Mik378 Du versuchst von Natur aus, Schritte in deinen Szenarien auf erstklassigen Status zu bringen. Während Sie dies tun können und die Vorzüge davon an anderer Stelle diskutiert werden könnten (z. B. auf einer Website über QA-Testtechnik), ist dies eine Website über Projektmanagement. Aus PM-Perspektive sollten Low-Level-Tests und technikorientierte Sprache keine erstklassigen Projektartefakte sein. Tatsächlich würde ich das Berichten auf technischer Ebene, das sich als „Abnahmetest“ tarnt, als ernsthaften Projektgeruch betrachten, der definitiv als Anti-Pattern behandelt werden sollte. YMMV.
@CodeGnome Ich glaube nicht, dass es sich um Low-Level-Tests handelt. Ein Szenario ist kein Low-Level-Test, sondern eine vom Unternehmen geforderte Spezifikation.

TL;DR: Ja, Sie können es so belassen.

Lange Antwort

Je nachdem, wofür Sie die Szenarien oder Geschäftsregeln verwenden , gibt es mehrere Möglichkeiten, sie aufzuschreiben

Erster Fall: Das Szenario wird für Akzeptanzkriterien verwendet

Geschichte

Als Benutzer möchte ich Meetings erstellen, um...

Akzeptanzkriterium

  • Authentifizierte Benutzer können Meetings über eine GUI / API erstellen
  • Anonyme Benutzer sollten keine Meetings erstellen können und stattdessen eine Fehlermeldung erhalten

Erster Fall: Das Szenario wird für Akzeptanz- / Regressionstests verwendet , das sind fragmentierte Anweisungen, um sich durch die Anwendung zu klicken. All diese Tests sollten nach jeder Story (oder zumindest vor jeder Veröffentlichung) bestanden werden.

Unvollständiges Beispiel:

glücklicher Weg

  1. Browser öffnen -> Anmeldebildschirm erscheint
  2. authentifizieren -> Login-Erfolgsmeldung
  3. ein Meeting erstellen -> Details zum Meeting anzeigen

ohne Authentifizierung

  1. Browser öffnen -> Anmeldebildschirm erscheint
  2. ein Meeting erstellen -> siehe Erstellung aufgrund eines Authentifizierungsfehlers fehlgeschlagen

Randnotiz

Ich würde empfehlen, die Regressionstests von einem Benutzer über die GUI durchzuführen. Wenn sie gut geschrieben sind, können sie in Code implementiert und automatisch ausgeführt werden.

Was Sie Story nennen, nenne ich Feature. Was Sie Kriterien nennen, nenne ich eine Geschichte oder ein Szenario. Das sind Gurkenbegriffe.
Ich verstehe, vielleicht ersetzen Sie ein Tag durch Gurke :) Egal, abgesehen von den Begriffen, ist diese Antwort irgendwie nützlich?
Ja, die Antwort ist nützlich, aber ich bin anderer Meinung, dass Regressionstests über die GUI erfolgen sollten. 8thlight.com/blog/doug-bradbury/2011/04/26/… (am Ende dieses Artikels)
Interessante Gedanken :) Nur um das klarzustellen, neben Regressionstests verwenden wir jeden Tag Unit-Tests, um schnelle Ergebnisse zu erhalten (fast keine Wartezeiten) und automatisierte Regressionstests, wobei wir alle Abnahmetests in "echten" Umgebungen (plus mehrere Versions- und DB-Systeme). So stellen wir sicher, dass auch bei kleinen Änderungen alles so funktioniert, wie es soll. Davor hatten wir oft die Situation, dass zu viel in unseren Tests verspottet wurde und nach der Veröffentlichung in anderen Umgebungen Fehler verursachte.
Ich praktiziere ATDD, bestehend aus Akzeptanztests, die durch einige TDD-Zyklen (Unit-Tests) implementiert werden. Sobald diese Unit-Tests bestanden sind (inkrementeller Algorithmus), sollte der betreffende Akzeptanztest bestanden werden.
Onkel Bob (Robert C. Martin) spricht darüber, wie Sie tiefgründig vorgehen. Der Nachteil Ihres Ansatzes besteht darin, dass Sie die GUI an Geschäftsregeln koppeln. Sie ändern die GUI (z. B. Heavy Client zu Web Client), Sie brechen die Tests über Geschäftsregeln ... Außerdem wären Ihre Tests langsam, sehr langsam, wenn Sie die GUI berücksichtigen. Tests, die sich mit der GUI befassen, sollten keine Geschäftsregeln testen, sondern nur GUI-Dinge.
In der Tat ist die Leistung ein Problem und ja, eine Änderung der GUI zwingt Sie dazu, den Test zu ändern - deshalb wird unsere Geschäftslogik vollständig mit Einheitentests getestet! Die Regressionstests, wie wir sie verwenden, mit einer GUI, sind so nah wie möglich an der Vorgehensweise des Benutzers, deshalb mag ich sie.
Unit-Tests reichen nicht aus, obwohl sie wie Akzeptanztests aussehen ( vimeo.com/68375232 ). Der Unterschied besteht darin, dass Abnahmetests vom Geschäftsteam gemeistert werden, nicht nur von Entwicklern. Gherkin zum Beispiel ist dabei, sich mit Business zu unterhalten. Gherkin-Dateien sind die Quelle für Akzeptanztests, sie sollten sich nicht mit der GUI befassen. 8thlight.com/blog/uncle-bob/2013/09/26/AT-FAIL.html ctrl+f => „Was ändert sich mehr als die Benutzeroberfläche“

Wie andere geschrieben haben, ist die Berücksichtigung negativer Fälle gut. Die Struktur Ihres negativen Falls ist es jedoch nicht, da sie einen inneren Widerspruch enthält.

Das Problem ist, dass Sie Ergebnisse so beschreiben, als wären sie Benutzeraktionen. Aber sie sind eigentlich die Aktion, die die Software als Reaktion auf die Benutzeraktion ausführt. Fehler haben Benutzeraktionen, aber die erwartete Ausgabe tritt nie auf, da der Fehler verhindert, dass sie tatsächlich eintritt, sodass eine auf dem Ereignis basierende Geschichte niemals erfüllt ist.

Schlecht:

Vorausgesetzt, ich bin authentifiziert

Wenn ich Besprechung X erstelle

Besser:

Vorausgesetzt, ich bin authentifiziert

Wenn ich eine „Meeting erstellen“-Anfrage sende

Dies funktioniert immer noch auf der Ebene des Backends, bezieht sich nicht auf bestimmte UI-Elemente wie Menüs oder Schaltflächen und deckt Netzwerkaktivitäten ab, die nicht vom genehmigten Frontend generiert werden (was die „Hack“-Bedenken abdeckt).

Hmm, ich bin anderer Meinung, wie ich oben erklärt habe. Akzeptanztests sollten sich nicht auf den GUI- oder Controller-Teil konzentrieren, sondern direkt auf den Anwendungsfall. Wenn Sie "submit"/"request" erwähnen, sind das Begriffe von web => gui. Gui ist ein Implementierungsdetail, und Details sollten nicht Teil von Akzeptanztests sein. Wenn Ihr Client beispielsweise eher eine reine Konsole (Terminal) als ein Web ist, wären die Bedingungen Ihres Akzeptanztests unangemessen.
Ich habe über deinen Punkt nachgedacht. Ich habe das folgende Beispiel gefunden, das die Kohärenz eines Szenarios ziemlich verbessert: agilealliance.org/glossary/gwt (ganz unten). Ich mag den Ansatz "Ich versuche zu ...", was bedeutet, dass der Output vor dem Handeln noch nicht vorhersehbar ist. Es ist genug abstrakt, um meinen UI-Agnostizismus zu erfüllen, und ähnelt Ihrem "Ich reiche ...".
@Mik378: Ja, das sollte auch gut gehen.
Sollte ich User Stories haben, die sich mit dem Fall befassen, in dem der Benutzer nicht authentifiziert ist?
AntwortenHierDatenschutz-Bestimmungen1y, 0v