Aktivität: Build-Stabilität prüfen
Diese Aktivität stellt sicher, dass der Build so stabil ist, dass mit detaillierten Tests und Bewertungen begonnen werden kann.
Erweiterung: Build-Stabilität prüfen
BeschreibungProjektstrukturplanTeamzuordnungVerwendung der Arbeitsergebnisse
Beziehungen
Übergeordnete Aktivitäten
Beschreibung

Bei jedem Build konzentriert sich diese Arbeit auf folgende Punkte:

  • Die Stabilität und Testfähigkeit des Builds beurteilen.
  • Sich einen Überblick über die im Build bereitgestellte Entwicklungsarbeit verschaffen oder nach Bestätigung entsprechender Erwartungen suchen.
  • Entscheiden, ob der Build laut Bewertungsauftrag für weitere Tests verwendet werden kann oder weitere Tests mit einem älteren Build durchgeführt werden sollen.

Diese Arbeit wird auch als Smoke-Test, Build-Prüftest, Build-Regressionstest, Vitalitätsprüfung oder Abnahme für Test bezeichnet. Mit dieser Arbeit kann verhindert werden, dass Testressourcen für sinnlose und fruchtlose Tests verschwendet werden.

Eigenschaften
Ereignisgesteuert
Mehrere Vorkommen
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Mitarbeiterauswahl

Diese Arbeit wird primär von den Rollen Tester und Testanalytiker ausgeführt. Zu den wichtigsten Voraussetzungen für diese Arbeit gehören die rechtzeitige Bereitstellung von Ergebnissen, Gründlichkeit und gutes Urteilsvermögen bei der Bewertung der Eignung des Builds für weitere Tests.

Es empfiehlt sich, eine eigenständige Gruppe innerhalb des Testteams mit dieser Aufgabe zu betrauen. Die anderen Teammitglieder ignorieren den neuen Build, bis er als stabil validiert ist, und konzentrieren sich stattdessen darauf, weitere Tests mit dem Build aus dem vorherigen Testzyklus durchzuführen oder Test-Assets nach Bedarf zu verbessern. Weitere Informationen finden Sie auf der Seite Aktivität: Test-Assets verbessern.

Als heuristische Werte für die relative Ressourcenzuordnung nach Phase kann man hinsichtlich der Verwendung von Testressourcen für diese Aktivität folgende Prozentsätze annehmen: Konzeption - 0 %, Ausarbeitung - 5 %, Konstruktion - 10 % und Übergang - 10 %. Beachten Sie, dass in der Konzeptionsphase normalerweise kein formaler Build erstellt wird.

Der Entwicklungsstand und die Verfügbarkeit von Testautomatisierungstools sowie das erforderliche Know-how ihre Verwendung betreffend haben Auswirkungen auf die Ressourcenbeschaffung für diese Arbeit. Bei Verwendung von Automatisierungstools kann ein Großteil dieser Arbeit schnell und effizient ausgeführt werden, ohne Automatisierung ist wesentlich mehr Aufwand erforderlich.

Verwendung
Anleitung zur Verwendung

Diese Arbeit wird möglicherweise einmal pro Build ausgeführt. Gewöhnlich wird jedoch nicht jeder Build getestet. Sobald der Build als ausreichend stabil befunden wird, verlagert sich der Schwerpunkt auf die Aktivität Testen und auswerten. Wenn festgestellt wird, dass der Build sich nicht für weitere Tests eignet, beginnt die Aktivität "Testen und Auswerten" gewöhnlich von vorn mit einem vorherigen stabilen Build.

Obwohl die Größe des Entwicklungsaufwands eine gewisse Rolle spielt, empfehlen wir, bestimmte Teile dieser Aktivität zu automatisieren. Automatisierte Elemente solcher "Smoke-Tests" werden gewöhnlich unbeaufsichtigt in "Stillstandzeiten", z. B. über Mittag oder über Nacht ausgeführt.

Zusätzlich zu automatisierten Smoke-Tests sollten Sie eine minimale Menge von Tests für neue oder erheblich geänderte Softwarekomponenten ausführen.

Weitere Informationen