Agiles Testen vs. ISTQB? Teil 2

In diesem zweiteiligen Artikel stelle ich agile Softwareentwicklung und die darin enthaltende agile Testmethodik mit ihren Vorteilen und Nachteilen dar und vergleiche diese anschließend mit den Forderungen aus dem ISTQB-Standard.

Vergleich mit dem ISTQB

Wie man aus den Erläuterungen zum agilen Test Manifest und dem agilen Testen entnehmen kann, erfolgt hier ein grundlegender Paradigmenwechsel beim Testmanagement. Der fundamentale Testprozess wird in seiner starren Form bestehend aus Testplanung und Steuerung, Testanalyse und Testentwurf, Testrealisierung und Testdurchführung, Bewertung von Endekriterien und Bericht, Abschluss der Testaktivitäten aufgebrochen. Dies ist für einen ISTQB

Certified Tester ein teilweiser Paradigmenwechsel, da er grundsätzlich sehr viel Überlegungen zum Testmanagement (insbes. zum Testkonzept nach IEEE 829) anstellt. Damit geht die Gefahr einher, dass wichtige Metriken wie die Testabdeckung nicht mehr ermittelt werden können. Auch der Nachweis der Testaktivitäten ist schwieriger aufgrund des explorativen Ansatzes.
Die verschiedenen Testentwurfstechniken aus dem ISTQB aus dem Bereich Whiteboxtest und Blackboxtest werden hingegen weiterverwendet. Die hohe Testautomatisierung trägt dazu bei, dass trotz der geringen Testzeit während eines Sprints immer sichergestellt ist, dass die bestehenden Funktionalität stabil bleiben (Regressionstests). Die explorativen Tests verfeinern die eher gröberen automatisierten Tests. Wichtig ist die ständige Kommunikation im Testteam und eingespielte Prozesse. Die reduzierte Testdokumentation steht im Widerspruch zu dem, was das ISTQB fordert. Dies kann ausgeglichen werden durch automatisierte Tests mit einer geeigneten Testprotokollierung. Das Testergebnis ist weniger eine formale, vertragsrelevante Fehlerliste jedoch eine Liste mit potenziellen Optimierungen, sogenannten Issues. Der Kunde entscheidet bzgl. deren Umsetzung.

Vorteile

  • Ansprechpartner (Product Owner) vor Ort
  • Offene Fragen und kleine Änderungen können zu dem Zeitpunkt erledigt werden, an dem der Entwickler noch das jeweilige Modul programmiert.
  • keine langen Meetings für die Softwarefreigabe
  • keine starren und unflexiblen Strukturen

Nachteile

  • vollständiger Systemtest erst am Ende möglich (wg. Sprints, d.h. Interationen), je nach Integrationsstrategie sind die Integrationstest nicht beeinflusst (z.B. Ad hoc Ansatz)
  • agile Entwicklung bedeutet, dass die Testbasis (Abnahmekriterien) für System- und Abnahmetest erst gegen Ende vollständig steht
  • übergreifenden System- und Integrationstests weiterhin erforderlich
  • Testmanager ist nicht mehr Koordinator sondern für alle Testaufgaben zuständig
  • systematische Aspekte des Testmanagements werden leicht vergessen
 Ich freue mich, wenn Ihnen der Artikel geholfen hat, sich als ISTQB certified tester mit dem agilen Testansatz zu beschäftigen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert