BDD 2007: Test – Handbuch für das Feature-Team

Planung

Veröffentlicht: 30. Nov 2006

In Abbildung 2 werden die Hauptaktivitäten angezeigt, die während der Planungsphase stattfinden. Diese Aktivitäten und Pflichtergebnisse sind sowohl für den Erfolg des Testverfahrens als auch für die Überprüfung der BDD 2007-Implementierung in der Testumgebung von entscheidender Wichtigkeit. Das TestFeature-Team plant Testaktivitäten und legt Strategien fest. Dies geschieht teilweise durch Untersuchen der Wechselwirkung zwischen den Benutzern, der Organisation und internen IT-Prozessen sowie die für die BDD 2007-Implementierung definierten Geschäftsziele und der Effektivität der Organisation.

Abbildung 2: Aktivitäten während der Planungsphase

Das TestFeature-Team arbeitet eng mit den verschiedenen Feature-Teams zusammen, um eine objektive Überprüfung der BDD 2007-Implementierung sowie deren Komponenten zu bieten. Die vorrangige Anforderung für das TestFeature-Team während der Planungsphase ist der Testplan, der mit drei Schlüsselelementen der BDD 2007-Implementierung interagiert und diese beeinflusst:

  • Der Testplan beeinflusst den gesamten BDD 2007-Projektplan.

  • Der im Testplan enthaltene Testzeitplan wirkt sich auf den BDD 2007-Projektzeitplan aus.

  • Die im Testplan enthaltenen Anforderungen an die Testumgebung spielen eine Rolle im Hardware- und Anlagenplan; diese Anforderungen beeinflussen außerdem das BDD 2007-Budget.

Die verschiedenen Komponenten, aus denen der Testplan besteht, werden nicht isoliert vorbereitet. Beim Entwickeln des Testplans muss das TestFeature-Team mit anderen BDD 2007-Implementierungsteams zusammenarbeiten und aus mehreren Quellen gewonnene Informationen verwenden, einschließlich:

  • Die mit BDD 2007 bereitgestellte Dokumentation.

  • Entwicklungsplan für das BDD 2007-Projekt.

  • Funktionsbeschreibung für das BDD 2007-Projekt.

Das TestFeature-Team konzentriert sich darauf, die Funktionsweise der Prozess- und Technologiekomponenten als Lösung in der Testumgebung zu testen. Bei diesem Ansatz wird während des Testens des Erstellungsprozesses der BDD 2007-Implementierung, der technischen Komponenten, Funktionen und Funktionalität der breitere Unternehmenskontext berücksichtigt, bevor die Lösung in der Produktionsumgebung bereitgestellt wird. Das Ergebnis dieses Ansatzes ist eine optimale bzw. vollständig getestete Lösung einschließlich Bildern und Softwarepaketen, die auf den Computern in der Organisation bereitgestellt werden kann.

Auf dieser Seite

Rollen und Verantwortlichkeiten Rollen und Verantwortlichkeiten
Überlegungen zum Testplan Überlegungen zum Testplan
Vorbereiten des Testplans Vorbereiten des Testplans
Meilenstein: Testplan entwickelt und akzeptiert Meilenstein: Testplan entwickelt und akzeptiert

Rollen und Verantwortlichkeiten

Alle sechs Rollencluster des MSF-Teammodells spielen in der Planungsphase der Initiative eine Rolle. In Tabelle 1 sind diese Rollen aufgeführt und die Schwerpunkte für jeden Rollencluster definiert.

Weitere Informationen zu MSF Rollenclustern finden Sie in Microsoft Solutions Framework unter http://www.microsoft.com/technet/itsolutions/msf/default.mspx (möglicherweise in englischer Sprache).

Tabelle 1: Rollen und Verantwortlichkeiten während der Planungsphase

Rolle

Schwerpunkt

Produktmanagement

  • Analyse der Geschäftsanforderungen

  • Kommunikationsplan

  • Konzeptioneller Entwurf

Programmmanagement

  • Budget

  • Konzeptioneller und logischer Entwurf

  • Funktionsbeschreibung

  • Projektplan und Projektzeitplan

