Richtlinie: Testplan
In einem Testplan müssen Anforderungen, Risiken, Prioritäten, Strategien und Erfüllungskriterien festgelegt sein. Diese Richtlinie beschreibt detailliert Zweck und Inhalt eines Testplans.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Überblick

Der Zweck eines Testplans ist, die Absicht der Testaufgaben zu vermitteln. Es ist äußerst wichtig, dass dieses Dokument in einem möglichst frühen Stadium erstellt wird. Wenn Sie eine der ersten Iterationen der Ausarbeitungsphase als Zeitpunkt für die Generierung dieses Artefakts festlegen, ist dies keinesfalls zu früh. Es kann sinnvoll sein, den Testplan iterativ zu entwickeln und weitere Abschnitte hinzuzufügen, sobald neue Informationen verfügbar sind.

Sie sollten darauf achten, dass der Testumfang, die Anforderungen an den Test, die Teststrategien und der Ressourcenbedarf klar und deutlich beschrieben werden. Mit diesen Informationen werden Zweck und Grenzen der einzelnen Tests, der Testgegenstand, das Testverfahren und die erforderlichen Testressourcen festgelegt. Klare Formulierungen beschleunigen die Überprüfung der einzelnen Tests sowie die entsprechenden Rückmeldungen und Bestätigungen.

Gleich zu Beginn eines Projekts sollte ein so genannter Master-Testplan erstellt werden, in dem die insgesamt für das Projekt vorgesehenen Tests angegeben sind. Bei der Planung der einzelnen Iterationen können genauere Iterationstestpläne (oder auch mehrere, nach Testtyp organisierte Testpläne pro Iteration) erstellt werden, in denen nur die für die Iteration relevanten Daten (zu testende Anforderungen, Teststrategien, Ressourcen usw.) enthalten sind. Diese Informationen können alternativ auch in den Iterationsplan aufgenommen werden, sofern dadurch nicht die Verwendung oder Verwaltung des Iterationsplans erschwert wird.  

Nachfolgend finden Sie einige Richtlinien für die bessere Festlegung und Vermittlung der zu testenden Anforderungen, Testrisiken, Prioritäten und Teststrategien.

Zu testende Anforderungen festlegen

Die zu testenden Anforderungen geben an, was getestet werden soll. Sie sind das spezifische Testobjekt. Es gibt einige allgemeine Regeln für die Ableitung von zu testenden Anforderungen:

  • Die zu testende Anforderung muss ein beobachtbares, messbares Verhalten sein. Wenn eine zu testende Anforderung nicht beobachtbar oder messbar ist, kann nicht festgestellt werden, ob die Anforderung erfüllt ist.
  • Es gibt keine 1:1-Beziehung zwischen Anwendungsfall oder Zusatzanforderung eines Systems und zu testender Anforderung. Ein Anwendungsfall enthält oft mehr als eine zu testende Anforderung und aus einer Zusatzanforderung können mehrere zu testende Anforderungen abgeleitet werden oder auch keine (z. B. bei Marketing- oder Konfektionierungsanforderungen).

Die zu testenden Anforderungen können aus vielen Quellen abgeleitet werden, z. B. aus Anwendungsfällen, Anwendungsfallmodellen, zusätzlichen Spezifikationen, Designanforderungen, Geschäftsfällen, Interviews mit Benutzern und Dokumenten zur Softwarearchitektur. Alle diese Quellen sollten auf Informationen geprüft werden, die geeignet sind, um die zu testenden Anforderungen festzulegen.

Zu testende funktionale Anforderungen

Zu testende funktionale Anforderungen werden, wie der Name schon sagt, aus den Beschreibungen des funktionalen Verhaltens des Testobjekts abgeleitet. Jeder Anwendungsfall sollte mindestens eine abgeleitete zu testende Anforderung enthalten. Eine detailliertere Liste zu testender Anforderungen würde mindestens eine Anforderung pro Ereignisablauf in einem Anwendungsfall enthalten.

Zu testende Leistungsanforderungen

Zu testende Leistungsanforderungen werden aus dem spezifizierten Leistungsverhalten des Testobjekts abgeleitet. Die Leistung wird in der Regel als messbare Reaktionszeit und/oder Ressourcennutzung unter verschiedenen Bedingungen angegeben. Zu diesen Bedingungen gehören unter anderem:

  • verschiedene Auslastungen und/oder Systembedingungen
  • verschiedene Anwendungsfälle
  • verschiedene Konfigurationen

Anforderungen an das Leistungsverhalten sind in den ergänzenden Spezifikationen beschrieben. Achten Sie beim Durcharbeiten dieser Materialien besonders auf Angaben, die Folgendes enthalten:

  • Zeitangaben, z. B. Angaben zur Reaktionszeit oder Ablaufsteuerungsprofile
  • Hinweise darauf, dass eine bestimmte Anzahl von Ereignissen oder Anwendungsfällen in einem festgelegten Zeitraum eintreten muss
  • Vergleiche des Verhaltens mehrerer Elemente
  • Vergleiche des Anwendungsverhaltens in mehreren Konfigurationen
  • Hinweise zur Zuverlässigkeit über einen bestimmten Zeitraum (MTTF oder Zeit, nach der bei normalem Betrieb ein Fehler auftritt)
  • Hinweise zu Konfigurationen oder Einschränkungen

Aus jeder Angabe in der Spezifikation, die Informationen wie die oben genannten enthält, sollten Sie mindestens eine zu testende Anforderung ableiten.

Zu testende Anforderungen an die Zuverlässigkeit

Zu testende Anforderungen an die Zuverlässigkeit werden aus verschiedenen Quellen abgeleitet, die in der Regel in ergänzenden Spezifikationen, Richtlinien zur Benutzerschnittstelle, Designrichtlinien und Programmierungsrichtlinien enthalten sind.

Achten Sie beim Durcharbeiten dieser Materialien besonders auf Angaben, die Folgendes enthalten:

  • Hinweise auf die Zuverlässigkeit oder Fehlerbeständigkeit und Laufzeitfehler (z. B. Speicherverluste)
  • Hinweise auf die Integrität und Struktur des Codes (sprachliche Konformität und Einhaltung der Syntax)
  • Hinweise zur Ressourcennutzung

Aus jeder Angabe in den Materialien, die Informationen wie die oben genannten enthält, sollten Sie mindestens eine zu testende Anforderung ableiten.

Erfolgreiche Tests sind nur möglich, wenn beim Festlegen des Testaufwandes verschiedene Faktoren (z. B. Ressourcenengpässe und Risiken) in ausgewogenem Maße Berücksichtigung finden. Zur Erreichung dieses Ziels sollten Prioritäten für die einzelnen Tests vergeben werden, so dass die wichtigsten oder mit den meisten Risiken behafteten Anwendungsfälle bzw. Komponenten zuerst getestet werden. Für die Festlegung der Testprioritäten werden eine Risikobewertung und ein Nutzungsprofil erstellt und herangezogen.

In den folgenden Absätzen ist die Bestimmung der Testprioritäten beschrieben.

Risiko einschätzen und Testprioritäten festlegen

Die Festlegung der zu testenden Anforderungen ist nur ein Schritt bei der Bestimmung des Testgegenstands. Darüber hinaus müssen Prioritäten vergeben werden, damit klar ist, was in welcher Reihenfolge getestet werden soll. Dieser Schritt ist unter anderem aus folgenden Gründen erforderlich:

  • Es muss sichergestellt werden, dass das Hauptaugenmerk der Tests auf den wirklich relevanten Anforderungen liegt.
  • Es muss sichergestellt werden, dass die kritischsten, wichtigsten oder mit den meisten Risiken behafteten Anforderungen so früh wie möglich Tests unterzogen werden.
  • Es muss sichergestellt werden, dass alle Abhängigkeiten (Folgen oder Daten) getestet werden.

Zur Einschätzung des Risikos und zur Festlegung der Testprioritäten gehören drei Schritte:

Nachfolgend sind die Richtlinien für diese drei Schritte beschrieben.

Risiko einschätzen

Die Festlegung der Testpriorität beginnt mit der Einschätzung des Risikos. Anwendungsfälle oder Komponenten, die bei bei einem Ausfall oder Fehler ein großes Risiko mit sich bringen oder mit einer hohen Ausfall-/Fehlerwahrscheinlichkeit behaftet sind, sollten zu den ersten getesteten Anwendungsfällen gehören.

Benennen Sie zunächst die zu verwendenden Indikatoren für die Risikohöhe und beschreiben Sie sie. Vergleichen Sie dazu die folgenden Beispiele:

  • H - Hohes, nicht tolerierbares Risiko. Schwerwiegende Auswirkungen nach außen. Das Unternehmen wird hohe finanzielle Verluste erleiden, in Haftung genommen werden oder seinen guten Ruf verlieren.
  • M - Mittleres Risiko, das tolerierbar, aber dennoch unerwünscht ist. Minimale Auswirkungen nach außen. Das Unternehmen kann finanzielle Verluste erleiden. Die Möglichkeit, dass das Unternehmen haftbar gemacht werden kann oder seine Reputation verliert, ist begrenzt.
  • L - Niedriges, tolerierbares Risiko. Geringfügige oder keine Auswirkungen nach außen. Das Unternehmen wird nur geringe oder keine finanziellen Verluste hinnehmen müssen. Die Wahrscheinlichkeit, in Haftung genommen zu werden, ist ebenfalls gering. Die Reputation des Unternehmens wird nicht beeinträchtigt.

Listen Sie nach Festlegung der Indikatoren für die Risikohöhe alle zum Testobjekt gehörenden Anwendungsfälle oder Komponenten auf. Ordnen Sie jedem Anwendungsfall bzw. jeder Komponente in Ihrer Liste einen Indikator für die Risikohöhe zu und begründen Sie den ausgewählten Indikator (mit einer kurzen Angabe).

Das Risiko kann aus drei verschiedenen Perspektiven eingeschätzt werden:

  • Wirkung - Die Auswirkung bzw. die Konsequenzen bei einem Fehler/Ausfall in einem angegebenen Anwendungsfall (einer Anforderung usw.)
  • Ursache - Das durch einen Fehler in einem Anwendungsfall bewirkte unerwünschte Resultat als Ausgangspunkt einer Untersuchung
  • Wahrscheinlichkeit - Die Wahrscheinlichkeit für einen Fehler in einem Anwendungsfall

Wählen Sie eine Perspektive aus, geben Sie einen Indikator für die Risikohöhe an und begründen Sie Ihre Auswahl. Sie müssen nicht für jede Perspektive einen Indikator angeben. Wenn ein niedriger Indikator zugeordnet wurde, sollten Sie jedoch versuchen, das entsprechende Element aus einer anderen Risikoperspektive zu beurteilen, um sicherzustellen, dass das Risiko tatsächlich nur gering ist.

Nachfolgend ist die Einschätzung des Risikos aus den genannten drei Perspektiven detaillierter beschrieben.

Wirkung

Für eine Einschätzung des Risikos nach der Wirkung müssen Sie eine Bedingung, ein Ereignis oder eine Aktivität für die Feststellung der Auswirkungen festlegen. Stellen Sie die folgende Frage:

"Was würde passieren, wenn ___________?"

Beispiele:

  • "Was würde passieren, wenn während der Softwareinstallation festgestellt wird, dass nicht genug Plattenspeicherplatz verfügbar ist?"
  • "Was würde passieren, wenn während einer Anfragetransaktion die Internet-Verbindung unterbrochen wird?"
  • "Was würde passieren, wenn während einer Kauftransaktion die Internet-Verbindung unterbrochen wird?"
  • "Was würde passieren, wenn der Benutzer einen unerwarteten Wert eingibt?"

Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:

Beschreibung Risikofaktor Begründung
Nicht genug Plattenspeicherplatz während der Installation H Bei der Installation der Software erhält der Benutzer einen ersten Eindruck vom Produkt. Unerwünschte Ergebnisse wie die nachfolgend aufgelisteten würden die Qualität des Benutzersystems und der installierten Software herabsetzen und beim Benutzer einen negativen Eindruck hinterlassen:
  • Die Software wird nur teilweise installiert (einige Dateien und Registry-Einträge) und ist dadurch instabil.
  • Die Installation wird abgebrochen und das System wird dadurch instabil.
Die Internet-Verbindung wird während einer Anfrage unterbrochen. L Weder Daten noch die Datenbank werden durch die Unterbrechung beschädigt. Es besteht die Möglichkeit, dass dem Benutzer durch den Vorfall ein negativer Eindruck vermittelt wird.
Die Internet-Verbindung wird während eines Einkaufs. H Alle unterbrochenen Verbindungen oder Transaktionen mit den nachfolgend aufgelisteten Resultaten sind inakzeptabel, denn Sie erhöhen den Systemaufwand und schmälern den Gewinn:
  • beschädigte Datenbank
  • unvollständiger Auftrag
  • Verlust von Daten oder Aufträgen
  • Mehrfachbestellungen (durch Replikation)
Ein unerwarteter Wert wird eingegeben. H Alle Transaktionen mit den nachfolgend aufgelisteten Resultaten sind inakzeptabel:
  • beschädigte Datenbank
  • ungenaue Daten

Ursache

Die Einschätzung des Risikos nach der Ursache ist die entgegengesetzte Perspektive zur Einschätzung nach der Wirkung. Geben Sie zunächst ein unerwünschtes Ereignis oder eine unerwünschte Situation an und beschreiben Sie dann die Ursachen, die zum Entstehen dieses Ereignisses bzw. dieser Situation führen können. Stellen Sie die folgende Frage:

"Wie konnte es dazu kommen, dass ___________ ?

Beispiele:

  • "Wie konnte es dazu kommen, dass sich nur einige Dateien auf dem System befinden und nicht alle Einträge in die Registry geschrieben wurden?"
  • "Wie konnte es kommen, dass eine Transaktion in der zentralen Datenbank nicht richtig widergespiegelt wird?"
  • "Wie konnte es dazu kommen, dass der Rechnungsstellungszyklus nur einige der Datensätze aus der Datenbank enthält, die die gewünschten Kriterien erfüllen?"

Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:

Beschreibung Risikofaktor Begründung
Fehlende Anwendungsdateien und Registry-Einträge H Die Anwendung wird unbrauchbar (und das System potenziell auch). Bei der Installation macht sich der Benutzer einen ersten Eindruck von der Anwendung. Scheitert die Installation, sieht der Benutzer die Software in einem ungünstigen Licht.

Für diese Situation kann es unter anderem folgende Ursachen geben:

  • Während des Installationsprozesses wurden nicht alle Dateien installiert und die Registry nicht ordnungsgemäß aktualisiert.
  • Der Installationsprozess wurde durch einen Benutzereingriff gestoppt (Abbruch oder Beendigung).
  • Der Installationsprozess wurde durch die Software oder Hardware gestoppt (nicht genug Plattenspeicherplatz, nicht unterstützte Konfiguration usw.).
  • Der Installationsprozess wurde aufgrund unbekannter Bedingungen gestoppt.
  • Der Benutzer hat Dateien/Registry-Einträge gelöscht.

Nur der letzte der genannten Anwendungsfälle kann nicht vom Installationsprozess selbst festgestellt und gehandhabt werden.

Unvollständiger Auftrag H Unvollständige Aufträge können nicht ausgeführt werden. Dies führt zu Umsatzeinbußen und möglicherweise zu einem Verlust des Kunden.

Hierfür kann es unter anderem folgende Ursachen geben:

  • Die Internet-Verbindung wird aufgrund einer Benutzeraktion unterbrochen (Ausschalten des Modems oder Herunterfahren des PC usw.).
  • Die Internet-Verbindung wird vom IP unterbrochen.
  • Die Internet-Verbindung wird aufgrund einer Mitarbeiteraktion unterbrochen (Ausschalten des Modems oder Herunterfahren von Servern usw.).
Beschädigte Daten/Datenbank H Beschädigte Daten können auf keinen Fall toleriert werden.

Hierfür kann es unter anderem folgende Ursachen geben:

  • Eine Transaktion, die Daten in die Datenbank schreibt, wurde wegen eines Benutzereingriffs nicht abgeschlossen/festgeschrieben.
  • Eine Transaktion, die Daten in die Datenbank schreibt, wurde wegen einer Unterbrechung der Internet-Verbindung nicht abgeschlossen/festgeschrieben.
  • Der Benutzer gibt ungültige Daten für die Transaktion ein.
  • Methoden/Dienstprogramme für den Datenbankzugriff
  • Die Datenbank wurde (bei der Erstellung der ersten Instanz) nicht ordnungsgemäß mit Daten gefüllt.
Replizierte Bestellungen H Replizierte Bestellungen erhöhen den Systemaufwand des Unternehmens, denn sie erzeugen Mehrkosten für Versand, Bearbeitung und Nachfüllen der Lagerbestände. Dies führt zu Gewinneinbußen.

Hierfür kann es unter anderem folgende Ursachen geben:

  • Eine Transaktion, die eine Bestellung in die Datenbank schreibt, wird durch einen Benutzereingriff (doppelte Eingabe oder Eingabe ohne Bestätigung) repliziert.
  • Eine Transaktion, die eine Bestellung in die Datenbank schreibt, wird durch einen Eingriff des Systems (Wiederherstellung einer unterbrochenen Internet-Verbindung, Wiederherstellung der Datenbank) repliziert.
Ungenaue Daten für einen Auftrag H Alle Aufträge, die nicht vollständig ausgeführt werden können oder durch erhöhten Systemaufwand Zusatzkosten verursachen, sind inakzeptabel.

Hierfür kann es unter anderem folgende Ursachen geben:

  • Eine Bestelltransaktion wurde wegen eines Benutzereingriffs nicht abgeschlossen/festgeschrieben.
  • Eine Bestelltransaktion wurde wegen einer Unterbrechung der Internet-Verbindung nicht abgeschlossen/festgeschrieben.
  • Der Benutzer gibt ungültige Daten ein.
Die Anweisung spiegelt nicht die richtige Anzahl von Datensätzen wider. H Von der Genauigkeit dieser Berichte hängen Geschäftsentscheidungen und Außenstände ab.

Hierfür kann es unter anderem folgende Ursachen geben:

  • fehlerhafte Such-/Auswahlkriterien
  • fehlerhafte SQL-Anweisung
  • beschädigte Daten in der Datenbank
  • fehlerhafte Daten in der Datenbank

Wahrscheinlichkeit

Wenn Sie ein Risiko nach Wahrscheinlichkeit einschätzen wollen, müssen Sie feststellen, wie wahrscheinlich es ist, das es bei einem Anwendungsfall (oder einer Komponente für die Implementierung eines Anwendungsfalls) zu einem Fehler/Ausfall kommt. Die Wahrscheinlichkeit wird in der Regel anhand externer Faktoren wie der folgenden ermittelt:

  • Ausfallquote
  • Änderungsrate
  • Komplexität
  • Ursprung / Urheber

Beachten Sie, dass sich die Risikofaktoren bei Verwendung dieser Risikoperspektive nur auf die Wahrscheinlichkeit eines Fehlers/Ausfalls beziehen und nicht auf die Auswirkungen, die ein solcher auf die Organisation hat (wie es bei er Einschätzung nach Wirkung und Ursache) der Fall ist.

Zwischen diesen Faktoren und der Wahrscheinlichkeit eines Fehlers/Ausfalls besteht folgende Korrelation:

Externer Faktor Wahrscheinlichkeit
Fehlererkennungsquote
Mit zunehmender Fehlererkennungsquote oder -dichte steigt die Wahrscheinlichkeit eines Fehlers/Ausfalls. Mängel haben die Tendenz, weitere Mängel nach sich zu ziehen. Wenn die Anzahl der erkannten Mängel für einen Anwendungsfall oder eine Komponente steigt, erhöht sich die Wahrscheinlichkeit, dass ein weiterer Mangel gefunden wird. Die Erkennungsquote oder -dichte früherer Releases sollte bei der Einschätzung des Risikos aus dieser Perspektive mit berücksichtigt werden, da eine hohe Erkennungsquote oder -dichte in diesen Releases auf eine hohe Wahrscheinlichkeit weiterer Fehler/Ausfälle hinweisen.
Änderungsrate Mit zunehmender Änderungsrate für einen Anwendungsfall oder eine Komponente steigt die Wahrscheinlichkeit eines Fehlers/Ausfalls. Bei wachsender Anzahl der Änderungen erhöht sich die Wahrscheinlichkeit, dass mit einer Änderung ein Fehler eingebracht wird. Jedes Mal, wenn der Code geändert wird, besteht die Gefahr, dass sich ein Fehler einschleicht.
Komplexität Mit zunehmender Komplexität des Anwendungsfalls oder der Komponente steigt die Wahrscheinlichkeit eines Fehlers/Ausfalls.
Ursprung / Urheber Das Wissen um den Ursprung und Urheber des Codes kann die Wahrscheinlichkeit eines Fehlers erhöhen oder senken.
Die Verwendung von Komponenten eines Fremdanbieters kann die Fehlerwahrscheinlichkeit verringern, sofern diese Komponenten zertifiziert sind, d. h. durch formale Tests oder aus Erfahrung nachweislich Ihre Anforderungen erfüllen.
Je größer das Know-how des Implementierenden ist, desto geringer ist in der Regel die Fehlerwahrscheinlichkeit. Dennoch können Faktoren wie die Verwendung neuer Tools oder Technologien und die Verteilung von Aktivitäten auf mehrere Rollen die Fehlerwahrscheinlichkeit trotz guter Teammitglieder erhöhen.



Beispiele:

  • Installation der neuen Software
  • "Laut Protokoll wurden viele Mängel bei den Komponenten festgestellt, die für die Implementierung der Anwendungsfälle 1, 10 und 12 verwendet werden. Unsere Kunden haben viele Änderungen an den Anwendungsfällen 14 und 19 gefordert."

Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:

Beschreibung Risikofaktor Begründung
Installation neuer Software H Wir schreiben unser eigenes Installationsdienstprogramm.

Die Anwendung kann unbrauchbar sein. Bei der Installation macht sich der Benutzer einen ersten Eindruck von der Anwendung. Scheitert die Installation, sieht der Benutzer die Software in einem ungünstigen Licht.

Installation neuer Software L Wir verwenden ein bewährtes kommerzielles Installationsdienstprogramm.

Bei einer gescheiterten Installation ist die Anwendung zwar nicht brauchbar, aber das ausgewählte Installationsdienstprogramm stammt von einem Hersteller, der mit diesem Produkt Marktführer und seit Jahren erfolgreich im Geschäft ist. Unsere Auswertung hat ergeben, dass dieses Produkt unseren Anforderungen genügt und andere Kunden mit dem Produkt und dem Hersteller sowie dessen Service und Unterstützung zufrieden sind.

Hohe Fehlererkennungsquote/Mängeldichte in den Anwendungsfällen 1, 10, 12. H Aufgrund der bisherigen hohen Fehlererkennungsquote und Mängeldichte sind die Anwendungsfälle 1, 10 und 12 als mit hohem Risiko behaftet anzusehen.
Änderungsanfragen für die Anwendungsfälle 14 und 19 H Die hohe Anzahl der Änderungen an diesen Anwendungsfällen erhöhen die Wahrscheinlichkeit, dass sich Mängel in den Code eingeschlichen haben.

Nutzungsprofil ermitteln

Der nächste Schritt bei der Einschätzung des Risikos und der Festlegung einer Testpriorität ist die Ermittlung des Nutzungsprofils für das Testobjekt.

Benennen Sie zunächst die zu verwendenden Indikatoren für die Nutzungshäufigkeit und beschreiben Sie sie. Vergleichen Sie dazu die folgenden Beispiele:

  • H - Sehr häufige Nutzung, viele Male pro Zeitraum oder durch viele Akteure bzw. Anwendungsfälle
  • M - Häufige Nutzung, mehrere Male pro Zeitraum oder durch mehrere Akteure bzw. Anwendungsfälle
  • L - Gelegentliche Nutzung oder Nutzung durch wenige Akteure bzw. Anwendungsfälle

Die Auswahl des Indikators für das Nutzungsprofil sollte auf der Häufigkeit basieren, mit der ein Anwendungsfall ausgeführt oder eine Komponente verwendet wird. Diese Häufigkeit drückt sich unter anderem durch Folgendes aus:

  • die Häufigkeit, mit der EIN Akteur (oder Anwendungsfall) den Anwendungsfall (oder die Komponente) innerhalb einer gegebenen Zeit ausführt
  • die Anzahl der AKTEURE (oder Anwendungsfälle), die den Anwendungsfall (oder die Komponente) ausführen

Je häufiger ein Anwendungsfall ausgeführt oder eine Komponente verwendet wird, desto höher ist in der Regel der Indikator für das Nutzungsprofil.

Listen Sie nach Festlegung der Indikatoren für die Nutzungshäufigkeit alle zum Testobjekt gehörenden Anwendungsfälle oder Komponenten auf. Bestimmen Sie für jeden Listeneintrag einen Nutzungsprofilindikator und geben Sie eine Begründung für den Indikator an. Für diese Einschätzung können Sie das Dokument zur Auslastungsanalyse heranziehen (siehe Arbeitsergebnis: Modell für Auslastungsanalyse).

Beispiele:

  • Installation neuer Software
  • Bestellung von Artikeln aus dem Onlinekatalog
  • Onlinenachfragen von Kunden nach Aufgabe der Bestellung
  • Dialog für Produktauswahl
Beschreibung Nutzungsprofilfaktor Begründung
Installation neuer Software H Wird (normalerweise) nur einmal durchgeführt, jedoch von vielen Benutzern. Ohne Installation kann die Anwendung nicht genutzt werden.
Bestellung von Artikeln aus dem Katalog H Dies ist der häufigste Anwendungsfall bei den Benutzern.
Kundennachfragen zu Bestellungen L Nur wenige Kunden haben Nachfragen, nachdem Sie ihre Bestellungen aufgegeben haben.
Dialog für Produktauswahl H Dieser Dialog wird von Kunden für die Bestellung von Produkten und von der Lagerverwaltung zur Auffüllung des Warenbestandes genutzt.

Testpriorität festlegen

Der letzte Schritt bei der Einschätzung des Risikos und der Festlegung einer Testpriorität ist die Festlegung der Testpriorität.

Benennen Sie zunächst die zu verwendenden Indikatoren für die Höhe der Testpriorität und beschreiben Sie sie. Vergleichen Sie dazu die folgenden Beispiele:

  • H - Muss getestet werden
  • M - Sollte getestet werden, jedoch erst, nachdem alle Elemente mit Indikator H getestet wurden
  • L - Kann getestet werden, jedoch erst, wenn alle Elemente mit den Indikatoren H und M getestet wurden

Listen Sie nach Festlegung der Indikatoren für die Höhe der Priorität alle zum Testobjekt gehörenden Anwendungsfälle oder Komponenten auf. Bestimmen Sie für jeden Listeneintrag einen Indikator für die Testpriorität und geben Sie eine Begründung an. Nachfolgend sind einige Richtlinien für die Festlegung eines Prioritätsindikators angegeben.

Berücksichtigen Sie bei der Festlegung der Prioritätsindikatoren für die einzelnen Einträge Folgendes:

  • den zuvor festgelegten Indikator für die Risikohöhe
  • den zuvor festgelegten Indikator für das Nutzungsprofil
  • die Beschreibungen der Akteure (Sind sie erfahren? Kennen sie Strategien zur Behebung von Problemen?)
  • vertragliche Verpflichtungen (Ist das Testobjekt annehmbar, wenn ein Anwendungsfall oder eine Komponente nicht geliefert wird?)

Es gibt unter anderem folgende Strategien für die Festlegung einer Testpriorität:

  • Verwenden Sie den höchsten Bewertungsfaktor (Risiko, Nutzungsprofil usw.) als Faktor für die generelle Priorität.
  • Geben Sie an, welcher der Bewertungsfaktoren (Risiko, Nutzungsprofil usw.) die größte Bedeutung hat, und verwenden Sie diesen Faktor als Prioritätsfaktor.
  • Nutzen Sie eine Kombination aus mehreren Bewertungsfaktoren zur Bestimmung der Priorität.
  • Gewichten Sie die einzelnen Bewertungsfaktoren nach einem Gewichtungsschema und berechnen Sie die Priorität nach der Gewichtung.

Beispiele:

  • Installation neuer Software
  • Bestellung von Artikeln aus dem Onlinekatalog
  • Onlinenachfragen von Kunden nach Aufgabe der Bestellung
  • Dialog für Produktauswahl

Festlegung der Priorität nach höchstem Bewertungsfaktor:

Punkt Risiko Nutzungsprofil Akteur Vertrag Priorität
Installation neuer Software H H L H H
Bestellung von Artikeln aus dem Katalog H H H H H
Kundenrückfragen L L L L L
Dialog für Produktauswahl L H L L H

Festlegung der Priorität nach dem Wert eines Bewertungsfaktors (Risiko):

Punkt Risiko Nutzungsprofil Akteur Vertrag Priorität
Installation neuer Software H H L H H
Bestellung von Artikeln aus dem Katalog H H H H H
Kundenrückfragen L L L L L
Dialog für Produktauswahl L H L L L

