Aufgabe: Zusage zur Testfähigkeit anfordern
Diese Aufgabe konzentriert sich darauf, die Testfähigkeitsanforderungen und deren Vorteile zu definieren, nach Priorität zu ordnen und für sie zu werben.
Disziplinen: Test
Zweck

Diese Aufgabe hat folgenden Zweck:

  • Für die Erstellung testfähiger Software, die die testbezogenen Bedürfnisse unterstützt, werben
  • Die Verwendung geeigneter Automatisierungstechniken und -tools unterstützen und für sie werben.
Beziehungen
Schritte
Testanforderungen untersuchen
Zweck:  Sich mit den Bedürfnissen hinsichtlich der Testimplementierung und -bewertung, die durch den Softwarefertigungsprozess oder die Softwarearchitektur und das Softwaredesign erfüllt werden sollen, vertraut machen. 

Untersuchen Sie die Architektur der Testautomatisierung, um sich mit den Bedürfnissen hinsichtlich der Testimplementierung und -bewertung vertraut zu machen. Besonders wichtig ist es, die Einschränkungen zu verstehen, die diese Bedürfnisse für den Softwarefertigungsprozess oder die Softwarearchitektur und das Softwaredesign mit sich bringen.

Auswirkungen bewerten und nach Priorität ordnen
Zweck:  Die für den Test wichtigsten Testfähigkeitsanforderungen identifizieren und deren Erfüllung vor weniger wichtigen Anforderungen ansetzen.  

Untersuchen Sie die Testfähigkeitsanforderungen, und führen Sie eine grundlegende Wirkungsanalyse hinsichtlich der Auswirkungen auf den Test durch, wenn das Bedürfnis nicht erfüllt werden konnte. Ziehen Sie auch in Erwägung, eine Basisanalyse des potenziellen Aufwands, den das Entwicklungsteam betreiben muss, durchzuführen, um eine Lösung für den Bedarf zu ermitteln und bereitzustellen. Geben Sie für jeden Bedarf potenzielle alternative Lösungen an, die sich weniger stark auf die Entwicklungsteams auswirken.

Formulieren Sie mit diesen Informationen eine nach Prioritäten geordnete Liste, in der die Bedürfnisse, die bei Nichterfüllen eine große Auswirkung auf den Test haben und zu denen es keine Alternative gibt, ganz oben stehen. So können Sie vermeiden, dass wertvolle Entwicklungsressourcen für weniger wichtige Testfähigkeitsanforderungen verschwendet werden, und diese Chance für die wirklich wichtigen Anforderungen nutzen.

Vorzüge der Testanforderungen definieren
Zweck:  Sich in die Lage versetzen, den Stakeholdern den Nutzen der Testfähigkeitsanforderungen in Form einer grundlegenden Kosten-Nutzen-Aufstellung zu präsentieren.  

Indem Sie das Entwicklungsteam auffordern, Software mit bestimmten Bedingungen für den Test zu entwickeln, fügen Sie weitere Anforderungen und Einschränkungen zur Entwicklungsarbeit hinzu. Das bedeutet Mehrarbeit, mehr Risiken und eine höhere Komplexität für das Entwicklungsteam. Es gibt Entwicklungsteams, die das Design der Testfähigkeit als eine Aufgabe betrachten, die nicht in ihre Zuständigkeit fällt. In anderen Fällen müssen die Testfähigkeitsanforderungen mit anderen Kundenbedürfnissen und -anforderungen, denn normalerweise die höhere Priorität eingeräumt wird, um die Entwicklungsressourcen konkurrieren. Daher müssen Sie die Vorteile, die sich aus den Testfähigkeitsanforderungen ergeben, dem Projektleiter, dem Softwarearchitekten und anderen Stakeholdern des Entwicklungsteams gut verkaufen.

