Software wird in Iterationen während des Lebenszyklus der RUP-Softwareentwicklung verfeinert. Der Testlebenszyklus
profitiert davon, dass er in dieser Prozessumgebung einem iterativen Ansatz folgt. In jeder Iteration produziert das
Softwareentwicklungsteam einen oder mehrere Builds, wobei jeder Build ein potenzieller Testkandidat ist.
Der Fokus und die Ziel des Entwicklungsteams variieren von Iteration zu Iteration. Daher müssen die Teammitglieder
ihren Testaufwand entsprechend strukturieren. Es wird empfohlen, das Testdesign und die Testplanung auf ein Mindestmaß
zu reduzieren. Der zeitliche Abstand zwischen Design- und Planungsaktivitäten und der Realisierung sollte so kurz wie
möglich sein. Außerdem wird empfohlen, einen Test frühestens eine Iteration vor der geplanten Durchführung detailliert
zu entwickeln.
Zusätze, Verfeinerungen und Löschungen werden für die Tests vorgenommen, die für jeden einzelnen Build implementiert
und durchgeführt werden. Einige dieser Tests werden zurückgehalten und zu Testeinheiten zusammengeführt, die für
Regressionstests der nachfolgenden Builds in den künftigen Testzyklen verwendet werden. Bei diesem Ansatz werden die
Tests während des ganzen Prozesses nachgearbeitet und überarbeitet, so wie die Software selbst. Es gibt keine
unveränderlichen Softwarespezifikationen und keine unveränderlichen Tests. Das folgende Diagramm veranschaulicht, wie
Tests sich im Laufe der Zeit weiterentwickeln.
Der iterative Ansatz, verbunden mit der Verwendung von Komponentenarchitekturen, erfordert, dass sie bei allen
nachfolgenden Builds Regressionstests in Erwägung ziehen. Alle in Iteration X entwickelten Tests sind potenzielle
Kandidaten für den Regressionstest in Iteration X+1, Iteration X+2 usw. Wenn derselbe Test wahrscheinlich mehrmals
wiederholt werden muss, lohnt es sich, über seine Automatisierung nachzudenken. Die Testautomatisierung ermöglicht das
wiederholte Testen von Einsatzszenarios, so dass Tester genügend freie Ressourcen haben, um Tests in neuen
Funktionsbereichen zu erproben.
Prüfen Sie den Lebenszyklus der Tests, ohne das restliche Projekt zu berücksichtigen. Die folgende Abbildung zeigt die
Aufteilung der Arbeitsdetails für die Disziplin "Testen" in einer bestimmten Iteration.
Der Lebenszyklus richtet sich am Iterationszyklus aus, dem das restliche Entwicklungsteam folgt. Die Iteration beginnt
mit einer Untersuchung durch das Testteam, das mit dem Projektleiter und anderen Stakeholdern darüber verhandelt,
welche Tests in der nächsten Iteration am sinnvollsten wären. Die meisten Mitglieder des Testteams sind an diesem
Vorgang beteiligt.
Normalerweise enthält jede Iteration zumindest einen Testzyklus, wie in der nächsten Abbildung dargestellt.
Normalerweise werden mehrere Builds für jede Iteration erstellt, und jedem Build wird ein Testzyklus zugeordnet. In
einigen Fällen werden bestimmte Builds jedoch nicht getestet.
Ausgehend von einem Kerntest kann eine Untergruppe der Teammitglieder neue Testtechniken untersuchen. Mit dieser
Vorgehensweise soll versucht werden, zu beweisen, dass die entwickelten Techniken funktionieren und das Team sich auf
sie verlassen kann, insbesondere in nachfolgenden Iterationen.
Der Testlebenszyklus ist Teil des Softwarelebenszyklus, beide Zyklen sollten in einem äquivalenten Zeitrahmen gestartet
werden. Der Design- und Entwicklungsprozess für Tests kann ebenso komplex und beschwerlich sein wie der Prozess zur
Entwicklung des Softwareprodukts selbst. Wenn Tests nicht im Einklang mit den ersten ausführbaren Softwarereleases
gestartet werden, führt die Testverzögerung dazu, dass zu viele Probleme erst spät im Entwicklungszyklus erkannt
werden. Das hat zur Folge, dass viel Zeit für die Fehlerbehebung an das Ende der Entwicklungsphase angehängt werden
muss. Die gesteckten Ziele werden dann nicht erreicht, und die Vorteile der iterativen Entwicklung entfallen.
Wenn Sie Tests zu früh planen und definieren, kann dies schwere Fehler in den ersten Spezifikationen zur Folge haben.
Dennoch wird empfohlen, die Tests, die durchgeführt werden sollen, vorab sorgfältig auszuwählen. Der potenzielle
Aufwand für die Nacharbeitung wurde bereits erwähnt. Das Testteam muss darauf bedacht sein, seine Rolle als
unparteiischer Ratgeber in Sachen Qualität aufrechtzuerhalten und nicht schon bei den ersten Anforderungen und
Designaufgaben als "Qualitätspolizei" aufzutreten. Wenn das geschieht, nimmt die Motivation des Projektteams, das
Problem und die Lösungsschritte zu verstehen, schon zu Beginn Schaden. Wenn in diesem frühen Stadium unangemessene
Forderungen hinsichtlich der Arbeitsqualität gestellt werden, läuft das Testteam Gefahr, dass die übrige
Entwicklungsgruppe sich ihm entfremdet.
Probleme, die während einer Iteration gefunden werden, können in derselben Iteration gelöst oder bis zur nächsten
Iteration verschoben werden. Diese Entscheidung bleibt letztlich der Rolle des Projektleiters vorbehalten. Eine der
wichtigsten Aufgaben für das Testteam und die Projektleiter besteht darin, festzustellen, wie vollständig die Iteration
ist, d. h., zu überprüfen, ob die Iterationsziele laut Iterationsplan erreicht wurden. Mit jeder neuen Iteration können
neue Anforderungen ermittelt werden. Dessen müssen Sie sich bewusst und darauf müssen Sie vorbereitet sein.
Die Testausführung ist von verschiedenen Faktoren abhängig:
-
Ihrer Anwendungsdomäne
-
Ihrem Budget
-
Ihrer Geschäftspolitik
-
Ihrer Risikotoleranz
-
Ihren Mitarbeitern.
Wie viel Sie in Tests investieren, hängt davon ab, wie Sie Qualität bewerten und Risiken in Ihrer besonderen Umgebung
tolerieren.
|