Entwicklung

  • Priorisieren und Überprüfen des Anwendungsinventars

  • Einrichten der Testumgebung

Benutzerfreundlichkeit

  • Anforderungen an Lokalisierung und Zugänglichkeit

  • Zeitpläne

  • Schulungspläne

  • Nutzungsszenarios und Anwendungsfälle

  • Benutzerdokumentation

  • Benutzeranforderungen

Test

  • Testplan und Zeitplan

  • Definition der Testanforderungen

Veröffentlichungsverwaltung (Release Management)

  • Anwendungs- und Hardwareinventur

  • Entwurfsbeurteilung

  • Netzwerkermittlung

  • Betriebsanforderungen

  • Pilot- und Bereitstellungsplan und Zeitplan

  • Arbeiten mit dem IT-Operationsteam und dem SicherheitsFeature-Team

Überlegungen zum Testplan

Beim Vorbereiten des Testplans müssen Mitglieder des TestFeature-Teams mehrere Aspekte des Implementierungsprozesses berücksichtigen, einschließlich:

  • Welche Testtypen für die verschiedenen Phasen der Lösungsimplementierung erforderlich sind und insbesondere die Verantwortlichkeiten des TestFeature-Teams bei jedem Testtyp.

  • Die bei jedem Testtyp zum Testen verwendete Strategie.

  • Die verschiedenen Teamrollen für die Mitglieder des TestFeature-Teams.

  • Die erforderlichen vorausgesetzten Aktivitäten für jedes Teammitglied.

Jeder Aspekt wird weiter unten ausführlich behandelt. An dieser Stelle sei noch einmal erwähnt, dass diese Informationen als Anleitung bereitgestellt werden, die in die vorhandenen Vorgehensweisen der Organisation beim Testen eingegliedert werden sollen.

Testtypen

Für die Vorbereitung komplizierter technologischer Lösungen sind mehrere verschiedene Testarten erforderlich. Jeder Typ hat seine eigenen Anforderungen und seine eigene Teststrategie. Die Lösung wird von einer Testart zur nächsten immer weiter entwickelt, bis sie gründlich getestet wurde und für Einführung in die Produktionsumgebung bereit ist.

Die empfohlenen Testtypen für BDD 2007 umfassen:

  • Komponententest. Der erste Testtyp konzentriert sich auf die Analyse einer einzelnen Lösungskomponente. Während die Erstellung der Gesamtlösung vorbereitet wird, beginnen Teammitglieder jedes Feature-Teams mit der Analyse der Komponenten, für die sie verantwortlich sind. Zu diesem Zeitpunkt werden diese Komponenten häufig in isolierten Umgebungen installiert, um die Funktionen der Komponente zu überprüfen. Dieser Testtyp wird oft von Einzelpersonen auf einem einzelnen Computer durchgeführt.

  • Funktionstests. Nachdem die einzelnen Teams mit den technologischen Komponenten, für die sie verantwortlich sind, vertraut sind, fahren sie mit Funktionstests fort. In diesen Funktionstests wird überprüft, ob Produkte und Komponenten wie entworfen funktionieren. Anleitungen für diesen Testtyp sind von den Funktionsbeschreibungen des Gesamtprojekts abgeleitet.

  • Gesamttest. Beim nächsten Testtyp werden die verschiedenen Komponenten, aus denen die Lösung besteht, in ein zusammenhängendes Ganzes integriert. Dieser Test wird in der Integrations- oder Testumgebung vom TestFeature-Team selbst durchgeführt.

  • Staging-Test. Der Staging-Test ist ein optionaler Testtyp, der eine endgültige Überprüfung der Verfahren bereitstellt, mit denen die Lösung implementiert wird. Bei den vorhergehenden Testtypen kann es einen Fehlerspielraum geben, bei diesem Test darf kein Fehler auftreten. Wenn eine Lösung in die Produktionsumgebung integriert wird, muss sie vollständig fehlerfrei sein, um ihre Langlebigkeit und langfristige Unterstützbarkeit zu gewährleisten.

  • Pilot- und Produktionsprüfung. Bei der abschließenden Testphase sind oft die gleichen Komponenten beteiligt, die auch in der Produktion verwendet werden. Wenn die Teams die Lösung in eine Produktionsumgebung implementieren, beginnen sie mit einer Pilotbereitstellung für eine kleine, repräsentative Gruppe von Benutzern in der Produktionsumgebung, die einen endgültigen Test aller Implementierungsstrategien und Verfahren durchführt, bevor das System für die gesamte Produktionsumgebung bereitgestellt wird. Bei diesem Testtyp liegt der Schwerpunkt mehr auf Schulung, Kommunikation und Supportstrategien als auf den eigentlichen technologischen Strategien, obwohl diese ebenfalls überprüft werden. Die Pilotlösung ist mit der Produktion verknüpft, denn wenn alles gut geht, werden die mit dem Pilotprogramm eingeführten Technologien und Komponenten zu jenen Komponenten, die in der Produktion verwendet werden.

