Die Akzeptanztest-getriebene Entwicklung ( ATDD ) ist eine Entwicklungsmethodik , die auf der Kommunikation zwischen Geschäftskunden, Entwicklern und Testern basiert. [ 1 ] ATDD umfasst viele der gleichen Praktiken wie die Spezifikation durch Beispiele (SBE), [ 2 ] [ 3 ] die verhaltensgetriebene Entwicklung (BDD), [ 4 ] die beispielgetriebene Entwicklung (EDD) [ 5 ] und die supportgetriebene Entwicklung, auch Story-Test-getriebene Entwicklung (SDD) genannt. [ 6 ] All diese Prozesse helfen Entwicklern und Testern, die Kundenbedürfnisse vor der Implementierung zu verstehen und ermöglichen es den Kunden, in ihrer eigenen Fachsprache zu kommunizieren.

ATDD ist eng mit testgetriebener Entwicklung (TDD) verwandt. [ 7 ] Es unterscheidet sich durch die Betonung der Zusammenarbeit zwischen Entwicklern, Testern und Geschäftskunden. ATDD umfasst Akzeptanztests , legt aber Wert darauf, diese vor Beginn der eigentlichen Programmierung zu schreiben.

Überblick

Akzeptanztests werden aus der Sicht des Benutzers durchgeführt – aus der externen Perspektive des Systems. [ 1 ] Sie untersuchen extern sichtbare Effekte, beispielsweise die korrekte Ausgabe eines Systems bei einer bestimmten Eingabe. Akzeptanztests können überprüfen, wie sich der Zustand eines Systems ändert, etwa wenn eine Bestellung von „bezahlt“ auf „versendet“ wechselt. Sie können auch die Interaktionen mit Schnittstellen anderer Systeme prüfen, beispielsweise mit gemeinsam genutzten Datenbanken oder Webdiensten. Im Allgemeinen sind sie implementierungsunabhängig, ihre Automatisierung jedoch nicht immer. [ 8 ] [ 9 ]

Schaffung

Akzeptanztests werden erstellt, wenn die Anforderungen analysiert werden und bevor mit der Programmierung begonnen wird. [ 1 ] Sie können gemeinsam vom Anforderungssteller (z. B. Product Owner, Business Analyst, Kundenvertreter), Entwickler und Tester entwickelt werden. Die Entwickler implementieren das System mithilfe der Akzeptanztests. Fehlgeschlagene Tests geben schnelles Feedback darüber, dass die Anforderungen nicht erfüllt werden. Die Tests werden in Fachbegriffen der Geschäftsdomäne spezifiziert. Diese Begriffe bilden eine gemeinsame Sprache, die von Kunden, Entwicklern und Testern verwendet wird. [ 10 ] Tests und Anforderungen sind eng miteinander verknüpft. [ 11 ] Eine Anforderung ohne Test kann nicht korrekt implementiert werden. Ein Test, der sich nicht auf eine Anforderung bezieht, ist überflüssig. Ein Akzeptanztest, der nach Beginn der Implementierung entwickelt wird, stellt eine neue Anforderung dar. [ 12 ]

Teststrategie

Akzeptanztests sind Bestandteil einer umfassenden Teststrategie. Sie sind kunden- bzw. nutzerorientierte Tests, die die geschäftliche Zielsetzung eines Systems demonstrieren. Abhängig von Ihrer Teststrategie können Sie sie in Kombination mit anderen Testarten einsetzen, z. B. mit Unit-Tests auf niedrigerer Ebene [ 13 ] , funktionsübergreifenden Tests einschließlich Usability-Tests [ 14 ] , explorativen Tests [ 15 ] und Eigenschaftstests (Skalierung und Sicherheit) [ 16 ] .

Akzeptanzkriterien und Prüfungen

Akzeptanzkriterien beschreiben, was ein Test überprüfen soll. Angenommen, die Anforderung lautet: „Als Benutzer möchte ich ein Buch aus der Bibliothek ausleihen“, dann könnte ein Akzeptanzkriterium lauten: „Überprüfen, ob das Buch als ausgeliehen markiert ist.“ Ein Akzeptanztest für diese Anforderung liefert die Details, sodass der Test jedes Mal mit demselben Ergebnis ausgeführt werden kann.

Testformat

Abnahmetests folgen üblicherweise dieser Form: [ 1 ]

Gegeben (Setup)

Ein bestimmter Zustand eines Systems

Wenn (Auslöser)

Eine Handlung oder ein Ereignis tritt ein

Dann (Überprüfung)

Der Zustand des Systems hat sich geändert oder es wurde ein Ergebnis erzeugt.

Außerdem können Sie in jedem der folgenden Abschnitte (Gegeben, Wenn, Dann) Anweisungen hinzufügen, die mit UND beginnen.

Für die beispielhafte Anforderung könnten die Schritte wie folgt aufgelistet werden:

Angenommen, ein Buch ist noch nicht ausgeliehen und der Benutzer ist im System registriert. Wenn der Benutzer ein Buch ausleiht, wird das Buch als ausgeliehen markiert.

Vollständiger Test

Die vorherigen Schritte enthielten keine konkreten Beispieldaten, daher werden diese hinzugefügt, um den Test abzuschließen:

Gegeben:

Buch, das nicht ausgeliehen wurde
Bücher
TitelAusgecheckt
Großartiges BuchNEIN
Benutzer, der im System registriert ist
Benutzer
Name
Sam

Wann:

Ein Benutzer leiht ein Buch aus
Checkout-Aktion
BenutzerSamChecksGroßartiges Buch

Dann:

Das Buch ist als ausgeliehen markiert.
Bücher
TitelAusgechecktBenutzer
Großartiges BuchJaSam

Prüfung

Die Auswertung des Tests anhand konkreter Daten wirft üblicherweise viele Fragen auf. Für das Beispiel könnten dies beispielsweise folgende sein:

  • Was passiert, wenn das Buch bereits ausgeliehen ist?
  • Was, wenn das Buch nicht existiert?
  • Was passiert, wenn der Benutzer nicht im System registriert ist?
  • Gibt es ein Datum, an dem das Buch zurückgegeben werden muss?
  • Wie viele Bücher kann ein Benutzer ausleihen?

Diese Fragen helfen, fehlende oder unklare Anforderungen zu verdeutlichen. Zusätzliche Details wie ein Fälligkeitsdatum können dem erwarteten Ergebnis hinzugefügt werden. Weitere Akzeptanztests können überprüfen, ob Bedingungen wie der Versuch, ein bereits ausgeliehenes Buch auszuleihen, den erwarteten Fehler hervorrufen.

Ein weiteres Testbeispiel

Angenommen, der Geschäftskunde wünscht eine Geschäftsregel, die besagt, dass ein Benutzer jeweils nur ein Buch ausleihen kann. Der folgende Test würde dies beweisen:

Szenario: Überprüfen, ob die Geschäftsregel für den Checkout durchgesetzt wird.

Gegeben:

ausgeliehenes Buch
Bücher
TitelAusgechecktBenutzer
Großartiges BuchJaSam
Ein weiteres großartiges BuchNEIN
Benutzer
Name
Sam

Wann:

Der Nutzer leiht sich ein anderes Buch aus
Checkout-Aktion
BenutzerSamChecksEin weiteres großartiges Buch

Dann:

Es tritt ein Fehler auf
Es ist ein Fehler aufgetreten
Beschreibung
Verstoß gegen die Kassen-Geschäftsregel

Projektabnahmetests

Neben Akzeptanztests für einzelne Anforderungen können Akzeptanztests auch für ein Gesamtprojekt durchgeführt werden. [ 1 ] Wenn diese Anforderung beispielsweise Teil eines Projekts zur Bibliotheksausleihe wäre, könnten Akzeptanztests für das gesamte Projekt durchgeführt werden. Diese werden häufig als SMART-Ziele bezeichnet . Ein Beispiel für einen solchen Test lautet: „Sobald das neue Bibliothekssystem in Betrieb ist, können die Benutzer Bücher dreimal so schnell ausleihen und zurückgeben wie bisher.“

Siehe auch

Referenzen

  1. ^ a b c d e Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration . Addison-Wesley. ISBN 978-0321714084Die
  2. ^ Adzic, Gojko. (2009) Überbrückung der Kommunikationslücke: Spezifikation durch Beispiele und agiles Akzeptanztesting , Neuri Limited,
  3. ^ Adzic, Gojko (2011). Spezifikation durch Beispiele: Wie erfolgreiche Teams die richtige Software liefern . Manning. ISBN 978-0-321-27865-4Die
  4. ^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp und Dan North. Das RSpec-Buch: Verhaltensgetriebene Entwicklung mit RSpec, Cucumber und Freunden. The Pragmatic Bookshelf.
  5. ^ „Beispielgetriebenes Design“ . Abgerufen am 15.04.2013 .
  6. ^ „Story Test-Driven Development“ (PDF) . Abgerufen am 15.04.2013 .
  7. ^ Beck, Kent. Testgetriebene Entwicklung: Anhand von Beispielen. Addison-Wesley Professional, 2002.
  8. ^ Melnik, Grigori und Frank Maurer. Melnik, Grigori; Maurer, Frank (2007). „Multiple Perspectives on Executable Acceptance Test-Driven Development“. Agile Processes in Software Engineering and Extreme Programming . Lecture Notes in Computer Science. Band 4536. S.  245–249 . doi : 10.1007/978-3-540-73101-6_46 . ISBN 978-3-540-73100-9Die
  9. ^ Koskela, Lasse. (2007) Testgetriebenes Lernen: TDD und Akzeptanz-TDD für Java-Entwickler. Manning Publications
  10. ^ Evans, Eric. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software . Addison-Wesley Professional.
  11. Weinberg , Gerald ; Gause, Donald (1989). Anforderungen erforschen: Qualität vor Design . Dorset House. ISBN 0-932633-13-7Die
  12. ^ Martin, Robert C., und Grigori Melnik. „Tests and Requirements, Requirements and Tests: A Möbius Strip“ (PDF) . Abgerufen am 15.04.2013 .
  13. ^ [Testgetriebene Entwicklung]
  14. ^ Meszaros, Gerard und Janice Aston. (2006) „Hinzufügen von Usability-Tests zu einem agilen Projekt.“ Agile Conference
  15. ^ „Exploratives Testen erklärt“ (PDF) . 23. März 2019.
  16. ^ Meszaros, Gerard.(2007) xUnit Test Patterns: Refactoring Test Code . Addison-Wesley.