Agiles Testen - Kurzanleitung

Agileist eine iterative Entwicklungsmethode, bei der sowohl Entwicklungs- als auch Testaktivitäten gleichzeitig ausgeführt werden. Das Testen ist keine separate Phase. Codierung und Tests werden interaktiv und inkrementell durchgeführt, was zu einem hochwertigen Endprodukt führt, das den Kundenanforderungen entspricht. Darüber hinaus führt eine kontinuierliche Integration zu einer frühzeitigen Fehlerbeseitigung und damit zu Zeit-, Arbeits- und Kosteneinsparungen.

Agiles Manifest

Das Agile Manifest wurde 2001 von einem Team von Softwareentwicklern veröffentlicht. Es unterstreicht die Bedeutung des Entwicklungsteams, berücksichtigt sich ändernde Anforderungen und die Einbeziehung der Kunden.

The Agile Manifesto is −

Wir entdecken bessere Möglichkeiten zur Entwicklung von Software, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit sind wir zu Wert gekommen -

• Individuen und Interaktionen über Prozesse und Werkzeuge.
• Arbeitssoftware über umfassende Dokumentation.
• Kundenzusammenarbeit über Vertragsverhandlungen.
• Antworten auf Umstellung nach einem Plan.

Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr.

Was ist Agiles Testen?

Agile Testing ist eine Software-Testpraxis, die den Prinzipien der agilen Softwareentwicklung folgt.

An Agile Testing sind alle Mitglieder des Projektteams beteiligt, wobei die Tester über besondere Fachkenntnisse verfügen. Das Testen ist keine separate Phase und ist mit allen Entwicklungsphasen wie Anforderungen, Design und Codierung sowie Testfallgenerierung verwoben. Das Testen erfolgt gleichzeitig über den Entwicklungslebenszyklus.

Darüber hinaus würde mit der Teilnahme von Testern am gesamten Entwicklungslebenszyklus in Verbindung mit funktionsübergreifenden Teammitgliedern der Beitrag von Testern zur Erstellung der Software gemäß den Kundenanforderungen mit besserem Design und Code möglich.

Agile Tests decken alle Teststufen und alle Testarten ab.

Agile Testing Vs. Wasserfallprüfung

In einer Wasserfallentwicklungsmethode finden die Aktivitäten des Entwicklungslebenszyklus in aufeinander folgenden Phasen statt. Das Testen ist daher eine separate Phase und wird erst nach Abschluss der Entwicklungsphase eingeleitet.

Im Folgenden sind die Unterschiede zwischen Agile Testing und Waterfall Testing aufgeführt.

Agiles Testen	Wasserfallprüfung
Das Testen ist keine separate Phase und erfolgt gleichzeitig mit der Entwicklung.	Das Testen ist eine separate Phase. Alle Teststufen und -typen können erst nach Abschluss der Entwicklung beginnen.
Tester und Entwickler arbeiten zusammen.	Tester arbeiten getrennt von Entwicklern.
Tester sind an der Erarbeitung von Anforderungen beteiligt. Dies hilft bei der Zuordnung der Anforderungen zu den Verhaltensweisen im realen Szenario und bei der Festlegung der Akzeptanzkriterien. Außerdem wären logische Abnahmetestfälle zusammen mit den Anforderungen bereit.	Tester sind möglicherweise nicht an der Anforderungsphase beteiligt.
Abnahmetests werden nach jeder Iteration durchgeführt und Kundenfeedback eingeholt.	Abnahmetests werden erst am Ende des Projekts durchgeführt.
Jede Iteration führt ihre eigenen Tests durch, sodass Regressionstests jedes Mal implementiert werden können, wenn neue Funktionen oder Logik freigegeben werden.	Regressionstests können erst nach Abschluss der Entwicklung implementiert werden.
Keine Zeitverzögerungen zwischen Codierung und Test.	Übliche Zeitverzögerungen zwischen Codierung und Test.
Kontinuierliche Tests mit überlappenden Teststufen.	Das Testen ist eine zeitgesteuerte Aktivität und die Teststufen können sich nicht überschneiden.
Testen ist eine bewährte Methode.	Tests werden oft übersehen.

Agile Testprinzipien

Die Prinzipien des agilen Testens sind -

• Testing moves the project forward- Kontinuierliche Tests sind der einzige Weg, um einen kontinuierlichen Fortschritt sicherzustellen. Agile Testing bietet laufend Feedback und das Endprodukt erfüllt die geschäftlichen Anforderungen.

• Testing is not a phase- Agile Teamtests zusammen mit dem Entwicklungsteam, um sicherzustellen, dass die während einer bestimmten Iteration implementierten Funktionen tatsächlich ausgeführt werden. Das Testen wird nicht für eine spätere Phase aufbewahrt.

• Everyone tests- Bei agilen Tests testet das gesamte Team, einschließlich Analysten, Entwickler und Tester, die Anwendung. Nach jeder Iteration führt sogar der Kunde den Benutzerakzeptanztest durch.

• Shortening Feedback Loops- In Agile Testing lernt das Geschäftsteam die Produktentwicklung für jede einzelne Iteration kennen. Sie sind an jeder Iteration beteiligt. Kontinuierliches Feedback verkürzt die Feedback-Reaktionszeit und damit die Kosten für die Behebung.

• Keep the Code Clean- Die Fehler werden behoben, wenn sie innerhalb derselben Iteration ausgelöst werden. Dies gewährleistet sauberen Code bei jedem Meilenstein der Entwicklung.

• Lightweight Documentation - Anstelle einer umfassenden Testdokumentation können Agile Tester -

  • Verwenden Sie wiederverwendbare Checklisten, um Tests vorzuschlagen.

  • Konzentrieren Sie sich eher auf das Wesentliche des Tests als auf die zufälligen Details.

  • Verwenden Sie einfache Dokumentationsstile / -werkzeuge.

  • Erfassen Sie Testideen in Chartas für Erkundungstests.

  • Nutzen Sie Dokumente für mehrere Zwecke.

• Leveraging one test artifact for manual and automated tests- Das gleiche Artefakt des Testskripts kann für manuelle Tests und als Eingabe für automatisierte Tests verwendet werden. Dadurch entfällt die Anforderung einer manuellen Testdokumentation und eines entsprechenden Automatisierungstestskripts.

• “Done Done,” not just done - In Agile soll eine Funktion nicht nach der Entwicklung, sondern nach der Entwicklung und dem Testen ausgeführt werden.

• Test-Last vs. Test Driven- Testfälle werden zusammen mit den Anforderungen geschrieben. Daher kann die Entwicklung durch Tests vorangetrieben werden. Dieser Ansatz wird als Test Driven Development (TDD) und Acceptance Test Driven Development (ATDD) bezeichnet. Dies steht im Gegensatz zum Testen als letzte Phase des Wasserfalltests.

Agile Testaktivitäten

Die agilen Testaktivitäten auf Projektebene sind -

• Release-Planung (Testplan)

  • Für jede Iteration,

  • Agile Testaktivitäten während einer Iteration

• Regressionstests

• Freigabeaktivitäten (testbezogen)

Die agilen Testaktivitäten während einer Iteration umfassen:

• Teilnahme an der Iterationsplanung
• Schätzen von Aufgaben aus Sicht des Testens
• Schreiben von Testfällen mithilfe der Funktionsbeschreibungen
• Unit Testing
• Integrationstests
• Funktionstests
• Fehlerbehebung
• Integrationstests
• Abnahmetests
• Statusberichterstattung über den Testfortschritt
• Fehlerverfolgung

Agile ist eine iterative Entwicklungsmethode, bei der das gesamte Projektteam an allen Aktivitäten teilnimmt. Die Anforderungen entwickeln sich im Verlauf der Iterationen durch die Zusammenarbeit zwischen dem Kunden und den selbstorganisierenden Teams. Da Codierung und Tests im Verlauf der Entwicklung interaktiv und inkrementell durchgeführt werden, ist das Endprodukt von Qualität und stellt die Kundenanforderungen sicher.

Jede Iteration führt zu einem integrierten Arbeitsproduktinkrement und wird für Benutzerakzeptanztests bereitgestellt. Das so erhaltene Kundenfeedback wäre eine Eingabe für die nächsten / nachfolgenden Iterationen.

Kontinuierliche Integration, kontinuierliche Qualität

Kontinuierliche Integration ist der Schlüssel zum Erfolg von Agile Development. Integrieren Sie häufig, mindestens täglich, damit Sie bei Bedarf für eine Veröffentlichung bereit sind. Das Testen in Agile wird zu einem wesentlichen Bestandteil aller Entwicklungsphasen und gewährleistet die kontinuierliche Qualität des Produkts. Ständiges Feedback von allen Projektbeteiligten trägt zur Qualität des Produkts bei.

In Agile wird der Kommunikation höchste Bedeutung beigemessen und die Kundenanfragen werden bei Bedarf empfangen. Dies gibt dem Kunden die Zufriedenheit, dass alle Eingaben berücksichtigt werden und ein Produkt von Arbeitsqualität während der gesamten Entwicklung verfügbar ist.

Agile Methoden

Es gibt verschiedene agile Methoden, die die agile Entwicklung unterstützen. Die agilen Methoden umfassen -

Gedränge

Scrum ist eine agile Entwicklungsmethode, bei der der teamorientierte Ansatz im Vordergrund steht. Es befürwortet die Teilnahme des gesamten Teams an allen Projektentwicklungsaktivitäten.

XP

eXtreme Programming ist kundenorientiert und konzentriert sich auf sich ständig ändernde Anforderungen. Durch häufige Veröffentlichungen und Kundenfeedbacks wird das Endprodukt von Qualität sein und die Kundenanforderungen erfüllen, die während des Prozesses klarer werden.

Kristall

Crystal basiert auf Chartern, zyklischer Lieferung und Verpackung.

• Das Chartern beinhaltet die Bildung eines Entwicklungsteams, die Durchführung einer vorläufigen Machbarkeitsanalyse, die Erstellung eines ersten Plans und der Entwicklungsmethodik.