In Abbildung 3 werden die verschiedenen Testtypen und der zyklische Entwicklungsprozess von Typ zu Typ dargestellt.

Abbildung 3: Die fünf möglichen Testtypen

Teststrategie

Die Anleitungen – detaillierte schrittweise Anweisungen, die skizzieren, wie eine Aktivität durchzuführen ist – für die Vorbereitung jedes Testtyps sind von den Informationen abgeleitet, die in jedem Handbuch für das Feature-Team in BDD 2007 enthalten sind. Jedes Feature-Team muss diese Anweisungen dokumentieren und immer dann aktualisieren, wenn Probleme oder Fehler korrigiert werden. Damit dieses Verfahren gelingt, müssen die verschiedenen Teams Testreihen ausführen. In verschiedenen Phasen einer Testzyklus werden für jeden der oben identifizierten fünf Testtypen verschiedene Testreihen ausgeführt. Diese schrittweise Annäherung an das Testen ermöglicht die Verfeinerung aller Prozesse und Verfahren, bevor sie ins Produktionsnetzwerk eingeführt werden.

Testzyklen

Durch das Testen mit mehreren Testszyklen wird sichergestellt, dass im Testzyklus N gefundene Probleme im rückläufigen Testzyklus N + 1 behoben sind. Durch dieses Verfahren wird eine qualitativ hochwertige Lösung gewährleistet, und das ist die Rechtfertigung für die vielen Testtypen, die das TestFeature-Team ausführen muss.

Jeder Testtyp beginnt mit der Erstellung von Basislinienabbildern der Testscomputer. Anweisungen zum Erstellen dieser Basisliniencomputer befinden sich in den verschiedenen Handbüchern für das Feature-Team in BDD 2007. Während Tests durchgeführt und Prozesse von einem Testtyp zum nächsten weiterentwickelt werden, werden diese Basislinienabbilder mit den Ergebnissen des vorherigen Testtyps aktualisiert. Durch diese Aktualisierungen werden die Basislinienabbilder mit jedem Testtyp verbessert. Am Ende des vollständigen Testzyklus erreicht die Lösung einen stabilen Zustand.

Kriterien für Bestehen bzw. Fehlschlagen

Vor der ersten Ausführung des Testzyklus müssen die folgenden Kriterien definiert werden, um Defekten vorzubeugen und die Fehlerauflösung sicherzustellen:

  • Alle Testfälle müssen mit den erwarteten Ergebnissen bestehen, wie im Arbeitsbuch für Testfälle skizziert.

  • Ein Testfall wird als bestanden betrachtet, wenn das tatsächliche Ergebnis mit dem für den Testfall dokumentierten erwarteten Ergebnis übereinstimmt. Ein tatsächliches Ergebnis, das nicht mit dem erwarteten Ergebnis übereinstimmt, muss als fehlgeschlagener Testfall behandelt werden, und es muss ein Fehler angelegt werden, dem ein Schweregrad und eine Priorität zugewiesen wird.

  • Wenn ein Testfall fehlschlägt, ist nicht unbedingt die Lösung fehlerhaft. So könnte beispielsweise eine Fehlinterpretation der Produktdokumentation, eine unvollständige oder ungenaue Dokumentation Fehler verursachen. Jeder Fehler muss analysiert werden, um seine Ursache auf der Basis tatsächlicher Ergebnisse zu entdecken, und die Ergebnisse müssen sowohl in der Projektdokumentation beschrieben als auch an das richtige Feature-Team weitergeleitet werden.

