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.
|
|