ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1813
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 56/84
1.8.2011
© International Software Testing Qualifications Board
Beispiele von Maßnahmen zur Teststeuerung:
•
Entscheidungsfindung basierend auf Informationen aus der Testüberwachung
•
Repriorisierung von Tests, wenn identifizierte Risiken auftreten (z.B. verspätete Lieferung der
Software)
•
Änderung des Testzeitplans aufgrund der Verfügbarkeit oder Nichtverfügbarkeit der Testum-
gebung
•
Setzen eines Eingangskriteriums mit der Maßgabe, dass Fehlerbehebungen durch einen Ent-
wickler nachzutesten sind, bevor die Software an die nächste Teststufe übergeben wird
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 57/84
1.8.2011
© International Software Testing Qualifications Board
5.4 Konfigurationsmanagement
(K2)
10 Minuten
Begriffe
Konfigurationsmanagement, Versionskontrolle
Hintergrund
Ziel des Konfigurationsmanagements ist es, die Integrität der Produkte herzustellen und zu erhalten.
Das betrifft Komponenten, Daten und Dokumentation der Software oder des Systems während des
Projekt- und Produktlebenszyklus.
Für das Testen kann das Konfigurationsmanagement sicherstellen, dass:
•
alle Teile der Testmittel identifiziert und einer Versionskontrolle unterworfen sind sowie Ände-
rungen verfolgt und zueinander und zu den Entwicklungseinheiten (Testobjekten) in Bezie-
hung gesetzt werden, so dass die Rückverfolgbarkeit während des gesamten Testprozesses
oder auch des gesamten Produktlebenszyklus erhalten werden kann
•
alle identifizierten Dokumente und Entwicklungsgegenstände eindeutig in der Testdokumen-
tation referenziert werden.
Das Konfigurationsmanagement unterstützt den Tester, die Testobjekte, Testdokumente, Tests und
den/die Testrahmen eindeutig zu identifizieren (und zu reproduzieren).
Während der Testplanung sollten die Konfigurationsmanagementverfahren und -infrastruktur (Werk-
zeuge) ausgewählt, dokumentiert und implementiert werden.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 58/84
1.8.2011
© International Software Testing Qualifications Board
5.5 Risiko und Testen (K2)
30 Minuten
Begriffe
Produktrisiko, Projektrisiko, Risiko, risikoorientiertes Testen
Hintergrund
Risiko kann definiert werden als die Eintrittswahrscheinlichkeit eines Ereignisses, einer Gefahr, Be-
drohung oder Situation, die zu unerwünschten Konsequenzen oder einem potenziellen Problem füh-
ren. Die Höhe des Risikos wird bestimmt durch die Wahrscheinlichkeit des Eintritts und die Auswir-
kung eines unerwünschten Ereignisses (Schaden, der aus dem Ereignis resultiert).
5.5.1 Projektrisiken (K2)
Projektrisiken sind die Risiken, die mit der Fähigkeit des Projekts zusammenhängen, seine Ziele zu
erreichen:
•
Organisatorische Faktoren:
Qualifikation, Schulung und Mitarbeiterengpässe
Personalaspekte
politische Aspekte wie
o
Probleme mit Testern, die ihre Anforderungen und Ergebnisse kommunizieren
o
Versagen des Teams bei der Verfolgung von Informationen, die durch Testen und in
Reviews gefunden werden (z.B. fehlende Verbesserung der Entwicklungs- und Test-
praktiken)
unangemessene Einstellung gegenüber oder Erwartung an das Testen (wenn beispiels-
weise das Finden von Fehlerzuständen beim Testen nicht als wertvoll betrachtet wird)
•
Technische Aspekte:
Probleme bei der Definition der richtigen Anforderungen
Ausmaß, in dem Anforderungen unter den gegebenen Randbedingungen nicht erfüllt
werden können
nicht rechtzeitig verfügbare Testumgebung
verspätete Datenkonvertierung, Migrationsplanung und -entwicklung sowie verspätete
Tests der Datenkonvertierung/Migrationswerkzeuge
geringe Qualität des Designs, des Codes, der Konfigurationsdaten, Testdaten und der
Tests
•
Lieferantenaspekte:
Versagen einer dritten Partei
Vertragsaspekte
Zur Analyse, Management und Reduzierung dieser Risiken folgt der Testmanager etablierten Pro-
jektmanagementprinzipien. Eine Vorlage für Testkonzepte (test plan) im ‘Standard for Software Test
Documentation’ (IEEE Std 829-1998) fordert die Benennung von Risiken und (Gegen-) Maßnahmen.
5.5.2 Produktrisiken (K2)
Mögliche Ausfallbereiche (unerwünschte zukünftige Ereignisse oder Gefahren) in der Software oder
dem System werden als Produktrisiken bezeichnet, da sie ein Risiko für die Qualität des Produkts
darstellen. Dazu gehören:
•
gelieferte fehleranfällige Software
•
Potenzial, dass die Software/Hardware einem Individuum oder einer Firma Schaden zufügen
könnte
•
schlechte Softwareeigenschaften (z.B. fehlende/mangelhafte Funktionalität, Zuverlässigkeit,
Benutzbarkeit und Performanz)
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 59/84
1.8.2011
© International Software Testing Qualifications Board
•
schlechte Datenintegrität und -qualität (z.B. Datenmigrationsprobleme, Datenkonvertierungs-
probleme, Datenüberführungsprobleme, Verletzung von Datenstandards)
•
Software, die ihre beabsichtigten Funktionen nicht erfüllt
Risiken werden herangezogen, um zu entscheiden, in welchem Bereich mit dem Testen begonnen
wird und welche Bereiche intensiver getestet werden; Testen wird eingesetzt, um das Risiko oder den
Schaden eines unerwünschten Effekts zu reduzieren.
Produktrisiken sind ein spezieller Risikotyp für den Erfolg eines Projekts. Als Aktivität der Risikoüber-
wachung liefert das Testen Rückmeldungen über das verbleibende Risiko, indem es die Effektivität
der Behebung kritischer Fehlerzustände und von Notfallplänen misst.
Ein risikoorientiertes Testvorgehen erlaubt pro-aktive Möglichkeiten zur Reduzierung des Produktrisi-
kos, beginnend mit den ersten Projektphasen. Es enthält die Identifikation von Produktrisiken und ihre
Verwendung zur Führung der Testplanung und -steuerung sowie der Spezifikation, Vorbereitung und
Durchführung von Tests. Bei einem risikoorientierten Testvorgehen können die identifizierten Risiken
genutzt werden, um:
•
einzusetzende Testverfahren zu bestimmen
•
auszuführenden Testumfang zu bestimmen
•
Testen zu priorisieren mit dem Ziel, die kritischen Fehlerzustände so früh wie möglich zu fin-
den
•
zu bestimmen, ob zusätzlich zum Testen weitere Tätigkeiten zur Risikoreduktion notwendig
sind (z.B. die Bereitstellung von Schulungsmaßnahmen für unerfahrene Designer)
Risikoorientiertes Testen nutzt das Wissen und die Kenntnisse der Stakeholder, um Risiken zu identi-
fizieren, sowie entsprechende Teststufen zur Risikobehandlung zu bestimmen.
Um sicherzustellen, dass die Wahrscheinlichkeit von Produktfehlern minimiert wird, bietet das Risiko-
management einen systematischen Ansatz für:
•
Bewertung (und regelmäßige Neubewertung) dessen, was an Fehlern auftreten kann (Risi-
ken)
•
Festlegung, welche Risiken reduziert werden müssen
•
Implementierung von Maßnahmen zur Behandlung dieser Risiken
Zusätzlich kann Testen die Identifikation neuer Risiken unterstützen. Es kann helfen festzulegen, wel-
che Risiken reduziert werden sollten und es kann die Unsicherheit bezüglich der Risiken verringern.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 60/84
1.8.2011
© International Software Testing Qualifications Board
5.6 Fehler- und Abweichungsmanagement (K3)
40 Minuten
Begriffe
Abweichungsprotokollierung, Fehler- und Abweichungsbericht, Fehler- und Abweichungsmanagement
Hintergrund
Da eines der Ziele des Testens das Finden von Fehlerzuständen ist, müssen Unterschiede zwischen
aktuellen und erwarteten Ergebnissen als Abweichung aufgezeichnet werden. Eine Abweichung muss
untersucht werden. Sie kann sich als Fehlerzustand erweisen. Angemessene Maßnahmen sollten
definiert sein, um Abweichungen und Fehlerzustände zu beseitigen. Abweichungen und Fehlerzu-
stände sollten von der Entdeckung und Klassifizierung bis hin zur Korrektur und Überprüfung der Lö-
sung verfolgt werden. Um alle Abweichungen bis zum Abschluss zu verwalten, sollte die Organisation
einen Fehler- und Abweichungsmanagementprozess sowie Regeln für die Klassifizierung etablieren.
Abweichungen können während der Entwicklung, in Reviews, Tests sowie beim Einsatz von Software
festgestellt werden. Sie können im Code oder dem betriebenen System oder in jeder Art von Doku-
mentation festgestellt werden (einschließlich Anforderungen, Entwicklungsdokumente, Testdokumente
und Benutzerinformation wie „Hilfe” oder Installationsanleitungen).
Abweichungsberichte haben folgende Ziele:
•
Für die Entwickler und andere Parteien liefern sie Hinweise, um nach Bedarf die Identifikation,
Isolation und Korrektur zu ermöglichen.
•
Für den Testmanager sind sie ein Hilfsmittel zur Verfolgung der Systemqualität im Test und
des Testfortschritts.
•
Sie liefern Hinweise zur Testprozessverbesserung.
Ein Abweichungsbericht kann die folgenden Informationen enthalten:
•
Meldungsdatum, meldende Organisation und Autor
•
IST- und erwartete Ergebnisse
•
Identifikation des Testobjekts (Konfigurationsobjekt) und der Testumgebung
•
Software- oder Systemlebenszyklusprozess, in dem die Abweichung beobachtet wurde
•
Beschreibung der Abweichung, um Reproduzierbarkeit und Behebung zu ermöglichen (ein-
schließlich Protokoll, Datenbank-Dumps oder Screenshots)
•
Umfang und Grad der Auswirkung auf Stakeholder-Interessen
•
Klassifizierung der Schwere der Auswirkung auf das System
•
Dringlichkeit/Priorität für die Behebung
•
Status der Abweichung (z.B. offen, zurückgestellt, dupliziert, wartet auf Behebung, Behebung
wartet auf Fehlernachtest oder geschlossen)
•
Schlussfolgerungen, Empfehlungen und Freigaben
•
globale Punkte, beispielsweise andere Bereiche, die durch eine Änderung aufgrund der Ab-
weichung beeinflusst sein könnten
•
Änderungshistorie, was von Projektteammitgliedern im Zusammenhang mit der Abweichung
zur Isolation, Behebung und Bestätigung der Behebung durchgeführt wurde
•
Referenzen einschließlich der Testfallspezifikations-ID, welche das Problem aufdeckte
Der Aufbau eines Abweichungsberichts wird auch im ‘Standard for Software Test Documentation’
(IEEE Std 829-1998) behandelt.