Berechnung der Priorität anhand einer Gewichtung:

(Anmerkung: In der folgenden Matrix gelten die Gewichtungen H = 5, M = 3 und L = 1. Eine Gesamtgewichtung von mehr als 30 kennzeichnet einen Test mit hoher Priorität, Werte von 20 bis einschließlich 30 einen Test mit mittlerer Priorität und Werte unter 20 einen Test mit niedriger Priorität.)

Punkt Risiko (x 3) Nutzungsprofil (x 2) Akteur (x 1) Vertrag (x 3) Gewichtung Priorität
Installation neuer Software 5 (15) 5 (10) 1 (1) 5 (15) 41 H (2)
Bestellung von Artikeln aus dem Katalog 5 (15) 5 (10) 5 (5) 5 (15) 45 H (1)
Kundenrückfragen 1 (3) 1 (2) 1 (1) 1 (3) 9 L (4)
Dialog für Produktauswahl 1 (3) 5 (10) 1 (1) 1 (3) 17 L (3)

Teststrategie

Die Teststrategie beschreibt den allgemeinen Ansatz und die allgemeinen Zielsetzungen für einen bestimmten Test.

In einer guten Teststrategie darf Folgendes nicht fehlen:

Art und Ziel des Tests Seitenanfang

Formulieren Sie klar die Art des zu implementierenden Tests und dessen Zielsetzung. Je genauer Sie diese Informationen angeben, desto weniger Unklarheiten und Missverständnisse sind möglich. (Dies gilt insbesondere, wenn es mehrere sehr ähnliche Tests gibt.) Aus der Zielsetzung sollte klar hervorgehen, warum der Test ausgeführt wird.

Beispiele:

"Funktionstest. Der Funktionstest konzentriert sich auf die Ausführung der folgenden, im Testobjekt implementierten Anwendungsfälle auf der Benutzerschnittstelle."

"Leistungstest. Schwerpunkt des Leistungstests für das System wird die Messung der Reaktionszeit für die Anwendungsfälle 2, 4 und 8-10 sein. Für diesen Test wird das System nur von einem Akteur genutzt, der diese Testfälle ausführt. Das System unterliegt keinen weiteren Belastungen."

"Konfigurationstest. Der Konfigurationstest wird implementiert, um das Verhalten des Testobjekts in drei verschiedenen Konfigurationen festzustellen und zu bewerten. Die Leistungskenndaten werden mit unserer Benchmark-Konfiguration verglichen."

Phase für Testausführung

Geben Sie klar die Phase an, in der der Test ausgeführt werden soll. Nachfolgend sind die Phasen angegeben, in denen Tests allgemein durchgeführt werden:

  Phase für Testausführung
Art der Tests Einheit Integration System Abnahme
Funktionstest

(Konfiguration, Funktion, Installation, Sicherheit, Volumen)

X X X X
Leistungstests

(Leistungsprofile einzelner Komponenten)

X X (X)

Optional oder bei Feststellung von Mängeln bei Systemtests

 
Leistungstests

(Auslastung, Belastung, Konflikte)

    X X
Zuverlässigkeit

(Integrität, Struktur)

X X (X)

Optional oder bei Feststellung von Mängeln bei anderen Tests

 

Verfahren

Das Verfahren sollte beschreiben, wie die Tests implementiert und ausgeführt werden. Geben Sie auch an, was getestet werden soll, welche wichtigen Maßnahmen während der Testausführung zu ergreifen sind und welche Methoden für die Evaluierung der Tests angewendet werden sollen.

Beispiel:

Funktionstest:

  • Für jeden Ereignisablauf im Anwendungsfall wird eine repräsentative Gruppe von Transaktionen angegeben, die die Aufgaben des Akteurs bei Ausführung des Anwendungsfalls widerspiegeln.
  • Für jede Transaktion werden mindestens zwei Testfälle entwickelt. Ein Testfall repräsentiert den positiven Zustand und der andere den negativen (inakzeptablen) Zustand.
  • In der ersten Iteration werden die Anwendungsfälle 1-4 und 12 wie folgt getestet:
    • Anwendungsfall 1:
      • Der Anwendungsfall 1 beginnt, wenn sich der Akteur bei der Anwendung angemeldet hat und das Hauptfenster angezeigt wird. Er endet, wenn der Benutzer 'Speichern' ausgewählt hat.
      • Alle Testfälle werden mit Rational Robot implementiert und ausgeführt.
      • Zur Überprüfung und Einschätzung der Ausführung aller Testfälle werden die folgenden Methoden angewendet:
        • Ausführung der Test-Scripts (Konnte jedes Test-Script fehlerfrei und wie vorgesehen ausgeführt werden?)
        • Mit (in den Test-Scripts implementierten) Methoden zur Überprüfung des Vorhandenseins von Fenstern oder von Daten wird festgestellt, ob die wichtigsten Fenster angezeigt werden und die angegebenen Daten während der Testausführung vom Testobjekt erfasst/angezeigt werden.
        • Die Datenbank des Testobjekts wird vor und nach dem Test (mit Microsoft Access) untersucht,um festzustellen, ob die Daten die während des Tests vorgenommenen Änderungen exakt widerspiegeln.

