Agile Methodik beim Softwaretesten

Agile Methodologie

Was ist eine agile Methodik beim Testen?

Agile Methodologie bedeutet eine Praxis, die promoTES kontinuierliche Iteration der Entwicklung und des Testens während des gesamten Softwareentwicklungslebenszyklus des Projekts. Im agilen Modell beim Softwaretesten laufen im Gegensatz zum Wasserfallmodell sowohl Entwicklungs- als auch Testaktivitäten gleichzeitig ab.

Agile Methodologie
Agile Methodologie

Was ist agile Softwareentwicklung?

Das Agile Software Entwicklung Die Methodik ist einer der einfachsten und effektivsten Prozesse, um eine Vision für einen Geschäftsbedarf in Softwarelösungen umzusetzen. Agil ist ein Begriff, der verwendet wird, um Softwareentwicklungsansätze zu beschreiben, die kontinuierliche Planung, Lernen, Verbesserung, Teamzusammenarbeit, evolutionäre Entwicklung und frühe Bereitstellung beinhalten. Es fördert flexible Reaktionen auf Veränderungen.

Die agile Softwareentwicklung legt Wert auf vier Grundwerte.

  1. Individuelle und Teaminteraktionen über Prozesse und Tools
  2. Arbeitssoftware über umfassende Dokumentation
  3. Kundenzusammenarbeit über Vertragsverhandlungen
  4. Reagieren Sie auf die Änderung über Following ein Plan

Agiles Modell vs. Wasserfallmodell

Agile- und Wasserfallmodell sind zwei verschiedene Methoden für den Softwareentwicklungsprozess. Obwohl sie sich in ihrer Herangehensweise unterscheiden, sind beide Methoden manchmal nützlich, je nach Anforderung und Art des Projekts.

Agiles Modell Wasserfall-Modell
Agile Methodik bei der Definition von Softwaretests: Agile Methodologien schlagen einen inkrementellen und iterativen Ansatz für das Software-Design vor Wasserfallmodell: Die Entwicklung der Software verläuft sequentiell vom Startpunkt zum Endpunkt.
Das Agiler Prozess Beim Softwaretest wird es in einzelne Modelle unterteilt, an denen Designer arbeiten Der Designprozess ist nicht in einzelne Modelle unterteilt
Der Kunde hat frühzeitig und häufig Gelegenheit, sich das Produkt anzusehen und Entscheidungen und Änderungen am Projekt zu treffen Der Kunde kann das Produkt erst am Ende des Projekts sehen
Das agile Testmodell gilt im Vergleich zum Wasserfallmodell als unstrukturiert Wasserfallmodelle sind sicherer, weil sie so planorientiert sind
Kleine Projekte können sehr schnell umgesetzt werden. Bei großen Projekten ist es schwierig, die Entwicklungszeit abzuschätzen. Alle Arten von Projekten können geschätzt und abgeschlossen werden.
Fehler können mitten im Projekt behoben werden. Erst am Ende wird das gesamte Produkt getestet. Wenn der Anforderungsfehler gefunden wird oder Änderungen vorgenommen werden müssen, muss das Projekt von vorne beginnen
Der Entwicklungsprozess ist iterativ und das Projekt wird in kurzen Iterationen (2–4 Wochen) ausgeführt. Die Planung ist sehr gering. Der Entwicklungsprozess ist phasenweise und die Phase ist viel größer als die Iteration. Jede Phase endet mit der detaillierten Beschreibung der nächsten Phase.
Die Dokumentation hat eine geringere Priorität als Software-Entwicklung Die Dokumentation hat oberste Priorität und kann sogar für die Schulung des Personals verwendet werden upgrade die Software mit einem anderen Team
Jede Iteration hat ihre eigene Testphase. Es ermöglicht die Implementierung von Regressionstests jedes Mal, wenn neue Funktionen oder Logik veröffentlicht werden. Erst nach der Entwicklungsphase wird die Testphase durchgeführt, da einzelne Teile nicht voll funktionsfähig sind.
Bei agilen Tests werden am Ende einer Iteration die lieferbaren Funktionen des Produkts an den Kunden geliefert. Neue Funktionen sind direkt nach der Auslieferung nutzbar. Es ist nützlich, wenn Sie guten Kontakt zu Kunden haben. Alle entwickelten Features werden nach der langen Implementierungsphase sofort ausgeliefert.
Tester und Entwickler arbeiten zusammen Tester arbeiten getrennt von Entwicklern
Am Ende jedes sprint, wird die Benutzerakzeptanz durchgeführt Die Benutzerakzeptanz ist durchgeführt am Ende des Projekts.
Es erfordert eine enge Kommunikation mit den Entwicklern und die gemeinsame Analyse von Anforderungen und Planung Der Entwickler ist nicht am Anforderungs- und Planungsprozess beteiligt. Normalerweise gibt es Zeitverzögerungen zwischen Tests und Codierung

