Software tester Flashcards
SLM
- 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 zugehörigen Entwicklungsaktivität.
- Tester nehmen an Diskussionen zur Definition und Verfeinerung von Anforderungen und des Entwurfs teil.
Darüber hinaus sind sie am Review von Arbeitsergebnissen (z.B. Anforderungen, Architekturdesign, User-Stories usw.) beteiligt, sobald erste Entwürfe dafür vorliegen.
Sequenzielle Entwicklungsmodelle
- jede Phase im Entwicklungsprozess erst beginnen sollte, wenn die vorherige Phase abgeschlossen ist.
- Theoretisch gibt es keine Überlappung der Phasen.
- In der Praxis ist es aber von Nutzen, aus der folgenden Phase eine frühe Rückmeldung zu erhalten.
- Wasserfallmodell
- V-Modell
Iterative und inkrementelle Entwicklungsmodelle
Rational Unified Process:
Rational Unified Process:
• Jede Iteration ist tendenziell relativ lang (z.B. zwei bis drei Monate) und die
• Inkremente der Features sind entsprechend groß (z.B. zwei oder drei Gruppen zusammengehörender Features).
Scrum
•Jede Iteration ist tendenziell eher kurz (z.B. Stunden, Tage oder einige Wochen)
• Inkremente der Features sind entsprechend klein (z.B. einige Verbesserungen und/oder zwei oder drei neue Features).
Kanban:
•Implementierung mit Iterationen mit oder ohne festgelegten Länge.
• Sie liefert entweder eine einzige Verbesserung oder ein einziges vollständiges Feature oder Gruppen von Features zusammengefasst in einem Release.
Spiralmodell:
•Beinhaltet das Schaffen von experimentellen Inkrementen, von denen einige in den folgenden Iterationen stark überarbeitet oder sogar aufgegeben werden müssen.
SLM Teststüfe
- Komponententest
- Integrationstest
- Systemtest
- Abnahmetest
Für jede Teststufe ist eine passende Testumgebung erforderlich
Komponententest
Ziele
• Risikoreduktion
• Verifizierung, ob die funktionalen und nicht-funktionalen Verhaltensweisen der Komponente dem Entwurf und der Spezifikation entsprechen
• Schaffen von Vertrauen in die Qualität der
Komponente
• Finden von Fehlerzuständen in der Komponente
• Verhindern, dass Fehlerzustände an höhere Teststufen weitergegeben werden In manchen Fällen, insbesondere in inkrementellen und iterativen Entwicklungsmodellen (z.B. agilen Entwicklungsmodellen), in denen Codeänderungen stetig erfolgen, spielen automatisierte Komponentenregressionstests eine Schlüsselrolle.
Testbasis • Feinentwurf • Code • Datenmodelle • Komponentenspezifikationen
Testobjekte • Komponenten, Units oder Module • Code und Datenstrukturen • Klassen • Datenbankmodule
Gängige Fehlerzustände und Fehlerwirkungen
• Nicht korrekte Funktionalität
• Datenflussprobleme
• Nicht korrekter Code und nicht korrekte Logik
Integrationstest
Ziele
• Risikoreduktion
• Verifizierung, ob die funktionalen und nicht-funktionalen Verhaltensweisen der Schnittstellen dem Entwurf und der Spezifikation entsprechen
• Vertrauen schaffen in die Qualität der Schnittstellen
• Fehlerzustände finden (die in den Schnittstellen selbst oder innerhalb der Komponenten oder des Systems liegen können)
• Verhindern, dass Fehlerzustände an höhere Teststufen weitergegeben werden
Testbasis
• Software- und Systementwurf
• Sequenzdiagramme
• Spezifikationen von Schnittstellen und
Kommunikationsprotokollen • Anwendungsfälle • Architektur auf Komponenten- oder Systemebene • Workflows • Externe Schnittstellendefinitionen
Testobjekte • Subsysteme • Datenbanken • Infrastruktur • Schnittstellen • APIs • Microservices
Fehlerzustände und Fehlerwirkungen
- Falsche Daten, fehlende Daten oder falsche Datenverschlüsselung
- Falsche Reihenfolge oder fehlerhafte zeitliche Abfolge von Schnittstellenaufrufen
- Falsch angepasste Schnittstellen
- Fehlerwirkungen in der Kommunikation zwischen Komponenten
- Nicht behandelte oder nicht ordnungsgemäß behandelte Fehlerwirkungen in der Kommunikation zwischen den Komponenten
- Nicht korrekte Annahmen über die Bedeutung, Einheiten oder Grenzen der Daten, die zwischen den Komponenten hin- und hergereicht werden
für Systemintegrationstests sind u.a.:
• Inkonsistente Nachrichtenstrukturen zwischen den Systemen
• Falsche Daten, fehlende Daten oder falsche Datenverschlüsselung
• Falsch angepasste Schnittstellen
• Fehlerwirkungen in der Kommunikation zwischen den Systemen
• Nicht behandelte oder nicht ordnungsgemäß behandelte Fehlerwirkungen in der Kommunikation zwischen den Systemen
• Falsche Annahmen über die Bedeutung, Einheiten oder Grenzen der Daten, die zwischen den Systemen hin- und hergereicht werden
• Fehlende Konformität mit erforderlichen Richtlinien zur IT-Sicherheit
Abnahmetest
Ziele
• Vertrauen in die Qualität des Systems als Ganzen aufbauen
• Validieren, ob das System vollständig ist und wie erwartet funktionieren wird
• Verifizieren, ob funktionale und nicht-funktionale Verhaltensweisen des Systems den Spezifikationen entsprechen Der
Häufige Ausprägungen von Abnahmetests sind u.a.:
• Benutzerabnahmetest
• Betrieblicher Abnahmetest
• Vertraglicher und regulatorischer Abnahmetest
• Alpha- und Beta-Test
Testbasis • Geschäftsprozesse • Benutzer- oder Fachanforderungen • Vorschriften, rechtliche Verträge und Standards • Anwendungsfälle und/oder User Stories • Systemanforderungen • System- oder Benutzerdokumentation • Installationsverfahren • Risikoanalyseberichte • Sicherungs- und Wiederherstellungsverfahren • Disaster-Recovery-Verfahren • Nicht-funktionale Anforderungen • Betriebsdokumentation • Bereitstellungs- und Installationsanweisungen • Performanzziele • Datenbankpakete • Standards oder Vorschriften bzgl. IT-Sicherheit
Typische Testobjekte
• System unter Test (SUT)
• Systemkonfigurationen und Konfigurationsdaten
• Geschäftsprozesse des vollintegrierten Systems
• Wiederherstellungssysteme und Hot Sites (für Tests zur Business-Continuity (Betriebskontinuität) und Notfallwiederherstellung)
• Betriebs- und Wartungsprozesse
• Formulare
• Berichte
• Bestehende und konvertierte Produktionsdaten
Fehlerzustände und Fehlerwirkungen
• Systemworkflows erfüllen nicht die Fach- oder Benutzeranforderungen
• Geschäftsregeln wurden nicht korrekt umgesetzt
• Das System erfüllt nicht die vertraglichen oder regulatorischen Anforderungen
• Nicht-funktionale Fehlerwirkungen wie IT-Sicherheitsschwachstellen, nicht angemessene Performanz unter hoher Last oder nicht ordnungsgemäßer Betrieb auf einer unterstützten Plattform
Spezifische Ansätze und Verantwortlichkeiten
Der Abnahmetest liegt häufig in der Verantwortung der Kunden, Fachanwender, Product Owner oder Betreiber eines Systems. Andere Stakeholder können ebenfalls mit einbezogen werden.
Der Abnahmetest wird oft als die letzte Stufe in einem sequenziellen Entwicklungslebenszyklus verstanden, er kann aber auch zu anderen Zeitpunkten stattfinden, z.B.:
• Der Abnahmetests eines kommerziellen Standardsoftwareprodukts kann zum Zeitpunkt der Installation oder Integration stattfinden
• Der Abnahmetest einer neuen funktionalen Verbesserung kann vor dem Systemtest stattfinden
Testarten
Funktionale Tests
Nicht-funktionale Tests
White-Box
Änderungsbezogenes Testen
Funktionale Tests
- „was” das System tun sollte
- sollten in allen Teststufen durchgeführt werden
- Black-Box-Verfahren
- Gründlichkeit von funktionalen Tests kann durch die funktionale Überdeckung gemessen werden
Nicht-funktionale Tests
•wie gut“ das System sich verhält
•in allen Teststufen früh wie möglich durchgeführt werden
•Black-Box-Verfahren
Gründlichkeit von nicht-funktionalen Tests kann durch die nicht-funktionale Überdeckung gemessen werden
•Nicht-funktionale Überdeckung ist der Grad, zu dem einige Arten von nicht-funktionalen Elementen durch Tests ausgeführt wurden, und wird als Prozentsatz der Arten der Elemente ausgedrückt, die abgedeckt sind.
White-Box-Tests
- internen Struktur
- Gründlichkeit von White-Box-Tests kann durch strukturelle Überdeckung gemessen werden
- Strukturelle Überdeckung ist der Grad, zu dem einige Arten von strukturellen Elementen durch Tests ausgeführt wurden, und wird ausgedrückt durch den Prozentsatz der Elementart, die übergedeckt wurde.
Änderungsbezogenes Testen
- Fehlernachtests
* Regressionstests
Wartungstest
Auslöser für Wartung
• Modifikation
• Migration
• Außerbetriebnahme
• Wiederherstellungsverfahren nach der Archivierung
• um sicherzustellen, dass jede Funktionalität, die in Betrieb bleibt, weiterhin funktioniert
Auswirkungsanalyse für Wartung
Die Auswirkungsanalyse kann schwierig sein, wenn:
• Spezifikationen (z.B. Fachanforderungen, User-Stories, Architektur) veraltet sind oder fehlen
• Testfälle nicht dokumentiert oder veraltet sind
• Bidirektionale Verfolgbarkeit zwischen Tests und der Testbasis nicht aufrechterhalten wurde
• Werkzeugunterstützung schwach ist oder nicht existiert
• Die beteiligten Personen keine Fach- oder Systemkenntnis haben
• Während der Entwicklung nur ungenügende Aufmerksamkeit auf die Wartbarkeit der Software gelegt wurde
Statischer Test
Reviewprozess für Arbeitsergebnisse
- Planung
- Reviewbeginn
- Individuelles Review (d.h. individuelle Vorbereitung)
- Befundkommunikation und -analyse
- Fehlerbehebung und Bericht
Reviewprozess für Arbeitsergebnisse :
Planung
- Definition des Umfangs inkl. des Zwecks des Reviews, welche Dokumente oder Teile von Dokumenten im Review einbezogen werden sollen und der Qualitätsmerkmale, die bewertet werden sollen
- Schätzung von Aufwand und Zeitbedarf
- Identifizieren von Revieweigenschaften wie der Reviewart mit Rollen, Aktivitäten und Checklisten
- Auswahl der Personen, die am Review teilnehmen sollen, und Zuordnung der Rollen
- Definition der Eingangs- und Endekriterien für formalere Reviewarten (z.B. Inspektionen)
- Prüfung, ob Eingangskriterien erfüllt sind (für formalere Reviewarten)
Reviewprozess für Arbeitsergebnisse :
Reviewbeginn
• Verteilen des Arbeitsergebnisses (physisch oder elektronisch) und anderer Materialien, wie Befund-Template, Checklisten und zugehörige Arbeitsergebnisse
• Erläutern des Umfangs, der Ziele, des Prozesses, der Rollen und der Arbeitsergebnisse gegenüber den Teilnehmern
• Beantwortung von Fragen, die die Teilnehmer zum Review haben könnten
Lehrplan Certified Tester Foundation Level
Reviewprozess für Arbeitsergebnisse: Individuelles Review (d.h. individuelle Vorbereitung)
- Review des gesamten oder von Teilen des Arbeitsergebnisses
- Aufzeichnung potenzieller Fehlerzustände, Empfehlungen und Fragen
Reviewprozess für Arbeitsergebnisse: Befundkommunikation und -analyse
- Kommunikation identifizierter potenzieller Fehlerzustände (z.B. in einer Reviewsitzung)
- Analyse potenzieller Fehlerzustände, Zuweisung von Zuständigkeit und Status
- Bewertung und Dokumentation von Qualitätsmerkmalen
- Bewertung der Reviewbefunde gegenüber den Endekriterien, um eine Reviewentscheidung zu treffen (ablehnen, umfangreiche Änderungen notwendig, annehmen, vielleicht mit geringfügigen Änderungen)