• Die zyklische Lieferung mit zwei oder mehr Lieferzyklen konzentriert sich auf die Entwicklungsphase und die endgültige integrierte Produktlieferung.

• Während des Abschlusses werden die Bereitstellung in der Benutzerumgebung, Überprüfungen nach der Bereitstellung und Überlegungen durchgeführt.

FDD

Feature Driven Development (FDD) umfasst das Entwerfen und Erstellen von Features. Der Unterschied zwischen FDD und anderen agilen Entwicklungsmethoden besteht darin, dass die Funktionen in spezifischen und kurzen Phasen getrennt entwickelt werden.

DSDM

Die Dynamic Software Development Method (DSDM) basiert auf der Rapid Application Development (RAD) und ist auf das Agile Framework ausgerichtet. DSDM konzentriert sich auf die häufige Lieferung des Produkts, wobei die Benutzer aktiv einbezogen werden und die Teams in die Lage versetzt werden, schnelle Entscheidungen zu treffen.

Lean Software-Entwicklung

Bei der schlanken Softwareentwicklung liegt der Schwerpunkt auf der Beseitigung von Verschwendung und der Wertschöpfung für den Kunden. Dies führt zu einer schnellen Entwicklung und einem Wertprodukt.

Abfall umfasst teilweise erledigte Arbeiten, irrelevante Arbeiten, Funktionen, die vom Kunden nicht verwendet werden, Mängel usw., die zu Verzögerungen bei der Lieferung führen.

Das Lean Principles sind -

• Abfall beseitigen
• Lernen verstärken
• Verzögerungsverpflichtung
• Stärken Sie das Team
• Liefern Sie schnell
• Integrität aufbauen in
• Das Ganze sehen

Kanban

Kanban konzentriert sich auf die Verwaltung der Arbeit mit Schwerpunkt auf Just-in-Time-Bereitstellung (JIT), ohne die Teammitglieder zu überlasten. Die Aufgaben werden allen Teilnehmern angezeigt und den Teammitgliedern wird die Arbeit aus einer Warteschlange entnommen.

Kanban basiert auf -

• Kanban Board (visuell und beständig in der gesamten Entwicklung)
• Work-in-Progress (WIP) -Limit
• Vorlaufzeit

Agile Testmethoden

Die Testpraktiken sind für jedes Projekt, ob agil oder nicht, genau definiert, um Qualitätsprodukte zu liefern. Traditionelle Testprinzipien werden beim agilen Testen häufig verwendet. Eines davon ist Early Testing, das sich auf -

• Schreiben von Testfällen, um das Verhalten des Systems auszudrücken.

• Früherkennung, Erkennung und Beseitigung von Fehlern.

• Sicherstellen, dass die richtigen Testtypen zur richtigen Zeit und als Teil der richtigen Teststufe ausgeführt werden.

In allen von uns diskutierten agilen Methoden ist das agile Testen an sich eine Methodik. In allen Ansätzen werden Testfälle vor dem Codieren geschrieben.

In diesem Tutorial konzentrieren wir uns auf Scrum als agile Testmethode.

Die anderen häufig verwendeten agilen Testmethoden sind -

• Test-Driven Development (TDD) - Test Driven Development (TDD) basiert auf einer von Tests geleiteten Codierung.

• Acceptance Test-Driven Development (ATDD) - Acceptance Test-Driven Development (ATDD) basiert auf der Kommunikation zwischen Kunden, Entwicklern und Testern und basiert auf vordefinierten Abnahmekriterien und Abnahmetestfällen.

• Behavior-Driven Development (BDD) - In der verhaltensgesteuerten Entwicklung (BDD) basiert das Testen auf dem erwarteten Verhalten der zu entwickelnden Software.

Agiler Testlebenszyklus

In Scrum umfassen die Testaktivitäten:

• Beitrag zu User Stories basierend auf dem erwarteten Verhalten des als Testfälle dargestellten Systems

• Release-Planung basierend auf Testaufwand und Fehlern

• Sprint-Planung basierend auf User Stories und Defekten

• Sprint-Ausführung mit kontinuierlichem Testen

• Regressionstests nach Abschluss des Sprints

• Testergebnisse melden

• Automatisierungstests

Das Testen ist iterativ und basiert auf Sprints, wie in der folgenden Abbildung dargestellt.

Agile Development ist teamorientiert und Entwickler und Tester nehmen an allen Projekt- und Entwicklungsaktivitäten teil. Die Teamarbeit maximiert den Erfolg von Tests in agilen Projekten.

Ein Tester in Agile-Team muss an allen Projektaktivitäten teilnehmen und dazu beitragen und gleichzeitig das Know-how beim Testen nutzen.

Ein agiler Tester sollte über traditionelle Testfähigkeiten verfügen. Darüber hinaus benötigt Agile Tester -

• Gute zwischenmenschliche Fähigkeiten.

• Fähigkeit, mit Teammitgliedern und Stakeholdern positiv und lösungsorientiert zu handeln.

• Fähigkeit, kritisches, qualitätsorientiertes und skeptisches Denken über das Produkt zu zeigen.

• Fähigkeit, proaktiv zu sein, um aktiv Informationen von den Stakeholdern zu erhalten.

• Fähigkeiten zur effektiven Zusammenarbeit mit Kunden und Stakeholdern bei der Definition testbarer User Stories, den Akzeptanzkriterien.

• Talent, ein gutes Teammitglied zu sein, das mit Entwicklern bei der Erstellung von Qualitätscode zusammenarbeitet.

• Verwendbarkeit von Testfähigkeiten, um die richtigen Testfälle zur richtigen Zeit und auf dem richtigen Niveau zu haben und sie innerhalb der Sprintdauer gut auszuführen.

• Fähigkeit, Testergebnisse, Testfortschritte und die Produktqualität zu bewerten und zu melden.

• Offenheit, schnell auf Änderungen zu reagieren, einschließlich Ändern, Hinzufügen oder Verbessern von Testfällen.

• Potenzial zur Selbstorganisation der Arbeit.

• Begeisterung für kontinuierliches Kompetenzwachstum.

• Kompetenz in Testautomatisierung, testgetriebener Entwicklung (TDD), akzeptanztestgetriebener Entwicklung (ATDD), verhaltensgetriebener Entwicklung (BDD) und erfahrungsbasiertem Testen.

Rolle des Testers im agilen Team

Das Tester in Agile Team nimmt an allen Projekt- und Entwicklungsaktivitäten teil, um das Beste aus dem Test-Know-how beizutragen.

Agile Tester Aktivitäten umfassen -

• Sicherstellen, dass die Testwerkzeuge ordnungsgemäß verwendet werden.

• Konfigurieren, Verwenden und Verwalten der Testumgebungen und der Testdaten.

• Mentoring anderer Teammitglieder in relevanten Aspekten des Testens.

• Sicherstellen, dass während der Release- und Sprint-Planung geeignete Testaufgaben geplant werden.

• Teststrategie verstehen, implementieren und aktualisieren.

• Zusammenarbeit mit Entwicklern, Kunden und Stakeholdern bei der Klärung von Anforderungen in Bezug auf Testbarkeit, Konsistenz und Vollständigkeit.

• Durchführen der richtigen Tests zur richtigen Zeit und auf den richtigen Testniveaus.

• Fehler melden und mit dem Team zusammenarbeiten, um sie zu beheben.

• Messen und Berichten der Testabdeckung über alle anwendbaren Abdeckungsdimensionen.

• Teilnahme an Sprint-Retrospektiven, proaktives Vorschlagen und Implementieren von Verbesserungen.

Im agilen Lebenszyklus spielt ein Tester eine wichtige Rolle in -

• Teamwork
• Testplanung
• Sprint Zero
• Integration
• Agile Testpraktiken

Zusammenarbeit

In der agilen Entwicklung ist Teamwork von grundlegender Bedeutung und erfordert daher Folgendes:

• Collaborative Approach- Zusammenarbeit mit funktionsübergreifenden Teammitgliedern in Bezug auf Teststrategie, Testplanung, Testspezifikation, Testdurchführung, Testauswertung und Berichterstattung über Testergebnisse. Einbringen der Testkompetenz in Verbindung mit anderen Teamaktivitäten.

• Self-organizing - Planen und organisieren Sie sich gut innerhalb der Sprints, um die Testziele zu erreichen, indem Sie das Fachwissen anderer Teammitglieder zusammenführen.

• Empowerment - Treffen geeigneter technischer Entscheidungen zur Erreichung der Teamziele.

• Commitment - Verpflichtung, das Verhalten und die Eigenschaften des Produkts gemäß den Anforderungen der Kunden und Stakeholder zu verstehen und zu bewerten.

• Transparent - Offen, kommunizierend und rechenschaftspflichtig.

• Credibility- Gewährleistung der Glaubwürdigkeit der Teststrategie, ihrer Implementierung und Ausführung. Halten Sie die Kunden und Stakeholder über die Teststrategie auf dem Laufenden.

• Open to Feedback- Teilnahme an Sprint-Retrospektiven, um aus Erfolgen und Misserfolgen zu lernen. Kundenfeedback einholen und schnell und angemessen handeln, um qualitativ hochwertige Ergebnisse sicherzustellen.

• Resilient - Auf Änderungen reagieren.

Testplanung

Die Testplanung sollte während der Release-Planung beginnen und während jedes Sprints aktualisiert werden. Die Testplanung sollte die folgenden Aufgaben abdecken:

• Definieren des Testumfangs, des Testumfangs, der Test- und Sprintziele.

• Festlegen der Testumgebung, Testtools, Testdaten und Konfigurationen.

• Zuweisen von Tests von Merkmalen und Eigenschaften.

• Planen von Testaufgaben und Definieren der Häufigkeit von Tests.

• Identifizierung von Testmethoden, -techniken, -werkzeugen und -testdaten.

• Feststellen von Voraussetzungen wie Vorgängeraufgaben, Fachwissen und Schulung.

• Identifizieren von Abhängigkeiten wie Funktionen, Code, Systemkomponenten, Anbieter, Technologie, Tools, Aktivitäten, Aufgaben, Teams, Testtypen, Teststufen und Einschränkungen.

• Festlegen von Prioritäten unter Berücksichtigung der Kunden- / Benutzerbedeutung und -abhängigkeiten.

• Ankunft zu der Zeitdauer und dem Aufwand, die zum Testen erforderlich sind.

• Identifizieren von Aufgaben bei jeder Sprintplanung.

Sprint Zero

Sprint Zero beinhaltet Vorbereitungsaktivitäten vor dem ersten Sprint. Ein Tester muss bei den folgenden Aktivitäten mit dem Team zusammenarbeiten:

• Umfang identifizieren
• Teilen von User Stories in Sprints
• Systemarchitektur erstellen
• Planen, Erwerben und Installieren von Tools (einschließlich Testtools)
• Erstellen der ersten Teststrategie für alle Teststufen
• Testmetriken definieren
• Angabe der Akzeptanzkriterien, auch Definition von „Fertig“ genannt
• Ausstiegskriterien definieren
• Scrum Board erstellen
• Festlegen der Testrichtung während der Sprints

Integration

In Agile sollte ein qualitativ hochwertiges Arbeitsprodukt zu jedem Zeitpunkt im Entwicklungslebenszyklus zur Veröffentlichung bereit sein. Dies impliziert eine kontinuierliche Integration als Teil der Entwicklung. Ein agiler Tester muss die kontinuierliche Integration mit kontinuierlichen Tests unterstützen.

Um dies zu erreichen, muss ein Tester -

• Verstehen Sie die Integrationsstrategie.
• Identifizieren Sie alle Abhängigkeiten zwischen Funktionen und Merkmalen.

Agile Testpraktiken

Ein agiler Tester muss die agilen Praktiken für das Testen in einem agilen Projekt anpassen.

• Pairing- Zwei Teammitglieder arbeiten an derselben Tastatur zusammen. Während einer von ihnen testet, überprüft / analysiert der andere Test. Die beiden Teammitglieder können sein

  • Ein Tester und ein Entwickler

  • Ein Tester und ein Business Analyst

  • Zwei Tester

• Incremental Test Design - Testfälle werden aus User Stories erstellt, angefangen bei einfachen Tests bis hin zu komplexeren Tests.

• Mind Mapping- Eine Mind Map ist ein Diagramm, um die Informationen visuell zu organisieren. Mind Mapping kann als effektives Werkzeug für agile Tests verwendet werden, mit denen Informationen zu den erforderlichen Testsitzungen, Teststrategien und Testdaten organisiert werden können.

Teststatus kann mitgeteilt werden -

• Während der täglichen Stand-up-Meetings
• Verwenden von Standard-Testmanagement-Tools
• Über Boten

Der Teststatus, der durch den Testbestandsstatus bestimmt wird, ist entscheidend für die Entscheidung, ob die Aufgabe „erledigt“ ist. Fertig bedeutet, dass alle Tests für den Task bestanden wurden.

Testfortschritt

Der Testfortschritt kann mit - verfolgt werden

• Scrum Boards (Agile Task Boards)
• Burndown-Diagramme
• Automatisierte Testergebnisse

Der Testfortschritt wirkt sich auch direkt auf den Entwicklungsfortschritt aus. Dies liegt daran, dass eine User Story verschoben werden kannDoneStatus erst nach Erreichen der Abnahmekriterien. Dies wird wiederum durch den Teststatus entschieden, da die Akzeptanzkriterien anhand eines Teststatus beurteilt werden.

Wenn der Testfortschritt verzögert oder blockiert wird, diskutiert das gesamte Team und arbeitet zusammen, um diese zu beheben.

In agilen Projekten finden Änderungen häufig statt. Wenn viele Änderungen vorgenommen werden, können wir erwarten, dass sich der Teststatus, der Testfortschritt und die Produktqualität ständig weiterentwickeln. Die agilen Tester müssen diese Informationen an das Team weiterleiten, damit die richtigen Entscheidungen zum richtigen Zeitpunkt getroffen werden können, um für den erfolgreichen Abschluss jeder Iteration auf dem richtigen Weg zu bleiben.

Wenn Änderungen auftreten, können sie sich auf vorhandene Features aus früheren Iterationen auswirken. In solchen Fällen müssen manuelle und automatisierte Tests aktualisiert werden, um das Regressionsrisiko wirksam zu bewältigen. Regressionstests sind ebenfalls erforderlich.

Produktqualität

Produktqualitätsmetriken umfassen -

• Tests bestanden / nicht bestanden
• Fehler gefunden / behoben
• Testabdeckung
• Test Pass / Fail-Raten
• Fehlererkennungsraten
• Fehlerdichte

Die Automatisierung der Erfassung und Berichterstellung von Produktqualitätsmetriken hilft bei -

• Transparenz bewahren.
• Sammeln Sie alle relevanten und erforderlichen Metriken zum richtigen Zeitpunkt.
• Sofortige Berichterstattung ohne Kommunikationsverzögerungen.
• Ermöglichen, dass sich Tester auf das Testen konzentrieren können.
• Filterung des Missbrauchs von Metriken.

Um die Gesamtproduktqualität sicherzustellen, muss das Agile-Team Kundenfeedback einholen, ob das Produkt den Kundenerwartungen entspricht. Dies muss am Ende jeder Iteration durchgeführt werden, und das Feedback wird als Eingabe für nachfolgende Iterationen verwendet.

Schlüsselfaktoren für den Erfolg

In Agile-Projekten können Qualitätsprodukte geliefert werden, wenn Agile-Tests erfolgreich sind.

Die folgenden Punkte müssen für den Erfolg von Agile-Tests berücksichtigt werden:

• Agiles Testen basiert auf Test First und kontinuierlichen Testansätzen. Daher sind die herkömmlichen Testwerkzeuge, die auf dem Test-Last-Ansatz basieren, möglicherweise nicht geeignet. Daher muss bei der Auswahl der Testwerkzeuge in agilen Projekten die Ausrichtung auf agile Tests überprüft werden.

• Reduzieren Sie die Gesamttestzeit, indem Sie Tests früher im Entwicklungslebenszyklus automatisieren.

• Agile Tester müssen ihr Tempo beibehalten, um sich an den Zeitplan für die Entwicklungsversion anzupassen. Daher muss die ordnungsgemäße Planung, Nachverfolgung und Neuplanung der Testaktivitäten im laufenden Betrieb erfolgen, wobei die Produktqualität das Ziel ist.

• Manuelle Tests machen 80% der Tests in den Projekten aus. Daher müssen Tester mit Fachwissen Teil des Agile-Teams sein.

• Durch die Teilnahme dieser Tester mit Fachwissen während des gesamten Entwicklungslebenszyklus konzentriert sich das gesamte Team auf Qualitätsprodukte, die die Kundenerwartungen erfüllen.

  • Definieren von User Stories, die das vom Endbenutzer erwartete Produktverhalten hervorheben.

  • Identifizieren von Akzeptanzkriterien auf User Story- / Aufgabenebene gemäß Kundenerwartungen.

  • Aufwands- und Dauerschätzung für Testaktivitäten.

  • Planen von Testaktivitäten.

  • Abstimmung mit dem Entwicklungsteam, um die Produktion von Code sicherzustellen, der die Anforderungen mit einem Vorab-Testdesign erfüllt.

  • Testen Sie zuerst und testen Sie kontinuierlich, um sicherzustellen, dass der Status "Fertig" zum erwarteten Zeitpunkt den Akzeptanzkriterien entspricht.

  • Sicherstellung von Tests auf allen Ebenen innerhalb des Sprints.

  • Regressionstests am Ende jedes Sprints.

  • Sammeln und Analysieren von Produktmetriken, die für den Erfolg des Projekts nützlich sind.

  • Analysieren von Fehlern, um festzustellen, welche im aktuellen Sprint behoben werden müssen und welche auf nachfolgende Sprints verzögert werden können.

  • Konzentration auf das, was aus Kundensicht wichtig ist.

Lisa Crispin hat sieben Schlüsselfaktoren für den Erfolg agiler Tests definiert -

• Whole Team approach- Bei diesem Ansatz schulen die Entwickler die Tester und die Tester andere Teammitglieder. Dies hilft jedem, jede Aufgabe im Projekt zu verstehen, wodurch Zusammenarbeit und Beitrag den größtmöglichen Nutzen bringen. Die Zusammenarbeit von Testern mit Kunden ist auch ein wichtiger Faktor, um ihre Erwartungen gleich zu Beginn festzulegen und die Akzeptanzkriterien in die für das Bestehen des Tests erforderlichen zu übersetzen.

• Agile Testing Mindset - Die Tester sind proaktiv dabei, die Qualität kontinuierlich zu verbessern und ständig mit dem Rest des Teams zusammenzuarbeiten.

• Automate Regression Testing- Design für Testbarkeit und Laufwerksentwicklung mit Tests. Fangen Sie einfach an und lassen Sie das Team die Werkzeuge auswählen. Seien Sie bereit, Ratschläge zu geben.

• Provide and Obtain Feedback- Da dies ein zentraler Wert von Agile ist, sollte das gesamte Team offen für Rückmeldungen sein. Da die Tester Experten-Feedback-Anbieter sind, müssen sie sich auf relevante und notwendige Informationen konzentrieren. Im Gegenzug sollten beim Einholen von Feedback Änderungen und Tests von Testfällen berücksichtigt werden.

• Build a Foundation of Core Agile Practices - Konzentrieren Sie sich auf das Testen neben Codierung, kontinuierliche Integration, kollaborative Testumgebungen, inkrementelles Arbeiten, Akzeptanz für Änderungen und Aufrechterhaltung von Synergien.

