Menü

Wie die Tester an TDD-, BDD- und ATDD-Techniken beteiligt sind

how testers are involved tdd

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Übersicht über TDD-, BDD- und ATDD-Techniken:

TDD, BDD & ATDD sind die Begriffe, die die Welt der Tester in Agile revolutioniert und ebenfalls an Dynamik gewonnen haben. Änderung der Denkweise von Testern erfordert auch das Erlernen neuer Fähigkeiten und vor allem das Ändern der Einstellung und der Arbeitsweise.

Im Gegensatz zur isolierten Arbeit müssen Tester mit den Programmierern zusammenarbeiten, was bedeutet

  • Teilen der Testfälle
  • Teilnahme am Schreiben der Akzeptanzkriterien der Geschichten
  • Kontinuierliches Feedback an die Stakeholder
  • Zusammenarbeit, um die Mängel rechtzeitig zu beheben.
  • Geben Sie Vorschläge und Anregungen zur Verbesserung der Qualität der Ergebnisse
  • Automatisierung

An Agile beteiligte Tester

Bevor ich mich mit der Diskussion über die Beteiligung eines Testers an diesen Praktiken befasse, versuchen wir zunächst, die Konzepte hinter diesen Begriffen zu verstehen:

Was du lernen wirst:

Testgetriebene Entwicklung

Betrachten Sie den traditionellen Ansatz der Softwareentwicklung, bei dem der Code zuerst geschrieben und dann getestet wird. Testgetriebene Entwicklung oder TDD ist ein Ansatz, der genau die Umkehrung der traditionellen Entwicklung darstellt. Bei diesem Ansatz wird zuerst getestet und dann der Code geschrieben.

Verwirrt?!!

Wie können wir eine Software testen, die noch entwickelt werden muss?

Ja!! Das ist testgetriebene Entwicklung oder TDD.

TDD arbeitet in kleinen Schritten, wobei:

  • Der Test wird zuerst geschrieben
  • Der Test wird ausgeführt - was (aus offensichtlichen Gründen) fehlschlägt.
  • Der Code wird geschrieben (oder überarbeitet), damit der Testfall bestanden wird
  • Der Test wird erneut ausgeführt
  • Wenn der Test bestanden wurde, fahren Sie mit dem nächsten Test fort. Andernfalls schreiben / ändern Sie den Code neu, um den Test zu bestehen

Lassen Sie mich versuchen, es durch ein Flussdiagramm zu erklären:

TDD-Flussdiagramm

Jetzt müssen wir verstehen, dass TDD nicht über die Tests spricht, die Tester durchführen. Vielmehr spricht dieser Ansatz tatsächlich von den Tests, die die Programmierer durchführen.

Ja!! Du hast es richtig erraten !! Es ist der Unit-Test.

Der Test, der zuerst geschrieben wird, ist nicht der Test, den die Tester schreiben, sondern der Komponententest, den die Programmierer schreiben. Also würde ich die Schritte wie folgt umformulieren:

  • Der UNIT-Test wird zuerst geschrieben
  • Der UNIT-Test wird ausgeführt - was (aus offensichtlichen Gründen) fehlschlägt.
  • Der Code wird geschrieben (oder überarbeitet), um den Test zu bestehen
  • Der UNIT-Test wird erneut ausgeführt
  • Wenn der Test bestanden wurde, fahren Sie mit dem nächsten Test fort. Andernfalls schreiben / ändern Sie den Code neu, um den Test zu bestehen

Hier stellt sich nun die Frage: Wenn TDD ein Programmiererjob ist, welche Rolle spielt der Tester bei diesem Ansatz?

Nun, obwohl TDD ein Programmiererjob ist, bedeutet dies nicht, dass die Tester nicht daran beteiligt sind. Tester können zusammenarbeiten, indem sie die folgenden Testszenarien gemeinsam nutzen:

  • Grenzwert Fälle
  • Äquivalenzklasse Testfälle
  • Kritische Geschäftsfälle
  • Fälle der fehleranfälligen Funktionalitäten
  • Level-Fälle sichern

Ich möchte damit sagen, dass Tester an der Definition der Unit-Test-Szenarien teilnehmen und mit den Programmierern zusammenarbeiten sollten, um diese zu implementieren. Tester sollten ihr Feedback zu den Testergebnissen geben.

Wenn wir TDD implementieren möchten, müssen Tester ihre Fähigkeiten verbessern. Sie müssen technischer sein und sich darauf konzentrieren, ihre analytischen und logischen Fähigkeiten zu verbessern.

Tester sollten sich auch bemühen, die Fachsprache zu verstehen, die die Programmierer verwenden, und wenn möglich, den Code aus der Vogelperspektive betrachten. In ähnlicher Weise müssen die Programmierer in die Fußstapfen des Testers treten und versuchen, ausgefeiltere Szenarien zu entwickeln, die den Komponententest robuster und solider machen.

Sowohl Programmierer als auch Tester müssen ineinander übergehen, im Gegensatz zu dem alten traditionellen Ansatz, bei dem die Programmierer den Komponententests nicht viel Gewicht beimessen, weil sie sich darauf verlassen, dass die Tester Fehler und Defekte finden, und die Tester sich nicht verwöhnen wollten in das Erlernen der technischen Dinge, weil sie denken, dass ihre Arbeit endet, nachdem sie die Mängel gefunden haben.

Verhaltensorientierte Entwicklung

Behavior Driven Development oder BDD ist eine Erweiterung von Test Driven Development.

BDD veranschaulicht, wie der Name schon sagt, die Methoden zum Entwickeln eines Features basierend auf seinem Verhalten. Das Verhalten wird im Wesentlichen anhand von Beispielen in einer sehr einfachen Sprache erklärt, die von jedem im Team, der für die Entwicklung verantwortlich ist, verstanden werden kann.

Einige der Hauptmerkmale von BDD sind folgende:

  • Die zur Definition des Verhaltens verwendete Sprache ist sehr einfach und in einem einzigen Format, in dem sie von jedem verstanden werden kann - sowohl von technischen als auch von nichttechnischen Personen, die an der Implementierung beteiligt sind
  • Bietet eine Plattform, auf der die drei Freunde (Programmierer, Tester und PO / BA) zusammenarbeiten und die Anforderungen verstehen können. Bestimmt eine gemeinsame Vorlage, um sie zu dokumentieren
  • Diese Technik / dieser Ansatz beschreibt das endgültige Verhalten des Systems oder das Verhalten des Systems und es wird NICHT darüber gesprochen, wie das System entworfen oder implementiert werden soll
  • Betont beide Aspekte der Qualität:
    • Die Anforderungen erfüllen
    • Gebrauchstauglich

Warum BDD?

Nun, wir wissen, dass das Beheben eines Defekts / Fehler Zu einem späteren Zeitpunkt eines Entwicklungszyklus ist dies recht kostspielig. Die Behebung der Produktionsfehler wirkt sich nicht nur auf den Code aus, sondern auch auf das Design und seine Anforderungen. Wenn wir das tun RCA (Ursachenanalyse) In den meisten Fällen kommen wir zu dem Schluss, dass der Defekt tatsächlich auf missverstandene Anforderungen hinausläuft.

Dies geschieht im Wesentlichen, weil jeder unterschiedliche Fähigkeiten hat, die Anforderungen zu verstehen. Daher können technische und nichttechnische Personen dieselbe Anforderung unterschiedlich interpretieren, was zu einer fehlerhaften Lieferung führen kann. Daher ist es wichtig, dass jeder im Entwicklungsteam die gleiche Anforderung versteht und sie auf die gleiche Weise interpretiert.

Wir müssen sicherstellen, dass die gesamten Entwicklungsbemühungen darauf ausgerichtet sind, die Anforderungen zu erfüllen. Um jegliche Art von „Anforderungsfehler“ zu vermeiden, muss das gesamte Entwicklungsteam diese ausrichten, um die einsatzfähige Anforderung zu verstehen.