Leistungstest:

  • Für jeden Anwendungsfall wird wie im Dokument zur Auslastungsanalyse angegeben eine repräsentative Gruppe von Transaktionen implementiert und mit Rational Suite PerformanceStudio (vu-Scripts) und Rational Robot (GUI-Scripts) ausgeführt.
  • Die Test-Scripts und Testausführungspläne beziehen sich auf mindestens drei Auslastungen, einschließlich der folgenden:
    • Extreme Dauerbelastung: 750 Benutzer (15 % Management, 50 % Verkauf, 35 % Marketing)
    • Auslastungsspitze: 350 Benutzer (10 % Management, 60 % Verkauf, 30 % Marketing)
    • Nominale Auslastung: 150 Benutzer (2 % Management, 75 % Verkauf, 23 % Marketing)
  • Die Test-Scripts für die Ausführung der einzelnen Transaktionen enthalten die erforderlichen Zeitgeber zur Erfassung der Antwortzeiten, z. B. der gesamten Transaktionszeit (gemäß Dokument zur Auslastungsanalyse) und der Zeit für wichtige Transaktionsaufgaben oder -prozesse.
  • Die Test-Scripts halten die Auslastungen für eine Stunde aufrecht (sofern im Dokument zur Auslastungsanalyse nichts anderes angegeben ist).
  • Zur Überprüfung und Einschätzung der Ausführung aller Auslastungstests gehört Folgendes:
    • Die Testausführung wird mit Statushistogrammen überwacht (um sicherzustellen, dass Test und Auslastungen der Planung und den Erwartungen entsprechen).
    • Ausführung der Test-Scripts (Konnte jedes Test-Script fehlerfrei und wie vorgesehen ausgeführt werden?)
    • Erfassung und Bewertung der ermittelten Antwortzeiten in folgenden Berichten:
      • Leistungsperzentil
      • Antwortzeit


Erfüllungskriterien

Erfüllungskriterien werden aus zwei Gründen angegeben:

  • Sie helfen festzustellen, ob die Produktqualität annehmbar ist.
  • Sie helfen festzustellen, ob die Tests erfolgreich implementiert wurden.

Klar angegebene Erfüllungskriterien sollte unter anderem Folgendes umfassen:

  • zu messende Funktion, zu messendes Verhalten oder zu messender Zustand
  • Messmethode
  • Konformität(skriterien) der Messungen

Beispiel 1

  • Alle geplanten Testfälle wurden ausgeführt.
  • Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
  • Alle geplanten Testfälle wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich behoben. Es wurden keine neuen Mängel entdeckt.

Beispiel 2

  • Es wurden alle Testfälle mit hoher Priorität ausgeführt.
  • Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
  • Alle Mängel mit Schweregrad 1 oder 2 wurden beseitigt (Status = beseitigt oder zurückgestellt).
  • Alle Testfälle mit hoher Priorität wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich behoben. Es wurden keine neuen Mängel entdeckt.

Beispiel 3

  • Alle geplanten Testfälle wurden ausgeführt.
  • Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
  • Alle Mängel mit Schweregrad 1 oder 2 wurden beseitigt (Status = überprüft oder zurückgestellt).
  • Alle Testfälle mit hoher Priorität wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich behoben. Es wurden keine neuen Mängel entdeckt.

Spezielle Aspekte

In diesem Abschnitt sollten alle Einflüsse und Abhängigkeiten aufgelistet werden, die sich auf die in der Teststrategie beschriebenen Testverfahren auswirken könnten. Hierzu gehören unter anderem:

  • Personal (Ressourcenverfügbarkeit/-bedarf zur Unterstützung von Tests bzw. zur Teilnahme an Tests)
  • Einschränkungen (Ausrüstungs- oder Verfügbarkeitsgrenzen, der Bedarf an Sonderausrüstungen oder das Fehlen von Sonderausrüstungen)
  • spezielle Anforderungen, z. B. Zeitplanung für Tests oder Zugriff auf Systeme

Beispiele:

  • Testdatenbanken erfordern die Unterstützung durch einen Datenbankdesigner/-administrator, der Testdaten erstellen und aktualisieren muss.
  • Für Systemleistungstests werden die Server des vorhandenen Netzes verwendet (die auch für testunabhängigen Datenverkehr genutzt werden). Die Tests müssen für die Zeit nach Geschäftsschluss geplant werden, um sicherzustellen, dass außerhalb der Tests kein Datenverkehr im Netz stattfindet.
  • Das Testobjekt muss mit dem herkömmlichen System synchronisiert werden (ggf. simulierte Synchronisation), um einen vollständigen Funktionstest implementieren und ausführen zu können.