Diese Kriterien müssen Bestandteil des Testplans sein. Sie können selbstverständlich durch andere individuelle Kriterien ergänzt werden, um die spezifischen Bedürfnisse der Organisation zu erfüllen.

Identifizieren von Testfalltypen

Schließlich muss der Testplan verschiedene Typen von Testfällen enthalten. Es sind verschiedene Tests möglich, doch im Kontext dieser Lösung sind die folgenden Typen häufig die wichtigsten:

  • Installationstest. Mit diesen Testtypen wird überprüft, ob Lösungskomponenten richtig installiert sind. Die Lösungskomponenten bestehen aus dem gesamten mit BDD 2007 bereitgestellten Code und den Tools, zusammen mit dem Code und den Tools, die bereits innerhalb der Organisation verwendet werden. Mit diesem Testfall werden auch Elemente wie z. B. Leistung und Bandbreitennutzung während der Installation abgedeckt.

  • Konfigurationstest. Anhand dieser Tests wird überprüft, ob alle Konfigurationsoptionen der Lösung vorhanden sind und bei Aufruf richtig ausgeführt werden. Bei der Bereitstellung eines Computers beispielsweise müssen die Post-Build-Prozesse richtig ausgeführt werden. In diesen Prozessen ist sowohl die Anwendung zusätzlicher Softwarekomponenten als auch die Wiederherstellung persönlicher Einstellungen eines Benutzers durch das Microsoft Windows User State Migration Tool (USMT) enthalten. Da die Lösung aus mehreren Konfigurationen besteht, müssen Sie sicherstellen, dass jede Konfiguration wie erwartet funktioniert.

  • Funktionalitätstest. Mit diesem Test wird die grundlegende Überprüfung des Betriebssystems und der Anwendungsfunktionalität aus der Entwicklungs- und Testperspektive sichergestellt.

  • Benutzerakzeptanztest. Mit diesem Test wird gewährleistet, dass das System als Ganzes im typischen Benutzerbetrieb wie gewünscht funktioniert. Der Benutzerakzeptanztest muss auch an jedem Anwendungspaket durchgeführt werden, das vom Anwendungsverwaltungssteam erstellt wird.

  • Sicherheitstest. Durch diesen Test wird sichergestellt, dass die Sicherheitsaspekte der Lösung während des gesamten Testzyklus beibehalten werden. Zu Sicherheitstests gehören Aktivitäten wie die Überprüfung, dass Kennwörter in keiner Komponente der Lösung als einfacher Text angezeigt werden (bzw. dass Anmeldeinformationen, die als einfacher Text angezeigt werden, dedizierte Rechte und Berechtigungen haben); dass Protokolle keine Anmeldeinformationen aufzeichnen; und dass jede Teamrolle in der Lösung, einschließlich der Benutzer, über die richtigen Zugriffsrechte auf alle freigegebenen Ordner verfügt, aus denen die Lösung besteht.

Vorbereiten zum Testen der BDD 2007-Implementierung

Teammitglieder werden während der Projektbeschreibungsphase ausgewählt. Während der Planungsphase müssen sie damit beginnen, das Testen von BDD 2007 vorzubereiten. Im Verlaufe dieser Tests müssen drei wichtige Dokumentationssätze überprüft werden. Die Überprüfung dieser Dokumentationssätze hilft auch bei der Vorbereitung des Testplans. Es gibt folgende Dokumentationssätze:

  • Die BDD 2007-Dokumentation. Insbesondere dieses Handbuch für das Feature-Team, das Handbuch zum Planen , Erstellen und Bereitstellen und das Arbeitsbuch für Testfälle. Teammitglieder könnenn auch die anderen Handbücher für das Feature-Team durcharbeiten, doch diese drei Handbücher sind die wichtigsten.

  • Der Entwicklungsplan für die BDD 2007-Implementierung muss sehr genau überprüft werden.

  • Die Funktionsbeschreibung, die eine Basislinie für die BDD 2007-Funktionen und Funktionalitäten festlegt, die in der Produktionsumgebung bereitgestellt werden sollen. Der Lösungsarchitekt, der dem Rollencluster für Entwicklung angehört, bereitet dieses Dokument während der Planungsphase vor. Mitglieder anderer Rollencluster stellen bei der Vorbereitung dieses Dokuments ihren Input zur Verfügung.