Formulieren Sie eine Analyse der Vorteile der einzelnen Testfähigkeitsanforderungen, für die Sie eine Zusage anstreben. Suchen Sie nach allen Veröffentlichungen und Studien, die den Nutzen der Testfähigkeitsanforderung stützen, und nutzen Sie, wo möglich, ROI-Statistiken. Denken Sie an die Vorteile, die für das Entwicklungsteam nutzbringend sind. Welche nützlichen Informationen für die Bewertung können Sie den Teammitgliedern nur bereitstellen, wenn dieser Bedarf erfüllt wird? Inwiefern wird es einfacher für Sie, Feedback rechtzeitig, akkurat, umfassend und in nützlicher Form bereitzustellen? Wird den Mitgliedern des Entwicklungsteam durch die Deckung des Bedarfs eine nützliche Funktion zur Verfügung gestellt, die sie bei ihrer eigenen Testarbeit oder bei der künftigen Diagnose von Softwarefehlern einsetzen können? Im Falle der Konkurrenz mit Kundenbedürfnissen sollten Sie darüber nachdenken, wie Sie zeigen können, dass eine Lösung der Testfähigkeitsanforderung zusätzliche Möglichkeiten für die Unterstützung der Kundenanforderungen in späteren Build-Zyklen bietet.

Testfähigkeitspaten identifizieren und einbeziehen
Zweck:  Kooperation mit wichtigen Stakeholdern, die als Paten für die Erstellung testfähiger Software fungieren und die Bedürfnisse der Testteams in dieser Hinsicht unterstützen, sicherstellen.  

Sie sollten die Stakeholder, die den nötigen Einfluss und die Fähigkeit haben, die Unterstützung der Testfähigkeit zu genehmigen oder anzuordnen, identifizieren und einbeziehen. Tun Sie das so schnell wie möglich, bevor Sie aktiv für die zu unterstützenden Testfähigkeitsanforderungen werben.

Die drei wichtigsten Stakeholder sind der Softwarearchitekt, der Projektleiter und der Kundenvertreter. Nehmen Sie sich die Zeit für ein ausführliches Gespräch mit dem Softwarearchitekten und erläutern Sie den Nutzen, den die Erstellung einer Softwarearchitektur, die die Testfähigkeit unterstützt, bringt. Sprechen Sie auch mit dem Projektleiter und erläutern Sie, wie vorteilhaft sich die Testfähigkeit auf die Produktivität des Teams und die Schnelligkeit des Durchlaufs der Bewertungsinformationen auswirkt. Ermutigen Sie den Kunden, den Nutzen eines zu liefernden Qualitätsprodukts klar zum Ausdruck zu bringen.

Für Testfähigkeitsanforderungen und deren Vorteile werben
Zweck:  Die relevanten Stakeholder über die wichtigen Testfähigkeitsanforderungen informieren und sich ihrer Unterstützung für die Testfähigkeit versichern.  

Es ist wichtig, in angemessener Weise für Testanforderungen zu werben. Jede Kombination aus Projektleiter, Entwicklungsteam und Kunden-Stakeholder hat eine andere soziale Dynamik und Projektkultur, und es ist wichtig, dass Sie ein Gespür dafür haben, wenn Sie für Testfähigkeitsanforderungen werben. Als allgemeines heuristisches Verfahren lässt sich formulieren, dass kein formelles Testfähigkeitsverfahren eingesetzt werden sollte, wenn das Team relativ unkonventionell und informell arbeitet. Analog dazu sollten Sie auch keinen informellen Ansatz in einem in hohem Maße formalisierten Projekt verwenden.

In einigen Fällen ist ein bereichsübergreifendes Brainstorming eine nützliche Präsentationsform. Der Bedarf wird dem Entwicklungsteam als Herausforderung präsentiert und die Teammitglieder werden ermutigt, kreative Lösungen für die Testfähigkeitsanforderungen zu identifizieren. Das trägt dazu bei, ihr Verantwortungsgefühl für die Lösung zu stärken, und fördert ein partnerschaftliches Klima bei der Arbeit.

