Inhalt dieser Lerneinheit

Im Rahmen dieser Lerneinheit werden sie mit den folgenden Themen vertraut gemacht:

• Grundlagen

• Testorganisation

• Testplanung und -Steuerung

• Testfortschrittsüberwachung und -Steuerung

• Konfigurationsmanagement

• Risiko und Testen

• Abweichungs- und Fehlermanagement

Grundlagen des Testmanagement

Definition und Ziele des Testmanagement

Testmanagement -Planung, Aufwandschätzung, Steuerung und Auswertung von Testaktivitäten, typischerweise durch einen Testmanager. -verantwortliche Personengruppe für den Test.

Testdokumente

Die Definition IEEE 829 Standard for Software Test Documentation ist ein vom IEEE (Institute of Electrical and Electronics Engineers) veröffentlichter Standard, der einen Satz von acht Basis-Dokumenten zur Dokumentation von Softwaretests beschreibt. Die aktuelle Version ist die IEEE 829-2008.[1] Der Standard beschreibt Form und Inhalt der jeweiligen Dokumente. Er schreibt jedoch nicht vor, welche der jeweiligen Dokumente zwingend verwendet werden müssen.

Im September 2013 wurden die ersten Teile des internationalen Standards ISO/IEC/IEEE 29119 veröffentlicht, der den IEEE 829 Standard for Software Test Documentation international ersetzt.

Open

Diese vier Dokumenttypen können zusammengefasst werden oder auf weitere Dokumenttypen aufgeteilt sein. Insgesamt sollten sie jedoch die gleichen Informationen enthalten.

Open

Der Einsatz und Entwurf für diese Testdokumente werden im Standard: «IEEE 829 - Standard for Software Test Documentation» beschrieben.

Die Definition IEEE 829 Standard for Software Test Documentation ist ein vom IEEE (Institute of Electrical and Electronics Engineers) veröffentlichter Standard, der einen Satz von acht Basis-Dokumenten zur Dokumentation von Softwaretests beschreibt. Die aktuelle Version ist die IEEE 829-2008.[1] Der Standard beschreibt Form und Inhalt der jeweiligen Dokumente. Er schreibt jedoch nicht vor, welche der jeweiligen Dokumente zwingend verwendet werden müssen.

Im September 2013 wurden die ersten Teile des internationalen Standards ISO/IEC/IEEE 29119 veröffentlicht, der den IEEE 829 Standard for Software Test Documentation international ersetzt.

Testorganisation

Testorganisation und Unabhängigkeit

Die folgenden Organisationsformen unterscheiden sich im Grad der Unabhängigkeit:

• kein unabhängiger Tester. Entwickler testen ihren eigenen Code

• unabhängige Tester innerhalb des Entwicklungsteams

• unabhängiges Testteam oder -gruppe innerhalb der Organisation, das/die dem Projektmanagement oder dem Management der Linienorganisation berichtet

• unabhängige Tester aus der Fachabteilung oder Anwendergruppe unabhängige Testspezialisten für spezifische Testarten, wie Tester für Benutzerfreundlichkeit, Sicherheits- oder Konformitätstester (die ein Softwareprodukt gegen Standards und gesetzliche Vorschriften prüfen)

• unabhängige Tester, ausgegliedert oder aus externen Organisationen

Vorteile von Unabhänigkeit

• Unabhängige Tester sehen andere und unterschiedliche Fehler und sind unvoreingenommen.

• Ein unabhängiger Tester kann Annahmen verifizieren, die während der Spezifikation und Implementierung des Systems gemacht wurden.

Nachteile von Unabhängigkeit

• Tester sind vom Entwicklungsteam isoliert (wenn als vollkommen unabhängig behandelt).

• Die Entwickler können das Verantwortungsgefühl für Qualität verlieren. Unabhängige Tester können als Engpass gesehen werden oder die Schuld für Verzögerungen zugewiesen bekommen.

Aufgaben von Testmanagern und Testern

Typische Aufgaben des Testmanagers

• Koordination der Teststrategie und Planung mit Projektleitern und anderen Beteiligten

• Erstellen oder Prüfen der Teststrategie für das Projekt und einer Testrichtlinie für die Organisation

• Einbringen der Testperspektive in andere Projektaktivitäten, beispielsweise die Integrationsplanung

• Planen der Tests – unter Beachtung des Kontexts und mit Verständnis von Testzielen und Risiken – einschließlich Auswahl der Testvorgehensweise, Schätzen der Zeit, des Aufwandsund der Kosten des Testens, Ressourcenbeschaffung, Definition der Teststufen, Testzyklen und Planen des Abweichungsmanagements

• Initiieren der Spezifikation, Vorbereiten, Implementieren und Durchführen von Tests, Überwachender Testergebnisse und Prüfen der Endekriterien

• Anpassen der Planung an Testergebnisse und Testfortschritt (manchmal in den Statusberichten dokumentiert) und Einleiten aller erforderlichen Maßnahmen bei Problemen Aufbau eines angemessenen Konfigurationsmanagements der Testmittel zur Rückverfolgbarkeit

• Einführen passender Metriken zum Messen des Testfortschritts und zur Bewertung der Qualität des Testens und des Produkts Entscheidung, was zu welchem Grad und wie automatisiert werden sollte

• Auswahl der Werkzeuge zur Testunterstützung und Organisation sämtlicher Werkzeugschulungen für Tester

• Entscheiden über die Implementierung der Testumgebung

• Schreiben von Testabschlussberichten auf der Grundlage der Informationen, die währenddes Testens gesammelt werden

Typische Aufgaben des Testers

• Mitarbeit an und Prüfung von Testkonzepten

• Analyse, Prüfung und Bewertung von Benutzeranforderungen, Spezifikationen und Modellen im Hinblick auf Testbarkeit

• Erstellen von Testspezifikationen

• Aufbau der Testumgebung (oft in Abstimmung mit System- und Netzwerkadministration).

• Vorbereiten oder Anfordern von Testdaten

• Implementieren von Tests auf allen Stufen, Durchführen der Tests und ihre Protokollierung, Auswerten der Testergebnisse und Dokumentation der Abweichungen von erwarteten Ergebnissen

• Einsetzen von Testadministrations- oder Testmanagement- und Testüberwachungswerkzeugen wie gefordert

• Automatisieren von Tests (kann durch einen Entwickler oder Testautomatisierungsexperten unterstützt werden)

• Messen der Leistungsfähigkeit/Performanz von Komponenten und Systemen (wenn zutreffend)

• Prüfen der Tests, die von anderen entwickelt wurden

Weitere Rollen beim Testen

Testdesigner (Testanalyst)

Erstellung von Testfällen anhand von Anforderungen, Spezifikationen und Systemmodellen

Test-Automatisierer

Automatisierung spezifizierter Tests

Test-Administrator

Bereitstellung und Betreuung der Testumgebung

Testplanung und -schätzung

Aktivitäten der Testplanung

• Festlegen des Umfangs und der Risiken sowie Identifizierung der Testziele

• Definieren des allgemeinen Testansatzes, einschließlich Definition der Teststufen und der Eingangs- und Endekriterien

• Koordinieren und Integrieren der Testaktivitäten in die Aktivitäten des Softwarelebenszyklus (Beschaffung, Bereitstellung, Entwicklung, Betrieb und Wartung)

• Entscheiden, was zu testen ist, welche Rollen welche Testaktivitäten ausführen werden, wann und wie die Testaktivitäten auszuführen sind und wie die Testergebnisse bewertet wer- denTestanalyse und Entwurfsaktivitäten planen

• Testimplementierung, -ausführung und -bewertung planen

• Ressourcen den verschiedenen definierten Aufgaben zuordnen

• Definieren des Umfangs, des Detaillierungsgrads, der Struktur und der Vorlagen für die Test- dokumentation

• Selektieren  der  Metriken  zur  Überwachung  und  Steuerung  der  Testvorbereitung  und -durchführung, Fehlerzustandsbehebung und Risikofaktoren

• Bestimmen des Detaillierungsgrads für Testablaufspezifikationen, um genügend Informatio- nen in Hinblick auf eine reproduzierbare Testvorbereitung und -durchführung zu liefern

Testeingangs- und Ausgangskriterien

Testeingangskriterien

Eingangskriterien bestimmen, wann der Test begonnen wird, beispielsweise zu Beginn einer Teststufe oder wenn eine Reihe Tests zur Ausführung bereit steht.

Typische Eingangskriterien:

• Verfügbarkeit und Einsatzbereitschaft der Testumgebung

• Bereitschaft der Testwerkzeuge in der Testumgebung

• Verfügbarkeit des testbaren Codes

• Verfügbarkeit der Testdaten

Endekriterien

Ausgangskriterien begegnen der Gefahr, dass die Testarbeiten zufällig beendet bzw. abgebrochen werden. Sie verhindern, dass der Test zu früh beendet wird, etwa aus Zeitdruck oder wegen Ressourcenmangels. Sie verhindern aber auch, dass zu ausufernd getestet wird.

Typische Endekriterien:

• Intensitätsmaße, beispielsweise Codeüberdeckung, Funktionalität oder Risiko

• Schätzungen über Fehlerdichte oder Zuverlässigkeitsmaße

• Kosten

• Verbleibende Risiken, beispielsweise nicht behobene Fehlerzustände oder fehlende Te- stüberdeckung in bestimmten Bereichen

• Zeitpläne, beispielsweise basierend auf dem Termin der Markteinführung

Inhalte eines Qualitätssicherungsplan IEEE 730

1. Zweck und Anwendungsbereich

2. Referenzierte Dokumente

3. Projektorganisation und Management

4. Dokumentation

5. Standards, Verfahren, Konventionen, Metriken

6. Software-Reviews

7. Softwaretests

8. Problemmelde- und Korrekturverfahren

9. Werkzeuge, Techniken und Methoden

10. Verwaltung der Medien und Datenträger

11. Lieferantenmanagement

12. Qualitätsaufzeichnungen

13. Trainingsmaßnahmen

14. Risikomanagement

15. Glossar

16. Änderungsverfahren und Änderungsverzeichnis

Inhalte eines Testkonzept nach IEEE 829-1998

• Testkonzeptbezeichnung

• Einführung

• Testobjekte

• Zu testende Leistungsmerkmale Leistungsmerkmale, die nicht getestet werden

• Teststrategie

• Abnahme- und Ausgangskriterien

• Kriterien für Testabbruch und Testfortsetzung

• Testdokumentation

• Testaufgaben

• Testinfrastruktur

• Verantwortlichkeiten/ Zuständigkeiten

• Personal, Einarbeitung, Ausbildung

Priorisierung von Tests (Kriterien)

• Nutzungshäufigkeit

• Fehlerrisiko

• Wahrnehmung

• Qualitätsmerkmale

• Entwicklung

• Komplexität

• Fehlerwirkung

Testaufwandschätzung

Zwei Ansätze für die Schätzung des Testaufwands sind:

• Der metrikenbasierte Ansatz: Schätzung des Testaufwands auf der Basis von Metriken früherer oder ähnlicher Projekte oder auf der Basis von typischen Werten

• Der expertenbasierte Ansatz: Schätzung des Aufwands für die einzelnen Aufgaben durch die Verantwortlichen für diese Aufgaben oder durch Experte

Sobald der Testaufwand geschätzt ist, können Ressourcen identifiziert und ein Zeitplan erstellt wer-den.

Der Testaufwand kann von einer Anzahl von Faktoren abhängen, u.a.:

• Charakteristiken des Produkts, Qualität der Spezifikation und anderer Informationen, die für das Testmodell herangezogen werden (d.h. die Testbasis), Größe des Produkts, Komplexität der Problembereiche, Anforderungen an Zuverlässigkeit und Sicherheit und Anforderungen an die Dokumentation

• Charakteristiken des Entwicklungsprozesses: Stabilität der Organisation, benutzte Werkzeu- ge, Testprozess, Kenntnisse der involvierten Personen und Zeitdruck

• Testergebnisse: Anzahl der Fehlerzustände und Menge der erforderlichen Nacharbeiten

Teststrategien und Vorgehensweisen

Eine Teststrategie definiert die Testziele und die Maßnahmen, die geeignet scheinen, diese zu erreichen. Sie bestimmt damit den Testaufwand und die Testkosten. Mit der Wahl der Teststrategie trifft der Testmanager eine seiner wichtigsten Entscheidungen. Ziel dabei ist, einen Maßnahmenmix zu finden, der die Relation zwischen Testkosten und drohenden Fehlerkosten optimiert und das Risiko minimiert.

Vorbeugender Ansatz, bei dem Tester ab Projektbeginn involviert werden. Testplanung und Testdesign beginnen frühestmöglich. Der Testmanager hat die Möglichkeit, optimierend und kostenreduzierend einzugreifen. Die Anwendung des allgemeinen V-Models mit Einsatz von z. B. Designreviews wird viel zur Vermeidung von Fehlern beitragen. Die frühzeitige Testspezifikation, Reviews und statische Analysetechniken helfen, Fehler frühzeitig zu entdecken, und reduzieren die Fehlerdichte beim späteren dynamischen Test. Bei der Entwicklung sicherheitskritischer Anwendungen kann ein vorbeugender Ansatz deshalb verpflichtend sein.

Reaktiver Ansatz, wenn Tester (zu) spät involviert werden und deshalb eine vorbeugende Herangehensweise nicht mehr möglich ist. Die Testplanung und der Testentwurf beginnen erst, nachdem das Softwaresystem schon erstellt ist. Dennoch muss ein Testmanager auch in einer solchen Situation eine Lösung finden. Eine in der Praxis sehr erfolgreiche Strategie ist »exploratives Testen«, ein heuristischer Ansatz, bei dem der Tester das Testobjekt »erkundet« und im Zuge der Erkundung Testentwurf, Testdurchführung und Testauswertung quasi simultan erfolgen (s. a. Abschnitt 5.3).Spillner, Andreas; Linz, Tilo. Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard (iSQI-Reihe) (German Edition) (Kindle-Positionen4688-4693). dpunkt.verlag. Kindle-Version.

Analytischer Ansatz: Die Testplanung stützt sich auf Daten und deren (mathematische) Analyse. Die in Abschnitt 6.3 besprochenen Einflussfaktoren werden (ausschnittsweise) quantifiziert und ihr wechselseitiger Zusammenhang modelliert. Testumfang und Intensität werden so gewählt, dass einzelne oder mehrere Parameter (Kosten, Zeitbedarf, Testüberdeckung etc.) optimiert werden.

Heuristischer Ansatz: Die Testplanung stützt sich auf Erfahrungswissen (beteiligter oder externer Experten) und/ oder auf Daumenregeln, weil keine Daten verfügbar sind, weil die Modellbildung zu aufwendig ist oder weil das nötige Know-how fehlt.

Herangehensweise in der Praxis

• Modellbasiertes Testen nutzt abstrakte funktionale Modelle des Testobjekts zur Ableitung von Testfällen, zur Definition von Ausgangskriterien und zur Messung der Testüberdeckung. Ein Beispiel ist der zustandsbezogene Test, wo Zustandsautomaten als Modelle dienen.

• Beim statistischen (modellbasierten) Test werden statistische Modelle über die Verteilung von Defekten im Testobjekt, über Ausfallraten im Betrieb der Software (Zuverlässigkeitsmodelle) oder über die statistische Verteilung von Anwendungsfällen (Einsatz- bzw. Benutzungsprofile) zur Bestimmung der Teststrategie herangezogen. Mit Hilfe der ermittelten Daten werden eine entsprechende Verteilung der Testaktivitäten und die Auswahl der Testmethoden festgelegt.

• Risikoorientiertes Testen nutzt Informationen über Projekt- und Produktrisiken und legt den Testschwerpunkt auf Bereiche hohen Risikos. Näheres zum risikoorientierten Test ist im nächsten Abschnitt beschrieben.

• Prozess- oder standardkonforme Ansätze (z. B. V-Modell oder IEEE 829) nutzen Handlungsanweisungen oder Empfehlungen78, die bei der Festlegung der Teststrategie als eine Art »Kochrezept« genutzt werden können.

• Beim wiederverwendungsorientierten Ansatz übernimmt man vorhandene Tests und Testumgebungen (aus früheren Projekten) als Ausgangsbasis. Ziel ist, die Tests schnell und pragmatisch aufzusetzen.

• Ein checklistenorientierter Ansatz nutzt Fehlerlisten aus früheren Testzyklen79, Listen potenzieller Fehler oder Risiken80 oder priorisierte Qualitätskriterien und andere wenig formelle Methoden.

• Der expertenorientierte Ansatz nutzt die Expertise und das »Bauchgefühl« beteiligter Experten. Ihre »Einstellung« zu den eingesetzten Technologien und/ oder zur Anwendungsdomäne beeinflusst und steuert die Auswahl der Teststrategie.

Testfortschrittsüberwachung und -steuerung

Testfortschrittsüberwachung

Testfortschrittsüberwachung

Das Ziel der Testfortschrittsüberwachung ist es, Feedback und Übersicht über Testaktivitäten zu lie- fern. Zu überwachende Informationen können manuell oder automatisiert gesammelt werden. Sie können herangezogen werden, um Endekriterien wie Testüberdeckung zu messen sowie den Fort- schritt gegen den Zeitplan und gegen das Budget zu beurteilen.

Gebräuchliche Testmetriken sind u.a.:

• Prozentsatz der durchgeführten Arbeiten in der Testvorbereitung (oder Prozentsatz der vorbe- reiteten geplanten Testfälle)

• Prozentsatz der durchgeführten Arbeiten in der Vorbereitung der Testumgebung

• Testfalldurchführung (z.B. die Anzahl der durchgeführten/nicht durchgeführten Testfälle und der bestandenen/nicht bestandenen Testfälle)

• Fehlerzustandsinformationen (z.B. Fehlerdichte, gefundene und behobene Fehlerzustände, Ausfallrate und Fehlernachtestergebnisse)

• Testüberdeckung der Anforderungen, Risiken oder des Codes

• subjektives Vertrauen der Tester in das Produkt

• Daten der Testmeilensteine

• Testkosten, inklusive Kosten im Vergleich zum Nutzen durch das Auffinden des nächsten Fehlerzustands oder für den nächsten Testdurchlauf

Testberichterstattung

Testberichterstattung

Testberichterstattung beschäftigt sich mit der Zusammenfassung der Informationen über die Testakti- vitäten, einschließlich:

• was während des Testzeitraums passierte, z.B. zu Zeitpunkten, an denen Endekriterien erfüllt wurden

• analysierte Informationen und Metriken zur Unterstützung von Empfehlungen und Entschei- dungen über zukünftige Aktivitäten, wie eine Beurteilung der verbleibenden Fehlerzustände, die ökonomischen Vorteile fortgesetzten Testens, offen stehende Risiken und der Grad des Vertrauens in die getestete Software

Die Gliederung eines Testabschlussberichts ist im ‘Standard for Software Test Documentation’ (IEEE Std 829-1998) enthalten.

Metriken sollten während des Testens und am Ende einer Teststufe zur Beurteilung folgender Aspekte gesammelt werden:

• Angemessenheit der Testziele für die Teststufe

• Angemessenheit des gewählten Testvorgehens

• Effektivität des Testens in Relation zu den Zielen

Teststeuerung

Teststeuerung beschreibt sämtliche Führungs- oder Korrekturmaßnahmen, die auf Grund gesammelter oder berichteter Informationen und Metriken ergriffen werden. Maßnahmen können jede Testaktivität betreffen und können jede andere Softwarelebenszyklusaktivität oder -aufgabe beeinflussen.

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 Testumgebung

• Setzen eines Eingangskriteriums mit der Maßgabe, dass Fehlerbehebungen durch einen Entwickler nach zu testen sind, bevor die Software an die nächste Teststufe übergeben wird

Konfigurationsmanagement

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.

Risiko und Testen

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 Auswirkung eines unerwünschten Ereignisses (Schaden, der aus dem Ereignis resultiert).

Projektrisiken

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

  • Probleme mit Testern, die ihre Anforderungen und Ergebnisse kommunizieren

  • Versagen des Teams bei der Verfolgung von Informationen, die durch Testen und in Reviews gefunden werden (z.B. fehlende Verbesserung der Entwicklungs- und Testpraktiken)

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

Produktrisiken

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)

• 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überwachung 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 proaktive Möglichkeiten zur Reduzierung des Produktrisikos, 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.

Fehler- und Abweichungsmanagement

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

Testprotokoll

Nach jedem Testlauf, spätestens mit Ende eines Testzyklus, erfolgt eine Auswertung der angefallenen Testprotokolle. Die Protokolle werden auf Abweichungen zwischen vorausgesagtem Sollverhalten und beobachtetem Istverhalten untersucht. Wird der Test automatisiert durchgeführt, dann erfolgt der Vergleich zwischen Soll- und Istverhalten (bzw. Soll- und Istergebnis) in aller Regel sofort durch das Werkzeug. Jedes signifikante, nicht vorausgesagte Ereignis, das während des Testens aufgetreten ist, kann ein Symptom sein, das auf ein Fehlverhalten des Testobjekts hindeutet. Entsprechende Stellen im Testprotokoll werden analysiert. Die Tester vergewissern sich, ob tatsächlich eine Abweichung im Sollverhalten vorliegt oder ob die Ursache ein falsch entworfener Testfall, eine fehlerhafte Testautomatisierung oder eine falsche Testausführung war (auch Testern können Fehlhandlungen unterlaufen). Fehler dokumentieren Liegt das Problem im Testobjekt83, wird über die Beobachtung eine Problemmeldung oder Fehlermeldung erstellt. Dies geschieht für jede im Testprotokoll enthaltene und vom Sollwert bzw. Sollverhalten abweichende Beobachtung. Eventuell ist die Beobachtung ein Duplikat einer schon früher erfassten Beobachtung. Dann muss geprüft werden, ob aus der zweiten Beobachtung zusätzliche Informationen zu entnehmen sind, die die Problemursache ggf. weiter eingrenzen können. Andernfalls erfolgt keine zweite Meldung, um Mehrfachnennungen ein und derselben Fehlerwirkung zu vermeiden. Ursachenanalyse ist Aufgabe der Entwickler Die Tester müssen allerdings nicht die Ursache des gemeldeten Problems herausfinden. Dies ist Aufgabe der Entwickler (Debugging).

Fehlermeldung

Üblicherweise wird im Projekt eine zentrale Fehlerdatenbank eingerichtet, in der alle Probleme, Mängel oder Fehlerwirkungen, die im Test (oder auch später im Betrieb) entdeckt werden, erfasst und verwaltet werden. Fehlermeldungen können von allen an der Entwicklung beteiligten Personen, aber auch von Kunden- und Anwenderseite eingebracht werden. Sie können sich auf Probleme in den getesteten Programm( teil) en beziehen, aber auch auf Fehler oder Mängel in Spezifikationen, Benutzerhandbüchern oder anderen Dokumenten. Das Fehlermeldeverfahren wird oft auch Problemmeldeverfahren genannt. Denn gemeldet werden alle offenen Probleme; aber nicht jedes Problem muss ein Fehler (der Entwickler) sein. Problemmeldung klingt auch weniger nach »Schuldzuweisung«. Es ist keine Einbahnstraße, sondern jeder Entwickler kann betreffende Meldungen kommentieren, etwa um Rückfragen an den Tester zu richten oder eine unberechtigte Meldung zurückzuweisen. Nimmt ein Entwickler aufgrund einer Fehlermeldung eine Korrektur am Testobjekt vor, so wird er dies ebenfalls in der Fehlerdatenbank dokumentieren, damit der zuständige Tester diese Korrektur im nächsten Testzyklus nachvollziehen und erneut testen kann. Testmanager und Projektmanager können sich mittels Fehlerdatenbank zu jedem Zeitpunkt ein aktuelles und vollständiges Bild über Anzahl und Status der Fehler und über den Korrekturfortschritt verschaffen. Die Datenbank stellt hierzu entsprechende Auswertungen zur Verfügung.

Aufbau einer Fehlermeldung

Klassifikation von Fehlern

Priorisierung von Fehlern

Status von Fehlern

Fehlerstatusmodell

Konfigurationsmanagement

Ein Softwaresystem besteht aus einer Vielzahl von Einzelbausteinen, die zueinander passen müssen, damit das System als Ganzes funktioniert. Von jedem dieser Bausteine entstehen im Laufe der Entwicklung des Systems neue, korrigierte oder verbesserte Versionen oder Varianten. Da an diesem Prozess mehrere Entwickler und Tester parallel beteiligt sind, ist es alles andere als einfach, den Überblick zu behalten, welche Bausteine aktuell sind und zusammengehören.