Das TestFeature-Team benötigt diese Dokumentation, um:

  • die Testanforderungen einzuschätzen und die Voraussetzungen für das Testen zu definieren.

  • die Zeit und die Ressourcen abzuschätzen, die zum Testen aller entwickelten Funktionen erforderlich sind.

  • Entwicklern Feedback zu jeglichen Spezifikationen in dem Dokument zu geben, die unklar, zweideutig oder widersprüchlich sind, um falsche Implementierungen aufgrund von Missverständnissen zu verhindern.

  • zu ermitteln, ob es Lösungsfunktionen gibt, die schwierig oder unmöglich zu testen sind.

In Situationen, in denen eine bestimmte Funktion nicht getestet werden kann, muss der Eskalationsprozess des TestFeature-Teams beinhalten, dass das Problem an das Kernteam übergeben wird. Das Kernteam entscheidet dann, ob die Funktion neu entwickelt werden muss oder, ob beibehalten werden kann und mit einer Anmerkung zur Version bereitgestellt werden muss, mit der Benutzer (IT Operations) davon in Kenntnis gesetzt werden, dass die Funktion nicht getestet werden konnte. Ungetestete Elemente müssen strikt auf ein Mindestmaß beschränkt werden.

In dieser Phase der Überprüfung und Abnahme der Funktionsbeschreibung durch das TestFeature-Team wird die Fähigkeit des Teams bestätigt, die Lösung zu testen. Diese Abnahme ist eine Planungsphaseanforderung für das Kernteam. (Weitere Informationen zu Funktionsbeschreibungen finden Sie in dem Handbuch zum Planen , Erstellen und Bereitstellen (möglicherweise in englischer Sprache).

Vorbereiten des Testplans

Das TestFeature-Team ist zuständig für die Entwicklung des Testplans für das BDD 2007-Projekt. Dieser Testplan besteht aus mehreren Komponenten. Im Dokumentationssatz für BDD 2007 wird eine Beispielvorlage für einen Testplan bereitgestellt. Diese befindet sich unter C:\Programme\BDD 2007\Dokumentation\Arbeitshilfen\Testplan.doc. Die für das TestFeature-Team relevantesten Komponenten werden in den folgenden Abschnitten beschrieben.

Umfang des Tests

Der Umfang der Aktivitäten des TestFeature-Teams wird von den Lösungsanforderungen und der Funktionsbeschreibung bestimmt. Mit dem Testumfang werden das Ausmaß und die Art der Testaktivitäten definiert, mit denen die Technologie und die Prozesse von BDD 2007 überprüft werden. Im Falle von BDD 2007 steht Technologie für die Skripts und Tools, die vom EntwicklungsFeature-Team erstellt wurden, während mit Prozessen die Methoden, die aktivierenden Technologien und Verfahren gemeint sind, die von den anderen BDD 2007-Teams verwendet werden. Im Testumfang müssen auch die im Testplan befindlichen Testtypen enthalten sein.

Testumgebungsanforderungen für jeden Testtyp

Das Ziel der Tests ist die Zertifizierung eines Produkts, das in der Produktionsumgebung bereitgestellt werden soll. Die Zertifizierung beinhaltet eine umfassende Überprüfung aller Komponenten, aus denen das Produkt besteht – Softwarepakete und Betriebssystemabbilder sowie all die Komponenten, die die Bereitstellung der Lösung unterstützen – gemäß vordefinierten Testparametern. Wenn die Testumgebung die Produktionsumgebung widerspiegelt, können die Systeme und Anwendungen von BDD 2007 zertifiziert werden, da die Ergebnisse der Tests in der Testumgebung das repräsentieren, was in der Produktionsumgebung zu erwarten ist.

Das TestFeature-Team ist zuständig dafür, dass die BDD 2007-Testumgebung so entworfen wird, dass sie die Produktionsumgebung genau wiedergibt. Der Entwicklungsplan und das Handbuch für das Feature-Team für Infrastrukturverbesserung helfen dem Team beim Ermitteln der Hardware, Software, Infrastruktur und der Anlagen, die für die Testumgebung erforderlich sind. Die Anforderungen an die Testumgebung variieren gemäß den durchgeführten Testtypen.

Wenn das Team z. B. nur Funktionen testet, kann erwogen werden, die Menge und Art der Hardware einzuschränken, die für die Umgebung erforderlich ist. Wenn das Team jedoch außerdem plant, Belastungstests durchzuführen, können die Hardwareanforderungen der Umgebung beträchtlich zunehmen. Virtuelle Computer (VMs) sind beim Testen besonders nützlich und können für die meisten Testtypen angewendet werden. Komponententests werden z. B. mithilfe von einem oder mehreren VMs, die alle für den Test erforderlichen Funktionen erfüllen, auf dem Computer des Benutzers durchgeführt. Bei Funktionstests kann derselbe Mechanismus verwendet werden, oder eine dedizierte Hardwarekomponente, auf der mehrere VMs ausgeführt werden. In ähnlicher Weise kann auch bei den meisten Tests der Integrations- und Staging-Testtypen auf VMs zurückgegriffen werden. VMs können Server simulieren, doch bereitgestellte Abbilder müssen mindestens ein physisches Beispiel jedes Computertyps enthalten, auf den bei der Produktionsbereitstellung abgezielt wird. Durch diese Kombination wird sichergestellt, dass bereitgestellte Abbilder alle richtigen Treiber enthalten. Weitere Informationen zum Verwenden von ausgeführten VMs in Virtual Server 2005 finden Sie in Microsoft Virtual Server 2005 R2 unter http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx (möglicherweise in englischer Sprache).

Fehlerbewertung, Berichterstattung und Nachverfolgung

Das TestFeature-Team entwickelt die Methode für die Meldung und Nachverfolgung von Fehlern. Das Verfahren für die Fehlerberichterstattung und -nachverfolgung muss Funktionen enthalten, mit denen das TestFeature-Team Fehler der richtigen Person bzw. dem richtigen Team zuweisen, Prioritäten für Fehler setzen, Zahlen für Schweregrade zuweisen, geschlossene Fehler wieder öffnen, Fehler verknüpfen, verschiedene Ansichten desselben Fehlers generieren und Berichte erstellen kann. Das TestFeature-Team ist außerdem verantwortlich für die Entwicklung eines Fehlerauswahlprozesses und für die Erstellung eines Zeitplans, mit dem der Status aller Testfehler nachverfolgt werden kann. Weitere Informationen zur Fehlernachverfolgung finden Sie im „Anhang: Abschließen der Testumgebung“.

Änderungssteuerung

Durch die Änderungssteuerung wird sichergestellt, dass das Kernteam über alle Änderungen an der Testumgebungshardware bzw. -software Bescheid weiß und diesen zustimmt. Das TestFeature-Team befolgt den Änderungsteuerungsprozess, der vom Lead Team erstellt wurde und während des gesamten Projektlebenszyklus von BDD 2007 verwendet wird. Der Testleiter muss den Status der Hardware und Software in der Testumgebung sowie die Testzeitpläne bekannt geben, damit die verschiedenen Feature-Teams über die Aktivitäten in der Testumgebung Bescheid wissen. Der Testleiter muss außerdem Verfahren eingerichtet haben, mit denen nach Vollendung des Projekts der ursprüngliche Zustand der Testumgebung wieder hergestellt werden kann.

Testzeitpläne

Der Testzeitplan wird in hohem Maße von dem BDD 2007-Entwicklungzeitplan beeinflusst. Das TestFeature-Team kann Komponententests an Lösungsmodulen ausführen, sobald diese von den Teams freigegeben werden. Das Team kann auch nur vollständige Systemtests durchführen, nachdem das Feature-Team für Computerimagingsysteme das gesamte Erstellungsprozessdokument vervollständigt und vollständige Bereitstellungsabbilder erstellt hat.

Auf der Basis seiner Erfahrung empfiehlt das BDD 2007 TestFeature-Team von Microsoft die Durchführung inoffizieller Komponententests, während das Erstellungsprozessdokument entwickelt wird. Durch diesen Ansatz hat das TestFeature-Team genügend Zeit, relevante Testfälle zu erstellen und sich in den Anfangsstadien der Stabilisierungsphase mit der Lösung vertraut zu machen. Außerdem können diese Komponententests auch zum Testen der Basisfunktionalität verwendet werden.

Der Testzeitplan muss mindestens die folgenden Aufgaben umfassen:

  • Einrichten der Testumgebung

  • Überprüfen der Dokumentation

  • Vorbereiten von High-Level-Testszenarios

  • Ausführliche Testfallvorbereitung

  • Ausführen der Tests

  • Anzahl und Dauer der Testzyklen

Risiken und Abhängigkeiten

Das TestFeature-Team sucht in der Regel nach Risiken, schätzt diese ein und arbeitet sie anschließend in den Testplan und den Testzeitplan ein. Dies betrifft folgende Risikoarten:

  • Die Anforderungen an die Testumgebung, basierend auf dem Entwicklungsplan, können das Budget des TestFeature-Teams und die Zeitzuordnung überschreiten.

  • Testfälle können parallel mit Eingaben des EntwicklungsFeature-Teams und Funktionsbeschreibungen abgeschlossen werden.

  • Unter Umständen wurde der Aufbau der Testumgebung bis zum Start der Stabilisierungsphase noch nicht abgeschlossen, weil die Ausstattung der Testumgebung noch nicht beschafft und installiert werden konnte.

  • Die Testumgebung spiegelt die Produktionsumgebung nicht ordnungsgemäß wider. Beispielsweise enthält sie u. U. nicht die richtigen Firewallkonfigurationen oder alle Gruppenrichtlinienobjekte (Group Policy objects, GPOs), die in der Produktion zu finden sind. Ziel ist es, die Testumgebung der Produktionsumgebung möglichst genau anzugleichen.

Entschärfungspläne für jedes dieser Risiken müssen ebenfalls Bestandteil des Testplans sein. Die oben genannten Risiken sind Beispiele für die gängigsten Risiken, doch je nach Organisation können andere vorhanden sein, die Alternativpläne erfordern.

Testtools

Der Testplan muss eine Beschreibung der Tools enthalten, die von den Testern verwendet werden. In dieser Toolliste müssen die verschiedenen Testszenarios, die Testtypen und die verwendeten Testfälle enthalten sein. Die Liste muss auf unterstützende Tools verweisen, z. B. das Fehlernachverfolgungssystem, das Änderungssteuerungssystem und jedes Dokumentationssystem, das verwendet werden soll; außerdem die Planungstools, die vom Teamleiter verwendet werden, um die Testzeitpläne zu kontrollieren.

Meilenstein: Testplan entwickelt und akzeptiert

Meilensteine sind Synchronisationspunkte für die Gesamtlösung. Weitere Informationen finden Sie in dem Handbuch zum Planen , Erstellen und Bereitstellen (möglicherweise in englischer Sprache). An diesem in Tabelle 2 angezeigten Meilenstein ist ein Testplan vorhanden, der ausführliches Wissen über die Anforderungen an die Netzwerkbandbreite und Serverkapazitäten beinhaltet.

Tabelle 2: Pflichtergebnisse

Pflichtergebnis-ID

Beschreibung

Testplan

In diesem Dokument wird der vollständige Testansatz skizziert, der vom TestFeature-Team verwendet wird.

Anzeigen: