1. Grundlagen des Testens
1.1. Die 7 Grundsätze des Testens
1.1.1. 1. Testen zeigt die Anwesenheit von Fehlerzuständen, nicht die Abwesenheit
1.1.2. 2. Vollständiges Testen ist nicht möglich
1.1.3. 3. Frühes Testen spart Zeit und Geld
1.1.4. 4. Häufung von Fehlerzuständen
1.1.5. 5. Vorsicht vor dem Pestizid-Paradoxon
1.1.6. 6. Testen ist kontextabhängig
1.1.7. 7. Trugschluss: "Keine Fehler" bedeutet ein brauchbares System
1.2. Testprozess
1.2.1. Testplanung
1.2.1.1. Erstellung Testkonzept!
1.2.2. Testüberwachung- und Teststeuerung
1.2.2.1. Verschiedene Arten von Testberichten
1.2.2.2. Testfortschrittsberichte
1.2.2.3. Testabschlussberichte
1.2.3. Testanalyse
1.2.3.1. Definierte & Priorisierte Testbedingungen
1.2.3.2. Ev. Bericht von Fehlerzuständen
1.2.4. Testentwurf
1.2.4.1. Testfälle
1.2.4.2. Sets von Testfällen
1.2.4.3. Identifikation nötiger Testdaten
1.2.4.4. Entwurf der Testumgebung
1.2.4.5. Identifizierung Infra & Werkzeuge
1.2.5. Testrealisierung
1.2.5.1. Testabläufe und Aneinanderreihung der Testabläufe
1.2.5.2. Testsuiten
1.2.5.3. Testausführungsplan
1.2.6. Testdurchführung
1.2.6.1. Dukumentation des Status der Testfälle und -abläufe
1.2.6.2. Fehlerbericht
1.2.6.3. Dokumentation über genutzte Werkzeuge usw.
1.2.7. Testabschluss
1.2.7.1. Testabschlussbericht
1.2.7.2. Testfortschrittsbericht
1.2.7.3. Offene Punkte zur Verbesserung
1.2.7.4. Change Requests, Product Backlog Elemente
2. Testen im Softwareentwicklungslebenszyklus
2.1. Testarten
2.1.1. Funktionale Tests
2.1.1.1. Bewerten funktionen, die das System ausführen soll --> Anforderungsspezifikationen
2.1.1.2. In allen Teststufen durchzuführen
2.1.1.3. Betrifft Verhalten der Software
2.1.1.4. Erfordert spezielle Kenntnisse des Fachproblems
2.1.2. Nicht funktionale Anforderugen
2.1.2.1. Gebrauchstauglichkeit
2.1.2.2. Performanz
2.1.2.3. IT-Sicherheit
2.1.2.4. Wie gut verhält sich das System?
2.1.3. White-Box-Tests
2.1.3.1. Leiten sich aus interner Struktur ab
2.1.4. Änderungsbezogenes Testen
2.1.4.1. Fehlernachtests: Beweisen, dass Fehlerzustand korrigiert wurde
2.1.4.2. Regressionstests: Weist nach, dass Änderung kein unerwünschtes Verhalten nach sich zieht
2.1.5. Wartungstests
2.2. Teststufen
2.2.1. Komponententest
2.2.1.1. Ziele
2.2.1.1.1. Risokoreduktion
2.2.1.1.2. Verifizierung Erfüllung funktionaler und nf Anforderungen
2.2.1.1.3. Finden Fehlerzustände
2.2.1.2. Testbasis
2.2.1.2.1. Feinentwurf
2.2.1.2.2. Code
2.2.1.2.3. Datenmodelle
2.2.1.2.4. Kompnentenspezifiationen (Anforderungen)
2.2.1.3. Testobjekte
2.2.1.3.1. Komponenten, Units, Module
2.2.1.3.2. Code und Datenstrukturen
2.2.1.3.3. Klassen
2.2.1.3.4. DB-Module
2.2.1.4. Gängige Fehlerzustände
2.2.1.4.1. Nicht korrekte Funktionalität
2.2.1.4.2. Datenflusprobleme
2.2.1.4.3. Inkorrekter Code
2.2.1.5. Ansätze und Verantwortlichkeiten
2.2.1.5.1. Üblicherweise vom Entwickler durchgeführt
2.2.1.5.2. Zugang zum Code muss gewährleistet sein
2.2.2. Integrationstest
2.2.2.1. Ziele
2.2.2.1.1. Risikoreduktion
2.2.2.1.2. Verifizieren, ob funkt und nf Verhaltensweisen der Schnittstellen der Soezifikation entsprechen
2.2.2.1.3. Vertrauen schaffen
2.2.2.1.4. Fehlerzustände in Schnittstellen finden
2.2.2.1.5. Verhindern, dass Fehler hochrutschen
2.2.2.2. Testbasis
2.2.2.2.1. Software- und Systementwurf
2.2.2.2.2. Sequenzdiagramme
2.2.2.2.3. Schnittstellenspezifikationen
2.2.2.2.4. Anwendungsfälle
2.2.2.2.5. Architektur auf Komponenten und Systemebene
2.2.2.2.6. Workflows
2.2.2.2.7. Externe Schnittstellendefinitionen
2.2.2.3. Testobjekte
2.2.2.3.1. Subsysteme
2.2.2.3.2. Datenbanken
2.2.2.3.3. Infrastruktur
2.2.2.3.4. SChnittstellen
2.2.2.3.5. APIs
2.2.2.3.6. Microservices
2.2.2.4. Gängige Fehlerzustände
2.2.2.4.1. Falsche Daten, fehlende Daten
2.2.2.4.2. Falsch angepasste Schnittstellen
2.2.2.4.3. Fehlerwirkungen in Kommunikation zwischen Komponenten
2.2.2.4.4. Nicht behandelte Fehlerwirkungen
2.2.2.4.5. Falsche Annahmen über Daten-Bedeutung
2.2.2.5. Ansätze und Verantwortlichkeiten
2.2.2.5.1. Konzentratin auf Integration selbst
2.2.2.5.2. Test der Kommunikation zwischen Modulen
2.2.2.6. Integrationsstrategien
2.2.2.6.1. Top-Down
2.2.2.6.2. Botom-Up
2.2.2.6.3. Ad-hoc-Integration
2.2.2.6.4. Backbone-Integration
2.2.2.6.5. Big Bang
2.2.3. Systemtests
2.2.3.1. Ziele
2.2.3.1.1. Verifizierung, ob funktionale und nf Verhaltensweisen des Systems der Spezifikation entsprechen
2.2.3.1.2. Validierung, ob System vollständig und wie erwartet funktioniert
2.2.3.1.3. Vertrauen in Qualität als Ganzes schaffen
2.2.3.1.4. Finden von Fehlerzuständen
2.2.3.1.5. Verhindern, dass Fehler nach oben gelangen
2.2.3.1.6. Infos an Stakeholder liefern, ob Freigabe möglich
2.2.3.2. Testbasis
2.2.3.2.1. System-Software-Anforderungsspezifikationen
2.2.3.2.2. Risikoanalyseberichte
2.2.3.2.3. Anwendungsfälle
2.2.3.2.4. Epics- und User-Stories
2.2.3.2.5. Modelle des Systemverhaltens
2.2.3.2.6. Zustandsdiagramme
2.2.3.2.7. System- und Benutzeranleitungen
2.2.3.3. Testobjekte
2.2.3.3.1. Anwendungen
2.2.3.3.2. Hardware- und Softwaresysteme
2.2.3.3.3. BS
2.2.3.3.4. Systeme under Test (SUT)
2.2.3.3.5. Systemkonfigurationen- und Konfigurationsdaten
2.2.3.4. Gängige Fehlerzustände
2.2.3.4.1. Falsche Berechnungen
2.2.3.4.2. Falsche funktionale oder nf Verhaltensweisen
2.2.3.4.3. Falsche Kontroll- oder Datenflüsse
2.2.3.4.4. Versagen bein der korrekten und Vollständigen Ausführung von funktionalen End-to-End Aufgaben
2.2.3.4.5. Versagen des Systems
2.2.3.4.6. System funktioniert nicht gemäss Anleitung
2.2.3.5. Ansätze & Verantwortlichkeiten
2.2.3.5.1. Werden von unabhängigen Testern durchgeführt
2.2.3.5.2. Starker Bezug zu Spezifikationen
2.2.3.5.3. Fehlerzustände in Spezifikationen sind fatal
2.2.4. Abnahmetests
2.2.4.1. Ziele
2.2.4.1.1. Vertrauen in Qualität als Ganzes schaffen
2.2.4.1.2. Validieren, ob System vollständig ist
2.2.4.1.3. Validieren, ob Spezifikation erfüllt ist
2.2.4.2. Testbasis
2.2.4.2.1. Geschäftsprozesse
2.2.4.2.2. Benutzer- und Fachanforderungen
2.2.4.2.3. Vorschriften
2.2.4.2.4. Anwendungsfälle
2.2.4.2.5. Systemanforderungen
2.2.4.2.6. System- und Benutzerdokumentation
2.2.4.2.7. Installationsverfahren
2.2.4.2.8. Risikoanalyseberichte
2.2.4.3. Testobjekte
2.2.4.3.1. System under TEst
2.2.4.3.2. Systemkonfigurationen
2.2.4.3.3. Geschäftsprozesse
2.2.4.3.4. Wiederherstellungssysteme
2.2.4.3.5. Bertiebs- und Wartungssysteme
2.2.4.3.6. Formulare
2.2.4.3.7. Berichte
2.2.4.3.8. Produktionsdaten
2.2.4.4. Gängige Fehlerzustände
2.2.4.4.1. Systemworkflows erfüllen nicht die Fach- und Benutzeranforderungen
2.2.4.4.2. Geschäftsregeln werden nicht korrekt umgesetzt
2.2.4.4.3. System erfüllt nicht die vertraglichen Anforderungen
2.2.4.5. Spezifische Ansätze und Verantwortlichkeiten
2.2.4.5.1. Abnahmetests liegen in Verantwortung des Kunden
2.2.4.6. Benutzerabnahmetest (UAT)
2.2.4.6.1. Können Benutzer das System verwenden
2.2.4.6.2. Sind Bedürfnisse und Anforderungen erfüllt?
2.2.4.7. Betrieblicher Abnahmetest (OAT)
2.2.4.7.1. Testen von Backups und Wiederherstellungen
2.2.4.7.2. Installieren, Aktualisieren, Deinstallieren
2.2.4.7.3. Notfallwiederherstellung
2.2.4.7.4. Benutzerverwaltung
2.2.4.7.5. Wartungsaufgaben
2.2.4.7.6. Migrationsaufgaben
2.2.4.7.7. Performanz
2.2.4.8. Vertraglicher und regulatorischer Abnahmetest
2.2.4.8.1. Sind die vertraglichen Kriterien erfüllt?
2.2.4.8.2. Sind die regulatorischen Kriterin erfüllt?
2.2.4.9. Alpha- und Betatests
2.2.4.9.1. Einholen von Rückmeldungen von Anwendern
2.2.4.9.2. Fehler werden gefunden, wenn Produmgebung schlecht nachzubauen
2.2.4.9.3. Alpha: Auf seiten des entwickelnden Unternehmens
2.2.4.9.4. Beta: Wird vom kaufenden Unternehmen durchgeführt
3. Statischer Test
3.1. Prüfbare Ergebnisse
3.1.1. Spezifikationen
3.1.2. Epics, User-Stories, Abnahmekriterien
3.1.3. Architektur- und Entwurfsspezifikationen
3.1.4. Code
3.1.5. Testmittel (Testkonzepte, Testfälle, usw.)
3.1.6. Benutzeranleitungen
3.1.7. Webseiten
3.1.8. Verträge, Projektpläne, Zeitpläne
3.1.9. Aufsetzen der Konfiguration
3.2. Wert
3.2.1. Wenn früh eingesetzt, werden Fehlerzustände früh erkannt
3.2.2. Erlaubt frühes finden von Fehlerzuständen
3.2.3. Prompte Behebung möglich
3.2.4. Verbesserung Entwurfsqualität
3.2.5. Erhöhung Entwicklungsproduktivität
3.2.6. Verbesserte Kommunitkaion in Reviewsitzungen
3.3. Reviewprozess
3.3.1. Aktivitäten
3.3.1.1. Reviewplanung
3.3.1.1.1. Definition Zweck & Umfang
3.3.1.1.2. Schätzung Aufwand und Zeitbedarf
3.3.1.1.3. Identifizieren der Revieweingenschaften
3.3.1.1.4. Auswahl der teilnehmenden Personen
3.3.1.1.5. Definition Eingangs- Endekriterien
3.3.1.1.6. Prüfung, ob Eingangskriterien erfüllt
3.3.1.2. Reviewbeginn (initiierung)
3.3.1.2.1. Verteilen des zu reviewenden Arbeitsergebnisses
3.3.1.2.2. Erläuterung des Umfangs, der Ziele, des Prozesses und der Rollen
3.3.1.2.3. Beantwortung von Fragen
3.3.1.3. Individuelles Review
3.3.1.3.1. Review des Arbeitsergebnisses
3.3.1.3.2. Aufzeichnung potentieller Fehlerzustände, Empfehlungen und Fragen
3.3.1.3.3. Reviewverfahren
3.3.1.4. Befundkommunikation und Analyse
3.3.1.4.1. Kommunikation identifiierter und potentieller Fehlerzustände
3.3.1.4.2. Analyse potentieller Fehlerzustände
3.3.1.4.3. Bewertung und Dokumentation von Qualitätsmerkmalen
3.3.1.4.4. Bewertung von Reviewbefunden gegenüber den Endekriterien, um Entscheidungen zu treffen (ablehnen, annehmen, Änderung notwendig)
3.3.1.5. Fehlerbehebung und Bericht
3.3.1.5.1. Fehlerberichte erstellen
3.3.1.5.2. Behebung von gefundenen Fehlerzuständen
3.3.1.5.3. Kommunikation von Fehlerzuständen an den Autor oder das Team
3.3.1.5.4. Aufzeichnen aktualisierter Status
3.3.1.5.5. Sammeln von Metriken
3.3.1.5.6. Prüfen, ob Endekriterien erfüllt sind
3.3.2. Rollen und Verantwortlichkeiten formales Review
3.3.2.1. Autor
3.3.2.1.1. Erstellt Arbeitsergebniss
3.3.2.1.2. Behebt gefundene Fehlerzustände
3.3.2.2. Management
3.3.2.2.1. Verantwortet Reviewplanung
3.3.2.2.2. Entscheidet über Reviewplanung
3.3.2.2.3. Legt Mitarbeiter, Budget und Fristen fest
3.3.2.2.4. Überwacht Kosteneffizienz
3.3.2.2.5. Trifft Steuerungsentscheidungen
3.3.2.3. Reviewmoderator
3.3.2.3.1. Stellt erfolgreichen Verlauf von Reviewsitzungen sicher
3.3.2.3.2. Vermittelt
3.3.2.3.3. Von ihm ist Erfolag abhängig
3.3.2.4. Reviewleiter
3.3.2.4.1. Übernimmt die Verantwortung des Reviews
3.3.2.4.2. Entscheidet, wer einbezogen wird
3.3.2.5. Gutachter (Reviewer)
3.3.2.5.1. Fachexperten
3.3.2.5.2. Stakeholder
3.3.2.5.3. Identifizieren potentielle Fehlerzustände
3.3.2.5.4. Können verchiedene Perspektiver vertreten
3.3.2.6. Protokollant
3.3.2.6.1. Erhebt gefundene Fehlerzustände
3.3.2.6.2. Erfasst neue pot. Fehlerzustände
3.3.2.6.3. Erfasst Entscheidungen und offene Punkte
3.4. Reviewarten
3.4.1. Informelles Review
3.4.1.1. Zweck: Erkennen von Fehlerzuständen:
3.4.1.2. Kein formaler Prozess
3.4.1.3. Möglicherweise keine Reviewsitzung
3.4.1.4. Kann von Kollegen des Autoren durchgeführt werden
3.4.1.5. Ergebnisse können dokumentiert werden
3.4.1.6. Nutzen variiert (abhängig vom Gutachter)
3.4.1.7. Nutzung von Checklisten ist optional
3.4.1.8. Sehr verbreitet in der agilen Entwicklung
3.4.2. Walkthrough
3.4.2.1. Zweck: Fehlerzustände finden, alternative Umsetzungen prüfen
3.4.2.2. Individuelle Vorbereitung ist optional
3.4.2.3. Reviewsitzung wird vom Autoren des Arbeitsergebnisses geleitet
3.4.2.4. Protokollant ist obligatorisch
3.4.2.5. Nutzung von Checklisten ist optional
3.4.2.6. Kann in Form von Szenarios, Dry Runs oder Somulationen durchgeführt werden
3.4.2.7. Protokolle werden erstellt
3.4.2.8. Kann von dehr informell bis sehr formal variieren
3.4.3. Technisches Review
3.4.3.1. Zweck: Gewinnen von Konsens, Autor befähigen, besser zu werden
3.4.3.2. Gutschter sollten fachspezifische Kokllegen des Autoren sein
3.4.3.3. Individuelle Voerbereitung erforderlich
3.4.3.4. Reviewsitzung optional
3.4.3.5. Protokollführung obligatorisch
3.4.3.6. Nutzung von Checklisten optional
3.4.3.7. Protokolle werden erstellt
3.4.4. Inspektion
3.4.4.1. Zwecke: Alles aus anderen
3.4.4.2. Folgt definiertem Prozess (sehr formal)
3.4.4.3. Nutzt klar definierte Rollen ( siehe Rollen oben)
3.4.4.4. Individuelle Vorbereitung erforderlich
3.4.4.5. Gutachter sind gleichrangig
3.4.4.6. Nutzung festgelegter Eingangs- und Endekriterien
3.4.4.7. Protokollant obligatorisch
3.4.4.8. Reviewsitzung wird von geschultem Moderator geleitet
3.4.4.9. Protokolle werden erstellt
3.4.4.10. Metriken werden gesammelt, um gesamten Entwicklungsprozess und Inspektionsprozess zu verbessern
3.5. Faktoren erfolgreiches Review
3.5.1. Organisatorisch
3.5.1.1. Klare Ziele, während Planung definiert
3.5.1.2. Nutzung passender Reviewarten
3.5.1.3. Nutzung passender Reviewverfahren
3.5.1.4. Checklisten decken Hauptrisiken ab
3.5.1.5. Grosse Dokumente werden in kleinen Happen geprüft
3.5.1.6. Teilnehmer erhalten genug Zeit zur Vorbereitung
3.5.1.7. Genug Vorankündigungszeit
3.5.1.8. Reviewprozess wird vom Management unterstützt
3.5.2. Personenbezogen
3.5.2.1. Richtige Personen sind involviert
3.5.2.2. Tester werden als wertgeschätzt Gutachter gesehen
3.5.2.3. Teilnehmer widmen Details genug Aufmerksamkeit
3.5.2.4. Reviews werden in kleinen Schritten durchgeführt
3.5.2.5. Objektive Behandlung von Fehlerzuständen
3.5.2.6. Meetings sind gut geleitet
3.5.2.7. Vertrauensvolle Atmosphäre
3.5.2.8. Keine negative Körpersprache
3.5.2.9. Angemessene Schulungen
3.5.2.10. Lernkultur wird gefördert
4. Testverfahren (dynamischer Test)
4.1. Black-Box-Testverfahren (spezifikationsbasierte Verfahren)
4.1.1. Merkmale
4.1.1.1. Testbedingungen, Testfälle und Testdaten werden aus Softwareanforderungen, Spezifikationen und Anwendungsfällen abgeleitet
4.1.1.2. Testfälle können genutzt werden . um Lücken zwischen den Anforderungen und deren Realisierung zu finden
4.1.1.3. Überdeckung wird anhand der getesteten Elemente gegen alle Elemente gemessen
4.1.1.4. Für funktionale wie auch nf Tests
4.1.1.5. Konzentrieren sich auf Ein- und Ausgaben des Testobjekts
4.1.1.6. Anwendbar auf allen Teststufen
4.1.2. Äquivalenzklassenbildung
4.1.2.1. Gültige Äquivalenzklassen
4.1.2.1.1. Werte, die von der Komponente oder System akzeptiert werden
4.1.2.1.2. Bsp: gÄK1: 0 <= X <= 15000; gÄK2: 15000 <= X <= 20000;
4.1.2.2. Ungültige Äquivalenzklassen
4.1.2.2.1. Werte, die von der Komponente nicht akzeptiert werden sollen
4.1.2.2.2. Bsp: üÄK1: x < 0
4.1.2.3. Für jede Äquivalenzklasse wir ein Repräsentatn gewählt
4.1.2.4. Äquivalenzklassen können für jedes Datenelement gebildet werden (Eingabe, Ausgabe, Schnittstellenparameter
4.1.2.5. Klassen können weiter verfeinert werden
4.1.2.6. Klassen sollen disjunkt sein
4.1.2.7. Überdeckung = # Klassen von denen Repräsentant getestet wurden / # Klassen
4.1.2.8. Für jede Klasse 1 Testfall
4.1.3. Grenzwertanalyse
4.1.3.1. Ist eine Erweiterung der Äquivalenzklassenbildung
4.1.3.2. Kann nur genutzt werden, wenn Klasse geordnet ist und aus numerischen oder sequentiellen Daten besteht
4.1.3.3. Minimum-Werte und Maximumwerte einer Klasse sind ohre Grenzwerte
4.1.4. Entscheidungstabellentests
4.1.4.1. Sinnvoll, um komplexe Regeln in Geschäftsprozessen zu erfassen
4.1.4.2. Identifikation von Bedingungen und daraus folgenden Ausgaben
4.1.4.3. Alle wichtigen Kombinationen von Bedingungne können identifiziert werden
4.1.4.4. Überdeckung = # Entscheidungsregeln getestet / # Entscheidungsregeln
4.1.4.5. Vorgehen
4.1.4.5.1. Alle n Bedingugen als ja/nein Entscheidungen definieren und alle möglichen Kombinationen auflisten. Anzahl = 2^n
4.1.4.5.2. don't care fälle streichen (sich ausschliessende Bedingungen)
4.1.4.5.3. Unter Aktionen alle möglichen Aktionen listen. Entsprechende Kreuze setzen
4.1.4.5.4. Tabelle konsolidieren (identische Testeingaben und ausgaben streichen)
4.1.4.5.5. Tests durchführen
4.1.5. Zustandsübergangstests
4.1.5.1. Basiert auf Vergangenheit einer Komponente (=Zustand)
4.1.5.2. Vorgehen: Aus Zustandsdiagramm Übergangstabelle erstellen
4.1.5.3. Möglichen Testfall mit Vorbedingung, Ereignis, Sollreaktion und Nachbedingung spezifizieren
4.1.5.4. Ereignis ist folge von EReignissen und daraus folgender Zustände
4.1.5.5. Häufig eingesetzt für GUI und Embedded Systeme
4.1.5.6. Überdeckung = # getesteter Zustandsübergänge / # ermittelte Zustandsübergänge
4.1.6. Anwendungsfalltests
4.1.6.1. Jeder Use-Case definiert ein bestimmtes Verhalten, welches mit einem oder mehreren Akteuren erreicht wird
4.1.6.2. Testfälle werden entworfen, um das spezifizierte Verhalten nachzuweisen
4.1.6.3. Überdeckung = # getesteter Anwendungsfallvarianten / Anzahl Anwendungsfallvarianten
4.2. White-Box-Testverfahren (strukturelle oder strukturbasierte Verfahren)
4.2.1. Merkmale
4.2.1.1. Testbedingungen, Testfälle und Testdaten werden aus Code, Softwarearchitektur und anderen Informationen zur STruktur der Software abgeleitet
4.2.1.2. Überdeckung wird auf Basis der getesteten Elemente innerhalb der Struktur gemessen
4.2.1.3. Basieren auf Analyse der Struktur des Testobjekts
4.2.1.4. Konzentrieren sich auf Struktur und Abläufe des Testobjekts
4.2.1.5. Ansendbar suf Komponenten- und Integrationstests
4.2.2. Anweisungsüberdeckung
4.2.2.1. Untersuchung aller potentiell ausführbaren Anweisungen im Code
4.2.2.2. Ziel: Alle Anweisungen ausführen
4.2.2.3. Es kann nie ausführbarer Code (Dead Code) gefunden werden
4.2.2.4. Vorgehen: Ausführungssequenz(en) finden, die allen Code zuer Ausführung bringen
4.2.2.5. Überdeckung = # ausgeführter Anweisungen / # Anweisungen
4.2.3. Entscheidungsüberdeckung
4.2.3.1. Untersuchungen aller Entscheiungen im Code
4.2.3.2. Testet Code, der aufgrund Entscheidungen im Code ausgeführt werden
4.2.3.3. Überdeckung = # durch Tests erreichter Entscheidungsergebnisse / Anzahl mögliche Entscheidungsergebnisse im Code
4.2.3.4. 100% Entscheidungsüberdeckung garantiert 100% Anweisungsüberdeckung
4.3. Erfahrungsbasierte Testverfahren
4.3.1. Merkmale
4.3.1.1. Testbedingungen, Testfälle unf Testdaten werden aus Kenntnissen und Erfahrungen der Tester abgeleitet
4.3.1.2. Wird oft mit Black- oder White-Box-Verfahren kombiniert
4.3.2. Intuitive Testfallermnittlung
4.3.2.1. Vermutet Fehlerzustände aufgrund von Erfahrungen der Tester
4.3.2.1.1. Wie funktionierte die Anwendung früher?
4.3.2.1.2. Welche Art von Fehlerhandlungen wurden gemacht
4.3.2.1.3. Welche Fehlerwirjungen traten in ähnlichen Anwendungen auf?
4.3.2.2. Methodischer Ansatz mittels Liste von Fehlhandlungen und anschliessendem Testentwurf daraus
4.3.3. Exploratives Testen
4.3.3.1. Dynamischer Entwurf informeller Tests während der Testdurchführung
4.3.3.2. Ergebnisse werden genutzt, um Verhalten des Testobjektes zu erfahren
4.3.3.3. Test-Charte mit Test-Zielen
4.3.3.4. Dort am Nützlichsten, wo ungenügende Spezifikationen oder grosser Zeitdruck existieren
4.3.4. Checklistenbasiertes Testen
4.3.4.1. Test entwerfen, um alle Testbedingungen aus einer Checkliste abzudecken
4.3.4.2. Checkliste soll erweitert und angepasst werden
4.3.4.3. Checklisten werden aufgrund von Erfahrungen erstellt
4.3.4.4. Können Hilfestellung sein, um ein gewisses Mass an Konsistenz zu erhalten
5. Testmanagement
5.1. Testorganisation
5.1.1. Unabhängiges Testen
5.1.1.1. Vorteile
5.1.1.1.1. Unabhängige Tester sehen anderes als die Entwickler
5.1.1.1.2. Unabhängige Tester können Annahmen der Stakeholder verifizieren, in Frage stellen oder widerlegen
5.1.1.1.3. Unabhängige Tester eines Anbieters können auf objektive Weise über das zu testende System berichten
5.1.1.2. Nachteile
5.1.1.2.1. Isolaton vom Entwicklungsteam kann zu fehlendem Zusammenhalt oder feindlichem Verhältnis führen
5.1.1.2.2. Entwickler können Qualitätsbewusstsein für eigenen Code verlieren
5.1.1.2.3. Unabhängige Tester können als Engpass angesehen werden
5.1.1.2.4. Unabhängigen Testern können wichtige Informationen fehlen
5.1.2. Aufgaben Test-Manager
5.1.2.1. Testrichtline und Teststrategie entwickeln oder prüfen
5.1.2.2. Testaktivitäten planen
5.1.2.3. Testkonzepte schreiben
5.1.2.4. Testkonzept mit Stakeholdern abstimmen
5.1.2.5. Einbringen der Testperspektive in andere Projektaktivitäten
5.1.2.6. Analyse, Entwurf, Realisierung und Durchführung von Tests anstossen
5.1.2.7. Testfortschritt und -ergebnisse überwachen
5.1.2.8. Stand der Endekriterien überprüfen
5.1.2.9. Berichte erstellen und verteilen
5.1.2.10. Planung anpassen
5.1.2.11. Massnahmen zur Teststeuerung einleiten
5.1.2.12. Aufsetzen Fehlermanagementsystem
5.1.2.13. Geeignete Metriken einführen
5.1.2.14. Werkzeuge auswählen
5.1.3. Aufgaben Tester
5.1.3.1. Testkonzepte prüfen
5.1.3.2. Anforderungen, User-Stories und Abnahmekriterien prüfen und beurteilen
5.1.3.3. Testbedingungen identifizieren und dokumentieren --> Verfolgbarkeit
5.1.3.4. Testumgebung entwerfen, einrichten und verifizieren
5.1.3.5. Testfälle und Testabläufe entwerfen und realisieren
5.1.3.6. Testdaten vorbereiten und beschaffen
5.1.3.7. Testausführungsplan erstellen
5.1.3.8. Tests durchführen und bewerten, Abweichungen dokumentieren
5.1.3.9. Geeignete Werkzeuge verwenden
5.1.3.10. Tests automatisieren
5.1.3.11. Nf- Eigenschaften bewerten
5.2. Testplanung- und schätzung
5.2.1. Testkonzept
5.2.1.1. Inhalt
5.2.1.1.1. Umfang, Ziele, Risiken der Tests
5.2.1.1.2. Festlegen der allgemeinen Testvorgehensweise
5.2.1.1.3. Integration und Koordination der Testaktivitäten un die Entwicklungsaktivitäten
5.2.1.1.4. Entscheidungen darüber, was zu testen ist und welche Personen dies tun sollen
5.2.1.1.5. Festlegen der Ressourcen
5.2.1.1.6. Planung der Aktivitäten zur Testanalyse, zum Entwurf, zur Realisierung sowie Durchführung und Bewertung der Tests
5.2.1.1.7. Auswahl der Metriken zur Testüberwachung und -steuerung
5.2.1.1.8. Festlegen des Budgets
5.2.1.1.9. Bestimmung des Detaillierungsgrad und der STruktur der Berichte
5.2.1.2. Zweck
5.2.1.2.1. Allgemeines Vorgehen festlegen
5.2.2. Teststrategien
5.2.2.1. Analytisch
5.2.2.1.1. Testentwurf aufgrund Analyse eines Faktors
5.2.2.1.2. Bsp: Risikobasiertes Testen
5.2.2.2. Modellbasiert
5.2.2.2.1. Tests werden aufgrund eines Modells eines geforderten Produktaspektes entworfen (z.B. Geschäftsprozess)
5.2.2.2.2. Bsp: Zustandsmodeltest
5.2.2.3. Methodisch
5.2.2.3.1. Vordefinierte Sets von Tests werden verwendet, um Teststrategie zu erstellen
5.2.2.4. Prozesskonforme (standardkonforme)
5.2.2.4.1. Tests aufgrund von Standards
5.2.2.5. Abgeleitete (oder beratende)
5.2.2.5.1. Teststrategie wird aufgrund von Experten bestimmt
5.2.2.6. Regressionsvermeidend
5.2.2.6.1. Motivation: Kein Verlust an vorhandener Leistungsfähigkeit
5.2.2.6.2. Wiederverwendung vorhandener Testmittel
5.2.2.6.3. Nutzung von Standardsuiten
5.2.2.7. Reaktiv
5.2.2.7.1. Reaktion auf Komponenten und System anstatt vorausplanend
5.2.2.7.2. Bsp: Exploratives Testen
5.2.3. Eingangskriterien
5.2.3.1. Verfügbarkeit testbarer Anforderungen
5.2.3.2. Verfügbarkeit Testelemente
5.2.3.3. Verfügbarkeit Testumgebung
5.2.3.4. Verfügbarkeit notwendiger Testwerkzeuge
5.2.3.5. Verfügbarkeiten Testdaten
5.2.4. Endekriterien
5.2.4.1. Geplante Tests wurden durchgeführt
5.2.4.2. Festgelegte Überdeckung erreicht
5.2.4.3. Anahl ungelöster Fehlerzustände akzeptabel
5.2.4.4. Bewertete Niveaus an nf-Anforderungen ausreichend
5.2.5. Testausführungsplan
5.2.5.1. Zuerst hoch priorisierte
5.2.5.2. Niedrig priorisierte auch zuerst, wenn hoch priorisierter von ihm abhängig
5.2.5.3. Tradeoff zwischen Effizienz und Priorisierunge, falls unterschiedliche Testfolgen möglich
5.2.6. Faktoren Testaufwand
5.2.6.1. Produkteigenschaften
5.2.6.1.1. Risiken, die mit dem Produkt einhergehen
5.2.6.1.2. Qualität der Testbasis
5.2.6.1.3. Grösse des Produkts
5.2.6.1.4. Komplexität des Produkteinsatzbereichs
5.2.6.1.5. Nf-Anforderungen
5.2.6.1.6. Geforderter Detaillierungsgrad Testdoku
5.2.6.1.7. Gesetzliche Anforderungen
5.2.6.2. Entwicklungsprozesseigenschaften
5.2.6.2.1. Stabilität und Reife der Organisation
5.2.6.2.2. Genutztes Entwicklungsmodell
5.2.6.2.3. Testvorgehensweise
5.2.6.2.4. Genutzte Werkzeuge
5.2.6.2.5. Testprozess
5.2.6.2.6. Zeitdruck
5.2.6.3. Menschliche Eigenschaften
5.2.6.3.1. Fähigkeit der beteiligten Personen
5.2.6.3.2. Teamzusammenhalt und Leitung
5.2.6.4. Testergebnisse
5.2.6.4.1. Anzahl und Schweregrad der Fehlerzustände
5.2.6.4.2. Menge erforderlicher Nachbesserungen
5.2.7. Aufwandschätzverfahren
5.2.7.1. Metrikbasiert
5.2.7.1.1. Schätzung auf Basis früherer, ähnlicher Projekte
5.2.7.1.2. Bsp: Team-Velocity aufgrund Burn-Down-Chart
5.2.7.2. Expertenbasiert
5.2.7.2.1. Schätzung auf Basis der für die Testaufgaben zuständiger Person oder Experten
5.2.7.2.2. Bsp: Planning Poker, Breitband-Delphi
5.3. Testüberwachung und -steuerung
5.3.1. Testmetriken
5.3.1.1. % der durchgeführten, geplanten Arbeit in der Testfallvorbereitung
5.3.1.2. % der durchgeführten, gaplanten Arbeit in der Testumgebungsvorbereitunge
5.3.1.3. Testfalldurchführung (Anzahl ausgeführter / nicht ausgeführter Testfälle)
5.3.1.4. Fehlerinformationen (Fehlerdichte)
5.3.1.5. Testüberdeckung der Anforderungen
5.3.1.6. Aufgabenfertigstellung, Ressourcenverteilung
5.3.1.7. Kosten des Testens
5.3.2. Testberichte
5.3.2.1. Zweck: Informationen über Testaktivitäten zusammenfassen und kommunizieren
5.3.2.2. Testfortschrittsbericht
5.3.2.2.1. Während der Testaktivität fabriziert
5.3.2.2.2. Status der Testaktivität und Fortschritt gegenüber dem Testkonzept
5.3.2.2.3. Den Testfortschritt behindernde Faktoren
5.3.2.2.4. Tests der nächsten Berichtsperiode
5.3.2.2.5. Qualität des Testobjekts
5.3.2.3. Testabschlussbericht
5.3.2.3.1. Zusammenfassung durchgeführte Tests
5.3.2.3.2. Informationen über Vorkommnisse während der Testperiode
5.3.2.3.3. Abweichungen vom Plan
5.3.2.3.4. Stand der Tests in Bezug auf die Endekriterien
5.3.2.3.5. Fortschrittsblockierende Faktoren
5.3.2.3.6. Metriken über Fehlerzustände
5.3.2.3.7. Restrisiken
5.3.2.3.8. Erzeugte wiederverwendbare Testarbeitsergebnisse
5.3.2.4. Zielgruppen
5.3.2.4.1. Entwickler: Technische Inhalte
5.3.2.4.2. Management: Eher Prozentzaheln
5.4. Konfigurationsmanagement unterstützt das Testen, indem...
5.4.1. ...alle Testelemente eindeutig identifiziert und versionskontrolliert sind sowie zueinander in Verbindung stehen
5.4.2. ...die Verfolgbarkeit im Testprozess gewährleistet wird
5.4.3. ... identifizierte Dokumente und Softwareelemente unmissverständlich in der Testdoku benannt sind
5.5. Risiken und Testen
5.5.1. Risikostufe = Eintretenswahrscheinlichkeit * Schadensausmass
5.5.2. Produktrisiken
5.5.2.1. Software arbeitet nicht gemäss Spezifikation
5.5.2.2. Nichterfüllung der gewünschten Funktionen gemäss Stakeholder
5.5.2.3. Systemarchitektur erfüllt die nf-Anforderungen nicht
5.5.2.4. Berechnung funktioniert unter bestimmten Umständen nicht
5.5.2.5. Schleifen nicht korrekt codiert
5.5.2.6. Antwortzeiten nicht angemessen
5.5.3. Projektrisiken
5.5.3.1. Projektprobleme
5.5.3.1.1. Verzögerung in der Lieferung
5.5.3.1.2. Ungenaue Schätzungen, Neuverteilung von Mitteln an andere Projekte
5.5.3.1.3. Späte Änderung an Anforderungen
5.5.3.2. Unternehmensprobleme
5.5.3.2.1. Fähigkeiten von Mtarbeitern ungenügend --> Schulungen nötig
5.5.3.2.2. Personalprobleme (Konflikte)
5.5.3.2.3. Nötiges Personal nicht verfügbar
5.5.3.3. Politische Prbleme
5.5.3.3.1. Tester können nicht ausreichend kommunizieren
5.5.3.3.2. Nichtwertschätzung des Testens
5.5.3.4. Technische Probleme
5.5.3.4.1. Anforderungen ungenügend definiert
5.5.3.4.2. Anforderungen können nicht erfüllt werden
5.5.3.4.3. Testumgebung zu spät verfügbar
5.5.3.4.4. Schwächen im Entwicklungsprozess
5.5.3.4.5. Schlechtes Fehlermanagement
5.5.3.5. Lieferantenprobleme
5.5.3.5.1. Drittanbieter liefert nicht
5.5.3.5.2. Vertragsprobleme
5.5.4. Produktrisikoanalyse
5.5.4.1. Bestimmt, welche Testverfahren genutzt werden
5.5.4.2. Bestimmen Teststufen und Testarten
5.5.4.3. Bestimmt Umfang von durchzuführenden Tests
5.5.4.4. Priorisiert Tests
5.5.4.5. Bestimmt zusätzliche Aktvitäten
5.6. Fehlermanagement
5.6.1. Fehlerbericht
5.6.1.1. enthält Fehlerzustände
5.6.1.2. Ziele
5.6.1.2.1. Entwicklern und anderen Beteiligten Informationen über jedes aufgetretene unerwünschte Ereignis geben
5.6.1.2.2. Probleme reproduzierbar machen
5.6.1.2.3. Testmanagern die Möglichkeit geben, die Qualität der Arbeitsergebnisse nachzuverfolgen
5.6.1.2.4. Ideen liefern, um Entwicklungs- und Testprozess zu verbessern
5.6.1.3. Inhalt Fehlerzustand
5.6.1.3.1. Identifikation
5.6.1.3.2. Referenzen
5.6.1.3.3. Klassifikation
5.6.1.3.4. Problembeschreibung
5.6.1.3.5. Historie
6. Werkzeugunterstützung
6.1. Testwerkzeuge
6.1.1. Management
6.1.1.1. Testmanagementwerkzeuge und Application-Lifecycle-Management-Werkzeuge
6.1.1.2. Anforderungsmanagementwerkzeuge
6.1.1.3. Fehlermanagementwerkzeuge
6.1.1.4. Konfigurationsmanagementerkzeuge
6.1.1.5. Werkzeuge zur kontinuierlichen Integration
6.1.2. statische Tests
6.1.2.1. Statische Analysewerkzeuge
6.1.3. Testentwurf und -realisierung
6.1.3.1. Testwerkzeuge für modellbasiertes Testen
6.1.3.2. Testdateneditoren und -generatoren
6.1.4. Testdurchführung und -protokollierung
6.1.4.1. Testausführungswerkzeuge
6.1.4.2. Überdeckungswerkzeuge
6.1.4.3. Testrahmen
6.1.5. Performanzmessung und dynamische Analyse
6.1.5.1. Performanztestwerkzeuge
6.1.5.2. Dynamische Analysewerkzeuge
6.1.6. Spezielle Testbedürfnisse
6.1.6.1. Werkzeuge zum Testen von nf-Anforderungen
6.1.7. Testautomatisierung
6.1.7.1. Nutzen
6.1.7.1.1. Reduktion sich wiederholender Arbeit --> Zeitersparnis
6.1.7.1.2. Höhere Konsistenz und Wiederholbarkeit
6.1.7.1.3. Objektivere Beurteilung (statische Masse, Überdeckung)
6.1.7.1.4. Vereinfachter Zugang zu Informationen über das Testen
6.1.7.2. Risiken
6.1.7.2.1. Unrealistische Erwartungen an das Werkzeug
6.1.7.2.2. Zeit, Kosten und Aufwand für die Einführung des Werkzeugs können unterschätzt werden
6.1.7.2.3. Man verlässt sich zu stark auf das Werkzeug
6.1.7.2.4. Versionskontrolle wird vernachlässigt
6.1.7.2.5. Interoperabilität zwischen Werkzeugen kann nicht gegeben sein
6.1.7.2.6. Werkzeuganbieter kann Arbeit einstellen
6.1.8. Testdurchführungs- und Testmanagementwerkzeuge
6.1.8.1. Testausführungswerkzeuge
6.1.8.1.1. Datengetrieben: Testansatz legt Testeingaben und erwartete Ergebnisse ab.
6.1.8.1.2. Schlüsselwortgetrieben: Generisches Skript verarbeitet Schlüsselworte und führt sie durch
6.1.8.1.3. Mitschnitt: Aufgezeichnetes Skript kann nicht mehr ausführbar sein
6.1.8.2. Testmanagementwerkzeuge
6.1.8.2.1. Benötigen Schnittstellen zu anderen Programmen (Informationen im richtigen Format bereitstellen, konsistente Verfolgbarkeit sicherstellen, Versionsinformationen richtig setzen
6.2. Effektive Nutzung von Testwerkzeugen
6.2.1. Hauptprinzipien für Auswahl
6.2.1.1. Bewertung der Reife des eigenen Unternehmens
6.2.1.2. Auswahl des Werkzeuges anhand der verwendeten Technologien
6.2.1.3. Verständnis der Werkzeuge
6.2.1.4. Bewertung des Werkzeugs gegen klar spezifizierte Anforderungen
6.2.1.5. Bewertung des Anbieters
6.2.1.6. Bewertung Schulungsbedarf
6.2.2. Ziele für die Nutzung von Pilotprojekten
6.2.2.1. Tiefgehende Kenntniss über das Werkzeug
6.2.2.2. Evaluierung, ob Werkzeug zu bestehenden Prozessen passt
6.2.2.3. Beurteilung, ob Nutzen die Kosten übersteigt
6.2.2.4. Metriken des Werkzeuges verstehen
6.2.3. Erfolgsfaktoren für Werkzeugeinsatz
6.2.3.1. Schrittweise Einführung
6.2.3.2. Anpassung und Verbesserung von Prozessen
6.2.3.3. Anbieten von Schulungsmassnahmen
6.2.3.4. Definition von Richtlinien zur Verwendung des Werkzeugs
6.2.3.5. Überwachung von Nutzung und Nutzen des Testobjekts
6.2.3.6. Sammeln von Erkenntissen der Benutzer