• Collaborate with Customers - Ermitteln Sie Beispiele, verstehen und überprüfen Sie die Anforderungszuordnung zum Produktverhalten, richten Sie Akzeptanzkriterien ein und holen Sie Feedback ein.

• Look at the Big Picture - Entwickeln Sie die Entwicklung mit Tests und Beispielen für Unternehmen, indem Sie reale Testdaten verwenden und über die Auswirkungen auf andere Bereiche nachdenken.

In diesem Kapitel werden einige wichtige Attribute des agilen Testens vorgestellt.

Vorteile des agilen Testens

Die Vorteile von Agile Tests sind:

• Kundenzufriedenheit durch schnelles, kontinuierliches, vollständig getestetes Produkt und Einholen von Kundenfeedback.

• Kunden, Entwickler und Tester interagieren kontinuierlich miteinander, wodurch sich die Zykluszeit verkürzt.

• Agile Tester beteiligen sich an der Definition von Anforderungen und bringen ihre Testkompetenz ein, um sich auf das zu konzentrieren, was praktikabel ist.

• Agile Tester nehmen an der Schätzung teil, um den Testaufwand und die Testzeit zu bewerten.

• Frühes Testdesign, das Akzeptanzkriterien widerspiegelt.

• Die Testanforderungen werden vom gesamten Team konsolidiert, um Nachteile zu vermeiden.

• Ständiger Fokus auf die Qualität des Produkts durch das gesamte Team.

• Definition von Done Der Status, der den Test besteht, stellt sicher, dass die Anforderung erfüllt ist.

• Kontinuierliches Feedback zu Verzögerungen oder Blockaden, damit das gesamte Team sofort Abhilfe schaffen kann.

• Schnelle Reaktion auf sich ändernde Anforderungen und baldige Anpassung.

• Kontinuierliche integrationsgesteuerte Regressionstests.

• Keine zeitlichen Verzögerungen zwischen Entwicklung und Test. Test zuerst werden kontinuierliche Testansätze verfolgt.

• Automatisierungstests werden früh im Entwicklungslebenszyklus implementiert, wodurch die Gesamttestzeit und der Testaufwand reduziert werden.

Best Practices für agiles Testen

Befolgen Sie die unten angegebenen Best Practices -

• Einbeziehung von Testern mit Fachkenntnissen in allen Arten von Tests auf allen Ebenen.

• Tester, die an der Definition von Anforderungen teilnehmen und mit Kunden am erwarteten Verhalten des Produkts zusammenarbeiten.

• Tester teilen kontinuierlich Feedback mit den Entwicklern und Kunden.

• Testen Sie zuerst und kontinuierliche Testansätze, um sich an der Entwicklungsarbeit auszurichten.

• Verfolgen Sie den Teststatus und den Testfortschritt zeitnah und konstant, wobei Sie sich auf die Lieferung von Qualitätsprodukten konzentrieren.

• Automatisierungstests zu Beginn des Entwicklungslebenszyklus, um die Zykluszeit zu verkürzen.

• Um Regressionstests durchzuführen, nutzen Sie Automatisierungstests als effektiven Weg.

Herausforderungen beim agilen Testen

Die folgenden Herausforderungen bestehen beim agilen Testen:

• Wenn der agile Ansatz und seine Einschränkungen durch Unternehmen und Management nicht verstanden werden, kann dies zu unerreichbaren Erwartungen führen.

• Agile verfolgt den Ansatz des gesamten Teams, aber nicht jeder kennt die Grundlagen der Testpraktiken. Testern wird empfohlen, die anderen zu coachen, aber im realen Szenario kann dies mit Sprints (Iterationen) mit Zeitboxen nicht praktikabel sein.

• Test First Approach erfordert, dass Entwickler die Codierung auf Tester-Feedback basieren. In realen Szenarien sind Entwickler jedoch eher daran gewöhnt, die Codierung auf den Anforderungen des Kunden oder des Unternehmens zu basieren.

• Die Verantwortung für das Qualitätsprodukt liegt beim gesamten agilen Team, aber in der Anfangsphase konzentrieren sich die Entwickler möglicherweise nicht auf Qualität, da sie sich mehr im Implementierungsmodus befinden.

• Die kontinuierliche Integration erfordert Regressionstests, die einen erheblichen Aufwand erfordern, auch wenn sie automatisiert werden müssen.

• Tester können an Änderungen mit der agilen Denkweise angepasst werden, aber die Anpassung der resultierenden Teständerungen und Tests kann nicht praktikabel sein, um das Ziel während des Sprints zu erreichen.

• Eine frühzeitige Automatisierung wird empfohlen, damit der manuelle Testaufwand und die manuelle Testzeit reduziert werden können. Im realen Szenario erfordert es jedoch Zeit und Mühe, zu den Tests zu gelangen, die automatisiert und automatisiert werden können.

Richtlinien für agile Tests

Verwenden Sie beim Ausführen von Agile Tests die folgenden Richtlinien.

• Nehmen Sie an der Release-Planung teil, um die erforderlichen Testaktivitäten zu ermitteln und die erste Version des Testplans zu erstellen.

• Nehmen Sie an der Schätzungssitzung teil, um den Testaufwand und die Testdauer zu ermitteln, damit die Testaktivitäten in den Iterationen berücksichtigt werden.

• Nehmen Sie an der Definition von User Storys teil, um zu Akzeptanztestfällen zu gelangen.

• Nehmen Sie an jedem Sprint-Planungsmeeting teil, um den Umfang zu verstehen und den Testplan zu aktualisieren.

• Arbeiten Sie während des Sprints kontinuierlich mit dem Entwicklungsteam zusammen, um das Testen und Codieren im Sprint zu einem Erfolg zu machen.

• Nehmen Sie an täglichen Stand-up-Meetings teil und übermitteln Sie eventuelle Testverzögerungen oder -blockaden, um eine sofortige Lösung zu erhalten.

• Verfolgen und melden Sie regelmäßig Teststatus, Testfortschritt und Produktqualität.

• Seien Sie bereit, Änderungen zu berücksichtigen, und reagieren Sie mit Änderungen an Testfällen und Testdaten.

• Nehmen Sie an Sprint-Retrospektiven teil, um die Best Practices und Lessons Learned zu verstehen und beizutragen.

• Arbeiten Sie bei jedem Sprint zusammen, um Kundenfeedback zu erhalten.

Wie beim herkömmlichen Testen müssen auch beim agilen Testen alle Teststufen abgedeckt werden.

• Unit Testing
• Integrationstests
• Systemtests
• User Acceptance Testing

Unit Testing

• Zusammen mit der Codierung vom Entwickler erledigt
• Unterstützt von Tester, der Testfälle schreibt, die eine 100% ige Designabdeckung gewährleisten
• Unit-Testfälle und Unit-Testergebnisse müssen überprüft werden
• Ungelöste größere Mängel (nach Priorität und Schweregrad) bleiben nicht bestehen
• Alle Unit Tests sind automatisiert

Integrationstests

• Geschehen zu Continuous Integration im Verlauf der Sprints
• Fertig am Ende, nachdem alle Sprints abgeschlossen sind
• Alle funktionalen Anforderungen werden getestet
• Alle Schnittstellen zwischen Einheiten werden getestet
• Alle Mängel werden gemeldet
• Tests werden nach Möglichkeit automatisiert

Systemtests

• Fertig im Verlauf der Entwicklung
• Benutzergeschichten, Features und Funktionen werden getestet
• Tests in der Produktionsumgebung durchgeführt
• Qualitätstests werden durchgeführt (Leistung, Zuverlässigkeit usw.)
• Mängel werden gemeldet
• Tests werden nach Möglichkeit automatisiert

User Acceptance Testing

• Fertig am Ende jedes Sprints und am Ende des Projekts

• Vom Kunden erledigt. Das Feedback wird vom Team entgegengenommen

• Feedback ist eine Eingabe für nachfolgende Sprints

• User Stories in einem Sprint sind vorab als testbar verifiziert und haben definierte Akzeptanzkriterien

Testtypen

• Komponententests (Unit Tests)
• Funktionstests (User Stories Tests)
• Nichtfunktionale Tests (Leistung, Belastung, Belastung usw.)
• Akzeptanztests

Die Tests können vollständig manuell, vollständig automatisiert, manuell und automatisiert oder manuell durchgeführt werden.

Unterstützung bei der Programmierung und bei kritischen Produkttests

Tests können sein für -

• Supporting Development (Support Programming) - Support-Programmiertests werden von den Programmierern verwendet.

  • Um zu entscheiden, welchen Code sie schreiben müssen, um ein bestimmtes Verhalten eines Systems zu erreichen

  • Welche Tests müssen nach dem Codieren ausgeführt werden, um sicherzustellen, dass der neue Code den Rest des Verhaltens des Systems nicht beeinträchtigt?

• Verification only (Critique Product) - Kritische Produkttests werden verwendet, um Unzulänglichkeiten im fertigen Produkt festzustellen

Business Facing und Technology Facing Tests

Um zu entscheiden, welche Tests wann durchgeführt werden sollen, müssen Sie feststellen, ob ein Test -

• Business Facing oder
• Technologie-Facing

Business Facing Tests

Ein Test ist ein geschäftlicher Test, wenn er die Fragen beantwortet, die mit Wörtern aus dem Geschäftsbereich umrahmt sind. Diese werden von den Geschäftsexperten verstanden und würden sie interessieren, damit das Verhalten des Systems im Echtzeitszenario erklärt werden kann.

Technologie-Facing-Tests

Ein Test ist ein technologiebezogener Test, wenn er die Fragen beantwortet, die mit Worten aus dem Technologiebereich umrahmt sind. Die Programmierer verstehen anhand der technologischen Klarstellungen, was implementiert werden muss.

Diese beiden Aspekte von Testtypen können mithilfe der von Brian Marick definierten Agile Testing Quadrants betrachtet werden.

Agile Testquadranten

Die folgenden Agile Testing Quadrants kombinieren die beiden Aspekte der Testtypen und werden von Brian Marick abgeleitet:

Die Agile Testing Quadrants bieten eine hilfreiche Taxonomie, mit der Teams die erforderlichen Tests identifizieren, planen und ausführen können.

• Quadrant Q1- Unit Level, Technology Facing und unterstützt die Entwickler. Unit-Tests gehören zu diesem Quadranten. Diese Tests können automatisierte Tests sein.

• Quadrant Q2- Systemebene, Geschäftsausrichtung und konformes Produktverhalten. Zu diesem Quadranten gehören Funktionstests. Diese Tests sind entweder manuell oder automatisiert.

• Quadrant Q3- System- oder Benutzerakzeptanzstufe, Business Facing und Fokus auf Echtzeitszenarien. Benutzerakzeptanztests gehören zu diesem Quadranten. Diese Tests sind manuell.

• Quadrant Q4- System- oder Betriebsakzeptanzniveau, technologische Ausrichtung und Konzentration auf Leistung, Last, Stress, Wartbarkeit, Skalierbarkeitstests. Für diese Tests können spezielle Werkzeuge zusammen mit Automatisierungstests verwendet werden.

Kombinieren Sie diese, die Agile Testing Quadrants, die reflektieren What-Testing-When kann wie folgt visualisiert werden -

Scrum befürwortet Whole Team Approachin dem Sinne, dass jedes Teammitglied an jeder Projektaktivität teilnehmen muss. Das Scrum-Team organisiert sich selbst und ist für die Projektergebnisse verantwortlich. Die Entscheidungsfindung bleibt dem Team überlassen, das dazu führt, dass geeignete Maßnahmen zum richtigen Zeitpunkt ohne zeitliche Verzögerungen ergriffen werden. Dieser Ansatz fördert auch den richtigen Einsatz des Teamtalents, anstatt sich auf eine Aktivität zu beschränken. Tester nehmen auch an allen Projekt- und Entwicklungsaktivitäten teil und bringen ihr Fachwissen im Testen ein.

Das gesamte Team arbeitet gemeinsam an Teststrategie, Testplanung, Testspezifikation, Testdurchführung, Testauswertung und Berichterstattung über Testergebnisse.

Kollaborative Erstellung von User Storys

Tester nehmen an der Erstellung von User Storys teil. Tester bringen ihre Ideen zum möglichen Verhalten des Systems ein. Dies hilft dem Kunden und / oder Endbenutzer, das System in der realen Umgebung zu verstehen und somit Klarheit darüber zu erhalten, was er tatsächlich als Ergebnis haben möchte. Dies führt zu einem schnelleren Einfrieren der Anforderungen und verringert auch die Wahrscheinlichkeit späterer Änderungen der Anforderungen.

Die Tester legen außerdem die Akzeptanzkriterien für jedes vom Kunden vereinbarte Szenario fest.

Tester tragen zur Erstellung testbarer User Stories bei.

Release-Planung

Die Release-Planung erfolgt für das gesamte Projekt. Das Scrum-Framework umfasst jedoch iterative Entscheidungen, da im Laufe der Ausführung von Sprints mehr Informationen erhalten werden. Daher muss für die Release-Planungssitzung zu Beginn des Projekts kein detaillierter Release-Plan für das gesamte Projekt erstellt werden. Es kann kontinuierlich aktualisiert werden, sobald relevante Informationen verfügbar sind.

Jedes Sprint-Ende muss keine Freigabe haben. Eine Veröffentlichung kann nach einer Gruppe von Sprints erfolgen. Das Hauptkriterium einer Veröffentlichung besteht darin, dem Kunden einen Geschäftswert zu liefern. Das Team entscheidet über die Sprintlänge mit Release-Planung als Eingabe.

Die Release-Planung ist die Grundlage für den Testansatz und den Testplan für das Release. Tester schätzen den Testaufwand und planen Tests für die Veröffentlichung. Wenn sich die Release-Pläne ändern, müssen die Tester mit Änderungen umgehen und eine angemessene Testbasis unter Berücksichtigung eines größeren Release-Kontexts erhalten. Tester bieten auch Testaufwand an, der am Ende aller Sprints erforderlich ist.

Sprintplanung

Die Sprintplanung erfolgt zu Beginn jedes Sprints. Das Sprint-Backlog wird mit den User Stories erstellt, die aus dem Product Backlog zur Implementierung in diesem bestimmten Sprint übernommen wurden.

Die Tester sollten -

• Bestimmen Sie die Testbarkeit der für den Sprint ausgewählten User Stories
• Erstellen Sie Abnahmetests
• Teststufen definieren
• Identifizieren Sie die Testautomatisierung

Tester aktualisieren den Testplan mit den Schätzungen für Testaufwand und -dauer im Sprint. Dies stellt sicher, dass während der Sprints mit Zeitbox Zeit für die erforderlichen Tests zur Verfügung steht und dass der Testaufwand rechenschaftspflichtig ist.

Testanalyse

Wenn ein Sprint beginnt und die Entwickler die Story-Analyse für Design und Implementierung fortsetzen, führen die Tester eine Testanalyse für die Storys im Sprint-Backlog durch. Der Tester erstellt die erforderlichen Testfälle - sowohl manuelle als auch automatisierte Tests.

Testen

Alle Mitglieder des Scrum-Teams sollten an Tests teilnehmen.

• Die Entwickler führen die Komponententests aus, während sie Code für die User Stories entwickeln. Unit-Tests werden in jedem Sprint erstellt, bevor der Code geschrieben wird. Die Unit-Testfälle werden aus Low-Level-Designspezifikationen abgeleitet.

• Die Tester führen funktionale und nicht funktionale Merkmale der User Stories aus.

• Die Tester betreuen die anderen Mitglieder des Scrum-Teams mit ihrem Fachwissen beim Testen, sodass das gesamte Team eine kollektive Verantwortung für die Qualität des Produkts trägt.

• Am Ende des Sprints führen Kunden und / oder Endbenutzer Benutzerakzeptanztests durch und geben dem Scrum-Team Feedback. Dies bildet sich als Eingabe für den nächsten Sprint.

• Testergebnisse werden gesammelt und gepflegt.

Automatisierungstests

Automatisierungstests haben in Scrum-Teams einen hohen Stellenwert. Die Tester widmen der Erstellung, Ausführung, Überwachung und Pflege automatisierter Tests und Ergebnisse viel Zeit. Da Änderungen in Scrum-Projekten jederzeit auftreten können, müssen Tester das Testen geänderter Funktionen und auch die damit verbundenen Regressionstests berücksichtigen. Automatisierungstests erleichtern die Verwaltung des mit den Änderungen verbundenen Testaufwands. Automatisierte Tests auf allen Ebenen ermöglichen eine kontinuierliche Integration. Automatisierte Tests laufen ohne zusätzlichen Aufwand viel schneller als manuelle Tests.

Die manuellen Tests konzentrieren sich mehr auf Erkundungstests, Produktanfälligkeiten und die Vorhersage von Fehlern.

Automatisierung von Testaktivitäten

Die Automatisierung von Testaktivitäten reduziert die Belastung durch wiederholte Arbeiten und führt zu Kosteneinsparungen. Automatisieren

• Testdatengenerierung
• Laden der Testdaten
• Erstellen Sie die Bereitstellung in der Testumgebung
• Testumgebungsmanagement
• Datenausgangsvergleich

Regressionstests

In einem Sprint testen Tester den Code, der in diesem Sprint neu / geändert ist. Tester müssen jedoch auch sicherstellen, dass der in den früheren Sprints entwickelte und getestete Code auch mit dem neuen Code zusammenarbeitet. Daher wird Regressionstests beim Scrum eine wichtige Rolle eingeräumt. Automatisierte Regressionstests werden in kontinuierlicher Integration ausgeführt.

Konfigurationsmanagement

In Scrum-Projekten wird ein Konfigurationsverwaltungssystem verwendet, das automatisierte Build- und Test-Frameworks verwendet. Auf diese Weise können statische Analysen und Komponententests wiederholt ausgeführt werden, wenn neuer Code in das Konfigurationsmanagementsystem eingecheckt wird. Es verwaltet auch die kontinuierliche Integration des neuen Codes in das System. Automatische Regressionstests werden während der kontinuierlichen Integration ausgeführt.

Manuelle Testfälle, automatisierte Tests, Testdaten, Testpläne, Teststrategien und andere Testartefakte müssen versioniert sein und relevante Zugriffsberechtigungen erfordern. Dies kann erreicht werden, indem die Testartefakte im Konfigurationsmanagementsystem verwaltet werden.

Agile Testpraktiken

Tester in einem Scrum-Team können die folgenden agilen Praktiken befolgen:

• Pairing- Zwei Teammitglieder sitzen zusammen und arbeiten zusammen. Die zwei Personen können zwei Tester oder ein Tester und ein Entwickler sein.

• Incremental Test Design - Testfälle werden entwickelt, während die Sprints schrittweise fortschreiten und User Stories addiert werden.

Agile Metriken

Während der Softwareentwicklung tragen die Erfassung und Analyse von Metriken dazu bei, den Prozess zu verbessern und dadurch eine bessere Produktivität, qualitativ hochwertige Ergebnisse und Kundenzufriedenheit zu erzielen. In der Scrum-basierten Entwicklung ist dies möglich und die Tester müssen auf die Metriken achten, die sie benötigen.

Für die Scrum-Entwicklung werden mehrere Metriken vorgeschlagen. Die wesentlichen Metriken sind -

• Ratio of Successful Sprints - - (Number of successful Sprints / Total number of Sprints) * 100. Ein erfolgreicher Sprint ist einer, bei dem das Team seinem Engagement nachkommen kann.

• Velocity- Die Geschwindigkeit eines Teams basiert auf der Anzahl der Story Points, die ein Team während eines Sprints gesammelt hat. Story Points sind das Maß für die User Stories, die während der Schätzung gezählt werden.

• Focus Factor - - (Velocity / Team’s Work Capacity) / 100. Der Fokusfaktor ist der Prozentsatz der Teamleistung, der zu fertigen Geschichten führt.

• Estimation Accuracy - - (Estimated effort / Actual effort) / 100. Schätzgenauigkeit ist die Fähigkeit des Teams, den Aufwand genau abzuschätzen.

• Sprint Burndown- Arbeit (in Story Points oder in Stunden), die Vs. Arbeit, die ideal bleiben muss (gemäß Schätzung).

  • Wenn es mehr ist, bedeutet dies, dass das Team mehr Arbeit aufgenommen hat, als es tun kann.

  • Wenn es weniger ist, bedeutet dies, dass das Team nicht genau geschätzt hat.

• Defect Count- Anzahl der Fehler in einem Sprint. Die Anzahl der Fehler ist die Anzahl der Fehler in der Software gegenüber dem Rückstand.

• Severity of Defects- Fehler können je nach Schweregrad als geringfügig, schwerwiegend und kritisch eingestuft werden. Tester können die Kategorisierung definieren.

Sprint-Rückblicke

An den Sprint-Retrospektiven nehmen alle Teammitglieder teil. Sie teilen -

• Die Dinge, die gut gelaufen sind
• Metrics
• Der Spielraum für Verbesserungen
• Zu verwendende Aktionselemente

Beim agilen Testen stammen die häufig verwendeten Testmethoden aus den traditionellen Praktiken und orientieren sich am Prinzip - Früh testen. Die Testfälle werden geschrieben, bevor der Code geschrieben wird. Der Schwerpunkt liegt auf der Fehlervermeidung, -erkennung und -beseitigung, wobei die richtigen Testtypen zur richtigen Zeit und auf der richtigen Ebene ausgeführt werden.

In diesem Kapitel erhalten Sie einen Einblick in die Methoden -

• Test Driven Development (TDD)
• Akzeptanztestgesteuerte Entwicklung (ATDD)
• Verhaltensorientierte Entwicklung (BDD)

Testgetriebene Entwicklung

Bei der TDD-Methode (Test Driven Development) wird der Code auf der Grundlage des Testfirst-Ansatzes entwickelt, der von automatisierten Testfällen geleitet wird. Ein Testfall wird zuerst geschrieben, um fehlzuschlagen. Darauf aufbauend wird Code entwickelt, um sicherzustellen, dass der Test bestanden wird. Die Methode wird wiederholt, das Refactoring erfolgt durch die Entwicklung von Code.

TDD kann mit Hilfe der folgenden Schritte verstanden werden:

• Step 1 - Schreiben Sie einen Testfall, um das erwartete Verhalten der Funktionalität des zu schreibenden Codes widerzuspiegeln.

• Step 2- Führen Sie den Test aus. Der Test schlägt fehl, da der Code noch nicht entwickelt wurde.

• Step 3 - Entwickeln Sie Code basierend auf dem Testfall.

• Step 4- Führen Sie den Test erneut aus. Diesmal muss der Test bestanden werden, da die Funktionalität codiert ist. Wiederholen Sie Schritt (3) und Schritt (4), bis der Test bestanden ist.

• Step 5 - Refactor den Code.

• Step 6 - Führen Sie den Test erneut durch, um sicherzustellen, dass er erfolgreich ist.

Wiederholen Step 1 – Step 6Hinzufügen von Testfällen zum Hinzufügen von Funktionen. Die hinzugefügten Tests und die früheren Tests werden jedes Mal ausgeführt, um sicherzustellen, dass der Code wie erwartet ausgeführt wird. Um diesen Prozess zu beschleunigen, werden Tests automatisiert.

Die Tests können auf Einheiten-, Integrations- oder Systemebene durchgeführt werden. Die ständige Kommunikation zwischen Testern und Entwicklern muss gewährleistet sein.

Akzeptanztestgesteuerte Entwicklung

Bei der ATDD-Methode (Acceptance Test Driven Development) wird der Code auf der Grundlage des Test-First-Ansatzes entwickelt, der von Acceptance Test Cases gesteuert wird. Der Schwerpunkt liegt auf den Akzeptanzkriterien und den Akzeptanztestfällen, die von den Testern während der Erstellung der User Story in Zusammenarbeit mit dem Kunden, den Endbenutzern und den relevanten Stakeholdern geschrieben wurden.

• Step 1 - Schreiben Sie in Zusammenarbeit mit dem Kunden und den Benutzern Akzeptanztestfälle zusammen mit User Stories.

• Step 2 - Definieren Sie die zugehörigen Akzeptanzkriterien.

• Step 3 - Entwickeln Sie Code basierend auf den Abnahmetests und Abnahmekriterien.

• Step 4 - Führen Sie die Abnahmetests durch, um sicherzustellen, dass der Code wie erwartet ausgeführt wird.

• Step 5- Automatisieren Sie die Abnahmetests. WiederholenStep 3 – Step 5 bis alle User Stories in der Iteration implementiert sind.

• Step 6 - Automatisieren Sie die Regressionstests.

• Step 7 - Führen Sie die automatisierten Regressionstests durch, um eine kontinuierliche Regression sicherzustellen.

Verhaltensorientierte Entwicklung (BDD)

Behavior Driven Development (BDD) ähnelt der Test Driven Development (TDD), und der Schwerpunkt liegt auf dem Testen des Codes, um das erwartete Verhalten des Systems sicherzustellen.

In BDD wird eine Sprache wie Englisch verwendet, damit sie für Benutzer, Tester und Entwickler sinnvoll ist. Es sorgt dafür -

• Kontinuierliche Kommunikation zwischen Anwendern, Testern und Entwicklern.
• Transparenz darüber, was entwickelt und getestet wird.

Testtechniken aus herkömmlichen Tests können auch beim agilen Testen verwendet werden. Darüber hinaus werden in den Agile-Projekten agilspezifische Testtechniken und -terminologien verwendet.

Testbasis

In agilen Projekten ersetzt das Product Backlog die Anforderungsspezifikationsdokumente. Der Inhalt des Product Backlogs sind normalerweise User Stories. Die nicht funktionalen Anforderungen werden auch in den User Stories berücksichtigt. Die Testbasis in Agile-Projekten ist daher die User Story.

Um die Qualitätsprüfung sicherzustellen, kann zusätzlich Folgendes als Prüfgrundlage betrachtet werden:

• Erfahrungen aus früheren Iterationen desselben Projekts oder aus früheren Projekten.
• Bestehende Funktionen, Architektur, Design, Code und Qualitätsmerkmale des Systems.
• Fehlerdaten aus aktuellen und vergangenen Projekten.
• Kundenbewertung.
• Benutzerdokumentation.

Definition von Fertig

Die Definition of Done (DoD) ist das Kriterium, das in agilen Projekten verwendet wird, um den Abschluss einer Aktivität im Sprint-Backlog sicherzustellen. DoD kann von Scrum-Team zu Scrum-Team unterschiedlich sein, sollte jedoch innerhalb eines Teams konsistent sein.

DoD ist eine Checkliste der erforderlichen Aktivitäten, die die Implementierung von Funktionen und Merkmalen in einer User Story sowie die nicht funktionalen Anforderungen, die Teil der User Story sind, sicherstellen. Eine User Story erreicht das Stadium "Fertig", nachdem alle Elemente in der DoD-Checkliste ausgeführt wurden. Ein DoD wird im gesamten Team geteilt.

Ein typisches DoD für eine User Story kann Folgendes enthalten:

• Detaillierte überprüfbare Akzeptanzkriterien
• Kriterien, um die Konsistenz der User Story mit den anderen in der Iteration sicherzustellen
• Spezifische Kriterien in Bezug auf das Produkt
• Aspekte des funktionalen Verhaltens
• Nichtfunktionale Eigenschaften
• Interfaces
• Testdatenanforderungen
• Testabdeckung
• Refactoring
• Überprüfungs- und Genehmigungsanforderungen

Neben dem DoD für User Stories ist auch DoD erforderlich -

• auf jeder Teststufe
• für jedes Feature
• für jede Iteration
• zur Veröffentlichung

Testinformationen

Ein Tester muss über die folgenden Testinformationen verfügen:

• User Stories, die getestet werden müssen
• Zugehörige Akzeptanzkriterien
• Systemschnittstellen
• Umgebung, in der das System voraussichtlich funktionieren wird
• Verfügbarkeit der Tools
• Testabdeckung
• DoD

In agilen Projekten liegt es in der Verantwortung des Testers, - da das Testen keine sequentielle Aktivität ist und Tester in einem kollaborativen Modus arbeiten sollen -

• Erhalten Sie laufend die erforderlichen Testinformationen.
• Identifizieren Sie die Informationslücken, die sich auf das Testen auswirken.
• Beheben Sie die Lücken gemeinsam mit anderen Teammitgliedern.
• Entscheiden Sie, wann ein Testlevel erreicht ist.
• Stellen Sie sicher, dass geeignete Tests zu relevanten Zeiten ausgeführt werden.

Funktionelles und nicht funktionales Testdesign

In agilen Projekten können die traditionellen Testtechniken verwendet werden, der Schwerpunkt liegt jedoch auf frühen Tests. Testfälle müssen vorhanden sein, bevor die Implementierung beginnt.

Für das funktionale Testdesign können die Tester und Entwickler die traditionellen Black-Box-Testdesign-Techniken verwenden, wie z.

• Äquivalenzpartitionierung
• Grenzwertanalyse
• Entscheidungstabellen
• Zustandsübergang
• Klassenbaum

Für das nicht funktionale Testdesign können die Black-Box-Testdesign-Techniken nur zum Entwerfen der relevanten Testfälle verwendet werden, da die nicht funktionalen Anforderungen auch Teil jeder User Story sind.

Versuchsforschung

In agilen Projekten ist Zeit häufig der Begrenzungsfaktor für Testanalyse und Testdesign. In solchen Fällen können explorative Testtechniken mit den traditionellen Testtechniken kombiniert werden.