Das Timing ist ebenfalls wichtig für diesen Schritt. Im Allgemeinen sollten Sie die wichtigsten Problemstellungen zur Testfähigkeit so früh wie möglich identifizieren und für sie werben. Im Normalfall sollte dies während der Ausarbeitung und, wo möglich, während der Konzeption geschehen. Wenn Problemstellungen im Zusammenhang mit der Testfähigkeit in diesen frühen Projektphasen definiert werden, ist das Team normalerweise kleiner und offener für Änderungen. Es ist also einfacher, diese Bedürfnisse bei der Erstellung des Designs zu berücksichtigen, da normalerweise Nacharbeit in geringem Umfang erforderlich ist.

Eine gute Möglichkeit, die Testfähigkeitsanforderungen zu identifizieren und auf ansprechende und weniger offizielle Art zu präsentieren, besteht darin, dem Testteam die Möglichkeit zu geben, seine Services bei der Bewertung von erprobten Aktivitäten und der Bewertung der Auswahl von Komponenten Dritter, die bei der Entwicklung verwendet werden sollen, zur Verfügung zu stellen. Insbesondere die Einbeziehung von Testteams während der Auswahl der Datenbankkomponenten, der UI-Steuerung oder der Auswahl der Komponenten und Middleware-Komponenten etc. bedeutet, dass Problemstellungen im Zusammenhang mit der Testfähigkeit als Aspekt für die Kriterien der Komponentenauswahl fungieren können. Beispielsweise werden Entwicklungsteams sich in vielen Fällen keine Gedanken darüber machen, welche Bibliothek für UI-Fensterobjekte sie verwenden sollen. Wenn eine Bibliothek für Fensterobjekte testfähiger ist als eine andere, wird das Entwicklungsteam diese Bibliothek auswählen.

Wenn Sie Schwierigkeiten haben, Testfähigkeitspaten zu identifizieren oder einzubeziehen, sollten Sie sich vielleicht einen Ansatz überlegen, der die Änderungen in kleineren Abschnitten einführt, so dass sie potenziell weniger riskant sind und leichter gehandhabt werden können. Sie haben auch die Möglichkeit, die wichtigsten Testfähigkeitsanforderungen als kritische projektbezogene Problemstellungen zu präsentieren, die dem Testerfolg im Wege stehen, solange sie nicht gelöst sind. Im letzteren Falle wird empfohlen, alle Optionen sorgfältig zu prüfen, bevor Sie hinsichtlich dieser Vorgehensweise Entscheidungen treffen.

Zusage für Unterstützung einholen und Testfähigkeit verwalten
Zweck:  Eine Übereinkunft darüber erzielen, dass das Entwicklungsteam die Testfähigkeitsfunktionen weiter unterstützt und verwaltet.  

Es ist muss sichergestellt sein, dass die Testfähigkeitsanforderungen genauso behandelt werden wie eine beliebige andere Anforderung oder Vorgabe für die Entwicklungsarbeit. Sie müssen sich darauf verlassen können, dass die Testfähigkeitsfunktionen, die heute verfügbar gemacht werden, nicht morgen schon obsolet sind.

Wenn Sie versuchen, diese Zusage einzuholen, kann es in einigen Fällen passieren, dass das Entwicklungsteam sich weigert, die Testfähigkeitsanforderungen zu entwickeln oder zu unterstützen. Das mag entmutigend sein, es ist aber besser, eine solche Situation so früh wie möglich zu erkennen und sich mit den Realitäten auseinanderzusetzen, als viel Zeit und Mühe auf die Entwicklung einer Testimplementierung zu verwenden, die dann vom Entwicklungsteam nicht unterstützt wird.

Lösung von Problemen im Zusammenhang mit der Testfähigkeit befürworten
Zweck:  Die Lösung von Problemen bei der Testfähigkeit überwachen und entsprechende Paten finden.  

Auch wenn das Entwicklungsteam zustimmt, die erforderliche Unterstützung für Testfähigkeitsanforderungen bereitzustellen, ist es wichtig, dass Sie das Design, die Implementierung und den Abschluss dieser Arbeit sorgfältig im Auge behalten. Lassen Sie in Ihrer Aufmerksamkeit nicht nach, nur weil das Entwicklungsteam zugestimmt hat, die Testfähigkeitsanforderungen zu bearbeiten, oder weil es bereits an einer Lösung arbeitet. Sie müssen sicherstellen, dass rechtzeitig eine geeignete Lösung entwickelt wird.

Sie und das übrige Testteam müssen gleichermaßen bereit sein, die Fragen des Entwicklungsteams zu beantworten und die Prototypen unmittelbar nach der Erstellung zu bewerten. Geben Sie ein konstruktives Feedback ab und äußern Sie Ihre Anerkennung für den Beitrag, den das Entwicklungsteam zur Realisierung Ihrer Bedürfnisse geleistet hat. Bieten Sie an, dass Ihre wichtigsten Mitarbeiter hinsichtlich der komplexeren Testfähigkeitsanforderungen an Design-Workshops teilnehmen oder diese vereinfachen können. Achten Sie jedoch darauf, dass Ihr Team nicht herrisch auftritt und den Entwicklern das Tempo für den Designprozess vorgibt.

Wenn Probleme auftreten und Sie das Gefühl haben, dass sie keine ausreichende Beachtung finden oder nicht schnell genug bearbeitet werden, teilen Sie Ihre Bedenken dem Softwarearchitekten und Projektleiter mit. Veranlassen Sie, fall nötig, dass der Projektleiter ein Problem in der Liste mit projektbezogenen Problemen aufführt.

Ergebnisse bewerten und prüfen
Zweck:  Überprüfen, ob die Aufgabe ordnungsgemäß ausgeführt wurde und die resultierenden Arbeitsergebnisse annehmbar sind.  

Wenn Sie Ihre Arbeit beendet haben, kann es vorteilhaft sein zu prüfen, ob diese Arbeit hinreichend nutzbringend oder eine reine Papierverschwendung war. Sie sollten bewerten, ob die Qualität Ihrer Arbeit angemessen ist und ob der Umfang der Arbeit ausreicht, um eine Hilfestellung für die Teammitglieder zu bieten, die sie als Arbeitsvorgabe verwenden sollen. Verwenden Sie nach Möglichkeit die RUP-Prüflisten, um zu überprüfen, ob Qualität und Umfang "gut genug" sind.

Legen Sie den Personen, die nachgeordnete Aufgaben ausführen müssen und auf Ihre Arbeitsvorgaben angewiesen sind, einen Zwischenstand Ihrer Arbeiten zur Prüfung vor. Wählen Sie dafür einen Zeitpunkt, der eine Einbeziehung von Änderungswünschen oder die Berücksichtigung von Problemstellungen zulässt. Bewerten Sie Ihre Arbeit auch anhand der Arbeitsergebnisse, die für Sie die wichtigsten Vorgaben waren, um sicherzugehen, dass Sie diese präzise und ausreichend dargestellt haben. Vielleicht lassen Sie Ihre Arbeit ja dahingehend vom Autor dieser Arbeitsergebnisse prüfen.

Vergessen Sie nicht, dass RUP ein iterativer Bereitstellungsprozess ist und dass sich in vielen Fällen Arbeitsergebnisse über einen längeren Zeitraum entwickeln. Es ist daher in der Regel nicht nötig und manchmal sogar kontraproduktiv, ein Arbeitsergebnis, das für die unmittelbar folgenden Arbeiten nur teilweise oder gar nicht benötigt wird, bereits vollständig und abschließend zu definieren. Es ist sehr wahrscheinlich, dass die umgebende Situation für das Arbeitsergebnis sich noch ändern wird und die bei Erzeugung des Arbeitsergebnisses gültigen Annahmen sich als fehlerhaft erweisen, so dass eine abschließende Gestaltung des Arbeitsergebnisses einen unnötigen Arbeitsaufwand und teures Nacharbeiten bedeuten würde. Sie sollten auch nicht zu viel Zeit auf die Darstellung verwenden, sondern sich eher auf den Inhalt konzentrieren. In Projektumgebungen, bei denen die Präsentation wichtig ist und als Projektliefergegenstand einen wirtschaftlichen Wert hat, könnten Sie für die Darstellungsaufgaben eine administrative Ressource nutzen.