Überprüfen Sie auch: - Agil vs. Wasserfall: Kennen Sie den Unterschied zwischen Methoden

Agiler Prozess

Überprüfen Sie das Folgende Agile Methodik Prozess zur schnellen Bereitstellung erfolgreicher Systeme.

Agiles Prozessmodell
Agiles Prozessmodell

Es gibt verschiedene Agile Methoden in agilen Tests vorhanden sind, und diese sind unten aufgeführt:

Scrum

SCRUM ist eine agile Entwicklungsmethode, die sich speziell auf die Verwaltung von Aufgaben in einer teambasierten Entwicklungsumgebung konzentriert. Grundsätzlich leitet sich Scrum von Aktivitäten ab, die während eines Rugbyspiels stattfinden. Scrum glaubt an die Stärkung des Entwicklungsteams und befürwortet die Arbeit in kleinen Teams (z. B. 7 bis 9 Mitglieder). Agile und Scrum bestehen aus drei Rollen, deren Verantwortlichkeiten wie folgt erläutert werden:

Scrum-Methode
Scrum-Methode
  • Scrum Master
    • Scrum Master ist verantwortlich für den Teamaufbau, sprint Treffen und beseitigt Hindernisse für den Fortschritt
  • Produkteigentümer
    • Der Product Owner erstellt ein Produkt-Backlog, priorisiert das Backlog und ist für die Bereitstellung der Funktionalität bei jeder Iteration verantwortlich
  • Scrum-Team
    • Das Team verwaltet seine eigene Arbeit und organisiert die Arbeit zur Fertigstellung sprint oder radeln

Produkt Rückstand

Dies ist ein Repository, in dem Anforderungen mit de verfolgt werdentails über die Anzahl der Anforderungen (User Stories), die für jede Veröffentlichung erfüllt werden müssen. Es sollte vom Product Owner gepflegt und priorisiert werden und an das Scrum-Team verteilt werden. Das Team kann auch die Hinzufügung, Änderung oder Löschung einer neuen Anforderung beantragen

Scrum-Praktiken

Die Praktiken werden ausführlich beschrieben:

Scrum-Praktiken
Scrum-Praktiken

Prozessablauf der Scrum-Methoden:

Prozessablauf von Scrum-Tests ist wie folgt:

  • Jede Iteration eines Scrums wird als bezeichnet Sprint
  • Das Product Backlog ist eine Liste, in der alle details werden eingegeben, um das Endprodukt zu erhalten
  • Während jeder Sprint, Top-User-Stories des Product Backlogs werden ausgewählt und umgewandelt Sprint Rückstand
  • Das Team arbeitet am Definierten sprint Rückstand
  • Das Team überprüft die tägliche Arbeit
  • Am Ende der sprint, Team liefert Produktfunktionalität

Extreme Programmierung (XP)

Die Extreme Programming-Technik ist sehr hilfreich, wenn sich die Anforderungen oder Anforderungen der Kunden ständig ändern oder wenn sie sich über die Funktionalität des Systems nicht sicher sind. Es befürwortet häufige „Releases“ des Produkts in kurzen Entwicklungszyklen, was die Produktivität des Systems grundsätzlich verbessert und außerdem einen Kontrollpunkt einführt, an dem alle Kundenanforderungen einfach umgesetzt werden können. Das XP entwickelt Software, die den Kunden im Ziel hält.

Extremes Programmieren
Extremes Programmieren

Geschäftsanforderungen werden in Form von Geschichten erfasst. Alle diese Geschichten werden an einem Ort namens Parkplatz gespeichert.

