ISTQB Foundation (CTFL v4.0) Probeprüfung #3 — Fragen & Antworten
Alle Fragen dieser Probeprüfung, mit markierter richtiger Antwort und einer schriftlichen Begründung zu jeder Option unten — zum Lesen und Wiederholen, kein zeitlich begrenzter Durchlauf.
Welche Aussage zu den sieben Testgrundsätzen ist KORREKT?
Vollständiges Testen ist unmöglich, daher muss das Testen über Risiko und Prioritäten fokussiert werden.
Richtig — das ist der Grundsatz 'Vollständiges Testen ist nicht möglich'.
Testen kann beweisen, dass Software völlig fehlerfrei ist.
Testen weist das Vorhandensein von Fehlerzuständen nach, nicht deren Abwesenheit.
Dieselben Tests wiederholt auszuführen findet immer wieder neue Fehlerzustände.
Das widerspricht dem Pestizid-Paradoxon — wiederholte Tests finden keine neuen Fehler mehr.
Fehlerzustände sind gleichmäßig über alle Module verteilt.
Fehler häufen sich — wenige Module enthalten meist die meisten Fehler.
Vollständiges Testen (alle Eingabe-/Vorbedingungskombinationen) ist außer in trivialen Fällen unmöglich; stattdessen sollten Risiko und Prioritäten den Testaufwand steuern.
Ein Entwickler macht beim Programmieren einer Berechnung einen Fehler. Dadurch entsteht fehlerhafter Code, der bei Ausführung eine falsche Summe auf dem Bildschirm erzeugt. Was ist die falsche Summe auf dem Bildschirm gemäß ISTQB-Terminologie?
Eine Fehlerwirkung
Richtig — die angezeigte falsche Summe ist die beobachtbare Fehlerwirkung.
Ein Fehlerzustand
Der Fehlerzustand ist der Mangel im Code, nicht die falsche Ausgabe.
Eine Fehlhandlung
Die Fehlhandlung ist die menschliche Handlung, die den Fehlerzustand verursacht hat.
Eine Grundursache
Die Grundursache ist der zugrunde liegende Grund der Fehlhandlung, nicht die sichtbare falsche Summe.
Fehlhandlung → Fehlerzustand (im Code) → Fehlerwirkung (das beobachtbare falsche Verhalten). Die angezeigte falsche Summe ist eine Fehlerwirkung.
Welches der folgenden Beispiele zeigt, dass Testen zum Erfolg beiträgt und nicht nur Fehler findet?
Tester prüfen Anforderungen vor Codierbeginn und verhindern so Fehlerzustände.
Richtig — frühe Einbindung verhindert Fehler und trägt zum Erfolg bei.
Möglichst viele Fehler während des Systemtests zu protokollieren.
Das ist Fehlerfindung, nicht der breitere Beitrag zum Erfolg.
Fehlgeschlagene Tests nach einer Korrektur erneut auszuführen.
Fehlernachtest bestätigt Korrekturen; es ist nicht der beschriebene präventive Beitrag.
Die Anzahl pro Tag ausgeführter Testfälle zu zählen.
Eine Produktivitätskennzahl, kein Beitrag zum Produkterfolg.
Tester, die Anforderungen früh prüfen, können verhindern, dass Fehlerzustände eingebaut werden — ein Beitrag zum Erfolg über das Auffinden von Fehlern hinaus.
Welche ZWEI der folgenden sind typische Testziele? (Wählen Sie zwei.)
Vertrauen in die Qualität des Testobjekts aufbauen.
Richtig — ein anerkanntes Testziel.
Informationen für die Entscheidungsfindung bereitstellen.
Richtig — Testen liefert Informationen für Stakeholder.
Die gefundenen Fehlerzustände beheben.
Beheben ist Debugging/Entwicklung, kein Testziel.
Die Systemanforderungsspezifikation schreiben.
Anforderungen zu verfassen ist Aufgabe der Anforderungsanalyse, nicht des Testens.
Typische Ziele sind u. a. Fehler vermeiden, Fehler/Fehlerwirkungen finden, Vertrauen aufbauen, Informationen für Entscheidungen liefern, verifizieren/validieren. Fehler beheben und Anforderungen schreiben sind keine Testziele.
Welches Paar unterscheidet Verifizierung und Validierung korrekt?
Verifizierung: festgelegte Anforderungen erfüllen; Validierung: tatsächliche Benutzerbedürfnisse erfüllen.
Richtig — die übliche Unterscheidung.
Verifizierung: dynamisches Testen; Validierung: statisches Testen.
Beide können statisch oder dynamisch sein; diese Zuordnung ist falsch.
Verifizierung: von Benutzern; Validierung: von Entwicklern.
Rollen definieren die Unterscheidung nicht.
Verifizierung und Validierung sind Synonyme.
Sie sind verwandt, aber unterschiedlich.
Verifizierung prüft, ob Arbeitsergebnisse die festgelegten Anforderungen erfüllen (das Produkt richtig bauen); Validierung prüft, ob das Produkt die tatsächlichen Benutzerbedürfnisse erfüllt (das richtige Produkt bauen).
In welcher Testaktivität wird geprüft, dass Testumgebung, Infrastruktur und Werkzeuge bereit sind, und die Eingangskriterien vor der Ausführung kontrolliert?
Testrealisierung
Richtig — die Realisierung bereitet Umgebung und Ressourcen vor und prüft sie.
Testplanung
Die Planung legt Ziele und Vorgehen fest, nicht die finale Umgebungsprüfung.
Testentwurf
Der Entwurf überführt Testbedingungen in Testfälle.
Testabschluss
Der Abschluss sammelt Daten und berichtet nach dem Testen.
Im ISTQB-Testprozess umfasst die Testrealisierung die Prüfung, dass Umgebung und Ressourcen korrekt eingerichtet sind, bevor die Ausführung beginnt.
Was beschreibt die Nachverfolgbarkeit zwischen Testbasis und Test-Arbeitsergebnissen am BESTEN?
Sie ermöglicht Überdeckungsbewertung, Auswirkungsanalyse und Auditierbarkeit des Testens.
Richtig — das sind zentrale Vorteile der Nachverfolgbarkeit.
Sie garantiert, dass keine Fehlerzustände mehr in der Software sind.
Nachverfolgbarkeit beweist nicht die Abwesenheit von Fehlern.
Sie ersetzt die Notwendigkeit der Testplanung.
Nachverfolgbarkeit unterstützt die Planung, ersetzt sie aber nicht.
Sie ist nur für automatisierte Tests nützlich.
Nachverfolgbarkeit gilt für manuelle und automatisierte Tests gleichermaßen.
Gute Nachverfolgbarkeit verknüpft Testbedingungen, Testfälle und Ergebnisse mit der Testbasis und ermöglicht Auswirkungsanalyse, Überdeckungsbewertung und Auditierbarkeit.
Welches ist das BESTE Beispiel dafür, dass ein Tester beim Melden eines Fehlers eine gute Testhaltung und die richtigen zwischenmenschlichen Fähigkeiten zeigt?
Den Fehler sachlich und neutral beschreiben, mit Fokus auf das Produkt, nicht die Person.
Richtig — konstruktive, faktenbasierte Kommunikation erhält gute Beziehungen.
Im Bericht angeben, welcher Entwickler den Fehler verursacht hat.
Schuldzuweisungen schaden Beziehungen und sind kontraproduktiv.
Warten, bis sich viele Fehler ansammeln, und sie dann gesammelt melden.
Verzögertes Melden mindert Wert und Aktualität.
Nur die Fehler melden, die die eigenen Erwartungen bestätigen.
Bestätigungsfehler untergräbt objektives Testen.
Fehler sollten konstruktiv und sachlich kommuniziert werden, mit Fokus auf das Produkt statt Schuldzuweisung an den Autor, um gute Arbeitsbeziehungen zu erhalten.
Welches ist gemäß dem Grundsatz des 'frühen Testens' (Shift Left) der BESTE Grund, das Testen bereits in der Anforderungsphase einzubinden?
Früh gefundene Fehler sind günstiger zu beheben und verbreiten sich nicht weiter.
Richtig — die Behebungskosten steigen stark, je später ein Fehler gefunden wird.
Es erlaubt, System- und Abnahmetests später zu überspringen.
Frühes Testen ergänzt spätere Teststufen, ersetzt sie aber nicht.
Anforderungen enthalten nie Fehler, daher ist die Prüfung schnell.
Anforderungen enthalten oft Fehler wie Mehrdeutigkeiten und Lücken.
Es garantiert, dass das Projekt rechtzeitig fertig wird.
Frühes Testen senkt Risiken, garantiert aber keinen Termin.
In den Anforderungen gefundene Fehler sind weit günstiger zu beheben als später gefundene; frühes Prüfen verhindert, dass teure Fehler in Entwurf und Code übergehen.
Ein Team hat mehrere Komponenten integriert und will prüfen, dass die Schnittstellen und Datenflüsse zwischen ihnen korrekt funktionieren. Welche Teststufe ist das?
Integrationstest
Richtig — er zielt auf Schnittstellen und Interaktionen zwischen Komponenten.
Komponententest
Der Komponententest prüft eine einzelne Komponente isoliert.
Abnahmetest
Der Abnahmetest validiert die Einsatzbereitschaft für Benutzer/Kunden.
Systemtest
Der Systemtest prüft das Verhalten des gesamten integrierten Systems.
Der Integrationstest fokussiert auf die Interaktionen und Schnittstellen zwischen integrierten Komponenten oder Systemen.
Welche der folgenden ist eine FUNKTIONALE Testart?
Prüfen, dass eine Überweisung die korrekten Konten belastet und gutschreibt.
Richtig — es prüft eine Funktion, die das System leisten muss.
Antwortzeit bei 1000 gleichzeitigen Benutzern messen.
Das ist Performanz- (nicht-funktionaler) Test.
Bewerten, wie leicht neue Benutzer den Bezahlvorgang abschließen.
Das ist Benutzbarkeits- (nicht-funktionaler) Test.
Prüfen, dass die App auf drei Betriebssystemen installiert.
Das ist Portabilitäts- (nicht-funktionaler) Test.
Funktionaler Test bewertet, was das System tut (seine Funktionen). Performanz, Benutzbarkeit und Portabilität sind nicht-funktionale Qualitätsmerkmale.
Nach einer Fehlerkorrektur führt das Team Tests in unveränderten Bereichen der Anwendung erneut aus, um sicherzustellen, dass die Korrektur keine unbeabsichtigten Nebenwirkungen hat. Wie heißt das?
Regressionstest
Richtig — er erkennt unbeabsichtigte Nebenwirkungen von Änderungen.
Fehlernachtest
Der Fehlernachtest wiederholt nur den ursprünglich fehlgeschlagenen Test.
Smoke-Test
Der Smoke-Test prüft oberflächlich, dass der Build stabil genug zum Testen ist.
Exploratives Testen
Exploratives Testen ist gleichzeitiges Lernen, Entwerfen und Ausführen.
Der Regressionstest prüft, dass bisher funktionierende Funktionalität durch Änderungen nicht beeinträchtigt wurde. Der Fehlernachtest wiederholt nur den ursprünglich fehlgeschlagenen Test.
An einem Live-System wird eine Wartungsänderung vorgenommen, damit es auf einer neuen Betriebssystemversion läuft, ohne Funktionsänderung. Welchen Wartungsauslöser stellt das dar?
Migration in eine neue Betriebsumgebung.
Richtig — die Anpassung an ein neues OS/Plattform ist ein anerkannter Auslöser.
Korrektive Wartung zur Behebung einer Produktionsstörung.
Hier wird kein Fehler behoben; die Funktionalität bleibt unverändert.
Erweiterung zum Hinzufügen einer neuen Funktion.
Es wird keine neue Funktionalität hinzugefügt.
Stilllegung des Systems.
Das System wird weiterbetrieben, nicht stillgelegt.
Die Migration von Software in eine neue Betriebsumgebung (neues OS, Plattform oder Hardware) ist ein Auslöser der Umgebungs-/Migrationswartung.
Neben funktionalen und nicht-funktionalen Testarten beschreibt der Lehrplan eine Testart, die bewertet, ob die interne Struktur bzw. Implementierung des Testobjekts ausreichend abgedeckt wurde, etwa durch Messung der Anweisungs- oder Zweigüberdeckung. Welche Testart ist das?
White-Box-Test
Richtig — der White-Box-Test (strukturbasiert) ist die Testart, die sich damit befasst, wie gründlich die interne Struktur des Testobjekts abgedeckt wurde.
Nicht-funktionaler Test
Der nicht-funktionale Test bewertet, wie gut das System sich verhält — Performanz, Benutzbarkeit, Zuverlässigkeit und Ähnliches — nicht, wie viel seiner Codestruktur abgedeckt wurde.
Funktionaler Test
Der funktionale Test bewertet, was das System gemäß seinen funktionalen Anforderungen tut; die interne Struktur ist für die Testauswahl unerheblich.
Fehlernachtest (Confirmation Test)
Der Fehlernachtest ist änderungsbezogen: Die zuvor fehlgeschlagenen Tests werden erneut ausgeführt, um die Wirksamkeit der Korrektur zu prüfen. Über strukturelle Abdeckung sagt er nichts.
Der White-Box-Test (strukturbasierter Test) leitet Tests aus der internen Struktur bzw. Implementierung des Testobjekts ab und berichtet typischerweise strukturelle Abdeckung wie Anweisungs- oder Zweigüberdeckung.
Welches der folgenden kann durch statisches Testen, aber NICHT durch dynamisches Testen untersucht werden?
Mehrdeutigkeiten und Inkonsistenzen in einem Anforderungsdokument.
Richtig — nur statisches Testen kann nicht ausführbare Dokumente prüfen.
Speicherlecks während der Ausführung.
Speicherlecks zeigen sich nur bei laufendem Code — dynamisches Testen.
Tatsächliche Antwortzeit einer Transaktion.
Antwortzeit erfordert Ausführung — dynamisches Testen.
Falsche Ergebnisse beim Ausführen des Programms.
Falsche Ergebnisse zu beobachten erfordert Ausführung — dynamisches Testen.
Statisches Testen findet Fehler in nicht ausführbaren Arbeitsergebnissen, z. B. Mehrdeutigkeiten und Inkonsistenzen in Anforderungen, die dynamisches Testen (das Ausführung erfordert) nicht findet.
Bei welcher Reviewart sind Fehlererkennung, Qualitätsbewertung und Vertrauensbildung die Hauptzwecke, mit geschultem Moderator und einem dokumentierten, formalen Prozess auf Basis von Regeln und Checklisten?
Inspektion
Richtig — das formalste Review mit geschultem Moderator und Metriken.
Informelles Review
Ein informelles Review hat keinen definierten Prozess oder dokumentierte Ergebnisse.
Walkthrough
Ein Walkthrough wird vom Autor geleitet und ist weniger formal als die Inspektion.
Technisches Review
Ein technisches Review ist formal, fokussiert aber auf technische Entscheidungen, oft ohne geschulten Moderator.
Die Inspektion ist die formalste Reviewart: von einem geschulten Moderator geleitet, mit definiertem Prozess, Rollen, Regeln, Checklisten und Metriken.
Welches der folgenden ist ein zentraler Erfolgsfaktor für ein Review, der eher mit Menschen als mit dem Prozess zusammenhängt?
Das Review in einer Atmosphäre des Vertrauens ohne Schuldzuweisung durchführen.
Richtig — ein menschenbezogener Faktor, der Offenheit fördert.
Klare Ziele für das Review definieren.
Wichtig, aber ein prozessbezogener Faktor.
Zum Arbeitsergebnis passende Checklisten verwenden.
Nützliche Technik, aber prozessbezogen.
Das Arbeitsergebnis klein genug halten, um effektiv zu prüfen.
Ein Prozess-/Organisationsfaktor, kein Menschenfaktor.
Menschenbezogene Erfolgsfaktoren sind u. a. Reviews in einer Atmosphäre des Vertrauens und ohne Schuldzuweisung durchzuführen, damit sich Teilnehmer sicher und engagiert fühlen.
Wer ist in einem formalen Review für das geprüfte Dokument verantwortlich und behebt üblicherweise die gefundenen Fehler?
Der Autor
Richtig — der Autor verantwortet das Arbeitsergebnis und nimmt die Korrekturen vor.
Der Moderator
Der Moderator leitet den Reviewprozess, nicht den Dokumentinhalt.
Der Protokollant
Der Protokollant erfasst die Befunde während des Treffens.
Der Reviewleiter
Der Reviewleiter plant das Review, verantwortet aber nicht das Dokument.
Der Autor erstellt das geprüfte Arbeitsergebnis, ist dafür verantwortlich und nimmt die resultierenden Änderungen vor.
Das folgende Zustandsdiagramm modelliert einen Media-Player. Wenn jede Transition ein eigener Testfall ist: Wie viele Testfälle sind mindestens nötig für 0-Switch-Abdeckung (jede gültige Transition einmal)?
5
Es gibt fünf gültige Transitionen; ein Testfall je Transition ergibt fünf.
3
3 ist die Anzahl der Zustände, nicht der abzudeckenden Transitionen.
4
Zu wenig; das Diagramm hat fünf gültige Transitionen, nicht vier.
6
Zu viel; es gibt keine sechste gültige Transition im Diagramm.
0-Switch-Abdeckung verlangt jede gültige Transition einmal. Das Diagramm zeigt fünf Transitionen, also fünf Testfälle.
Ein Eingabefeld akzeptiert eine Ganzzahl 'Alter', die die Spezifikation für 18 bis 65 einschließlich gleich behandelt. Welche Menge stellt mit Äquivalenzklassenbildung die DREI Klassen für gültige/ungültige Behandlung dar?
{ Alter < 18 } , { 18 ≤ Alter ≤ 65 } , { Alter > 65 }
Richtig — eine gültige und zwei ungültige Klassen darum herum.
{ 17, 18 } , { 65, 66 }
Das sind Grenzwerte, nicht die drei Äquivalenzklassen.
Nur { 18 } , { 65 }
Nur zwei Einzelwerte; ungültige Klassen fehlen.
Eine Klasse für jede Ganzzahl von 18 bis 65.
Das widerspricht dem Sinn der Klassenbildung in äquivalente Gruppen.
Die Äquivalenzklassenbildung ergibt eine gültige Klasse (18–65) und zwei ungültige (unter 18 und über 65). Ein Wert pro Klasse genügt für Basisüberdeckung.
Eine Rabatt-Engine ordnet anhand eines Ganzzahlwerts 'Punkte' eine Treuestufe zu: 0–199 = Bronze, 200–499 = Silber, 500–999 = Gold, ab 1000 = Platin. Welche Wertemenge testet mit der 2-Werte-Grenzwertanalyse (jeder Grenzwert und sein nächster Nachbar) ALLE Grenzen zwischen Bronze und Silber sowie zwischen Gold und Platin?
{ 199, 200, 999, 1000 }
Richtig — das sind die Grenzpaare für Bronze/Silber und Gold/Platin.
{ 200, 500, 1000 }
Es fehlen die unteren Nachbarn (199 und 999) der 2-Werte-Analyse.
{ 0, 199, 200, 499, 500, 999, 1000 }
Enthält die Grenze Silber/Gold (499/500) und 0, die nicht gefragt sind.
{ 100, 350, 750, 1500 }
Das sind Werte in der Klassenmitte, keine Grenzwerte.
Die 2-Werte-Grenzwertanalyse testet jeden Grenzwert und seinen nächsten Nachbarn. Grenze Bronze/Silber bei 199/200; Grenze Gold/Platin bei 999/1000. Also {199, 200, 999, 1000}.
Betrachten Sie die folgende Entscheidungstabelle für Kreditanträge. Ein Antragsteller hat eine Bonität von 680 und ein Jahreseinkommen von 60.000. Welche Aktion gilt laut Tabelle?
Manuelle Prüfung
Richtig — Bonität < 700 und Einkommen ≥ 50.000 entspricht Regel R3.
Genehmigen
Genehmigen erfordert beide Bedingungen wahr (R1); die Bonitätsbedingung ist hier falsch.
Ablehnen
Ablehnen (R4) erfordert beide Bedingungen falsch; das Einkommen ist hier mindestens 50.000.
Aus der Tabelle nicht bestimmbar
Die Eingaben treffen eindeutig Regel R3, die Aktion ist bestimmbar.
Bonität 680 ist unter 700 (Bedingung 1 = F); Einkommen 60.000 ist mindestens 50.000 (Bedingung 2 = T). Das ist Regel R3 (F, T) mit der Aktion Manuelle Prüfung.
Das folgende Zustandsübergangsdiagramm zeigt einen Dokumenten-Review-Workflow. Wie viele Testfälle sind mindestens nötig, um eine 0-Switch-Überdeckung (jeder gültige Übergang mindestens einmal) zu erreichen, wenn nur die gezeigten gültigen Übergänge gezählt werden?
5
Richtig — es gibt 5 gültige Übergänge, je ein Testfall für 0-Switch-Überdeckung.
4
Das übersieht einen der fünf gültigen Übergänge (z. B. retract).
3
Drei deckt nur die Zustände ab, nicht jeden gültigen Übergang.
6
Es gibt nur 5 gültige Übergänge, nicht 6.
0-Switch-Überdeckung erfordert jeden gültigen Übergang einmal. Die gültigen Übergänge sind: submit, approve, reject, publish, retract = 5 Übergänge, also 5 Testfälle.
Eine Funktion enthält folgenden Pseudocode: IF (a > 0) THEN print 'X' ENDIF; IF (b > 0) THEN print 'Y' ENDIF. Wie viele Testfälle sind mindestens nötig für 100% Anweisungsüberdeckung bzw. für 100% Zweig-(Entscheidungs-)Überdeckung?
1 für Anweisungsüberdeckung, 2 für Zweigüberdeckung
Richtig — ein Test deckt beide Anweisungen; zwei Tests alle vier Zweigausgänge.
2 für Anweisungsüberdeckung, 2 für Zweigüberdeckung
Anweisungsüberdeckung braucht hier nur 1 Test, nicht 2.
1 für Anweisungsüberdeckung, 4 für Zweigüberdeckung
Zweigüberdeckung braucht nur 2 Tests; die beiden IFs sind unabhängig.
2 für Anweisungsüberdeckung, 4 für Zweigüberdeckung
Beide Zahlen sind für diese einfache Struktur zu hoch.
Ein Test mit a>0 und b>0 führt beide print-Anweisungen aus → 100% Anweisungsüberdeckung mit 1 Test. Für Zweigüberdeckung muss jedes IF wahr und falsch sein: a>0,b>0 dann a≤0,b≤0 deckt alle vier Ausgänge → 2 Tests.
Welche Aussage charakterisiert die Beziehung zwischen Anweisungs- und Zweigüberdeckung am BESTEN?
100% Zweigüberdeckung impliziert 100% Anweisungsüberdeckung, aber nicht umgekehrt.
Richtig — Zweigüberdeckung schließt Anweisungsüberdeckung ein.
100% Anweisungsüberdeckung impliziert 100% Zweigüberdeckung.
Falsch — man kann jede Anweisung ausführen, ohne jeden Zweig zu nehmen.
Sie erfordern stets gleich viele Testfälle.
Zweigüberdeckung erfordert in der Regel mindestens so viele, oft mehr.
Sie haben keinerlei Beziehung zueinander.
Sie sind verwandt — Zweigüberdeckung schließt Anweisungsüberdeckung ein.
100% Zweig-(Entscheidungs-)Überdeckung garantiert 100% Anweisungsüberdeckung, aber nicht umgekehrt: Zweigüberdeckung ist das stärkere Kriterium.
Welche Beschreibung passt am BESTEN dazu, wann erfahrungsbasierte Testtechniken wie exploratives Testen und Fehlerraten eingesetzt werden?
Wenn Spezifikationen schlecht oder die Zeit knapp ist, um systematische Techniken zu ergänzen.
Richtig — sie nutzen die Erfahrung des Testers.
Nur wenn eine vollständige formale Überdeckungsmessung erforderlich ist.
Sie liefern keine systematischen Überdeckungsmaße.
Nur von Testern ohne Domänenwissen.
Sie beruhen auf Erfahrung und Domänenwissen.
Als vollständiger Ersatz für alle Black-Box-Techniken.
Sie ergänzen sie, ersetzen sie nicht.
Erfahrungsbasierte Techniken sind wertvoll, wenn Spezifikationen dürftig sind, die Zeit knapp ist oder um systematische Techniken zu ergänzen.
Welche der folgenden ist eine Black-Box-(spezifikationsbasierte) Testtechnik?
Äquivalenzklassenbildung
Richtig — aus der Spezifikation abgeleitet.
Anweisungstest
Der Anweisungstest ist eine White-Box-Technik.
Zweigtest
Der Zweigtest ist eine White-Box-Technik.
Fehlerraten
Fehlerraten ist eine erfahrungsbasierte Technik.
Die Äquivalenzklassenbildung leitet Tests aus der Spezifikation ab. Anweisungs- und Zweigtest sind White-Box.
Ein Webformularfeld akzeptiert einen 'Benutzernamen' mit 5 bis 12 Zeichen einschließlich. Welche Längenwerte sollten mit der 2-Werte-Grenzwertanalyse getestet werden?
{ 4, 5, 12, 13 }
Richtig — jede Grenze und ihr nächster ungültiger Nachbar.
{ 5, 12 }
Es fehlen die Nachbarn außerhalb des Bereichs.
{ 1, 5, 12, 20 }
1 und 20 sind keine nächsten Nachbarn.
{ 6, 11 }
Diese liegen im gültigen Bereich.
Die 2-Werte-Grenzwertanalyse testet jede Grenze und ihren Nachbarn: 5 mit 4; 12 mit 13. Also {4, 5, 12, 13}.
Welche Verhaltensarten sollten Testfälle abdecken, die aus einem Anwendungsfall abgeleitet werden?
Den Basisablauf sowie alternative und Ausnahmeabläufe.
Richtig — nicht nur der Happy Path.
Nur den Basisablauf.
Auch alternative und Ausnahmeabläufe müssen getestet werden.
Nur die internen Codezweige.
Anwendungsfalltests sind Black-Box.
Nur die Grenzwerte numerischer Eingaben.
Das ist die Grenzwertanalyse.
Anwendungsfalltests sollten den Basisablauf sowie alternative und Ausnahmeabläufe abdecken.
Wie wird beim risikobasierten Testen die Höhe eines Produktrisikos typischerweise bestimmt?
Durch Kombination von Eintrittswahrscheinlichkeit und Auswirkung.
Richtig — Risikohöhe = Wahrscheinlichkeit × Auswirkung.
Nur durch die Zahl der bereits gefundenen Fehler.
Frühere Fehler sind nicht die ganze Definition.
Nur durch die Größe in Codezeilen.
Größe definiert nicht die Risikohöhe.
Durch die Anzahl verfügbarer Tester.
Ressourcen beeinflussen nicht die Risikohöhe.
Die Risikohöhe ergibt sich aus Eintrittswahrscheinlichkeit und Auswirkung.
Ein Testmanager schätzt eine Aufgabe mit der Drei-Punkt-Technik. Optimistisch = 6, wahrscheinlichste = 12, pessimistisch = 30. Mit (a + 4m + b) / 6, wie lautet der Schätzwert?
14 Tage
Richtig — 84 / 6 = 14.
12 Tage
12 ist der wahrscheinlichste Wert.
16 Tage
Das ist der einfache Mittelwert.
18 Tage
Entspricht nicht 14.
(6 + 4×12 + 30) / 6 = 84 / 6 = 14 Tage.
Was beschreibt den Zweck von Endekriterien für eine Testaktivität am BESTEN?
Sie legen fest, wann die Aktivität als abgeschlossen gilt.
Richtig — Endekriterien zeigen das Ende des Testens an.
Sie legen die Bedingungen vor Testbeginn fest.
Das sind Eingangskriterien.
Sie listen alle gefundenen Fehler auf.
Das ist Inhalt von Fehlerberichten.
Sie geben die Testdaten an.
Testdaten werden im Entwurf festgelegt.
Endekriterien legen fest, wann eine Testaktivität als abgeschlossen gilt.
Welches Dokument beschreibt Umfang, Vorgehen, Ressourcen und Zeitplan der geplanten Testaktivitäten und ist das wichtigste Planungsergebnis eines Testmanagers?
Der Testplan
Richtig — er erfasst Umfang, Vorgehen, Ressourcen und Zeitplan.
Der Testabschlussbericht
Er beschreibt Ergebnisse nach dem Test.
Der Fehlerbericht
Er dokumentiert einen einzelnen Fehler.
Die Testfallspezifikation
Sie spezifiziert einzelne Testfälle.
Der Testplan dokumentiert Umfang, Ziele, Vorgehen, Ressourcen, Zeitplan und Risiken.
Welche Information ist in einem Fehlerbericht am WICHTIGSTEN, damit ein Entwickler das Problem reproduzieren kann?
Klare Schritte zur Reproduktion mit Ist- und Soll-Ergebnis.
Richtig — zentral für die Diagnose.
Der Name des Testers.
Nützlich, aber nicht entscheidend.
Die Gesamtzahl der Fehler an dem Tag.
Ohne Bezug zur Reproduktion.
Das Lieferdatum des nächsten Release.
Nicht zur Reproduktion nötig.
Klare Reproduktionsschritte mit Ist- und Soll-Ergebnis sind entscheidend.
Ein Team muss vier Funktionen regressionstesten. Risikohöhen: Zahlungen = 9, Login = 6, Suche = 4, Hilfeseiten = 2. Es bleibt Zeit für zwei. Welche zwei priorisieren?
Zahlungen und Login
Richtig — die zwei höchsten Werte (9 und 6).
Suche und Hilfeseiten
Die niedrigsten Werte.
Zahlungen und Hilfeseiten
Login (6) steht über Hilfeseiten (2).
Login und Suche
Zahlungen (9) muss enthalten sein.
Risikobasiert: die höchsten Risiken — Zahlungen (9) und Login (6).
Welches der folgenden ist ein Beispiel für ein Projektrisiko (kein Produktrisiko)?
Die Testumgebung wird nicht rechtzeitig bereitgestellt.
Richtig — ein Projektrisiko.
Eine Berechnung liefert falsche Ergebnisse.
Ein Produktrisiko.
Die Anwendung stürzt unter Last ab.
Ein Produkt-(Performanz-)Risiko.
Unbefugter Zugriff auf sensible Daten.
Ein Sicherheits-Produktrisiko.
Projektrisiken betreffen Management/Steuerung, z. B. verspätete Testumgebung. Produktrisiken betreffen die Produktqualität.
Ein Fortschrittsbericht zeigt deutlichen Verzug mit vielen offenen Tests hoher Priorität. Was ist die am BESTEN geeignete Steuerungsmaßnahme?
Das Testen auf die höchsten Risiken umpriorisieren.
Richtig — Steuerung passt den Plan an.
Den Bericht ignorieren.
Abweichungen zu ignorieren widerspricht der Steuerung.
Keine Fehlerberichte mehr schreiben.
Fehlerberichte sind wesentlich.
Alle Tests ohne Ausführung als bestanden markieren.
Ergebnisse zu fälschen ist unethisch.
Teststeuerung greift korrigierend ein, z. B. Umpriorisierung auf die höchsten Risiken.
Welche ZWEI sind typischerweise in einem Testabschlussbericht enthalten? (Zwei wählen.)
Eine Zusammenfassung des Testens und seiner Ergebnisse.
Richtig — ein Kernelement.
Eine Bewertung anhand der Endekriterien.
Richtig — bewertet die Endekriterien.
Der vollständige Quellcode.
Quellcode gehört nicht dazu.
Die detaillierte Entwurfsspezifikation.
Entwurfsspezifikationen sind Eingaben.
Er enthält eine Zusammenfassung des Testens und eine Bewertung gegen die Endekriterien.
Welches ist ein potenzielles RISIKO bei der Einführung eines Testautomatisierungswerkzeugs?
Den Wartungsaufwand der automatisierten Tests unterschätzen.
Richtig — ein bekanntes Werkzeugrisiko.
Den Aufwand repetitiver manueller Regression reduzieren.
Ein Vorteil, kein Risiko.
Die Konsistenz der Testausführung verbessern.
Ein Vorteil.
Objektive Überdeckungsmessungen liefern.
Ein Vorteil.
Häufige Risiken: Unterschätzen des Wartungsaufwands und zu großes Vertrauen.
Welche Werkzeugkategorie unterstützt das Management des Testprozesses am BESTEN, inkl. Nachverfolgbarkeit?
Ein Testmanagementwerkzeug
Richtig — verwaltet den Prozess und bietet Nachverfolgbarkeit.
Ein Performanztestwerkzeug
Es misst Performanz.
Ein statisches Analysewerkzeug
Es analysiert Code ohne Ausführung.
Ein Werkzeug zur Testdatenaufbereitung
Es erzeugt Testdaten.
Testmanagementwerkzeuge unterstützen Planung, Überwachung und Steuerung inkl. Nachverfolgbarkeit.