ISTQB Foundation (CTFL v4.0) Probeprüfung #13 — 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 Entwickler geht im Debugger durch den Code, um zu finden, warum eine Berechnung die falsche Summe liefert, und ändert dann die fehlerhafte Zeile. Wie heißt diese Tätigkeit gemäß der ISTQB-Unterscheidung?
Debugging
Das Lokalisieren, Diagnostizieren und Beheben eines Fehlerzustands ist Debugging, eine Entwicklungstätigkeit.
Dynamisches Testen
Dynamisches Testen führt Code aus, um Fehlerwirkungen zu beobachten, nicht um die Ursache zu beheben.
Bestätigungstest
Ein Bestätigungstest wiederholt einen Test nach der Korrektur; er führt die Korrektur nicht durch.
Statische Analyse
Statische Analyse untersucht Code ohne Ausführung und behebt keine Fehlerzustände.
Testen findet Fehlerwirkungen; Debugging findet, analysiert und behebt den zugrunde liegenden Fehlerzustand.
Ein Team führt jede Nacht eine umfangreich wirkende Suite aus und der Build ist stets grün, dennoch melden Nutzer ständig Abstürze in der Produktion. Welches Testprinzip erklärt diese Situation am besten?
Testen zeigt die Anwesenheit, nicht die Abwesenheit von Fehlerzuständen
Grüne Tests können nicht beweisen, dass keine Fehlerzustände existieren; ungetestete Bedingungen können dennoch fehlschlagen.
Vollständiges Testen ist unmöglich
Allgemein wahr, aber hier geht es darum, dass bestandene Tests keine Fehlerfreiheit garantieren, nicht um die Zahl der Kombinationen.
Tests nutzen sich ab (Pestizid-Paradoxon)
Dieses Prinzip betrifft, dass wiederholte Tests mit der Zeit weniger neue Fehlerzustände finden, nicht grüne Builds, die Abstürze verbergen.
Fehlerzustände treten gehäuft auf
Häufung sagt vorher, wo sich Fehlerzustände konzentrieren; sie erklärt nicht, warum bestandene Tests Produktionsabstürze übersehen.
Bestandene Tests zeigen nur das Fehlen der abgedeckten Fehlerwirkungen, nie das Fehlen aller Fehlerzustände.
In einem Sprint-Review sagt der Product Owner: 'Ich habe viel mehr Vertrauen in die Freigabe, jetzt da das Regressionspaket grün ist.' Welches Testziel wird hier erfüllt?
Vertrauen in das Qualitätsniveau aufbauen
Eine bestandene Regressionssuite erhöht das Vertrauen der Stakeholder in die Qualität — ein Kernziel.
Fehlerzustände verhindern
Fehlervermeidung erfolgt früher (z. B. Anforderungsreviews), nicht durch ein grünes Paket im Review.
Fehlerzustände finden
Hier wurden keine neuen Fehlerzustände gefunden; die Aussage betrifft Vertrauen, nicht Entdeckung.
Vertragliche Anforderungen erfüllen
Es wird kein Vertrag oder keine Vorschrift erwähnt; Auslöser ist das Vertrauen der Stakeholder.
Vertrauen in das Qualitätsniveau aufzubauen ist neben dem Finden von Fehlerzuständen ein anerkanntes Testziel.
Ein Tester gibt '30.02.2026' in ein Datumsfeld ein. Das Feld akzeptiert es und das System berechnet später ein Rechnungsdatum falsch. Ordnen Sie Fehlhandlung, Fehlerzustand und Fehlerwirkung in dieser Reihenfolge zu.
Fehlhandlung: falsche Annahme des Entwicklers zur Validierung; Fehlerzustand: fehlende Datumsbereichsprüfung im Code; Fehlerwirkung: falsches Rechnungsdatum
Der menschliche Irrtum ist die Fehlhandlung, der daraus entstehende Codefehler der Fehlerzustand und die beobachtbare falsche Ausgabe die Fehlerwirkung.
Fehlhandlung: falsches Rechnungsdatum; Fehlerzustand: Tippfehler des Testers; Fehlerwirkung: fehlende Validierung
Das kehrt die Kette um — das falsche Rechnungsdatum ist die Fehlerwirkung, nicht die Fehlhandlung.
Fehlhandlung: fehlende Validierung; Fehlerzustand: falsches Rechnungsdatum; Fehlerwirkung: Annahme des Entwicklers
Fehlende Validierung ist der Fehlerzustand und die Annahme des Entwicklers die Fehlhandlung — die Rollen sind vertauscht.
Alle drei Begriffe beschreiben dasselbe einzelne Ereignis
Es sind unterschiedliche, kausal verknüpfte Konzepte, keine Synonyme.
Fehlhandlung → Fehlerzustand (im Code) → Fehlerwirkung (beobachtetes Fehlverhalten) bilden die Ursachenkette.
Welche Aussage beschreibt am besten, warum ein Whole-Team-Ansatz mit Unabhängigkeit der Tester geschätzt wird, obwohl Entwickler auch ihren eigenen Code testen?
Unabhängige Tester haben andere Annahmen und unterliegen weniger der Autorenverzerrung
Andere Perspektiven decken Fehlerzustände auf, die Autoren, verankert im eigenen Denkmodell, übersehen.
Unabhängige Tester können fehlerfreie Software garantieren
Kein Testen kann Fehlerfreiheit garantieren; Unabhängigkeit verbessert nur die Entdeckung.
Entwickler sollten ihren eigenen Code nie testen
Entwickler testen ihren Code durchaus; Unabhängigkeit ergänzt dies, ersetzt es nicht.
Unabhängigkeit macht Testentwurfsverfahren überflüssig
Unabhängigkeit ersetzt keine systematischen Verfahren; beides ist nötig.
Unabhängige Tester bringen andere Annahmen und Verzerrungen mit und finden daher eher Fehlerzustände, die Autoren übersehen.
Eine Bank verlangt, dass jede Testaktivität auf eine dokumentierte Anforderung rückverfolgbar ist, und ein Prüfer kontrolliert diese Verfolgung. Welche zwei Testziele werden am unmittelbarsten erfüllt? (Wählen Sie zwei.)
Vertragliche, gesetzliche oder regulatorische Anforderungen erfüllen
Prüfbare Rückverfolgbarkeit ist ein klassisches konformitätsgetriebenes Ziel.
Stakeholdern Informationen für fundierte Entscheidungen liefern
Die Verfolgung gibt Stakeholdern Belege über die Abdeckung als Basis für Freigabeentscheidungen.
Die Kosten für Cloud-Hosting senken
Hosting-Kosten haben nichts mit Zielen der Anforderungsverfolgung zu tun.
Die Abwesenheit von Fehlerzuständen garantieren
Kein Ziel kann Fehlerfreiheit garantieren; Rückverfolgbarkeit ändert dieses Prinzip nicht.
Rückverfolgbarkeit zu Anforderungen unterstützt sowohl die Konformitäts-/Vertragsprüfung als auch die Informationsbereitstellung für Entscheidungen.
Welches Paar ordnet eine typische Aktivität des Testprozesses korrekt ihrem Zweck zu?
Testanalyse — bestimmen, 'was getestet wird', durch Identifikation von Testbedingungen
Die Testanalyse wertet die Testbasis aus, um Testbedingungen abzuleiten.
Testrealisierung — Festlegen der übergeordneten Testziele und des Umfangs
Ziele und Umfang gehören zur Testplanung, nicht zur Testrealisierung.
Testabschluss — erstmaliges Ausführen der Testfälle
Die erste Ausführung gehört zur Testdurchführung; der Abschluss archiviert Artefakte und berichtet Ergebnisse.
Testentwurf — Überwachung des Fortschritts gegenüber dem Plan
Überwachung ist eine Steuerungstätigkeit; der Testentwurf erstellt Testfälle aus Bedingungen.
Die Testanalyse identifiziert testbare Merkmale und definiert Testbedingungen ('was getestet wird').
Zur Mitte eines Testzyklus zeigen die Berichte, dass nur 40 % der geplanten Tests durchgeführt wurden. Der Testmanager reduziert daraufhin den Umfang der Regressionstestsuite und priorisiert die verbleibenden Tests neu. Wofür ist diese Entscheidung in ISTQB-Begriffen ein Beispiel?
Teststeuerung
Richtig — Korrekturmaßnahmen auf Basis der Überwachungsinformationen (Neupriorisierung, Umfangsänderung, Aufwandsverlagerung) sind Teststeuerung.
Testüberwachung
Die Überwachung hat den Wert von 40 % durch Sammeln und Berichten der Fortschrittsdaten geliefert. Die anschließende Entscheidung gehört zur Steuerung.
Testplanung
Die Planung legt Ziele, Vorgehen und Zeitplan vor Beginn des Zyklus fest. Hier wird ein bestehender Plan während der Durchführung gesteuert, also Steuerung.
Testabschluss
Der Testabschluss erfolgt am Ende des Testzyklus oder Projekts: Testmittel werden archiviert, Ergebnisse berichtet und Lessons Learned festgehalten. Dort wird nichts neu priorisiert.
Die Testüberwachung sammelt und berichtet Informationen zum Fortschritt; die Teststeuerung nutzt diese Informationen für Korrekturmaßnahmen wie Neupriorisierung von Tests oder Änderung des Testumfangs, damit die Testziele dennoch erreicht werden.
Ein Team führt einen Shift-Left-Ansatz ein. Welche konkrete Maßnahme verkörpert ihn am besten?
Tester reviewen User Stories und Akzeptanzkriterien während des Refinements, bevor die Codierung beginnt
Reviews vor dem Schreiben von Code sind eine typische Shift-Left-Aktivität.
Mehr manuelles exploratives Testen im finalen Härtungs-Sprint hinzufügen
Aufwand am Ende zu bündeln ist zeitlich Shift-Right, das Gegenteil von Shift-Left.
Das Live-System mit Produktions-Logging überwachen
Produktionsüberwachung ist eine Shift-Right-Praxis, wertvoll, aber nicht Shift-Left.
Alle Tests verschieben, bis ein vollständiger Build vorliegt
Auf einen vollständigen Build zu warten verschiebt Tests nach hinten und widerspricht Shift-Left.
Shift-Left bedeutet, Testaktivitäten früher zu beginnen, z. B. Anforderungen zu reviewen und Tests vor dem Code zu schreiben.
Auf der linken Seite eines V-Modells werden Systemtestfälle parallel zu welchem Arbeitsergebnis entworfen?
Die System-/Software-Anforderungsspezifikation
Systemtests prüfen das System gegen seine Anforderungsspezifikation, die parallel entworfen wird.
Der detaillierte Komponenten-(Unit-)Entwurf
Der Komponentenentwurf entspricht dem Komponententest, nicht dem Systemtest.
Der Business Case / die Machbarkeitsstudie
Ein Business Case geht den Anforderungen voraus und ist keine Basis für den Systemtestentwurf.
Der Quellcode
Quellcode entsteht beim Abstieg; Systemtests werden früher aus Anforderungen entworfen.
Im V-Modell wird jede Teststufe gegen die entsprechende Entwicklungsstufe entworfen; Systemtests entsprechen der System-/Software-Anforderungsspezifikation.
Ein Release-Kandidat hat den Systemtest bestanden. Vor dem Go-Live validieren echte Endnutzer in der Fachabteilung, dass die Software ihren täglichen Arbeitsablauf gemäß den Geschäftsanforderungen unterstützt. Welche Teststufe ist das?
Abnahmetest
Die Validierung der Gebrauchstauglichkeit gegen Geschäftsanforderungen durch Nutzer ist der Abnahmetest.
Integrationstest
Der Integrationstest prüft Schnittstellen zwischen Komponenten/Systemen, nicht die Geschäftstauglichkeit.
Komponententest
Der Komponententest zielt auf isolierte Einheiten, durchgeführt von Entwicklern, nicht Fachnutzern.
Komponentenintegrationstest
Dieser betrifft weiterhin interne Schnittstellen, nicht die Nutzervalidierung von Geschäftsabläufen.
Der Abnahmetest validiert die Gebrauchstauglichkeit und Einsatzbereitschaft aus Nutzer-/Geschäftssicht.
Nachdem ein Fehlerzustand im Zahlungsmodul behoben wurde, führt das Team genau den fehlgeschlagenen Test erneut aus, um die Korrektur zu prüfen, und danach auch benachbarte, zuvor bestandene Tests im Checkout-Ablauf. Nennen Sie die beiden Testarten in dieser Reihenfolge.
Bestätigungstest, dann Regressionstest
Den fehlgeschlagenen Test erneut auszuführen ist Bestätigung; die zuvor bestandenen Nachbarn erneut auszuführen ist Regression.
Regressionstest, dann Bestätigungstest
Die Reihenfolge ist vertauscht — zuerst bestätigt man die Korrektur, dann sucht man Regressionen.
Smoke-Test, dann Retest
Ein Smoke-Test ist eine breite Grundprüfung, nicht das gezielte Wiederholen des fehlgeschlagenen Falls.
Wartungstest, dann Bestätigungstest
Der Wartungstest ist ein breiterer Kontext (Änderungen an einem ausgelieferten System), nicht diese zwei spezifischen Wiederholungen.
Der Bestätigungstest prüft die Korrektur; der Regressionstest prüft, dass die Änderung zuvor funktionierendes Verhalten nicht beschädigt hat.
Eine mobile App ist seit zwei Jahren produktiv. Eine neue OS-Version erscheint und eine Steuerrechtsänderung erfordert aktualisierte Berechnungen. Welche zwei Punkte sind Beispiele für Auslöser von Wartungstests? (Wählen Sie zwei.)
Upgrade auf die neue Betriebssystemversion (Änderung der Betriebsumgebung)
Migration/Upgrade der Betriebsumgebung ist ein anerkannter Auslöser für Wartungstests.
Ändern der Berechnungslogik für das neue Steuerrecht
Eine korrektive/adaptive Modifikation an produktiver Software löst Wartungstests aus.
Die allerersten Unit-Tests während der Erstentwicklung schreiben
Tests der Erstentwicklung sind kein Wartungstest, der erst nach der Auslieferung gilt.
Die Farbgebung der Marketing-Website auswählen
Eine kosmetische Wahl auf einer separaten Website ist kein Auslöser für Wartungstests der App.
Wartungstests werden durch Modifikationen, Migration/Upgrade der Umgebung und Stilllegung ausgelöst; hier qualifizieren sich OS-Upgrade und eine regulatorische Änderung.
Was ist ein Beispiel für eine nicht-funktionale Testart statt einer funktionalen?
Die Seitenantwortzeit bei 1.000 gleichzeitigen Nutzern messen (Performanzeffizienz)
Performanzeffizienz ist ein nicht-funktionales Qualitätsmerkmal ('wie gut').
Prüfen, dass ein gültiger Login zum Dashboard führt
Zu prüfen, was das System tut (Login-Ergebnis), ist funktionales Testen.
Prüfen, dass der Rabatt auf die Warenkorbsumme angewendet wird
Den korrekten Rabatt zu berechnen ist ein funktionales Verhalten.
Bestätigen, dass bei einem leeren Pflichtfeld eine Fehlermeldung erscheint
Das Verhalten bei Pflichtfeldern zu validieren ist funktionales Testen.
Performanz, Gebrauchstauglichkeit, Zuverlässigkeit, Übertragbarkeit und Sicherheit sind nicht-funktionale Qualitätsmerkmale.
Ein Anforderungsdokument wird in einem formalen Review unter Leitung eines geschulten Moderators geprüft, mit definierten Rollen, individueller Vorbereitung, protokollierter Sitzung und erfassten Metriken. Welcher Review-Typ ist das?
Inspektion
Der geschulte Moderator, definierte Rollen, Vorbereitung und Metriken kennzeichnen eine Inspektion.
Informelles Review
Ein informelles Review hat keinen definierten Prozess, keine Rollen oder Metriken — das Gegenteil dieses Falls.
Walkthrough
Ein Walkthrough wird vom Autor geleitet und erfordert weder Metriken noch einen geschulten Moderator.
Ad-hoc-Schreibtischtest
Ein Schreibtischtest ist eine informelle Einzelprüfung ohne den beschriebenen formalen Apparat.
Eine Inspektion ist das formalste Review: geschulter Moderator, Rollen, Ein-/Ausgangskriterien, Vorbereitung und Metriken.
Warum ist das statische Testen einer Anforderungsspezifikation oft kosteneffizienter, als zu warten, bis dynamisches Testen dasselbe Problem aufdeckt?
In Anforderungen gefundene Fehlerzustände werden entfernt, bevor sie sich in Design, Code und Tests fortpflanzen
Einen Anforderungsfehler früh zu entfernen vermeidet die vervielfachten Kosten einer späteren Korrektur.
Statisches Testen führt den Code schneller aus als dynamisches Testen
Statisches Testen führt überhaupt keinen Code aus und kann daher nicht 'schneller ausführen'.
Statisches Testen garantiert, dass keine Fehlerzustände in die Produktion gelangen
Keine Technik garantiert null entwichene Fehlerzustände.
Statisches Testen macht dynamisches Testen überflüssig
Beide ergänzen sich; statisches Testen kann keine Laufzeit-/Verhaltensfehler finden.
Statisches Testen findet Fehlerzustände früh, bevor sie sich in Code und Tests fortpflanzen, und senkt so die Beseitigungskosten.
Welche zwei Anomalien kann ein Anforderungsreview realistisch erkennen, die dynamisches Testen typischerweise nicht erkennt? (Wählen Sie zwei.)
Eine mehrdeutige Anforderung, die zwei Leser unterschiedlich interpretieren
Mehrdeutigkeit ist ein Dokumentationsfehler, den ein Review aufdeckt; ausgeführter Code kann ihn nicht zeigen.
Eine Anforderung, die in der Spezifikation gänzlich fehlt
Eine Auslassung können Reviewer im Abgleich mit den Bedürfnissen erkennen; dynamische Tests prüfen nur Vorhandenes.
Ein Speicherleck, das erst nach Stunden Laufzeit auftritt
Ein Laufzeit-Speicherleck ist eine rein dynamische Fehlerwirkung, durch ein statisches Review nicht erkennbar.
Eine zeitliche Race-Condition unter hoher Nebenläufigkeitslast
Eine Nebenläufigkeits-Race tritt nur zur Laufzeit auf und wird durch dynamisches Testen gefunden.
Reviews erkennen Mehrdeutigkeiten, Widersprüche, fehlende Anforderungen und Standardabweichungen — Probleme, die durch Codeausführung nicht sichtbar sind.
Der Review-Prozess beginnt mit einer Planungsaktivität. Was wird in dieser Aktivität festgelegt, bevor die Reviewer das Arbeitsergebnis erhalten?
Umfang und Zweck des Reviews, Review-Typ und Rollen, die zu nutzenden Checklisten und bei formaleren Reviews die Eingangs- und Endekriterien.
Richtig — all das wird in der Review-Planung festgelegt, damit die Reviewer wissen, worauf sie achten, und wann das Review als abgeschlossen gilt.
Der Status und der Schweregrad jeder gefundenen Anomalie.
Zum Planungszeitpunkt existieren noch keine Anomalien. Sie werden später bei der Kommunikation und Analyse der Befunde besprochen und mit Status und Schweregrad versehen.
Die Korrekturen, die der Autor am Arbeitsergebnis vornehmen wird.
Korrekturen werden in der letzten Aktivität, dem Beheben und Berichten, festgelegt und durchgeführt, nachdem die Anomalien akzeptiert wurden.
Die individuellen Befunde jedes Reviewers.
Individuelle Befunde entstehen in der Aktivität des individuellen Reviews, wenn jeder Reviewer das Arbeitsergebnis für sich prüft.
Die Review-Planung legt Umfang und Zweck des Reviews, das zu prüfende Arbeitsergebnis, die zu bewertenden Qualitätseigenschaften, den Review-Typ und die Rollen, die zu nutzenden Checklisten, den Aufwand und bei formaleren Reviews die Eingangs- und Endekriterien fest.
Ein Registrierungsformular hat ein 'Alter'-Feld, das ganze Zahlen akzeptiert. Die Geschäftsregel lautet: Alter 18 bis 65 einschließlich wird akzeptiert; unter 18 wird der Antrag abgelehnt; über 65 wird der Antrag zur manuellen Prüfung weitergeleitet. Wie viele Testfälle sind bei Äquivalenzklassenbildung allein für das Altersfeld mindestens nötig, um jede gültige und ungültige Klasse genau einmal abzudecken?
3
Je ein Wert aus den drei Ergebnisklassen (z. B. 40, 10, 80) ergibt vollständige Klassenabdeckung.
2
Zwei Fälle können drei verschiedene Klassen nicht abdecken; eine Klasse bliebe ungetestet.
4
Vier würde eine Klasse redundant testen; für das Ergebnis existieren nur drei Klassen.
6
Sechs entspricht der Grenzwertanalyse, nicht der minimalen Klassenabdeckung.
Es gibt drei Klassen für das Ergebnis (akzeptieren 18–65, ablehnen <18, weiterleiten >65). ÄK verlangt mindestens einen Wert je Klasse → 3 Testfälle.
Verwenden Sie dasselbe Altersfeld, dessen gültiger Bereich 18 bis 65 einschließlich (ganze Zahlen) ist. Welche Menge an Alterswerten ist bei 2-Werte-Grenzwertanalyse (jede Grenze plus der nächste Nachbar auf der ungültigen Seite) genau zu testen?
17, 18, 65, 66
Jede Grenze (18, 65) plus der nächste ungültige Nachbar (17, 66) — vier Werte.
17, 18, 19, 64, 65, 66
Das ist die 3-Werte-GWA (Grenze plus beide Nachbarn), nicht die 2-Werte.
18, 65
Nur die Grenzen selbst — die nächsten ungültigen Nachbarn fehlen.
18, 19, 64, 65
Das sind die Grenzen und ihre gültigen Nachbarn; die 2-Werte-GWA nutzt den ungültigen Nachbarn.
Die 2-Werte-GWA testet jede Grenze und den unmittelbar außerhalb liegenden Wert: für [18,65] sind das 17, 18, 65, 66.
Eine Rabatt-Engine gewährt kostenlosen Versand, wenn die Bestellsumme mindestens 50 € und höchstens 500 € (einschließlich) beträgt. Wie viele verschiedene Testwerte sind bei 3-Werte-Grenzwertanalyse der Bestellsumme erforderlich, um beide Grenzen abzudecken?
6
Zwei Grenzen × je drei Werte (49/50/51 und 499/500/501) = 6 verschiedene Werte.
4
Vier ist die 2-Werte-GWA, nicht die 3-Werte.
3
Drei deckt nur eine Grenze ab; es gibt zwei Grenzen zu testen.
8
Acht zählt zu viel; die 3-Werte-GWA braucht genau drei Werte je Grenze.
Die 3-Werte-GWA testet die Grenze sowie die Werte direkt darunter und darüber: untere 49,50,51 und obere 499,500,501 → 6 Werte.
Regel R6 → Paid upgrade offer
R6 hat Gold=N, verfügbar=J, Preis>=200=N und führt zur Aktion 'Paid upgrade offer'.
Regel R5 → Free upgrade
R5 verlangt Preis>=200=J, aber 180 € liegt unter 200, daher greift R5 nicht.
Regel R2 → Free upgrade
R2 verlangt Gold=J; dieser Gast ist kein Gold-Mitglied.
Regel R7 → No upgrade
R7 verlangt verfügbar=N, aber ein Zimmer ist verfügbar, daher passt R7 nicht.
Gold=N, verfügbar=J, Preis 180 € bedeutet 'Preis >= 200?' = N. Das entspricht Spalte R6 mit der Aktion 'Paid upgrade offer'.
4 Regeln werden zu 1 zusammengefasst
R3, R4, R7, R8 teilen verfügbar=N und dieselbe Aktion und werden zu einer Don't-care-Regel.
2 Regeln werden zu 1 zusammengefasst
Mehr als zwei Regeln haben verfügbar=N; alle vier qualifizieren sich, nicht nur zwei.
3 Regeln werden zu 1 zusammengefasst
Vier Regeln (R3, R4, R7, R8), nicht drei, teilen die Don't-care-Bedingung.
Keine Regeln können zusammengefasst werden
Das Zusammenfassen ist gerade deshalb gültig, weil vier Regeln unter einer Don't-care-Bedingung dieselbe Aktion liefern.
Die Regeln R3, R4, R7, R8 haben alle Zimmer verfügbar=N und dieselbe Aktion 'No upgrade'; die anderen Bedingungen sind Don't-care, daher werden diese vier Regeln zu einer zusammengefasst.
Welche Aussage zur Äquivalenzklassenbildung ist korrekt?
Es wird angenommen, dass alle Werte innerhalb einer Klasse gleich verarbeitet werden, sodass ein Repräsentant getestet werden kann
Das ist die definierende Annahme, die die ÄK die Testanzahl reduzieren lässt.
Klassen müssen sich stets überlappen, um vollständige Abdeckung zu sichern
Gültige Klassen sind disjunkt; Überlappung würde die Äquivalenzannahme verletzen.
Äquivalenzklassenbildung gilt nur für ungültige Eingaben
Die ÄK gilt für gültige und ungültige Klassen.
Sie erfordert das Testen jedes möglichen Werts in jeder Klasse
Das wäre vollständiges Testen, das die ÄK gerade vermeiden soll.
Die Kernannahme der ÄK ist, dass alle Mitglieder einer Klasse gleich verarbeitet werden, sodass ein Repräsentant für die ganze Klasse steht.
7
Es gibt sieben gültige Übergänge, daher braucht die 0-switch-Abdeckung sieben Testfälle.
5
Fünf zählt zu wenig — es ignoriert beide 'reject'-Übergänge oder den 'decline'-Übergang.
4
Vier entspricht dem längsten Happy Path, nicht der Zahl aller Übergänge.
8
Acht zählt zu viel; der Startpfeil ist kein beschrifteter Zustandsübergang, der separat zu testen wäre.
0-switch-Abdeckung braucht einen Test pro gültigem Übergang. Das Diagramm hat 7: review, pass(Screening→Interview), pass(Interview→Offer), reject(Screening), reject(Interview), accept, decline.
Etwa 83% (5 von 6 Anweisungen)
Zeile 5 wird nicht ausgeführt, da b nicht größer als 0 ist; die anderen fünf laufen.
100%
Zeile 5 bleibt unausgeführt, daher kann die Überdeckung nicht vollständig sein.
67%
67% hieße, nur 4 von 6 Anweisungen liefen, aber fünf werden ausgeführt.
50%
Die Hälfte wäre 3 von 6; tatsächlich laufen fünf der sechs Anweisungen.
Mit a=5,b=-1 werden die Zeilen 1,2,3,4,6 ausgeführt, Zeile 5 (b>0-Zweig) jedoch übersprungen: 5 von 6 Anweisungen = 83%.
Welche zwei der folgenden sind Black-Box-Verfahren (spezifikationsbasiert)? (Wählen Sie zwei.)
Äquivalenzklassenbildung
Sie leitet Tests aus der Spezifikation von Ein-/Ausgaben ab, ein Black-Box-Verfahren.
Grenzwertanalyse
Die GWA ist spezifikationsbasiert und fokussiert die Klassenränder — Black-Box.
Anweisungsüberdeckung
Die Anweisungsüberdeckung misst ausgeführte Codezeilen — ein White-Box-Verfahren.
Zweigüberdeckung
Die Zweigüberdeckung basiert auf dem Kontrollfluss des Codes — White-Box, nicht Black-Box.
Äquivalenzklassenbildung und Grenzwertanalyse sind Black-Box; Anweisungs- und Zweigüberdeckung sind White-Box (strukturbasiert).
Ein erfahrener Tester prüft ohne formale Testfälle eine neue Funktion, indem er auf frühere Fehlererfahrung und Intuition zurückgreift und Tests in zeitlich begrenzten Sitzungen gleichzeitig entwirft und ausführt. Welche zwei Begriffe beschreiben das Geschehen? (Wählen Sie zwei.)
Exploratives Testen
Tests gleichzeitig zu entwerfen und in zeitlich begrenzten Sitzungen auszuführen ist exploratives Testen.
Fehler-Raten (Error Guessing)
Aus der Erfahrung wahrscheinlicher Fehlerzustände gezielt zu testen ist Fehler-Raten.
Grenzwertanalyse
Die GWA ist ein systematisches spezifikationsbasiertes Verfahren, keine erfahrungsbasierte Intuition.
Entscheidungstabellentest
Entscheidungstabellen sind ein strukturiertes spezifikationsbasiertes Verfahren mit dokumentierten Regeln.
Das ist erfahrungsbasiertes Testen; Fehler-Raten (error guessing) und exploratives Testen (oft sitzungsbasiert) sind hier die beiden anerkannten Techniken.
Ein erfahrener Tester listet wahrscheinliche Problembereiche — leere Eingaben, sehr lange Zeichenketten, Sonderzeichen, gleichzeitige Übermittlungen — basierend auf früheren Erfahrungen mit ähnlichen Systemen auf und entwirft dafür Tests. Welche Testtechnik ist das?
Fehlererwartung (Error Guessing).
Richtig — wahrscheinliche Fehler aus Erfahrung zu antizipieren ist Fehlererwartung.
Äquivalenzklassenbildung.
EP ist spezifikationsbasiert und partitioniert den Eingaberaum, kein erfahrungsbasiertes Raten.
Entscheidungstabellentest.
Entscheidungstabellen modellieren spezifizierte Bedingungskombinationen, kein erfahrungsbasiertes Raten.
Zweigtest.
Der Zweigtest ist eine White-Box-Technik auf Basis der Codestruktur.
Fehlererwartung (Error Guessing) ist eine erfahrungsbasierte Technik, bei der der Tester wahrscheinliche Fehler aufgrund von Wissen über frühere Fehlerwirkungen und häufige Fehler antizipiert.
Ein Testkonzept besagt: 'Das Testen beginnt erst, wenn der integrierte Build in der Testumgebung bereitgestellt ist und die Smoke-Tests bestehen.' Wofür ist das ein Beispiel?
Eingangskriterien
Das sind Vorbedingungen, die vor dem Start der Testdurchführung gelten müssen.
Endekriterien
Endekriterien legen fest, wann zu stoppen ist, nicht wann zu beginnen.
Ein Testziel
Ein Ziel ist ein Zweck des Testens, keine Startvorbedingung.
Ein Testorakel
Ein Testorakel ist eine Quelle erwarteter Ergebnisse, unabhängig von Startbedingungen.
Bedingungen, die vor dem Start einer Aktivität erfüllt sein müssen, sind Eingangskriterien (Definition of Ready).
Ein Team kennzeichnet 'der Zahlungs-Gateway-Anbieter könnte mitten im Projekt insolvent werden und die Lieferung verzögern' als zu steuerndes Risiko. Wie sollte dieses Risiko klassifiziert werden?
Projektrisiko
Lieferanten- und Terminbedrohungen betreffen die Lieferfähigkeit des Projekts — ein Projektrisiko.
Produktrisiko
Ein Produktrisiko betrifft einen Qualitätsmangel im Liefergegenstand selbst, nicht die Zahlungsfähigkeit des Lieferanten.
Ein Fehlerzustand
Ein Fehlerzustand ist ein bestehender Mangel, dies ist ein potenzielles künftiges Ereignis.
Eine Fehlerwirkung
Eine Fehlerwirkung ist beobachtetes Fehlverhalten zur Laufzeit, keine Geschäfts-/Lieferantenbedrohung.
Ein Risiko für die Lieferfähigkeit des Projekts (Termine, Ressourcen, Lieferanten) ist ein Projektrisiko, kein Produkt-(Qualitäts-)Risiko.
Welche zwei der folgenden sind Produktrisiken (im Gegensatz zu Projektrisiken)? (Wählen Sie zwei.)
Der Checkout könnte die Mehrwertsteuer für bestimmte Länder falsch berechnen
Ein potenzieller funktionaler Qualitätsmangel im Produkt ist ein Produktrisiko.
Die App könnte unter Spitzenlast zu langsam reagieren und die Gebrauchstauglichkeit beeinträchtigen
Ein potenzieller Performanz-/Qualitätsmangel im Liefergegenstand ist ein Produktrisiko.
Zwei wichtige Tester könnten vor dem Release kündigen
Personal-/Ressourcenbedrohungen sind Projektrisiken, keine Produktqualitätsrisiken.
Die Hardware der Testumgebung könnte verspätet geliefert werden
Verspätete Infrastrukturlieferung ist ein Projektrisiko (Termin/Ressourcen).
Produktrisiken betreffen potenzielle Qualitätsmängel des Liefergegenstands; Projektrisiken betreffen das Projektmanagement.
Während der Durchführung verfolgt ein Testmanager den Prozentsatz der ausgeführten geplanten Testfälle und die Zahl offener Fehlerzustände hoher Schwere gegenüber dem Plan. Welche Testaktivität unterstützt das in erster Linie?
Testüberwachung und -steuerung
Metriken gegen den Plan zu verfolgen, um den Aufwand zu steuern, ist Überwachung und Steuerung.
Testanalyse
Die Testanalyse definiert, was getestet wird; sie ist keine Fortschrittsverfolgung.
Testrealisierung
Die Realisierung bereitet Testmittel/Umgebungen vor, nicht die Metrikverfolgung gegen den Plan.
Testabschluss
Der Abschluss finalisiert und berichtet am Ende; hier erfolgt die Verfolgung während der Durchführung.
Den tatsächlichen Fortschritt mittels Metriken mit dem Plan zu vergleichen ist Testüberwachung und -steuerung.
Eine Testleiterin schätzt den Aufwand zum Testen einer Funktion mit der Dreipunkt-(PERT-)Technik. Die optimistische Schätzung beträgt 4 Tage, die wahrscheinlichste 10 Tage und die pessimistische 22 Tage. Wie hoch ist der erwartete Aufwand nach der Formel (a + 4m + b) / 6?
11 Tage
(4 + 40 + 22)/6 = 66/6 = 11.
12 Tage
12 ist das einfache Mittel der drei Werte, nicht der gewichtete PERT-Mittelwert.
10 Tage
10 ist allein der wahrscheinlichste Wert, ohne optimistisches und pessimistisches Ende.
13 Tage
13 ergibt sich nicht aus der Formel; der korrekte gewichtete Mittelwert ist 11.
(4 + 4×10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 Tage.
Welche zwei Angaben sind wesentlicher Inhalt eines guten Fehlerberichts (Incident Reports)? (Wählen Sie zwei.)
Klare Schritte zur Reproduktion des Problems
Reproduktionsschritte erlauben Entwicklern, den Fehlerzustand zuverlässig nachzustellen und zu diagnostizieren.
Das erwartete Ergebnis gegenüber dem tatsächlichen Ergebnis
Erwartet vs. tatsächlich zeigt genau, wie das Verhalten abweicht.
Die Privatadresse des Entwicklers, der den Code schrieb
Persönliche Daten des Autors sind irrelevant und unangemessen in einem Fehlerbericht.
Eine vom Tester vorgeschlagene garantierte Ursachenkorrektur
Ursachendiagnose und Korrektur sind Debugging, kein erforderlicher Inhalt des Berichts.
Ein Fehlerbericht soll Reproduktion und Bewertung ermöglichen: Reproduktionsschritte und erwartetes vs. tatsächliches Ergebnis sind zentral.
Welche Aufgabe liegt typischerweise in der Verantwortung eines Testmanagers und nicht eines Testers?
Erstellen und Pflegen des Testkonzepts und der übergreifenden Teststrategie
Planung und Strategie sind zentrale Aufgaben des Testmanagements.
Testfälle aus den Testbedingungen entwerfen
Konkrete Testfälle zu entwerfen ist eine Testeraufgabe.
Tests ausführen und Ergebnisse protokollieren
Durchführung und Ergebnisprotokollierung sind Testertätigkeiten.
Testdaten für einzelne Testfälle einrichten
Testdaten vorzubereiten gehört zur Testrealisierung durch Tester.
Testmanagement-Aufgaben umfassen Planen, Organisieren und Leiten des Testaufwands; Tester analysieren, entwerfen, realisieren und führen Tests aus.
Ein agiles Team vereinbart, dass eine Story erst dann 'fertig' ist, wenn ihre Akzeptanztests bestehen, der Code reviewt wurde und keine Fehlerzustände hoher Schwere offen sind. Was stellt diese Vereinbarung dar?
Die Definition of Done (eine Form von Endekriterien)
Sie listet die Bedingungen, die erfüllt sein müssen, damit die Story als fertig gilt.
Die Definition of Ready (Eingangskriterien)
Die Definition of Ready regelt, wann Arbeit beginnen kann, nicht wann sie fertig ist.
Ein Test-Charter
Ein Test-Charter umreißt eine explorative Sitzung, keine Story-Abschlussbedingungen.
Eine Verfolgbarkeitsmatrix
Eine Verfolgbarkeitsmatrix verknüpft Elemente mit Anforderungen; sie ist keine Abschlussvereinbarung.
Gemeinsame Abschlussbedingungen für ein Arbeitselement bilden die Definition of Done, eine agile Form der Endekriterien.
Ein Testplan legt fest, dass der Systemtest erst beginnen darf, wenn der Build einen Smoke-Test besteht und der Komponententest ohne offene kritische Fehler abgeschlossen ist. Wie heißen diese Bedingungen?
Eingangskriterien
Richtig — Bedingungen vor dem Teststart.
Endekriterien
Endekriterien definieren den Abschluss.
Testbedingungen
Eine Testbedingung ist ein testbarer Aspekt.
Abnahmekriterien
Definieren, wann eine Story akzeptabel ist.
Bedingungen vor dem Start einer Testaktivität sind Eingangskriterien.
Was ist ein realistischer Nutzen des Einsatzes eines Testausführungs-(Automatisierungs-)Werkzeugs für eine stabile Regressionssuite?
Repetitive Regressionstests können öfter und konsistenter laufen und entlasten Tester für andere Arbeit
Zuverlässige Wiederholbarkeit und reduzierter manueller Aufwand bei stabilen Tests ist ein Kernnutzen der Automatisierung.
Es macht das Entwerfen von Testfällen oder die Skriptpflege überflüssig
Automatisierung erfordert weiterhin Testentwurf und laufende Skriptpflege.
Es garantiert das Auffinden jedes Fehlerzustands
Kein Werkzeug kann garantieren, alle Fehlerzustände zu finden; Automatisierung führt nur die vorgegebenen Tests aus.
Es eignet sich am besten für einmalige, sich schnell ändernde explorative Prüfungen
Automatisierung passt zu stabilen, wiederholten Tests; volatile explorative Prüfungen erfolgen besser manuell.
Automatisierung ist stark darin, große Testmengen zuverlässig zu wiederholen und den repetitiven manuellen Aufwand bei stabilen Fällen zu senken.
Ein Werkzeug durchsucht den Quellcode auf Verstöße gegen Codierungsstandards und potenzielle Fehlerzustände, ohne das Programm auszuführen. In welche Werkzeugkategorie fällt es?
Ein Werkzeug für statische Analyse
Es untersucht Code ohne Ausführung — die Definition eines statischen Analysewerkzeugs.
Ein Testausführungswerkzeug
Testausführungswerkzeuge führen die Software aus; dieses Werkzeug führt das Programm nicht aus.
Ein Performance-Testwerkzeug
Performance-Werkzeuge messen das Laufzeitverhalten unter Last, was Ausführung erfordert.
Ein Testmanagement-Werkzeug
Testmanagement-Werkzeuge organisieren Testartefakte und Berichte, keine Codeanalyse.
Ein Werkzeug, das Code ohne Ausführung analysiert, ist ein Werkzeug für statische Analyse und unterstützt statisches Testen.