Der BDD-Ansatz ermöglicht es dem Entwicklungsteam, dies zu tun, indem:

  • Definieren eines Standardansatzes zum Definieren der Anforderung in einfachem Englisch
  • Bereitstellung von Definitionsbeispielen zur Erläuterung der Anforderungen
  • Bereitstellung einer Schnittstelle / Plattform, über die technische (Programmierer / Tester) und nichttechnische (PO / BA / Kunde) zusammenarbeiten und zusammenkommen und auf derselben Seite sein können, um die Anforderungen zu verstehen und umzusetzen

Wie implementiere ich BDD?

Auf dem Markt sind viele Tools zur Implementierung von BDD verfügbar. Ich nenne hier einige:

  • Gurke
  • Fitness
  • Konkordion
  • JBehave
  • Spezifikationsfluss

Beispiel:

Versuchen wir, BDD anhand eines Beispiels zu verstehen. Für meinen Fall verwende ich Gurke (Gurke):

Stellen Sie sich einen einfachen Fall vor, in dem nur authentifizierte Benutzer die XYZ-Site betreten dürfen.

Die Gurkendatei (Feature-Datei) wäre wie folgt:

Merkmal: Testregistrierungsportal

Szenarioübersicht: Gültiger Benutzer angemeldet

Gegeben: Der Kunde öffnet das Registrierungsportal

Wann: Der Benutzer gibt den Benutzernamen als '' und das Passwort als '' ein.

Dann: Der Kunde sollte in der Lage sein, das Formular anzuzeigen.

Beispiele ::

| Benutzer | Passwort |

| user1 | pwd1 |

| user2 | pwd2 |

Wir können sehen, wie eine bestimmte Anforderung mit einfachem Englisch dokumentiert wird. Die drei Amigos können zusammenarbeiten, um die Feature-Dateien zu entwerfen, und bestimmte Testdaten können im Beispielabschnitt dokumentiert werden. BDD bietet ein Medium, um Programmierer, Tester und Unternehmen an einen Tisch zu bringen und ein gemeinsames Verständnis der zu implementierenden Funktionen zu schaffen.

Der BDD-Ansatz spart Aufwand und Kosten und prüft, ob nach der Bereitstellung der Produktion Fehler vorliegen, da die Zusammenarbeit zwischen Kunden und Entwicklern während des gesamten Entwicklungszyklus des Features bestand.

Entwicklungsteams können diese Feature-Dateien verwenden und in ausführbare Programme konvertieren, um ein bestimmtes Feature zu testen.

Wie?

Nun, dafür musst du Gurke / Fitness lernen !!

Akzeptanztestgesteuerte Entwicklung

Acceptance Test Driven Development oder ATDD ist eine Technik, bei der das gesamte Team zusammenarbeitet, um die Akzeptanzkriterien eines Epos / einer Story zu definieren, bevor die Implementierung tatsächlich beginnt. Diese Abnahmetests werden durch geeignete Beispiele und andere notwendige Informationen unterstützt.

Meistens werden BDD und ATDD austauschbar verwendet. Der ATDD-Ansatz kann auch im Given-When-Then-Format implementiert werden, genau wie wir Features im BDD-Ansatz schreiben.

Versuchen wir schnell, die Unterschiede zwischen den drei Ansätzen zusammenzufassen:

  • TDD ist technischer und in derselben Sprache geschrieben, in der die Funktion implementiert ist. Wenn die Funktion in Java implementiert ist, schreiben wir JUnit Testfälle . Während BDD & ATDD in einfacher englischer Sprache geschrieben ist
  • Der TDD-Ansatz konzentriert sich auf die Implementierung eines Features. Während sich BDD auf das Verhalten der Funktion konzentriert und ATDD sich auf die Erfassung der Anforderungen konzentriert
  • Um TDD zu implementieren, benötigen wir technisches Wissen. Während BDD & ATDD keine technischen Kenntnisse erfordern. Das Schöne an BDD / ATDD liegt in der Tatsache, dass sowohl technische als auch nichttechnische Personen an der Entwicklung der Funktion teilnehmen können
  • Da TDD weiterentwickelt wird, bietet es Raum für gutes Design und konzentriert sich auf den Qualitätsaspekt „Erfüllung der Anforderungen“. BDD / ATDD konzentrieren sich auf die 2ndQualitätsaspekt, der „Fit for Use“ ist

Alle diese Techniken sprechen im Wesentlichen vom 'Test-First' -Ansatz, im Gegensatz zum 'Test-Last' -Ansatz, der in traditionellen Entwicklungsmethoden verwendet wird.

Da die Tests zuerst geschrieben werden, spielen Tester eine sehr wichtige Rolle. Tester müssen nicht nur über umfassende Kenntnisse und Geschäftskenntnisse verfügen, sondern auch über gute technische Fähigkeiten verfügen, damit sie während der 3-Amigos-Diskussionen einen Mehrwert beim Brainstorming erzielen können.

Mit Konzepten wie CI (Continuous Integration) und CD (Continuous Delivery) müssen Tester gut mit den Programmierern zusammenarbeiten und gleichermaßen zum Bereich Entwicklung und Betrieb beitragen.

wie man eine apk datei unter windows öffnet

Lassen Sie mich diese Diskussion mit der berühmten Testpyramide in Agile zusammenfassen:

Testpyramide in Agile

Die unterste Schicht dieser Pyramide besteht aus der Einheitentestschicht. Diese Schicht ist die Grundschicht; Daher ist es imperial, dass diese Schicht steinhart ist. Die meisten Tests sollten in diese Ebene verschoben werden. Diese unterste Ebene konzentriert sich nur auf TDD.

In dem Agil Weltweit wird ein Schwerpunkt darauf gelegt, diese Schicht der Pyramide stärker und robuster zu machen, und es wird betont, dass die meisten Tests auf dieser Schicht durchgeführt werden.

Werkzeuge, die in dieser Ebene einer Pyramide verwendet werden, sind alle Xunit-Werkzeuge.

Die mittlere Schicht der Pyramide ist die Service-Schicht, in der die Service-Level-Tests erläutert werden. Diese Schicht fungiert als Brücke zwischen der Benutzeroberfläche der Anwendung und der Einheit / Komponente der unteren Ebene. Diese Schicht besteht hauptsächlich aus den APIs, die Anforderungen von der Benutzeroberfläche annehmen und die Antwort zurücksenden. Der BDD- und TTDD-Ansatz ist in dieser Schicht der Pyramide aktiv.

In der mittleren Schicht der Pyramide verwendete Werkzeuge sind - Fitnesse, Gurke und Roboter-Framework .

Die oberste Ebene der Pyramide ist die eigentliche Benutzeroberfläche. Dies zeigt, dass diese Ebene die geringste Anzahl von Tests enthalten sollte, oder ich sollte sagen, dass der Testaufwand auf dieser bestimmten Ebene minimal sein sollte. Die meisten Tests des Features sollten abgeschlossen sein, wenn wir die oberste Schicht der Pyramide erreichen.

In der obersten Ebene verwendete Werkzeuge sind - Selen , QTP und RFT.

Da arbeiten wir in kleinen Schritten in Gedränge (Sprints genannt) ist eine manuelle Implementierung all dieser Ansätze nicht möglich. Diese Ansätze erfordern ein automatisiertes Eingreifen. Die Automatisierung ist in diesem Fall sehr wichtig.

Tatsächlich werden diese Ansätze tatsächlich durch Automatisierung ausgeführt. Am Ende jedes Sprints werden neue Funktionen hinzugefügt, sodass es wichtig wird, dass die zuvor implementierten Funktionen wie erwartet funktionieren. daher, Automatisierung wird hier der Held.

Fazit

Am Ende des Artikels müssen Sie erfahren haben, wie die Tester an TDD-, BDD- und ATDD-Techniken beteiligt sind.

Im dritten Teil der Serie werde ich meine Diskussion auf die Automatisierung in einer agilen Welt konzentrieren.

Über den Autor: Dieser Artikel ist vom STH-Autor Shilpa. Sie arbeitet seit über 10 Jahren im Bereich Softwaretests in Bereichen wie Internetwerbung, Investment Banking und Telekommunikation.

Beobachten Sie diesen Bereich für weitere Updates.

Literatur-Empfehlungen

^