Agiles Testen - Scrum
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 die Release-Planungssitzung zu Beginn des Projekts keinen detaillierten Release-Plan für das gesamte Projekt erstellen. 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 Freigabe 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 im 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, Qualitätsergebnisse 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