Exploratory Testing (ET) ist definiert als gleichzeitiges Lernen, Testdesign und Testdurchführung. Bei Exploratory Testing steuert der Tester aktiv das Design der durchgeführten Tests und verwendet die beim Testen gewonnenen Informationen, um neue und bessere Tests zu entwerfen.

Exploratory Testing ist praktisch, um Änderungen in agilen Projekten Rechnung zu tragen.

Risikobasiertes Testen

Risikobasierte Tests sind Tests, die auf dem Ausfallrisiko basieren und die Risiken mithilfe von Testdesign-Techniken mindern.

Ein Produktqualitätsrisiko kann als potenzielles Problem der Produktqualität definiert werden. Zu den Produktqualitätsrisiken gehören -

• Funktionsrisiken
• Nicht funktionale Leistungsrisiken
• Nicht funktionale Usability-Risiken

Eine Risikoanalyse ist durchzuführen, um die Wahrscheinlichkeit (Wahrscheinlichkeit) und die Auswirkungen jedes Risikos zu bewerten. Dann werden die Risiken priorisiert -

• Hohe Risiken erfordern umfangreiche Tests
• Geringe Risiken erfordern nur flüchtige Tests

Tests werden unter Verwendung geeigneter Testtechniken entworfen, die auf dem Risikograd und den Risikocharakteristiken jedes Risikos basieren. Anschließend werden Tests ausgeführt, um die Risiken zu minimieren.

Fit-Tests

Fit-Tests sind automatisierte Abnahmetests. Die Tools Fit und FitNesse können zur Automatisierung von Abnahmetests verwendet werden.

FIT verwendet JUnit, erweitert jedoch die Testfunktionalität. HTML-Tabellen werden verwendet, um die Testfälle anzuzeigen. Fixture ist eine Java-Klasse hinter der HTML-Tabelle. Das Fixture übernimmt den Inhalt der HTML-Tabelle und führt die Testfälle für das zu testende Projekt aus.

Der Testplan wird zum Zeitpunkt der Release-Planung erstellt und bei jeder Sprint-Planung überarbeitet. Der Testplan dient als Leitfaden für den Testprozess, um die vollständige Testabdeckung zu erhalten.

Typische Inhalte eines Testplans sind -

• Teststrategie
• Test Umgebung
• Testabdeckung
• Testumfang
• Testaufwand und Zeitplan
• Testwerkzeuge

In Agile Projects sind alle Teammitglieder für die Qualität des Produkts verantwortlich. Daher nimmt auch jeder an der Testplanung teil.

Die Verantwortung eines Testers besteht darin, die notwendige Anleitung zu geben und den Rest des Teams mit seiner Testkompetenz zu betreuen.

Benutzergeschichten

User Stories testen im Prinzip keine Arbeitsprodukte. In Agile Projects nehmen die Tester jedoch an der Erstellung von User Stories teil. Tester schreiben User Stories, die dem Kunden einen Mehrwert bringen und verschiedene mögliche Verhaltensweisen des Systems abdecken.

Tester stellen außerdem sicher, dass alle User Stories testbar sind und dass die Akzeptanzkriterien eingehalten werden.

Manuelle und automatisierte Tests

Während des ersten Testlaufs werden manuelle Tests verwendet. Dazu gehören -

• Unit Tests
• Integrationstests
• Funktionstests
• Nichtfunktionstests
• Akzeptanztests

Die Tests werden dann für nachfolgende Läufe automatisiert.

Im Test Driven Development, Unit-Tests werden zuerst geschrieben, um zu scheitern. Code wird entwickelt und getestet, um sicherzustellen, dass die Tests bestanden werden.

Im Acceptance Test Driven Development, Abnahmetests werden zuerst geschrieben, um zu scheitern. Code wird entwickelt und getestet, um sicherzustellen, dass die Tests bestanden werden.

Bei anderen Entwicklungsmethoden arbeiten die Tester mit dem Rest des Teams zusammen, um die Testabdeckung sicherzustellen.

Bei allen Arten von Methoden findet eine kontinuierliche Integration statt, einschließlich kontinuierlicher Integrationstests.

Das Team kann entscheiden, wann und welche Tests automatisiert werden sollen. Selbst wenn die Automatisierung der Tests Aufwand und Zeit erfordert, reduzieren die resultierenden automatisierten Tests den Aufwand und die Zeit für wiederholte Tests während der Iterationen des Agile-Projekts erheblich. Dies wiederum erleichtert es dem Team, den anderen erforderlichen Aktivitäten wie neuen User Stories, Änderungen usw. mehr Aufmerksamkeit zu schenken.

Im Scrumsind die Iterationen zeitlich begrenzt. Wenn ein User Story-Test in einem bestimmten Sprint nicht abgeschlossen werden kann, kann der Tester in der täglichen Standup-Besprechung melden, dass die User Story innerhalb dieses Sprints den Status "Fertig" nicht erreichen kann und daher bis zum nächsten Sprint beibehalten werden muss.

Testergebnisse

Da die meisten Tests in agilen Projekten automatisiert sind, generieren die Tools die erforderlichen Testergebnisprotokolle. Tester überprüfen die Testergebnisprotokolle. Die Testergebnisse müssen für jeden Sprint / jede Veröffentlichung beibehalten werden.

Es kann auch eine Testzusammenfassung erstellt werden, die Folgendes enthält:

• Testumfang (Was wurde getestet und was wurde nicht getestet)
• Fehleranalyse zusammen mit Ursachenanalyse, wenn möglich
• Regressionsteststatus nach Fehlerbehebungen
• Probleme und die entsprechende Lösung
• Ausstehende Probleme, falls vorhanden
• Alle in der Teststrategie erforderlichen Änderungen
• Testmetriken

Testmetrikberichte

In agilen Projekten enthalten die Testmetriken für jeden Sprint Folgendes:

• Testaufwand
• Genauigkeit der Testschätzung
• Testabdeckung
• Automatisierte Testabdeckung
• Anzahl der Mängel
• Fehlerrate (Anzahl der Fehler pro User Story Point)
• Schweregrad des Fehlers
• Zeit, um einen Fehler im selben Sprint zu beheben (Die Behebung eines Fehlers, der dem aktuellen Sprint entgeht, kostet 24-mal so viel)
• Anzahl der im selben Sprint behobenen Fehler
• Abschluss der Abnahmeprüfung durch den Kunden im Sprint

Sprint Review und retrospektive Berichte

Tester tragen auch zur Sprint-Überprüfung und zu den retrospektiven Berichten bei. Die typischen Inhalte sind -

• Testmetriken
• Testergebnisprotokolle überprüfen die Ergebnisse
• Was richtig gelaufen ist und was aus Testsicht verbessert werden kann
• Empfohlene Vorgehensweise
• gewonnene Erkenntnisse
• Issues
• Kundenbewertung

Agile Testing-Aktivitäten können mithilfe von Kanban-Konzepten effektiv verwaltet werden. Die folgenden Punkte stellen sicher, dass die Tests innerhalb einer Iteration / eines Sprints rechtzeitig abgeschlossen werden, und konzentrieren sich daher auf die Lieferung von Qualitätsprodukten.

• Testbare und effektiv dimensionierte User Stories führen zur Entwicklung und zum Testen innerhalb der angegebenen Fristen.

• Mit dem WIP-Limit (Work-In-Progress) können Sie sich auf eine begrenzte Anzahl von User Stories gleichzeitig konzentrieren.

• Das Kanban-Board, das den Workflow visuell darstellt, hilft bei der Verfolgung der Testaktivitäten und etwaiger Engpässe.

• Das Kanban-Team-Kollaborationskonzept ermöglicht die Behebung von festgestellten Engpässen ohne Wartezeit.

• Die Vorbereitung von Testfällen im Voraus, die Pflege der Testsuite während der Entwicklung und das Einholen von Kundenfeedback helfen bei der Beseitigung von Fehlern innerhalb der Iteration / des Sprints.

• Die Definition von Done (DoD) wird als Done-Done in dem Sinne bezeichnet, dass eine Story erst nach Abschluss des Tests einen Abschlusszustand erreicht.

Testaktivitäten in der Produktentwicklung

In der Produktentwicklung können die Releases mit dem Feature-Kanban-Board verfolgt werden. Features für eine bestimmte Version werden der Feature-Kanban-Karte zugewiesen, die den Feature-Entwicklungsstatus visuell verfolgt.

Die Funktionen in einer Version sind in Storys unterteilt und werden innerhalb der Version mithilfe eines agilen Ansatzes entwickelt.

Die folgenden Agile Testing-Aktivitäten stellen die Qualitätsbereitstellung in jeder Version und auch am Ende aller Versionen sicher:

• Tester nehmen an der Erstellung von User Storys teil und stellen so sicher, dass

  • Alle möglichen Verhaltensweisen des Systems werden mithilfe von User Stories und den nicht funktionalen Anforderungen erfasst, die Teil der User Stories sind.

  • User Stories sind testbar.

  • Durch die Größe der User Stories können Entwicklung und Test innerhalb der Iteration abgeschlossen (DoneDone) werden.

• Visuelle Aufgabe Kanban Board -

  • Zeigt den Status und den Fortschritt der Aufgaben an

  • Engpässe werden sofort erkannt, sobald sie auftreten

  • Erleichtert das Messen der Zykluszeit, die dann optimiert werden kann

• Team Collaboration hilft bei -

  • Rechenschaftspflicht des gesamten Teams für Qualitätsprodukte

  • Behebung von Engpässen, sobald diese auftreten, und Einsparung von Wartezeit

  • Beitrag aller Fachkenntnisse in allen Aktivitäten

• Kontinuierliche Integration, die sich auf kontinuierliche Integrationstests konzentriert

• Automatisierung von Tests, um Testaufwand und Zeit zu sparen

• Fehlervermeidung mit Testfällen, die zuvor an die Entwicklung geschrieben wurden, und Betreuung der Entwickler in Bezug auf das, was von verschiedenen Verhaltensweisen des Systems erwartet wird -

  • WIP-Limit, um sich auf eine begrenzte Anzahl von User Stories gleichzeitig zu konzentrieren

• Kontinuierliches Testen im Verlauf der Entwicklung, um Fehlerbehebungen innerhalb der Iteration sicherzustellen -

  • Stellen Sie die Testabdeckung sicher

  • Halten Sie die Anzahl offener Fehler niedrig

Story Exploration

Story Exploration ist die Kommunikation innerhalb eines agilen Teams, um das Story-Verständnis zu erkunden, wenn der Product Owner eine Story zur Annahme für die Entwicklung übergibt.

Der Product Owner erstellt die Story basierend auf der vom System erwarteten Funktionalität. Die Entwickler erforschen jede Geschichte genauer, bevor sie sie als zur Annahme bereit markieren. Tester nehmen auch aus Testperspektive an der Kommunikation teil, um sie so testbar wie möglich zu machen.

Die Fertigstellung der Story basiert auf einer ständigen und kontinuierlichen Kommunikation zwischen Product Owner, Entwicklern und Testern.

Einschätzung

Die Schätzung erfolgt in der Release-Planung und jeder Iterationsplanung.

In der Release-Planung bieten die Tester -

• Informationen darüber, welche Testaktivitäten erforderlich sind
• Aufwandsschätzung für das gleiche

Bei der Iterationsplanung tragen die Tester dazu bei, zu entscheiden, welche und wie viele Storys in eine Iteration aufgenommen werden können. Die Entscheidung hängt vom Testaufwand und der Schätzung des Testplans ab. Die Story-Schätzung spiegelt auch die Testschätzung wider.

In Kanban wird Done-Done nur ausgeführt, wenn eine Story entwickelt, getestet und als fehlerfrei markiert wurde.

Daher spielt die Testschätzung eine wichtige Rolle bei der Story-Schätzung.

Story-Planung

Die Story-Planung beginnt, nachdem eine Story geschätzt und der aktuellen Iteration zugewiesen wurde.

Die Story-Planung umfasst die folgenden Testaufgaben:

• Testdaten vorbereiten
• Akzeptanztests erweitern
• Führen Sie manuelle Tests durch
• Führen Sie explorative Tests durch
• Kontinuierliche Integrationstests automatisieren

Zusätzlich zu diesen Testaufgaben können auch andere Aufgaben erforderlich sein, wie z.

• Leistungstest
• Regressionstests
• Aktualisierungen verwandter kontinuierlicher Integrationstests

Story-Fortschritt

Story Progression deckt zusätzliche Tests auf, die aufgrund der kontinuierlichen Kommunikation zwischen Entwicklern und Testern erforderlich sind. In Situationen, in denen die Entwickler mehr Klarheit bei der Implementierung benötigen, führen die Tester Sondierungstests durch.

Kontinuierliche Tests werden während des Story-Fortschritts durchgeführt und umfassen kontinuierliche Integrationstests. Das gesamte Team nimmt an den Testaktivitäten teil.

Akzeptanz der Geschichte

Die Akzeptanz der Story erfolgt, wenn die Story den Status "Fertig" erreicht. Das heißt, die Geschichte wird entwickelt und getestet und als vollständig signalisiert.

Das Testen von Storys gilt als abgeschlossen, wenn alle für den Story-Pass oder den Grad der Testautomatisierung relevanten Tests erfüllt sind.

In agilen Projekten sind Tester für die folgenden täglichen Aufgaben verantwortlich:

• Unterstützung der Entwickler bei der Codierung mit Erläuterungen zum erwarteten Verhalten des Systems.

• Helfen Sie Entwicklern bei der Erstellung effektiver und effizienter Komponententests.

• Entwickeln Sie Automatisierungsskripte.

• Integrieren Sie Tools / Skripte für Automatisierungstests mit kontinuierlicher Integration für Regressionstests.

Für eine effektive und schnelle Implementierung dieser Aufgaben wird in den meisten Agile-Projekten ein CI-System (Continuous Integration) verwendet, das CI of Code und Testkomponenten unterstützt.

Die Tester und Entwickler in agilen Projekten können von verschiedenen Tools profitieren, um Testsitzungen zu verwalten und Fehlerberichte zu erstellen und einzureichen. Neben speziellen Tools für agile Tests können agile Teams auch von Testautomatisierungs- und Testmanagement-Tools profitieren.

Note - Record-and-Playback-, Test-Last-, Heavyweight- und Test Automation-Lösungen sind nicht agil wie -

• Der von solchen Tools empfohlene Test-Last-Workflow funktioniert nicht für agile Teams.

• Die mit solchen Tools erstellten nicht wartbaren Skripte werden zu einem Hindernis für Änderungen

• Solche Spezialwerkzeuge erfordern Testautomatisierungsspezialisten und fördern so Silos

Die Werkzeuge, die weit verbreitet sind, sind -

S.No.	Werkzeug & Zweck
1	Hudson CI Framework
2	Selenium Funktionstests - Integriert in Hudson
3	CruiseControl CI Framework
4	Junit Java Unit Test
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Java-Testabdeckung
7	Jester Java - Mutationstests / Automated Error Seeding
8	Gretel Java Test Coverage Monitoring Tool
9	TestCocoon C / C ++ oder C # - reduziert die Anzahl der Tests, indem redundante Tests gefunden und toter Code gefunden werden
10	JAZZ Java - Branch, Node und Defuse Coverage und implementiert eine GUI, Testplaner, Dynamic Instrumentation und einen Test Analyzer
11	Ant Java - Automation Build
12	Nant .Net - Automation Build
13	Bonfire Agile Testing Add-On für JIRA

Agile Test Automation Tools

Effektive Unterstützung für agile Testautomatisierungstools -

• Frühe Testautomatisierung mit einem Test-First-Ansatz.

• Schreiben von Testautomatisierungscode in realen Sprachen, domänenspezifischen Sprachen.

• Konzentration auf das erwartete Verhalten des Systems.

• Trennen Sie die Essenz des Tests von den Implementierungsdetails und machen Sie ihn so technologieunabhängig.

• Zusammenarbeit fördern.

Automatisierte Komponententests (mit Junit oder NUnit) unterstützen den Test-First-Ansatz für die Codierung. Dies sind White-Box-Tests, die sicherstellen, dass das Design einwandfrei ist und keine Mängel vorliegen. Solche Tests werden von Entwicklern mit Unterstützung von Testern erstellt und können unabhängig von der erforderlichen Funktionalität sein. Dies führt dazu, dass ein Produkt geliefert wird, das möglicherweise nicht den Kundenanforderungen entspricht und daher keinen geschäftlichen Wert hat.

Diesem Problem wird durch die Automatisierung von Abnahmetests begegnet, die in Zusammenarbeit mit Kunden, anderen Stakeholdern, Testern und Entwicklern erstellt werden. Die automatisierten Abnahmetests werden von Kunden oder Produktbesitzern / Geschäftsanalysten geschrieben und spiegeln das erwartete Verhalten des Produkts wider. Die Beteiligung der Entwickler stellt die Produktion von Code gemäß den Anforderungen sicher. Wenn sich der Test jedoch nur auf die Akzeptanz konzentriert, bleibt der resultierende Code möglicherweise nicht erweiterbar.

Daher sind automatisierte Komponententests und automatisierte Abnahmetests kostenlos und beide werden in der agilen Entwicklung benötigt.

Agile Tools und Frameworks, die automatisierte Abnahmetests unterstützen, sind:

• Fit
• Fitnesse
• Concordion
• Ruby
• Cucumber

Passen

Ward Cunningham hat das Tool Fit entwickelt, das für die Automatisierung von Abnahmetests verwendet werden kann. Passform ermöglicht -

• Kunden oder Produktbesitzer geben Beispiele für das Produktverhalten mit Microsoft Word und Microsoft Excel

• Programmierer können diese Beispiele einfach in automatisierte Tests umwandeln.

Fit 1.1 unterstützt sowohl Java als auch .NET.

FitNesse

FitNesse ist ein Wiki, ein Webserver-Stil, mit dem jeder Besucher Änderungen vornehmen kann, einschließlich des Änderns vorhandener Seiten und des Erstellens neuer Seiten. Mit einer einfachen Auszeichnungssprache können Sie auf einfache Weise Überschriften erstellen, Text fett, unterstrichen und kursiv gestalten, Listen mit Aufzählungszeichen erstellen und andere einfache Formatierungen vornehmen.

In FitNesse lautet die Automatisierung von Abnahmetests wie folgt:

• Express-Tests als Tabellen mit Eingabedaten und erwarteten Ausgabedaten.

• Verwenden Sie FitNesse, um die Testtabelle auf der Seite zu platzieren, die Sie bearbeiten können.

  • Alternativ können Sie die Testtabelle in Microsoft Excel ablegen, in die Zwischenablage kopieren und dann die verwenden Spreadsheet to FitNesse Befehl, damit FitNesse Ihre Tabelle richtig formatiert

• Führen Sie den Test aus

• Sie erhalten die Testergebnisse durch Farbcodierung der Zellen in der Testtabelle

  • Grüne Zellen zeigen an, dass die erwarteten Werte erhalten werden

  • rote Blutkörperchen bedeuten, dass ein anderer Wert als erwartet erhalten wird

  • Gelbe Zellen zeigen an, dass eine Ausnahme ausgelöst wurde

Gurke

Cucumber ist ein Tool, das auf dem BDD-Framework (Behavior Driven Development) basiert. Die Hauptmerkmale sind -

• Wird zum Schreiben von Abnahmetests für Webanwendungen verwendet.

• Ermöglicht die Automatisierung der Funktionsvalidierung in einem leicht lesbaren und verständlichen Format wie einfachem Englisch.

• Wurde in Ruby implementiert und dann auf das Java-Framework erweitert. Beide unterstützen Junit.

• Unterstützt andere Sprachen wie Perl, PHP, Python, .Net usw.

• Kann zusammen mit Selen, Watir, Capybara usw. verwendet werden.