Kapitel 2

• Für jede Entwicklungsaktivität gibt es eine zugehörige Testaktivität.

• Jede Teststufe hat ihre stufenspezifischen Ziele für den Test.

• Für eine vorgegebene Teststufe beginnen Testanalyse und Testentwurf bereits während der zuge- hörigen Entwicklungsaktivität.

• Tester nehmen an Diskussionen zur Definition und Verfeinerung von Anforderungen und des Ent- wurfs teil. Darüber hinaus sind sie am Review von Arbeitsergebnissen (z.B. Anforderungen, Archi- tekturdesign, User-Stories usw.) beteiligt, sobald erste Entwürfe dafür vorliegen.

• Frühes Testen

• Modifikation

• Migration

• Außerbetriebnahme

• Funktionen in Zyklen spezifiziert, entworfen, implementiert und getestet

• Sytem nicht "am Stück" erstellt, sondern in Inkrementen (Versionsstände, Zwischenlieferungen)

• Pro Iteration: neue Features/Funktionen, Änderungen, Verbesserung der Qualität des Systems

• Realisiert Testobjekt die geforderte Funktionalität korrekt und vollständig?

• Funktionalität gleichbedeutend mit Ein-/Ausgabe-Verhalten von Testobjekt

• Test der kleinsten Softwareinheit

Test, ob Zusammenspiel der Einzelteile funktioniert

• Testen eines integrierten Systems, um sicherzustellen, dass es spezifizierte Anforderungen erfüllt. [Hetzel]

• Fokus: spezifizierte Anforderungen vom Produkt erfüllt?

• Prüfung aus Sicht von Kunden und Anwendern

• Anforderungen vollständig und angemessen umgesetzt?

• Teststufe: je eine Instanz des Testprozesses

• Ziele und Arbeitsergebnisse

• Testbasis und Testobjekte

• Typische Fehlerzustände und Fehlerwirkungen

• Teststrategie und Testverfahren

• Testumgebung und Testwerkzeuge

• Verantwortlichkeiten und spezialisiertes Testpersonal

• Ziele des Gesamtsystems von Anfang an klar

• System iterativ überarbeitet, detailliert und ergänzt

• Inkrement: keine Untergrenze bzgl. sichtbaren Änderungsumfangs

• Annahme: TEilergebnisse nicht mehr ändern

• Systeme (inkl. Ziele) entsteht nach und nach mit den Inkrementen

• Features in Zyklen (mit festgelegter DAuer) spezifiziert, entworfen, implementiert und getestet

• pro Iteration lauffähgige, potenzielle auslieferbare Software

• Annahme: Leistungsmerkmale oder Projektumfang jederzeit änderbar

• Rational Unified Process (RAP): lange Iterationen, große Inkremente der Features

• Scrum: kurze Iterationen, Inkremente der Features klein

• Kanban: Iterationen mit oder ohne festgelegte Länge, ein einziges Feature bis zum Abschluss liefern oder Gruppen von Features in einem Release zusammenfassen

• Spiralmodell (oder Prototyping): erstellt "expreimentelle" Inkremente, einige werden später stark überarbeitet oder sogar weggeworfen

• pro Entwicklungsaktivität eine entsprechende Testaktivität

• Testaktivitäten so früh im Entwicklungszyklus wie möglich

• Tester früh einbinden: Definition der Anforderungen, Softwareentwurf, Review-Prozess von Anforderungen, Entwurfsdokumenten, User Stories, etc.

• Softwareentwicklungsmodelle and Projekt- und Produktcharakteristika anpassen

• Projektziele

• Art des zu entwickelnden Produkts

• Geschäftsprioritäten (z.B. Time-to-Market)

• Produkt- und Projektrisiken

• Kulturelle Aspekte

• Risikoreduktion

• Verifizierung der (nicht-)funktionalen Verhaltensweisen der Komponente

• Schaffen von Vertrauen in die Qualität der Komponente

• Finden von Fehlerzuständen in der Komponente

• Fehlerzustände nicht an höhere Teststufen weitergeben

• Prüfung von Korrektheit und Vollständigkeit der Implementierung: Komponente wird getestet, jeder Testfall deckt bestimmte Ein-/Ausgabe-Kombination (Teilfunktionalität) ab

• Test auf Robustheit

• alle Komponenteneigenschaften überprüfen

• Effizienz

• Wartbarkeit

• Arbeitsergebnisse des Feinentwurfs, Programmcode

• Komponenten, Unis oder Module

• Code, Datenstrukturen, Klassen

• Datenbankmodule

• fehlerhafter Code

• fehlerhafte Logik

• Berechnungsfehler

• Datenflussprobleme

• fehlende und falsch gewählte Programmpfade (z. B. vergessene Sonderfälle)

• Treiber/Testtreiber (Driver): Aufruf der Dienste des Testobjekts

• Platzhalter (Stub, Dummy): Simulation der Dienste, die das Testobjekt importiert

• Fehlerwirkungen in Schnittstellen finden

• Fehlerwirkungen im Zusammenspiel verschiedener Komponenten finden

• Verifizierung des (nicht-)funktionalen Verhaltens der Schnittstellen

• Vertrauen schaffen in Qualität der Schnittstellen

• Schnittstellenformaten passen nicht

• Dateien fehlen

• Entwickler haben System anders in Komponenten aufgeteilt als spezifiziert

• Software- und Systementwurf

• Sequenzdiagramme

• Spezifikationen von Schnittstellen und Kommunikationsprotokollen

• Anwendungsfälle

• Architektur auf Komponenten- oder Systemebene

• Workflows

• Externe Schnittstellendefinitionen (API)

• Subsysteme

• Datenbanken

• Infrastruktur

• Schnittstellen

• APIs

• Microservices

• nach Komponententest

• Fokus: Zusammenspiel von Komponenten

• meist Teil der kontinuierlichen Integration

• häufig in Verantwortung der Entwickler

• nach Systemtest (auch parallel zu Systemtest möglich)

• Fokus: Zusammenspiel der Systeme (inkl. Hardware), Pakete, Microservices

• auch Interaktionen und Schnittstellen von Dritten abdeckbar

• häufig in Verantwortung der Tester

• Komponente übermittelt falsche Daten, empfangende Komponente stürzt ab (Komponentenfehler, inkompatible Schnittstellenformate, Protokollfehler)

• Empfangende Komponenten interpretieren Daten falsch (funktionaler Fehler, widersprüchliche oder fehlinterpretierte Spezifikationen).

• Daten richtig übergeben, aber zum falschen Zeitpunkt (Timing-Problem) oder in zu kurzen Zeitintervallen (Durchsatz- oder Lastproblem).

• falsche / fehlende Daten, falsche Datenverschlüsselung

• Schnittstellenfehlanpassung

• Fehlerwirkungen in Kommunikation zwischen Komponenten

• Fehler bzgl. Bedeutung: Einheiten oder Grenzen der kommunizierten Daten

• Falsche (zeitliche) Abfolge von Schnittstellenaufrufen

• inklusive aller Fehlerzustände/wirkungen bei Komponentenintegrationstests

• Fehlende Konformität mit erforderlichen Richtlinien zur Informationssicherheit

• Inkonsistente Nachrichtenstrukturen zwischen den System

• Treiber aus Komponententest können wiederverwendet werden

• Monitore für Schnittstellenüberwachung können als zusätzliches Diagnoseinstrument verwendet werden

• Top-down-Integration: Beginn bei Komponenten, die andere aufruft, aber selbst nicht aufgerufen wird

• Bottom-up-Integration: Beginn mit elementaren Komponenten, die keine anderen aufrufen

• Ad-hoc-Integration: Komponenten in (zufälliger) Reihenfolge ihrer Fertigstellung integrieren

• Big-bang-Integration: Alles auf einmal am Ende integrieren

• Systemarchitektur

• Projektplan

• (Master-)Testkonzept

• Testmanager

• Fokus: spezifizierte Anforderungen vom Produkt erfüllt?

• Systemtest: Prüfung aus Sicht von Kunden und Anwendern

• Anforderungen vollständig und angemesen umgesetzt?

• Betrachtung des Systems als Ganzes

• Fehlerzustände nicht an höhere Teststufen / Produktion weitergeben

• Teilweise: Verifizierung der Datenqualität

• automatisierte Systemregressionstests zur Bestandssicherung

• Vertrauen in die Qualität des Systems als Ganzes schaffen

• Bereitstellung von Informationen für Freigabeentscheidung

• Verifizierung

• Validierung

• Funktionale und Nicht-Funktionale Anforderungen prüfen

• (Nicht-)Funktionale Anforderugnsspezifikationen

• Anwendungsfälle, Epics und User-Stories

• Risikoanalyseberichte

• Modelle des Systemverhaltens

• Dokumentation und Benutzeranleitungen

• Anwendungen

• Hardware/Softwaresysteme

• Betriebssysteme

• Systeme unter Test (SUT)

• Systemkonfiguration und Konfigurationsdaten

• Falsche Berechnungen

• Falsche / unterwartete (nicht-)funktionale Systemverhaltensweisen

• Falsche Kontroll- und/oder Datenflüsse innerhalb des Systems

• Versagen bei der korrekten oder vollständigen Ausführung von funktionalen End-to-End-Aufgaben

• Versagen des Systems bei der ordnungsgemäßen Arbeit in der Produktivumgebung

• System funktioniert nicht wie in Dokumentation beschrieben

• Testumgebung möglichst nahe der späteren Produktivumgebung

• möglichst die tatsächlich zum Einsatz kommende Hard- oder Software nutzen

• möglichst keine Platzhalter

• Anforderungsbasiertes Testen

• Geschäftsprozessbasiertes Testen

• Anwendungsfallbasiertes Testen

• Performanztest: Messung der Antwortzeit für Anwendugnsfälle (mit steigender Last)

• Lasttest: Verhalten eines Systems unter wechselnder Last - üblicherweise zwischen niedriger Last, typischer Last sowie Spitzenlast

• Volumen-/Massentest: Systemverhalten in Abhängigkeit zu Datenmenge prüfen (z. B. für sehr große Dateien)

• Stresstest: Beobachtung des Systemverhaltens bei Überlastung

• Test der (Daten-)Sicherheit: gegen unberechtigten Systemzugang oder Datenzugriff

• Zuverlässigkeitstest: Dauerbetrieb (Ausfälle pro Betriebsstunde bei Benutzungsprofil x, ...)

• Robustheitstest: gegenüber Fehlbedienung, Fehlprogrammierung, Hardwareausfall; Prüfung von Fehlerbehandlung und Wiederanlaufverhalten

• Kpmpatibilitätstest / Datenkonversionstest: Verträglichkeit mit vorhandenen Systeme prüfen; Import/Export von Datenbeständen

• Konfigurationstest: Fokus: Unterschiedliche Konfigurationen des Systems

• Gebrauchstauglichkeitstest / Benutzbarkeitstest: Prüfung der Bedienbarkeit, Verständlichkeit der Systemausgaben

• Prüfung der Dokumentation: Übereinstimmung mit Systemverhalten (z. B. Bedienungsanleitung)

• Prüfung auf Änderbarkeit / Wartbarkeit: Verständlichkeit der Entwicklungsdokumente, Systemstruktur, usw.

• Unklare Kundenanforderungen: Kundenanforderungen nirgendwo nachlesbar, Systemverhalten ohne Anforderungen nicht bewertbar

• Versäumte Entscheidungen: u.a. Offenbarung unterschiedlicher Ansichten beim nachträglichen Sammeln von Anforderungen

• Projekte scheitern: keine Anforderungen = keine klaren Ziele für Entwickler, Systemtest attestiert Scheitern des Projekts

• abschließender Test vor Inbetriebnahme der Software

• Fokus: Sicht/Urteil des Kunden/Anwenders; Erfüllung rechtlicher/regulatorischer Anforderungen

• Ziele: Vertrauen in Qualität des Systems schaffen, Validierung, Verifizierung

• Testkriterien: vertraglich festgeschriebene Abnahmekriterien

• Abnahmetest üblicherweise in simulierter Produktivumgebung

• Fokus auf betriebliche Aspekte: Backups/Recovery, (De-)Installation, Notfallwiederherstellung, Benutzerverwaltung, Performanz, ...

• Hauptziel: Vertrauen aufbauen, dass System in betrieblicher Umgebung auch unter schwierigen Bedingungen funktionsfähig bleibt

• Hauptziel: Vertrauen schaffen, dass das System die Bedürfnisse/Anforderungen der Benutzer erfüllt; die Geschäftsprozesse ohne Schwierigkeiten, Kosten oder Risiken ausführt

• Empfehlenswert: bei unterschiedlichen Anwendergruppe mit verschiedenen Erwartungen (Benutzerakzeptanztest für jede Anwendergruppe sinnvoll)

• Geschäftsprozesse, Anforderungen, Anwendungsfälle, User Stories

• Vorschriften, rechtliche Verträge und Standards

• System- oder Benutzerdokumentation, Installationsverfahren

• Risikoanalyseberichte

• Verfahren für Sicherung, Wiederherstellung, Disaster Recovery

• nicht-funktionale Anforderungen

• Datenbankpakete

• System unter Test (SUT)

• Systemkonfigurationen und Konfigurationsdaten

• Geschäftsprozesse

• Wiederherstellungssysteme und Hot Sites (Betriebskontinuität und Notfallwiederherstellung)

• Betriebs- und Wartungsprozesse

• Formulare

• Berichte

• Bestehende und konvertierte Produktionsdaten

• Nichterfüllung der Fach- oder Benutzeranforderungen

• Nichteinhaltung der Geschäftsregeln

• Nichterfüllung der vertraglichen oder regulatorischen Anforderungen

• Nicht-funktionale Einschränkungen: Informationssicherheit, Performanz, ...

• Alpha-Test: beim Hersteller durch Benutzer und unabhängigem Testteam

• Beta-Test (Feldtests): von Kunden an ihren eigenen Standorten durchgeführt

• stabile Vorabversionen an repräsentative Kunden geben

• Ziele: Fehler durch unbekannte/nicht spezifizierte Produktivumgebungen erkennen und ggf. beheben; Vertrauen bei Kunden aufbauen, dass sie System nutzen können

• Funktionale Tests

• Nichtfunktionale Tests

• Strukturelle Tests

• Änderungsbezogene Tests: Fehlernachtest, Regressionstest

• Funktionalität: *Was* soll das System leisten?

• prüft von außen sichtbares Verhalten

• *Wie gut* arbeitet das System?

• prüfen das von außen sicht- oder messbare Verhalten der Software

• strukturbasierte Tests: basieren auf interne Struktur / Architektur der Software

• Mögliche Grundlagen Kontroll/Datenfluss innerhalb ovn Komponenten, Aufrufhierarchie von Prozeduren, Modelle der Software

• Tests nach dem ein Fehlerzustand korrigiert wurde, um sicherzustellen, dass der Fehlerzustand tatsächlich behoben wurde

Tests nach Änderungen, um bestehende Funktionalität sicherzustellen, d. h. keine Fehlerzustände eingebaut oder bisher maskierte Fehler freigelegt wurden.

• Testen der Änderungen an einem laufenden System oder der Auswirkungen einer geänderten Umgebung auf ein laufendes System

• Test neuer Produktversionen

Der Prozess der Anpassung einer Komponente oder eines Systems nach der Auslieferung, um Fehlerzustände zu beheben, um Qualitätsmerkmale zu verbessern oder um es an eine veränderte Umgebung anzupassen.

• Modifikation: geplante Weiterentwicklung, Änderung der Umgebung, Fehlerbehebung, Verbesserung der Qualität

• Migration: Plattformen, Daten, Hardware, DB-Systeme, ...

• Außerbetriebnahme: Ablösung Des Systems, Datenmigration, Datenarchivierung

• 4-Augen-Prinzip

• verbessert Effektivität der Fehlerfindung

• Autoren und Tester haben unterschiedliche kognitive Ausrichtungen

• Alle Testfälle, die eine Fehlerwirkung aufgedeckt haben, müssen nach der Behebung der je- weiligen Ursachen nochmals getestet werden (Fehlernachtest). Ein Fehlernachtest wird durchgeführt, um sicherzustellen, dass eine Fehlerbehebung in der Software den gewünsch- ten Erfolg gebracht hat.

• Darüber hinaus sind weitere Testwiederholungen (Regressionstest) nötig, um sicherzustellen, dass die Fehlerbehebung bzw. Softwareänderung keinen negati- ven Einfluss auf bereits bestehende Funktionalität hatte, oder dass nicht weitere (bisher mas- kierte) Fehlerzustände freigelegt wurden.