Bei dieser Art von Methodik basieren Releases auf kürzeren Zyklen, sogenannten Iterationen, mit einer Zeitspanne von 14 Tagen. Jede Iteration umfasst Phasen wie Codierung, Unit-Tests und Systemtests, in denen in jeder Phase einige kleinere oder größere Funktionen in die Anwendung integriert werden.

Phasen der eXtreme-Programmierung:

In der Agile XP-Methode stehen 6 Phasen zur Verfügung, die wie folgt erklärt werden:

Planung

  • Identifizierung von Stakeholdern und Sponsoren
  • Anforderungen an die Infrastruktur
  • Sicherheit entsprechende Informationen und Sammeln
  • Service Level Agreements und ihre Bedingungen

Analyse

  • Erfassen von Geschichten auf dem Parkplatz
  • Priorisieren Sie Geschichten auf dem Parkplatz
  • Bereinigen von Geschichten zur Schätzung
  • Definieren Sie die Iterationsspanne (Zeit)
  • Ressourcenplanung für Entwicklungs- und QA-Teams

Design

  • Aufschlüsselung der Aufgaben
  • Vorbereitung des Testszenarios für jede Aufgabe
  • Regressionsautomatisierungs-Framework

ausführung

  • Programmierung
  • Durchführung manueller Testszenarien
  • Erstellung von Fehlerberichten
  • Konvertierung von manuellen in automatisierte Regressionstestfälle
  • Rezension zur Mitte der Iteration
  • Überprüfung des Endes der Iteration

Verpackung

  • Kleine Veröffentlichungen
  • Demos und Rezensionen
  • Entwickeln Sie je nach Bedarf neue Geschichten
  • Prozessverbesserungen basierend auf Kommentaren zur Überprüfung am Ende der Iteration

Schließung

  • Pilotstart
  • Ausbildung
  • Produktionsstart
  • SLA-Garantiezusicherung
  • Überprüfen Sie die SOA-Strategie
  • Produktionshilfe

Um die Arbeit täglich zu verfolgen, stehen zwei Storyboards zur Verfügung, die unten als Referenz aufgeführt sind.

  • Geschichtenkarton
    • Dies ist eine traditionelle Methode, alle Geschichten in Form von Haftnotizen auf einer Tafel zu sammeln, um die täglichen XP-Aktivitäten zu verfolgen. Da diese manuelle Tätigkeit mit mehr Aufwand und Zeit verbunden ist, ist es besser, auf ein Online-Formular auszuweichen.
  • Online-Storyboard
    • Zur Speicherung der Geschichten kann das Online-Tool Storyboard genutzt werden. Mehrere Teams können es nutzen für verschiedene Zwecke.

Kristallmethoden

Die Kristallmethodik basiert auf drei concepts

  1. Chartern: Zu den verschiedenen Aktivitäten dieser Phase gehören die Zusammenstellung eines Entwicklungsteams, die Durchführung einer vorläufigen Machbarkeitsanalyse, die Entwicklung eines ersten Plans und die Feinabstimmung der Entwicklungsmethodik
  2. Zyklische Lieferung: Die Hauptentwicklungsphase besteht aus zwei oder mehr Lieferzyklen, in denen die
    1. Das Team aktualisiert und verfeinert den Release-Plan
    2. Implementiert eine Teilmenge der Anforderungen durch eine oder mehrere Programmtest-Integrationsiterationen
    3. Das integrierte Produkt wird an echte Benutzer geliefert
    4. Überprüfung des Projektplans und der übernommenen Entwicklungsmethodik
  3. Einpacken: Die in dieser Phase durchgeführten Aktivitäten umfassen die Bereitstellung in der Benutzerumgebung sowie die Durchführung von Überprüfungen und Überlegungen nach der Bereitstellung.

Dynamische Softwareentwicklungsmethode (DSDM)

DSDM ist ein Schnelle Anwendungsentwicklung (RAD)-Ansatz für die Softwareentwicklung und bietet einen agilen Rahmen für die Projektabwicklung. Der wichtige Aspekt von DSDM besteht darin, dass die Benutzer aktiv einbezogen werden müssen und den Teams die Entscheidungsbefugnis gegeben wird. Mit DSDM wird die regelmäßige Lieferung von Produkten zum aktiven Fokus. Die in DSDM verwendeten Techniken sind

  1. Uhrzeit BoxIng.
  2. MoSCoW-Regeln
  3. Prototyping

Das DSDM-Projekt besteht aus 7 Phasen

  1. Vorprojekt
  2. Machbarkeitsstudie
  3. Wirtschaftsstudie
  4. Funktionsmodelliteration
  5. Entwerfen und erstellen Sie Iterationen
  6. Sytemimplementierung
  7. Nachprojekt

Funktionsorientierte Entwicklung (FDD)

Diese Methode konzentriert sich auf das „Entwerfen und Erstellen“ von Funktionen. Im Gegensatz zu anderen agilen Methoden in der Softwareentwicklung beschreibt FDD sehr spezifische und kurze Arbeitsphasen, die pro Feature separat durchgeführt werden müssen. Es umfasst Domänen-Komplettlösungen, Design-Inspektion, promoTe zum Erstellen, Code-Inspektion und Design. FDD entwickelt Produktaufbewahrungsfollowing Dinge im Ziel

  1. Domänenobjektmodellierung
  2. Entwicklung nach Merkmal
  3. Komponenten-/Klassenbesitz
  4. Feature-Teams
  5. Inspektionen
  6. Configuration Management
  7. Regelmäßige Builds
  8. Sichtbarkeit von Fortschritten und Ergebnissen

Lean Software-Entwicklung

Die Lean-Software-Entwicklungsmethode basiert auf dem Prinzip „Just-in-Time-Produktion“. Ziel ist es, die Geschwindigkeit der Softwareentwicklung zu erhöhen und die Kosten zu senken. Lean Development kann summarisch seinmarierfolgt in sieben Schritten.

  1. Abfall vermeiden
  2. Lernen verstärken
  3. Verpflichtung aufschieben (so spät wie möglich entscheiden)
  4. Frühe Lieferung
  5. Das Team stärken
  6. Integrität aufbauen
  7. Das Ganze optimieren

Kanban

Kanban entstand ursprünglich aus dem Japanischen und bedeutet eine Karte, die alle Informationen enthält, die in jeder Phase auf dem Weg zur Fertigstellung des Produkts erforderlich sind. Dieses Framework oder diese Methode wird in der Softwaretestmethode, insbesondere in Agile, häufig übernommen concepts.

Scrum vs. Kanban

Scrum Kanban
Bei der Scrum-Technik müssen Tests so unterteilt werden, dass sie innerhalb eines Tests abgeschlossen werden können sprint Es ist keine bestimmte Artikelgröße vorgeschrieben
Schreibt ein priorisiertes Produkt-Backlog vor Die Priorisierung ist optional
Das Scrum-Team verpflichtet sich zu einem bestimmten Arbeitsaufwand für die Iteration Engagement ist optional
Es ist ein Burndown-Diagramm vorgeschrieben Es ist keine bestimmte Artikelgröße vorgeschrieben
Zwischen jedem sprint, ein Scrum Board wird zurückgesetzt Ein Kanban-Board ist beständig. Es begrenzt die Anzahl der Elemente im Workflow-Status
Es können keine Elemente zur laufenden Iteration hinzugefügt werden Es können Elemente hinzugefügt werden, wann immer Kapazität verfügbar ist
WIP indirekt begrenzt WIP direkt begrenzt
Uhrzeitboxed-Iterationen vorgeschrieben Uhrzeitboxed-Iterationen optional

Überprüfen Sie auch: - Kanban vs. Scrum: Was ist der Unterschied?

Agile-Metriken

Folgende Kennzahlen können für eine effektive Nutzung von Agile erfasst werden:

  • Widerstandsfaktor
    • Anstrengung in hours die nicht dazu beitragen sprint Kundenziele
    • Der Widerstandsfaktor kann verbessert werden, indem die Anzahl der gemeinsam genutzten Ressourcen reduziert und so die Menge der nicht beitragenden Arbeit reduziert wird
    • Neue Schätzungen können um den Prozentsatz des Luftwiderstandsfaktors erhöht werden – Neue Schätzung = (Alte Schätzung + Luftwiderstandsfaktor)
  • Geschwindigkeit
    • Menge des Backlogs (User Stories), konvertiert in auslieferbare Funktionalität von sprint
  • Anzahl der hinzugefügten Unit-Tests
  • Zeitintervall, das zum Abschließen des täglichen Builds benötigt wird
  • In einer Iteration oder in früheren Iterationen erkannte Fehler
  • Leckage aufgrund von Produktionsfehlern