Abnahmetestgetriebene Entwicklung (ATDD) / Sudo Null IT News

Autor des Artikels: Dmitry Kurdyumov

Teilnahme an agilen Transformationen in den größten Unternehmen Russlands (Alfa Bank, MTS, X5 Retail Group), mit internationaler Erfahrung in einem Startup im Ausland.

Bei der Arbeit mit Produktentwicklungsteams habe ich oft zwei Szenarien zum Schreiben von Anforderungen für ein in der Entwicklung befindliches Produkt gesehen, und beide Szenarien sind in die eine oder andere Richtung verzerrt:

  1. Ein Großteil der Anforderungen liegt auf dem funktionalen und technischen Teil, dh darauf, wie es vom technischen Teil aus funktioniert, wenn ein wichtiger Teil der Anforderungen über den Benutzer und seine Bedürfnisse und Szenarien fehlt. Relativ gesehen, wenn ein Kunde eine andere Anforderung hat, machen wir uns, anstatt zuerst zu verstehen, wie es auf Seiten des Benutzers funktionieren wird, sofort Gedanken über die technische Umsetzung und stürzen uns darauf, dies so schnell wie möglich zu tun. Das führt dazu, dass wir am Anfang wichtige Nutzerszenarien verpassen und viel Überflüssiges und Unnötiges machen.

  1. Oder die Kehrseite, wenn wir zu viel Zeit damit verbringen, Geschäftsanforderungen zu analysieren, riesige Mengen an Dokumentation zu erstellen, mit UML-Diagrammen und einer gründlichen Untersuchung von allem. Solche Anforderungen gibt es im Überfluss, so dass sie am Ende niemand liest oder schräg liest. Und es ist noch schwieriger, solche Anforderungen zu ändern und aufrechtzuerhalten.

In diesem Artikel möchte ich einen einfachen Ansatz für die Erstellung von Geschäftsanforderungen vorstellen (akzeptanztestgetriebene Entwicklung oder ATDD), der das Team auf die Benutzer und das Geschäft konzentriert und das Verständnis dafür verbessert, was wir tun. Und baut darüber hinaus Qualität in den Entwicklungsprozess ein.

ATDD ist eine abnahmetestbasierte Entwicklung. Der Punkt ist, dass wir, bevor wir Code schreiben, Akzeptanzszenarien erstellen, damit wir bereits Code dafür schreiben können. Und es ist wichtig, sie eng mit dem Unternehmen zu erstellen. In der Regel geht der ATDD-Ansatz davon aus, dass wir uns mit einem Geschäftskunden (oder einem Produkt, das die Stimme des Kunden und der Stakeholder ist) und einem Team (einschließlich Analysten, Entwicklern und Testern) zusammensetzen und gemeinsam Anwendungsfälle modellieren und dann Schreiben Sie Code für diese Szenarien. Szenarien werden nicht von der technischen Implementierungsseite geschrieben, sondern von der Benutzerseite, um wichtige Bedürfnisse zu berücksichtigen.

Warum lohnt es sich, mit dem gesamten Team zusammenzukommen, einschließlich Entwicklern, Testern, Designern und allen anderen?

Erstens erhält Ihr Team alle Anforderungen aus der Quelle und versteht besser, was zu tun ist. Zweitens brauchen Sie später weniger Zeit, um dem Team die Anforderungen zu erklären, und Sie werden nicht wie ein kaputtes Telefon auftreten. Drittens wird die Qualität der Drehbücher und ihre Vollständigkeit besser, da alle mitmachen. Und viertens kann das gesamte Team interessante Fragen aus verschiedenen Blickwinkeln stellen und gemeinsam Szenarien analysieren.

Manchmal dauert es Wochen, die Anforderungen zu entwickeln, und weitere Wochen, um sie zur Entwicklung zu bringen, und dann wieder Wochen, um sie zu wiederholen, da der Kontext in der Entwicklung verloren gehen könnte. Hier können Sie für eine solche Arbeitssitzung ein paar Stunden pro Woche dem gesamten Team widmen und haben das gleiche und vollständige Bild für das gesamte Team.

Wie geht das in der Praxis?

Zu Beginn sollte jede Geschäftsanforderung in der User Story, also im Kontext, formuliert werden

  • Wer wird mit dem Produkt interagieren (Person).

  • Was wird tun (Aktion).

  • Warum braucht er es (Ziel).

Nehmen wir an, Sie haben eine User Story:

Ich als Benutzer einer mobilen Bank möchte meine Ausgaben für den Zeitraum verstehen, um sie zu optimieren. Mit einer solchen User Story verstehen wir im Team bereits besser den Kontext dessen, was getan werden muss und warum.

Und dann beginnen wir mit Hilfe des Gegeben-Wann-Dann-Frameworks, Akzeptanztests zu formulieren.

  • Gegeben – beschreibt den Zustand des Systems zu einem bestimmten Zeitpunkt.

  • Wann beschreibt eine Aktion.

  • Dann – was ändert sich, nachdem die Aktion ausgeführt wurde.

Beispiel:

Wenn ich Bankkunde bin und für den Zeitraum X Rubel Kosten habe.
Wenn ich für Y Rubel einkaufe,
In Ausgaben sollte ich die Höhe der Ausgaben für den Zeitraum (Tag / Woche / Monat) der Beträge (X; Y) sehen.

Wenn ich Bankkunde bin und für den Zeitraum X Rubel Ausgaben habe,
Und wenn ich einen zuvor abgeschlossenen Kauf für Y Rubel zurücksende,
In den Ausgaben für diesen Zeitraum sollte ich die Beträge (X; Y) -Y sehen.

Usw. Im Prozess des Dialogs zwischen dem Unternehmen und dem Team werden Szenarien geboren.

Welche Vorteile ergeben sich daraus:

  • Der Hauptvorteil dieses Ansatzes besteht darin, dass er einen Dialog zwischen dem Unternehmen und dem Team einleitet und eine Benutzerperspektive bietet.

  • Der nächste Vorteil besteht darin, dass Sie nicht einfach mit dem Codieren beginnen, indem Sie abstrakte technische Anforderungen des Analysten implementieren, sondern den Code schreiben und sofort selbst testen. Das heißt, Sie sorgen dafür, dass die Akzeptanzszenarien funktionieren. Diese Skripte sind auch einfach zu automatisieren, sodass Sie sich selbst testen können, bis der Test abgeschlossen ist.

  • Am Ende der Entwicklung fällt es dem Kunden, dem Team und dem Produkt leichter, die Arbeit anzunehmen, da man die gleiche Sprache spricht und diese Szenarien gemeinsam erstellt hat. Es gibt weniger Konflikte und mehrdeutige Anforderungen.

Das Hauptrisiko besteht darin, nicht auf unnötige Details einzugehen. Versuchen Sie nicht, jedes Detail zu durchdenken, heben Sie die Hauptszenarien hervor, die Sie in der ersten Version Ihrer neuen Lösung sehen möchten, und verbessern Sie sie dann mit neuen Szenarien in den nächsten Versionen.

Wenn Sie feststellen, dass es zu viele Szenarien gibt, die nicht in einen Sprint passen, teilen Sie die User Story in mehrere auf und führen Sie dies der Reihe nach durch. Vergessen Sie auch nicht, dass diese Szenarien priorisiert werden können.

Wie holt man das Beste aus ATDD heraus?

Verwenden Sie zusätzlich zu ATDD einen testgetriebenen Entwicklungsansatz (TDD), wenn Sie neue Funktionen entwickeln.

TDD verändert die traditionelle Entwicklung vollständig. Anstatt Code zu schreiben, schreiben Sie zunächst einen Komponententest für eine kleine Funktionalität. Und dann Code schreiben, bis der Test bestanden ist. Mit diesem Ansatz können Sie Qualität in die Entwicklung integrieren und den Testprozess nicht zu einer Phase der Entwicklung, sondern zu einem kontinuierlichen Prozess der Qualitätskontrolle machen.

Außerdem ist TDD die Quelle der technischen Dokumentation für das Team. Gut geschriebene Unit-Tests liefern eine funktionierende Spezifikation Ihres funktionalen Codes – und als Ergebnis werden Unit-Tests tatsächlich zu einem bedeutenden Teil Ihrer technischen Dokumentation. Ebenso können Abnahmetests einen wichtigen Teil Ihrer Anforderungsdokumentation bilden.

Was wir am Ende haben:

Zu Beginn erstellen wir Abnahmetests gemeinsam mit Stakeholdern und Kunden zusammen mit dem Team. Als nächstes konzentrieren wir uns bei der Entwicklung des Codes auf sie. Wir ergänzen den Entwicklungsprozess durch Unit-Tests, die geschrieben werden, bevor wir mit dem Schreiben von Code beginnen, und prüfen, ob für jede Funktion im Code ein Test durchgeführt wird. Am Ende der Entwicklung setzen wir uns als Team und Unternehmen zusammen, schauen uns eine funktionierende Lösung an und sammeln Feedback.

Wenn Ihnen der Artikel gefallen hat, kommen Sie zu Telegrammkanal Dmitri.

Bald wird OTUS eine offene Lektion „Problemkunde“ veranstalten, in der wir Folgendes besprechen werden:
— Arten von Stakeholdern und wie werden sie identifiziert?
— Konflikt (was ist das, wie geht man damit um)
– Strategien zum Umgang mit widersprüchlichen Stakeholdern – Arbeit an sich selbst und Selbstkontrolle (was ist, wenn ich das Problem bin?)
Anmeldung möglich Verknüpfung.

Similar Posts

Leave a Reply

Your email address will not be published.