ISTQB Foundation (CTFL v4.0) Probeprüfung #7 — 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.
Ein Testteam meldet: „Alle geplanten Tests bestanden.“ Ein Manager schließt daraus, die Software habe keine Fehlerzustände. Welches Testprinzip zeigt, dass diese Schlussfolgerung falsch ist?
Testen zeigt das Vorhandensein von Fehlerzuständen, nicht deren Abwesenheit.
Richtig — bestandene Tests können die Abwesenheit aller Fehlerzustände nicht beweisen.
Vollständiges Testen ist unmöglich.
Als Prinzip wahr, betrifft aber den Testaufwand, nicht die falsche Schlussfolgerung 'keine Fehler'.
Tests nutzen sich ab (Pestizid-Paradoxon).
Betrifft das Wiederholen gleicher Tests, nicht den Beweis der Fehlerfreiheit.
Fehlerzustände treten gehäuft auf.
Beschreibt ungleiche Fehlerverteilung, nicht die Grenzen bestandener Tests.
Testen kann das Vorhandensein von Fehlerzuständen zeigen, ihre Abwesenheit aber nicht beweisen; bestandene Tests senken das Risiko, garantieren aber kein fehlerfreies Produkt.
Ein Entwickler liest eine Anforderung falsch und programmiert die falsche Rabattformel. Der Code geht in Betrieb; ein Nutzer sieht später eine falsche Summe am Bildschirm. Was ist die falsche Summe in ISTQB-Terminologie?
Eine Fehlerwirkung.
Richtig — eine Fehlerwirkung ist die Manifestation eines Fehlerzustands bei der Ausführung.
Eine Fehlhandlung.
Die Fehlhandlung war das Missverstehen der Anforderung, nicht das Ergebnis am Bildschirm.
Ein Fehlerzustand.
Der Fehlerzustand ist die falsche Formel im Code; die sichtbare falsche Summe ist dessen Wirkung.
Eine Grundursache.
Die Grundursache ist der zugrunde liegende Grund der Fehlhandlung, nicht das sichtbare Ergebnis.
Das Missverständnis ist eine Fehlhandlung; die falsche Formel im Code ist ein Fehlerzustand; die sichtbare falsche Summe bei der Ausführung ist eine Fehlerwirkung.
Welches der folgenden ist ein typisches Testziel?
Stakeholdern Information zur Entscheidungsunterstützung bereitstellen.
Richtig — ein Kernziel des Testens ist die Information für Qualitäts- und Risikoentscheidungen.
Garantieren, dass das Produkt völlig fehlerfrei ist.
Unmöglich — Testen kann Fehlerfreiheit nicht beweisen.
Den Bedarf an Anforderungsreviews ersetzen.
Dynamisches Testen ergänzt statische Reviews, ersetzt sie aber nicht.
Entwicklern die Schuld für Fehler zuweisen.
Testen dient nicht der Schuldzuweisung; die Testpsychologie fördert konstruktive Kommunikation.
Typische Ziele sind Fehlervermeidung, Fehlerfindung, Vertrauensbildung, Bereitstellung von Information für Entscheidungen sowie Verifizierung/Validierung gegen Anforderungen.
In einem Projekt werden 80% der Fehlerzustände in zwei von zehn Modulen gefunden. Der Testmanager beschließt, diese zwei Module zusätzlich zu testen. Welches Testprinzip stützt diese Entscheidung?
Fehlerzustände treten gehäuft auf.
Richtig — die meisten Fehlerzustände konzentrieren sich auf wenige Module.
Frühes Testen spart Zeit und Geld.
Wahres Prinzip, betrifft aber den Zeitpunkt, nicht die Fehlerkonzentration.
Testen ist kontextabhängig.
Allgemein relevant, erklärt aber nicht den Fokus auf fehlerreiche Module.
Trugschluss der Fehlerfreiheit.
Warnt, dass ein fehlerfreies System dennoch Bedürfnisse verfehlen kann; nicht zur Häufung.
Fehlerhäufung: Eine kleine Zahl von Modulen enthält meist die meisten Fehlerzustände, daher ist der Fokus dort wirksam.
Welche ZWEI der folgenden gehören zur Testprozessaktivität „Testanalyse“? (Wählen Sie ZWEI.)
Die Testbasis analysieren, um testbare Merkmale zu identifizieren.
Richtig — ein Kernbestandteil der Testanalyse.
Testbedingungen definieren und priorisieren.
Richtig — Testbedingungen sind ein Ergebnis der Testanalyse.
Konkrete Testfälle entwerfen und priorisieren.
Das gehört zum Testentwurf, nicht zur Testanalyse.
Testfälle ausführen und Ergebnisse protokollieren.
Das ist die Testdurchführung, eine spätere Aktivität.
Testumgebung und Testdaten einrichten.
Das gehört zur Testrealisierung.
Die Testanalyse bestimmt das „Was“ des Testens, indem sie die Testbasis analysiert, testbare Merkmale identifiziert und Testbedingungen definiert/priorisiert.
Welche Aussage beschreibt den Unterschied zwischen Testen und Qualitätssicherung (QA) am BESTEN?
QA ist prozessorientiert (Fehlervermeidung); Testen ist produktorientiert (Fehlerfindung).
Richtig — das ist die übliche Unterscheidung.
Testen und QA sind Synonyme und austauschbar.
Sie sind verwandt, aber unterschiedliche Disziplinen.
Testen ist prozessorientiert; QA findet nur Fehler im Code.
Das vertauscht die korrekten Definitionen.
QA erfolgt nur nach Release, Testen nur davor.
Beide finden über den gesamten Lebenszyklus statt.
QA ist prozessorientiert und auf Fehlervermeidung durch Prozessverbesserung ausgerichtet; Testen ist produktorientiert und auf das Finden von Fehlerzuständen in Arbeitsergebnissen ausgerichtet.
Ein Tester und ein Entwickler sind uneinig, ob ein gemeldetes Verhalten ein Fehlerzustand ist. Was ist gemäß Testpsychologie der KONSTRUKTIVSTE Ansatz?
Befunde neutral und sachlich kommunizieren, mit Fokus auf Fakten sowie Soll- und Ist-Ergebnis.
Richtig — neutrale, faktenbasierte Kommunikation reduziert Konflikte.
Sofort an das Management eskalieren, um die Verantwortung zuzuweisen.
Vorzeitige Eskalation schadet der Zusammenarbeit; zuerst Fakten besprechen.
Den Bericht als „kein Fehler“ schließen, um Konflikte zu vermeiden.
Das Unterdrücken gültiger Information schadet der Produktqualität.
Darauf bestehen, dass der Entwickler unrecht hat, weil Tester für Qualität zuständig sind.
Qualität ist gemeinsame Verantwortung; eine konfrontative Haltung ist kontraproduktiv.
Fehlerinformationen sollten neutral und sachlich kommuniziert werden, um Reibung zu vermeiden und den Fokus auf die Produktverbesserung statt auf Schuldzuweisung zu legen.
Ein Team testet Release 3.2 einer Zahlungskomponente und leitet die Tests aus der Anforderungsspezifikation ab. Wie heißt in der ISTQB-Terminologie die Zahlungskomponente in Release 3.2 selbst?
Das Testobjekt (Prüfling)
Richtig — das Testobjekt ist die Komponente, das System oder ein anderes Arbeitsergebnis, das getestet wird.
Die Testbasis
Die Testbasis ist die Wissensgrundlage für Testanalyse und Testentwurf. In diesem Szenario ist das die Anforderungsspezifikation, nicht die Komponente.
Die Testbedingung
Eine Testbedingung ist ein testbarer Aspekt des Testobjekts, der aus der Testbasis abgeleitet wird, z. B. „negativer Zahlbetrag wird abgewiesen“. Sie beschreibt einen Aspekt, nicht das Objekt.
Die Testumgebung
Die Testumgebung ist die Hardware, Software, Konfiguration und Daten, in der das Testobjekt ausgeführt wird. Sie umgibt das Objekt, ist es aber nicht.
Das Testobjekt (der Prüfling) ist das zu testende Arbeitsergebnis — hier die Zahlungskomponente in Release 3.2. Die Anforderungsspezifikation ist die Testbasis, aus der die Tests abgeleitet werden.
Ein Team folgt einem sequenziellen Lebenszyklus (V-Modell). Was sollte gemäß dem Prinzip des frühen Testens mit den Abnahmetests für eine Anforderung geschehen?
Sie können entworfen werden, sobald die Anforderungen vorliegen.
Richtig — früher Testentwurf hilft, Anforderungsfehler früher zu finden.
Sie müssen warten, bis der gesamte Code integriert ist.
Warten widerspricht dem frühen Testen; der Entwurf kann mit den Anforderungen beginnen.
Sie sind im V-Modell unnötig.
Der Abnahmetest ist im V-Modell eine explizite Stufe.
Sie sollten nur von Entwicklern geschrieben werden.
Abnahmetests beziehen typischerweise Nutzer/Fachbereich ein, nicht nur Entwickler.
Im V-Modell hat jede Entwicklungsstufe eine entsprechende Teststufe; der Testentwurf (z. B. Abnahmetestentwurf) beginnt, sobald die zugehörige Basis (Anforderungen) vorliegt.
Am Steuerberechnungsmodul wird eine Änderung vorgenommen. Das Team führt die bestehenden, zuvor bestandenen Steuertests erneut aus, um sicherzustellen, dass die Änderung sie nicht beschädigt hat. Um welche Testart handelt es sich?
Regressionstest.
Richtig — das erneute Ausführen bestandener Tests nach einer Änderung ist ein Regressionstest.
Fehlernachtest (Bestätigungstest).
Der Fehlernachtest prüft eine konkrete Fehlerbehebung, nicht unveränderte Bereiche.
Smoke-Test.
Ein Smoke-Test prüft oberflächlich die Grundfunktionen, kein gezielter Regressionstest.
Abnahmetest.
Der Abnahmetest validiert die Gebrauchstauglichkeit durch Nutzer, nicht das Wiederholen von Steuertests.
Regressionstest führt zuvor bestandene Tests nach einer Änderung erneut aus, um unbeabsichtigte Nebenwirkungen zu finden; Fehlernachtest (Bestätigungstest) prüft, ob ein konkret behobener Fehler weg ist.
Welche Teststufe konzentriert sich auf die Schnittstellen und Interaktionen zwischen integrierten Komponenten oder Systemen?
Integrationstest.
Richtig — zielt auf Schnittstellen und Interaktionen zwischen integrierten Teilen.
Komponententest.
Der Komponententest prüft eine einzelne Komponente isoliert.
Systemtest.
Der Systemtest bewertet das Verhalten des gesamten Systems, nicht speziell Schnittstellen.
Abnahmetest.
Der Abnahmetest schafft Vertrauen und Einsatzbereitschaft, kein Schnittstellenfokus.
Der Integrationstest konzentriert sich auf Schnittstellen und Interaktionen; der Komponentenintegrationstest prüft Interaktionen zwischen Komponenten, der Systemintegrationstest zwischen Systemen.
Welche ZWEI der folgenden sind übliche Formen des Abnahmetests? (Wählen Sie ZWEI.)
Betrieblicher Abnahmetest (OAT).
Richtig — OAT prüft betriebliche Aspekte wie Backup/Restore und Wartung.
Beta-Test.
Richtig — der Beta-Test ist eine Form des Abnahmetests durch reale Nutzer in deren Umgebung.
Zweigüberdeckungstest.
Die Zweigüberdeckung ist ein White-Box-Maß, keine Abnahmetestform.
Komponentenintegrationstest.
Das ist eine Integrationsteststufe, kein Abnahmetest.
Anweisungsüberdeckungstest.
Die Anweisungsüberdeckung ist ein strukturelles Maß, keine Abnahmeform.
Übliche Formen des Abnahmetests sind Benutzerabnahmetest (UAT), betrieblicher Abnahmetest (OAT), vertraglicher/regulatorischer Abnahmetest sowie Alpha-/Beta-Test.
Eine Bank fügt eine neue Funktion „Sofortzahlung“ hinzu und muss vor dem Release prüfen, dass sie nationale Zahlungsvorschriften erfüllt. Welche Testart wird am DIREKTESTEN adressiert?
Funktionaler Test.
Richtig — zu prüfen, dass die Funktion das vorgeschriebene tut, ist funktionaler Test.
Test der Performanz-Effizienz.
Das ist ein nichtfunktionales Merkmal zu Geschwindigkeit/Ressourcen, nicht regulatorische Korrektheit.
Portabilitätstest.
Portabilität betrifft das Verschieben zwischen Umgebungen, hier irrelevant.
Wartbarkeitstest.
Wartbarkeit betrifft die Änderbarkeit, nicht regulatorisches Verhalten.
Der funktionale Test prüft das „Was“ des Systems gegen funktionale Anforderungen; die Erfüllung von Vorschriften darüber, was die Funktion tun muss, wird funktional geprüft.
Welche Maßnahme veranschaulicht das Konzept eines Shift-Left-Ansatzes am BESTEN?
Anforderungen reviewen und Tests schreiben, bevor der Code entwickelt wird.
Richtig — Testaktivitäten nach vorn zu verlagern ist das Wesen von Shift Left.
Alle Tests erst nach vollständigem Systembau ausführen.
Das ist das Gegenteil von Shift Left.
Mehr Tester in die finale Abnahmephase setzen.
Mehr Aufwand spät verlagert keine Aktivitäten nach vorn.
Den Testentwurf bis nach dem Deployment aufschieben.
Aufschieben ist eine Shift-Right-/Spätaktivität, kein Shift Left.
Shift Left bedeutet, Testaktivitäten früher durchzuführen, z. B. Anforderungen reviewen, Tests vor dem Code schreiben (TDD) und Tester von Anfang an einbinden.
Welcher der folgenden ist ein zentraler Vorteil des statischen Tests gegenüber dem dynamischen Test?
Es kann Fehler früher und in nicht ausführbaren Arbeitsergebnissen finden.
Richtig — statisches Testen findet Fehler in Anforderungen/Design, bevor Code existiert.
Es misst die tatsächliche Performanz unter Last.
Performanz unter Last erfordert dynamische Ausführung.
Es bestätigt das korrekte Laufzeitverhalten des Systems.
Laufzeitverhalten lässt sich nur dynamisch beobachten.
Es ersetzt stets den Bedarf an dynamischem Testen.
Statisches und dynamisches Testen ergänzen sich, sie ersetzen sich nicht.
Statisches Testen untersucht Arbeitsergebnisse ohne Codeausführung und findet daher Fehler (auch in Anforderungen/Design) früher und in nicht ausführbaren Artefakten.
Während eines Reviews plant und leitet der Moderator die Sitzung, während ein anderer Teilnehmer mithilfe von Checklisten Fehler aufspürt. Welche Rolle nimmt der zweite Teilnehmer ein?
Reviewer.
Richtig — Reviewer prüfen das Arbeitsergebnis und identifizieren Fehler.
Protokollführer.
Der Protokollführer hält die genannten Befunde fest; er findet sie nicht primär.
Autor.
Der Autor hat das geprüfte Arbeitsergebnis erstellt.
Moderator.
Das ist der erste Teilnehmer, der die Sitzung leitet.
In einem formalen Review besitzt der Autor das Arbeitsergebnis, der Moderator leitet das Review, der Protokollführer hält Befunde fest, die Reviewer finden Fehler und der Reviewleiter trägt die Gesamtverantwortung.
Welche ZWEI der folgenden werden typischerweise EFFEKTIVER durch statisches als durch dynamisches Testen gefunden? (Wählen Sie ZWEI.)
Mehrdeutigkeiten und Widersprüche in Anforderungen.
Richtig — Reviews finden Anforderungsfehler, bevor Code existiert.
Unerreichbarer (toter) Code.
Richtig — statische Analyse erkennt nie ausführbaren Code.
Verschlechterte Antwortzeiten unter hoher Last.
Performanz unter Last erfordert dynamische Ausführung.
Speicherlecks, die nur zur Laufzeit auftreten.
Laufzeit-Speicherverhalten wird dynamisch beobachtet.
Falsche Ergebnisse einer Berechnung zur Laufzeit.
Falsche berechnete Ausgaben zu beobachten erfordert Codeausführung.
Statisches Testen findet effektiv Anforderungs- und Designfehler, Abweichungen von Standards, Wartbarkeitsprobleme sowie toten/unerreichbaren Code, den dynamisches Testen übersehen kann.
Welcher Reviewtyp ist am FORMALSTEN, wird von einem geschulten Moderator geleitet und nutzt definierte Eingangs-/Ausgangskriterien, individuelle Vorbereitung und Metriken?
Inspektion.
Richtig — die Inspektion ist der formalste Reviewtyp.
Informelles Review.
Ein informelles Review hat keinen formalen Prozess oder dokumentierte Ergebnisse.
Walkthrough.
Ein Walkthrough wird vom Autor geleitet und ist weniger formal als eine Inspektion.
Technisches Review.
Ein technisches Review ist formal, aber meist weniger streng und metrikgetrieben als eine Inspektion.
Eine Inspektion ist der formalste Reviewtyp — mit geschultem Moderator, formalem Prozess, Eingangs-/Ausgangskriterien, definierten Rollen, individueller Vorbereitung und Metriksammlung.
Wie viele Testfälle sind für das folgende Support-Ticket-Zustandsdiagramm für 0-Switch-Überdeckung erforderlich (jeder gültige Einzelübergang genau einmal)?
6
New->Open, Open->InProgress, InProgress->Resolved, Resolved->Closed, Resolved->InProgress, Closed->Open.
4
Übersieht reject/reopen und Closed->Open.
5
Zählt einen Übergang zu wenig.
7
Zu viele; es gibt genau sechs Übergänge.
Es gibt sechs Übergänge: triage, assign, resolve, close, reject/reopen (Resolved->InProgress), reopen (Closed->Open).
Ein Eingabefeld „Alter“ akzeptiert ganzzahlige Werte von 18 bis 65 einschließlich als gültig; Werte außerhalb sind ungültig. Welche Wertemenge repräsentiert mittels Äquivalenzklassenbildung je einen Vertreter der gültigen und der beiden ungültigen Klassen?
10, 40, 80
Richtig — 10 (ungültig niedrig), 40 (gültig), 80 (ungültig hoch): je einer pro Klasse.
20, 40, 60
Alle drei liegen in der gültigen Klasse, die ungültigen Klassen sind nicht abgedeckt.
17, 18, 65
Das sind Grenzwerte (BVA), keine je einzelnen Vertreter dreier Klassen.
5, 12, 16
Alle drei liegen in der ungültig-niedrigen Klasse; gültig und ungültig-hoch fehlen.
Die Äquivalenzklassenbildung gruppiert Eingaben in gültige (18–65) und ungültige (≤17 und ≥66) Klassen; ein Vertreter je Klasse genügt.
Ein Bonussystem vergibt Punkte nach dem Jahresumsatz eines Kunden. Die Regeln: Umsatz von 0 bis 999 ergibt Bronze; Umsatz von 1000 bis 4999 ergibt Silber; Umsatz ab 5000 ergibt Gold. Der Umsatz ist eine ganze Zahl in Euro. Wie viele unterschiedliche Grenzwerte müssen mit der Zwei-Wert-Grenzwertanalyse (BVA) getestet werden, um die Grenzen zwischen allen drei Stufen abzudecken?
4 (999, 1000, 4999, 5000)
Richtig — zwei innere Stufengrenzen, jede mit zwei Werten getestet.
2 (1000, 5000)
Die Zwei-Wert-BVA testet auch den Wert direkt unter jeder Grenze (999 und 4999).
6 (0, 999, 1000, 4999, 5000, 9999)
0 und ein beliebig hoher Wert sind keine inneren Grenzen zwischen den drei Stufen.
3 (999, 1000, 5000)
Hier fehlt 4999, die untere Seite der zweiten Grenze.
Die Zwei-Wert-BVA testet jede Grenze und den Wert direkt jenseits davon. Die Grenzen zwischen den Stufen liegen bei 999/1000 und 4999/5000. Das ergibt die Werte 999, 1000, 4999, 5000 — vier unterschiedliche Grenzwerte.
Ein Kfz-Versicherer wendet Rabattregeln gemäß der folgenden Entscheidungstabelle an. Ein 40-jähriger Fahrer ohne Schadensfälle in den letzten 5 Jahren hat nur eine Police beim Versicherer (Multi-Police = Falsch). Welche Regel trifft zu und welche Aktion ergibt sich?
R7 — 10% Rabatt anwenden.
Richtig — T, T, F entspricht R7, dessen Aktion 10% Rabatt ist.
R8 — 10% Rabatt anwenden.
R8 erfordert Multi-Police = T; hier ist Multi-Police = F.
R5 — Premium-Tarif anwenden.
R5 erfordert No claims = F; hier ist No claims = T.
R3 — Premium-Tarif anwenden.
R3 erfordert Age>=25 = F; hier ist der Fahrer 40 (T).
Alter 40 → Age>=25 = T; keine Schäden in 5 Jahren = T; nur eine Police → Multi-policy = F. Die Spalte mit T, T, F ist R7, deren Aktion '10% Rabatt' ist (Premium-Tarif gilt nicht).
Der folgende Zustandsautomat modelliert eine Login-Maske. Nach 3 ungültigen Versuchen wird das Konto gesperrt (Locked); es kehrt erst nach einem 30-minütigen Reset zu Idle zurück. Wie viele Testfälle sind anhand des Diagramms mindestens nötig, um 100% gültige Übergangsüberdeckung (0-Switch) zu erreichen, wobei jeder Testfall ein Pfad ist, der im Startzustand beginnt?
2
Richtig — zwei im Start beginnende Pfade decken alle fünf gültigen Übergänge ab.
1
Ein einziger Pfad kann nicht sowohl 'valid login' (endet in LoggedIn) als auch 'reset' (braucht Locked) enthalten.
4
Vier ist mehr als das Minimum; zwei gut gewählte Pfade decken bereits alle Übergänge ab.
5
Fünf entspricht der Übergangszahl, aber ein Testfall deckt mehrere Übergänge in einem Pfad ab.
Es gibt 5 Übergänge: enterCredentials, den invaliden Selbstübergang, 3rd invalid, valid login und reset. Ein Pfad (Idle→Entering, invalid, invalid, 3rd invalid→Locked, reset→Idle) deckt vier ab; ein zweiter Pfad (Idle→Entering, valid login→LoggedIn) deckt valid login ab. Also genügen 2 Testfälle.
Was ist der Unterschied zwischen 0-Switch-Überdeckung (alle Übergänge) und 1-Switch-Überdeckung beim Zustandsübergangstest?
0-Switch deckt einzelne Übergänge ab; 1-Switch jede gültige Folge zweier aufeinanderfolgender Übergänge.
Richtig — 1-Switch deckt Übergangspaare ab und erhöht die Gründlichkeit.
0-Switch deckt nur gültige Zustände ab; 1-Switch nur ungültige Zustände.
Switch-Überdeckung betrifft Übergänge/Sequenzen, nicht gültige vs. ungültige Zustände.
0-Switch deckt alle Zustände einmal ab; 1-Switch alle Zustände zweimal.
Switch-Überdeckung zählt Übergänge, nicht Zustandsbesuche.
Es gibt keinen Unterschied; die Begriffe sind Synonyme.
Sie definieren unterschiedliche Überdeckungsgrade.
Die 0-Switch-Überdeckung durchläuft jeden einzelnen gültigen Übergang einmal; die 1-Switch-Überdeckung durchläuft jedes gültige Paar aufeinanderfolgender Übergänge (Sequenzen von zwei Übergängen).
Welche ZWEI Aussagen zum Entscheidungstabellentest sind korrekt? (Wählen Sie ZWEI.)
Volle Überdeckung erfordert mindestens einen Testfall je erreichbare Regel (Spalte).
Richtig — jede umsetzbare Regel sollte mindestens einmal durchlaufen werden.
Entscheidungstabellen sind besonders nützlich, wenn mehrere Bedingungen zusammen ein Ergebnis bestimmen.
Richtig — sie erfassen zusammenwirkende Bedingungen und Aktionen systematisch.
Eine Entscheidungstabelle kann nur eine einzige Bedingung enthalten.
Entscheidungstabellen sind für mehrere Bedingungen ausgelegt.
Der Entscheidungstabellentest garantiert 100% Code-Zweigüberdeckung.
Es ist eine Black-Box-Technik und garantiert keine strukturelle Codeüberdeckung.
Entscheidungstabellen sind eine White-Box-Technik auf Basis der Codestruktur.
Sie sind eine Black-Box-Technik auf Basis von Spezifikationen, nicht von Code.
Entscheidungstabellen modellieren Kombinationen von Bedingungen und resultierenden Aktionen; volle Überdeckung erfordert mindestens einen Testfall je erreichbare Regel (Spalte). Sie eignen sich gut für Geschäftsregeln mit zusammenwirkenden Bedingungen.
Ein Team möchte prüfen, ob ein erfahrener Nutzer einen komplexen Arbeitsablauf mit eigenem Wissen und Intuition ohne vordefinierte Testfälle abschließen kann, indem er die Anwendung erkundet und dabei lernt. Welcher Ansatz wird beschrieben?
Exploratives Testen.
Richtig — Entwurf, Ausführung und Lernen erfolgen gleichzeitig, ohne vordefinierte Skripte.
Grenzwertanalyse.
BVA ist eine spezifikationsbasierte Technik mit vordefinierten Grenzwerten.
Anweisungstest.
Der Anweisungstest ist eine White-Box-Technik auf Basis der Codeüberdeckung.
Checklistenbasiertes Testen.
Checklistenbasiertes Testen folgt einer vordefinierten Prüfliste, anders als freie Exploration.
Exploratives Testen ist ein erfahrungsbasierter Ansatz, bei dem der Tester gleichzeitig entwirft, ausführt und lernt, oft ohne vordefinierte Skripte.
Betrachten Sie diesen Pseudocode: Zeile 1 read x; Zeile 2 if x > 0 then Zeile 3 y = x * 2; Zeile 4 end if; Zeile 5 print y. Ein einzelner Test mit x = 5 wird ausgeführt. Welche Anweisungsüberdeckung erreicht dieser eine Test (gezählt werden die ausführbaren Anweisungen in Zeile 1, 3 und 5 sowie die Entscheidung in Zeile 2)?
100% Anweisungsüberdeckung (aber nur 50% Zweigüberdeckung).
Richtig — alle Anweisungen laufen, aber nur der Wahr-Zweig wird durchlaufen.
50% Anweisungsüberdeckung.
Alle drei ausführbaren Anweisungen laufen, also 100% Anweisungsüberdeckung, nicht 50%.
100% Anweisungs- und 100% Zweigüberdeckung.
Der Falsch-Zweig (x ≤ 0) wird nie genommen, also ist die Zweigüberdeckung nicht 100%.
75% Anweisungsüberdeckung.
Es gibt keine teilweise Anweisung; jede ausführbare Anweisung läuft, also 100%.
Mit x = 5 ist die Entscheidung wahr, also werden alle ausführbaren Anweisungen (read x, y = x*2, print y) ausgeführt. Das sind 100% Anweisungsüberdeckung. Der Falsch-Zweig der Entscheidung wird jedoch nicht genommen, daher beträgt die Zweig-/Entscheidungsüberdeckung nur 50%.
Welche Aussage über den Zusammenhang zwischen Anweisungsüberdeckung und Zweig-(Entscheidungs-)überdeckung ist korrekt?
100% Zweigüberdeckung impliziert 100% Anweisungsüberdeckung, aber nicht umgekehrt.
Richtig — die Zweigüberdeckung schließt die Anweisungsüberdeckung ein.
100% Anweisungsüberdeckung impliziert 100% Zweigüberdeckung.
Alle Anweisungen können laufen, ohne jedes Zweigergebnis zu durchlaufen.
Sie sind für jedes Programm immer gleich.
Sie unterscheiden sich, sobald ein Entscheidungsergebnis nicht genommen wird.
Keine impliziert die andere.
Die Zweigüberdeckung impliziert sehr wohl die Anweisungsüberdeckung; die Beziehung ist einseitig.
100% Zweigüberdeckung garantiert 100% Anweisungsüberdeckung, aber nicht umgekehrt; die Zweigüberdeckung ist stärker, da sie auch jedes Entscheidungsergebnis verlangt.
Eine Funktion enthält genau zwei unabhängige einfache Entscheidungen (zwei separate if-Anweisungen, jede mit Wahr- und Falsch-Ergebnis, ohne Verschachtelung). Wie viele Testfälle sind mindestens nötig, um 100% Zweig-(Entscheidungs-)überdeckung zu erreichen?
2
Richtig — (W,W) und (F,F) decken beide Ergebnisse beider Entscheidungen ab.
4
Vier wären nur für die volle Kombination (z. B. Mehrfachbedingungsüberdeckung) nötig, nicht für einfache Zweigüberdeckung.
1
Ein Test kann nicht beide Ergebnisse (wahr und falsch) einer Entscheidung nehmen.
3
Drei ist mehr als nötig; zwei Durchläufe decken bereits alle vier Ergebnisse ab.
Jede einfache Entscheidung benötigt ihr Wahr- und ihr Falsch-Ergebnis. Zwei unabhängige Entscheidungen lassen sich in denselben Durchläufen kombinieren: Test 1 nimmt (wahr, wahr), Test 2 (falsch, falsch) und deckt alle vier Ergebnisse ab. Also genügen 2 Testfälle.
Was wird typischerweise in einem Testkonzept (Testplan) dokumentiert?
Testumfang, Ziele, Vorgehen, Zeitplan sowie Eingangs-/Ausgangskriterien.
Richtig — das sind Kerninhalte eines Testkonzepts.
Den vollständigen Quellcode des Testobjekts.
Quellcode gehört in die Codebasis, nicht in das Testkonzept.
Das Marketingbudget für den Produktstart.
Marketingbudgets haben nichts mit der Testplanung zu tun.
Die persönlichen Leistungsbeurteilungen der Entwickler.
Personalbeurteilungen sind kein Teil eines Testkonzepts.
Ein Testkonzept beschreibt Umfang, Ziele, Vorgehen, Ressourcen, Zeitplan sowie Eingangs-/Ausgangskriterien des Testens; es verbindet die Teststrategie mit der zu leistenden Arbeit.
Ein Testleiter schätzt den Testaufwand für ein Feature mit der Drei-Punkt-Technik (PERT). Die optimistische Schätzung beträgt 4 Tage, die wahrscheinlichste 10 Tage und die pessimistische 22 Tage. Wie hoch ist der geschätzte Aufwand nach der Formel E = (a + 4m + b) / 6?
11 Tage
Richtig — (4 + 40 + 22) / 6 = 66 / 6 = 11.
12 Tage
Das ist der einfache Durchschnitt von 4, 10 und 22; PERT gewichtet den wahrscheinlichsten Wert mit 4.
10 Tage
10 ist nur der wahrscheinlichste Wert, nicht die gewichtete PERT-Schätzung.
13 Tage
Nachrechnen: (4 + 40 + 22)/6 = 11, nicht 13.
E = (4 + 4*10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 Tage.
Ein Projektleiter befürchtet, dass eine wichtige Testumgebung vom Lieferanten nicht rechtzeitig bereitgestellt wird. Wie wird dieses Risiko im risikobasierten Testen klassifiziert?
Ein Projektrisiko.
Richtig — die verspätete Umgebungslieferung betrifft die Projektsteuerung, ein Projektrisiko.
Ein Produktrisiko.
Produktrisiko betrifft das Verfehlen von Bedürfnissen, nicht Lieferantenverzögerungen.
Ein Restfehler.
Ein Restfehler ist ein nach dem Test verbleibender bekannter Fehler, kein Lieferrisiko.
Eine Fehlerwirkung.
Eine Fehlerwirkung ist ein beobachtetes Fehlverhalten bei der Ausführung, kein Planungsrisiko.
Ein Projektrisiko betrifft das Management und die Steuerung des Projekts (z. B. Ressourcen, Umgebungen, Termine, Lieferanten). Ein Produktrisiko betrifft die Möglichkeit, dass das Produkt Bedürfnisse nicht erfüllt.
Welche ZWEI der folgenden sind Beispiele für PROJEKTrisiken? (Wählen Sie ZWEI.)
Ein Mangel an Testern mit den benötigten Fähigkeiten.
Richtig — Personal-/Skill-Probleme sind Projektrisiken.
Eine Verzögerung des Lieferanten bei der Lieferung einer kritischen Komponente.
Richtig — Lieferantenverzögerungen gefährden die Projektlieferung, ein Projektrisiko.
Das Zahlungsmodul könnte Summen falsch berechnen.
Das ist ein Produktrisiko — es betrifft die Korrektheit des Produkts.
Die Anwendung könnte unter Spitzenlast zu langsam reagieren.
Das ist ein Produktrisiko zur Performanz, kein Projektrisiko.
Sensible Daten könnten durch eine Sicherheitslücke offengelegt werden.
Das ist ein Produkt-(Qualitäts-)risiko zur Sicherheit, kein Projektrisiko.
Projektrisiken betreffen die Lieferfähigkeit des Projekts: Personal-/Skill-Engpässe, organisatorische Probleme, Lieferantenverzögerungen, Umgebungsverfügbarkeit. Produktrisiken betreffen das Produkt selbst (z. B. falsche Berechnungen, schlechte Performanz, Sicherheitslücken).
Ein Team hat vier Produktrisiken mit folgenden Risikostufen (Eintrittswahrscheinlichkeit × Auswirkung): R1 = niedrig × hoch, R2 = hoch × hoch, R3 = hoch × niedrig, R4 = niedrig × niedrig. Es ist nur Zeit, zwei dieser Bereiche zuerst gründlich zu testen. Welche zwei Bereiche sollten gemäß risikobasiertem Testen die tiefste, früheste Prüfung erhalten?
R2 und R3 (die beiden mit einem 'hohen' Faktor und dem höchsten Gesamtrisiko), vor R1 und R4.
Richtig — R2 ist am höchsten; R3 (hoch×niedrig) folgt als kombiniertes Risiko, R4 (niedrig×niedrig) klar zuletzt.
R1 und R4, weil sie einfacher zu testen sind.
Testaufwand ist nicht die Basis der risikobasierten Priorisierung; R4 ist das geringste Risiko.
R3 und R4, weil beide eine hohe Eintrittswahrscheinlichkeit haben.
R4 hat niedrige Wahrscheinlichkeit und niedrige Auswirkung — es ist das geringste Risiko.
Alle vier gleichermaßen, unter Ignorieren der Risikostufen.
Alle Risiken gleich zu behandeln widerspricht dem Zweck des risikobasierten Testens.
Risikobasiertes Testen priorisiert das höchste kombinierte Risiko (Wahrscheinlichkeit × Auswirkung). R2 (hoch × hoch) ist klar am höchsten. R1 (niedrig × hoch) und R3 (hoch × niedrig) rangieren über R4 (niedrig × niedrig). Zuerst kommen also die beiden mit dem größten Risiko; R4 ist klar zuletzt.
Welches der folgenden ist das BESTE Beispiel für ein Ausgangskriterium (Kriterium zum Beenden des Tests) für eine Teststufe?
Alle geplanten Tests sind ausgeführt und es bleiben keine hochpriorisierten Fehler offen.
Richtig — das definiert, wann das Testen als abgeschlossen gilt.
Die Testumgebung ist eingerichtet und der Build installiert.
Das ist ein Eingangskriterium (Vorbedingung zum Start), kein Ausgangskriterium.
Die Anforderungen wurden gereviewt und freigegeben.
Das ist ein typisches Eingangskriterium, kein Beendigungskriterium.
Testdaten stehen zum Start der Durchführung bereit.
Die Verfügbarkeit von Testdaten ist eine Eingangsbedingung zum Start.
Ausgangs-(Abschluss-)kriterien definieren, wann eine Testaktivität enden darf, z. B. Überdeckungsziele erreicht, keine offenen hochpriorisierten Fehler, geplante Tests ausgeführt. Eingangskriterien definieren Vorbedingungen zum Start.
Welche der folgenden Informationen ist in einem guten Fehlerbericht ESSENZIELL, um ihn reproduzierbar zu machen?
Klare Reproduktionsschritte mit Soll- und Ist-Ergebnis.
Richtig — Reproduktionsschritte sowie Soll/Ist sind essenziell für die Reproduzierbarkeit.
Der Name des Entwicklers, dem die Schuld zuzuweisen ist.
Schuldzuweisung ist kontraproduktiv und kein Bestandteil eines guten Fehlerberichts.
Die Gesamtzahl der Testfälle im Projekt.
Projektweite Zählungen helfen nicht, einen konkreten Fehler zu reproduzieren.
Das Marketing-Releasedatum des Produkts.
Releasetermine haben nichts mit der Reproduktion eines Fehlers zu tun.
Ein nützlicher Fehlerbericht enthält Reproduktionsschritte, Soll- und Ist-Ergebnis, Umgebung/Konfiguration sowie Schweregrad/Priorität — genug, damit ein anderer den Fehler reproduzieren und bewerten kann.
Der Testfortschritt liegt hinter dem Zeitplan. Welche ZWEI der folgenden sind geeignete Maßnahmen der Teststeuerung? (Wählen Sie ZWEI.)
Die verbleibenden Tests neu priorisieren, sodass die Bereiche mit dem höchsten Risiko zuerst abgedeckt werden.
Richtig — Neupriorisierung nach Risiko ist eine übliche Steuerungsmaßnahme.
Ressourcen umverteilen oder den Zeitplan anpassen und die Auswirkung den Stakeholdern berichten.
Richtig — Ressourcen/Zeitplan anzupassen und Stakeholder zu informieren ist gültige Steuerung.
Das Erfassen von Fehlern einstellen, damit die Metriken besser aussehen.
Fehlerdaten zu unterdrücken ist unehrlich und schadet Qualitätsentscheidungen.
Alle offenen Fehler ohne Verifikation als „behoben“ markieren.
Den Fehlerstatus zu fälschen ist unethisch und untergräbt die Testintegrität.
Die Statusberichte an das Management einstellen, bis das Testen fertig ist.
Status zurückzuhalten nimmt die für Steuerungsentscheidungen nötige Transparenz.
Teststeuerung lenkt das Testen auf die Ziele zurück, z. B. Tests nach Risiko neu priorisieren, Ressourcen umverteilen, Zeitplan anpassen oder Eingangs-/Ausgangskriterien anpassen. Fehler verbergen oder Berichterstattung weglassen sind keine gültigen Steuerungsmaßnahmen.
Warum ist das Konfigurationsmanagement für das Testen wichtig?
Es stellt sicher, dass Testelemente und Testware eindeutig identifiziert und versioniert sind, sodass Ergebnisse reproduzierbar sind.
Richtig — nachvollziehbare, versionierte Elemente machen Testergebnisse reproduzierbar und verlässlich.
Es garantiert, dass die Software keine Fehler enthält.
Konfigurationsmanagement steuert Versionen; es beseitigt keine Fehler.
Es ersetzt den Bedarf an einem Testkonzept.
Konfigurationsmanagement ergänzt die Planung, ersetzt sie aber nicht.
Es führt automatisch alle Regressionstests aus.
Die Testdurchführung erfolgt durch Personen oder Testausführungswerkzeuge, nicht durch Konfigurationsmanagement.
Das Konfigurationsmanagement stellt sicher, dass alle Testelemente (Testware, Softwareversionen, Umgebungen, Daten) eindeutig identifiziert, versioniert und nachvollziehbar sind, sodass Testergebnisse reproduzierbar sind und sich auf bekannte Versionen beziehen.
Ein Team plant die Einführung eines Testautomatisierungswerkzeugs. Welches der folgenden ist ein realistisches RISIKO (kein Vorteil) der Einführung eines solchen Werkzeugs?
Der Aufwand zur Pflege der automatisierten Testskripte kann unterschätzt werden.
Richtig — der Wartungsaufwand ist ein bekanntes Risiko der Testautomatisierung.
Repetitive manuelle Arbeit kann reduziert werden.
Das ist ein Vorteil der Werkzeugunterstützung, kein Risiko.
Eine objektivere Bewertung (z. B. Überdeckungsmessung) wird möglich.
Das ist ein Vorteil, kein Risiko.
Einfacherer Zugang zu Informationen über Tests und das Testen.
Verbesserter Informationszugang ist ein Vorteil der Werkzeugunterstützung.
Risiken der Werkzeugeinführung sind u. a. unrealistische Erwartungen, Unterschätzung des Aufwands zur Pflege der Testskripte, übermäßiges Vertrauen in das Werkzeug sowie Einführungs- und Wartungskosten. Vorteile sind u. a. weniger repetitive Arbeit und objektivere Bewertung.
Welche ZWEI der folgenden sind Beispiele für Werkzeuge, die die Testdurchführung und Protokollierung oder das Testmanagement unterstützen? (Wählen Sie ZWEI.)
Ein Unit-Test-/Automatisierungs-Framework, das Tests ausführt und Pass/Fail-Ergebnisse aufzeichnet.
Richtig — das ist ein Testausführungs- und Protokollierungswerkzeug.
Ein Testmanagementwerkzeug, das Testfälle, Durchläufe und die Nachverfolgbarkeit zu Anforderungen speichert.
Richtig — ein Testmanagementwerkzeug unterstützt Organisation und Nachverfolgung des Testens.
Eine allgemeine Textverarbeitung.
Eine Textverarbeitung ist kein dediziertes Testwerkzeug.
Ein Sprachcompiler zum Erstellen der Anwendung.
Ein Compiler erstellt Software; er ist kein Testwerkzeug.
Eine Tabellenkalkulation für die private Budgetplanung.
Eine private Budget-Tabelle hat keine Rolle bei Testdurchführung oder -management.
Werkzeugkategorien sind u. a. Testmanagementwerkzeuge, Werkzeuge zur statischen Analyse, Testausführungswerkzeuge (z. B. Unit-Test-/Automatisierungs-Frameworks), Performanztestwerkzeuge und Fehlermanagementwerkzeuge. Ein Compiler und eine Textverarbeitung sind Allzweckwerkzeuge, keine Testwerkzeuge.