ISTQB Foundation (CTFL v4.0) Probeprüfung #9 — 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 schreibt Code, der ein Lieferdatum berechnet. Der Entwickler vertippt sich und schreibt in einer Formel '-' statt '+'. Wenn ein Kunde freitags bestellt, zeigt das System dadurch ein Lieferdatum in der Vergangenheit, und der Kunde beschwert sich. Ordnen Sie diese drei Beobachtungen den ISTQB-Begriffen Fehlhandlung, Fehlerzustand und Fehlerwirkung zu.
Fehlhandlung = das Vertippen des Entwicklers; Fehlerzustand = der falsche Operator im Code; Fehlerwirkung = das angezeigte Lieferdatum in der Vergangenheit.
Korrekte Zuordnung: der menschliche Irrtum ist die Fehlhandlung, der fehlerhafte Code der Fehlerzustand, das beobachtete falsche Verhalten die Fehlerwirkung.
Fehlhandlung = das Lieferdatum in der Vergangenheit; Fehlerzustand = die Kundenbeschwerde; Fehlerwirkung = das Vertippen.
Vertauscht: Datum und Beschwerde sind Folgen (Fehlerwirkung), nicht die Fehlhandlung; das Vertippen ist die Fehlhandlung.
Fehlhandlung = der falsche Operator im Code; Fehlerzustand = das Vertippen; Fehlerwirkung = die Kundenbeschwerde.
Der falsche Operator ist der Fehlerzustand, nicht die Fehlhandlung; das Vertippen ist die Fehlhandlung.
Alle drei Begriffe beschreiben dasselbe Einzelereignis und sind austauschbar.
ISTQB unterscheidet bewusst zwischen menschlicher Handlung, statischem Mangel und dynamischer Auswirkung — sie sind nicht austauschbar.
Eine Fehlhandlung ist eine menschliche Handlung, die ein falsches Ergebnis erzeugt; der Fehlerzustand ist der daraus entstandene Mangel im Code; die Fehlerwirkung ist das nach außen beobachtbare Fehlverhalten.
Welche Aussage beschreibt am besten einen zentralen Grund, warum Testen in der Softwareentwicklung notwendig ist?
Testen senkt das Risiko, dass Fehlerwirkungen im Betrieb auftreten, und liefert Informationen über die Qualität.
Kernbegründung: Testen verringert das Betriebsrisiko und informiert über die Qualität.
Testen garantiert, dass die Software vollständig fehlerfrei ist.
Testen kann die Abwesenheit von Fehlerzuständen nie beweisen; das ist ein bekannter Trugschluss.
Testen ersetzt die Notwendigkeit von Anforderungen und Entwurf.
Testen ergänzt Anforderungs- und Entwurfstätigkeiten, ersetzt sie nicht.
Testen ist nur nötig, wenn der Kunde ein Problem meldet.
Auf Kundenmeldungen zu warten widerspricht dem Ziel früher Fehlerentdeckung.
Testen reduziert das Risiko von Fehlerwirkungen im Betrieb und hilft zu verifizieren, dass Anforderungen erfüllt sind.
Welche Aussage gibt das Testprinzip korrekt wieder, das als 'Pestizid-Paradoxon' bekannt ist?
Werden dieselben Tests oft wiederholt, finden sie irgendwann keine neuen Fehlerzustände mehr, daher müssen Testfälle regelmäßig überarbeitet werden.
Genau das Pestizid-Paradoxon: statische Testmengen verlieren an Wirksamkeit und müssen aktualisiert werden.
Fehlerzustände häufen sich in einer kleinen Zahl von Modulen.
Das beschreibt das Prinzip 'Häufung von Fehlerzuständen', ein anderes Prinzip.
Vollständiges Testen aller Eingaben ist mit genügend Ressourcen erreichbar.
Das widerspricht dem Prinzip 'vollständiges Testen ist unmöglich'.
Frühes Testen spart Zeit und Geld.
Stimmt, aber das ist das Prinzip 'frühes Testen', nicht das Pestizid-Paradoxon.
Werden dieselben Tests wiederholt, finden sie keine neuen Fehlerzustände mehr; Tests müssen überprüft und überarbeitet werden.
Welche ZWEI der folgenden sind gültige Ziele des Testens gemäß ISTQB-Lehrplan? (Wählen Sie zwei.)
Die Qualität bewerten und Vertrauen in das Qualitätsniveau schaffen.
Ein anerkanntes Testziel im Lehrplan.
Fehlerzustände und Fehlerwirkungen finden und so das Risiko reduzieren.
Fehler aufdecken, um das Risiko unzureichender Qualität zu senken, ist ein Kernziel.
Beweisen, dass die Software keine Fehlerzustände enthält.
Unmöglich — Testen kann die Abwesenheit von Fehlerzuständen nicht zeigen.
Die gefundenen Fehlerzustände beheben.
Das Beheben ist Debugging-/Entwicklungsarbeit, kein Testziel.
Testen findet Fehlerzustände und schafft Vertrauen in das Qualitätsniveau; es kann die Abwesenheit von Fehlerzuständen nicht beweisen.
Im Testprozess wandelt das Team allgemeine Testziele in konkrete Testbedingungen und dann in Testfälle um. Welche Testaktivität befasst sich primär damit, durch Analyse der Testbasis zu ermitteln, WAS getestet werden soll (die Testbedingungen)?
Testanalyse
Die Testanalyse untersucht die Testbasis, um testbare Merkmale zu bestimmen und Testbedingungen zu definieren (was getestet wird).
Testentwurf
Der Testentwurf verfeinert Testbedingungen zu konkreten Testfällen (das Wie), nachdem die Analyse das Was definiert hat.
Testrealisierung
Die Realisierung ordnet Testfälle zu Abläufen/Suiten und bereitet die Umgebung vor, nach dem Entwurf.
Testdurchführung
Die Durchführung führt die Tests aus und vergleicht Ist- mit Soll-Ergebnissen — viel später im Prozess.
Die Testanalyse ermittelt, was getestet werden soll (Testbedingungen); der Testentwurf bestimmt dann das Wie und erzeugt Testfälle.
Warum ist ein gewisses Maß an Unabhängigkeit beim Testen von Software oft nützlich?
Unabhängige Tester erkennen wegen anderer kognitiver Verzerrungen und Annahmen tendenziell andere Fehlerzustände als der Autor.
Unabhängigkeit verringert die Verzerrung des Autors und deckt übersehene Fehler auf.
Autoren dürfen ihren eigenen Code unter keinen Umständen testen.
Autoren testen ihre Arbeit durchaus (z. B. Unit-Tests); Unabhängigkeit ist graduell, kein absolutes Verbot.
Unabhängige Tester finden immer mehr Fehlerzustände als Entwickler.
Nicht garantiert — Unabhängigkeit hilft, führt aber nicht immer zu mehr Fehlern.
Unabhängigkeit macht das Testen durch Entwickler vollständig überflüssig.
Entwicklertests bleiben wertvoll; Unabhängigkeit ergänzt sie, ersetzt sie nicht.
Unabhängige Tester erkennen eher andere Arten von Fehlerzuständen, da sie andere Annahmen und Verzerrungen haben.
Ein Projektleiter sagt: 'Wir haben alle geplanten Tests durchgeführt und fast alle waren erfolgreich, also ist das System releasefähig und die Anwender werden zufrieden sein.' Welches Testprinzip warnt vor dieser Argumentation?
Der Trugschluss der Fehlerfreiheit (absence-of-errors fallacy).
Fehler zu finden und zu beheben hilft nicht, wenn das System unbrauchbar ist oder die Anwenderbedürfnisse verfehlt.
Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit.
Ein echtes Prinzip, betrifft aber die Aussagekraft bestandener Tests, nicht die hier gemeinte Gebrauchstauglichkeit.
Häufung von Fehlerzuständen.
Betrifft die Verteilung von Fehlern über Module, nicht die Anwenderzufriedenheit.
Testen ist kontextabhängig.
Allgemein wahr, warnt aber nicht speziell davor, wenige Fehler mit Anwenderzufriedenheit gleichzusetzen.
Der Trugschluss der Fehlerfreiheit: Ein System kann fehlerarm sein und trotzdem die Bedürfnisse und Erwartungen der Anwender nicht erfüllen.
Ein Tester nimmt mehrere zusammengehörige Testfälle, bringt sie in die Reihenfolge, in der sie ausgeführt werden müssen, ergänzt die vor dem ersten Testfall nötigen Vorbereitungsschritte und speichert das Ergebnis. Was hat der Tester in ISTQB-Terminologie erstellt?
Einen Testablauf (Testverfahren)
Richtig — ein Testablauf ist eine Folge von Testfällen in Ausführungsreihenfolge samt der benötigten Vorbedingungen und Vorbereitungsschritte.
Einen Testfall
Ein einzelner Testfall beschreibt Vorbedingungen, Eingaben, erwartete Ergebnisse und Nachbedingungen für einen Test. Hier wurden mehrere bestehende Testfälle in eine Reihenfolge gebracht, also etwas oberhalb der Ebene eines Testfalls erzeugt.
Eine Testsuite
Eine Testsuite ist eine Menge von Testfällen oder Testabläufen, die gemeinsam ausgeführt werden, z. B. in einem Testzyklus. Sie gruppiert Tests, schreibt aber nicht die innere Reihenfolge und Vorbereitung vor, die einen Testablauf kennzeichnen.
Eine Testbedingung
Eine Testbedingung benennt, was getestet werden soll, etwa ein Merkmal oder eine Qualitätseigenschaft. Sie enthält keine Ausführungsschritte und keine Reihenfolge.
Ein Testablauf (Testverfahren) beschreibt eine Folge von Aktionen für die Testdurchführung, einschließlich der Testfälle in ihrer Ausführungsreihenfolge sowie der Vorbedingungen bzw. Vorbereitungsschritte. Er entsteht in der Testrealisierung.
Ein Team führt einen 'Shift-Left'-Ansatz ein. Was veranschaulicht Shift-Left-Testing in der Praxis am BESTEN?
Tester reviewen die Anforderungen und definieren Abnahmetests bereits in der Analysephase, bevor Code geschrieben wird.
Frühes Review und Testentwurf ist der Kern von Shift-Left — Fehler werden gefunden, bevor sie sich fortpflanzen.
Alle Tests werden bis zu einer eigenen Testphase nach der Entwicklung verschoben.
Das ist das Gegenteil von Shift-Left — es verschiebt Tests nach rechts (später).
Tests werden nur in der Produktion mittels Monitoring durchgeführt.
Produktionsmonitoring ist 'Shift-Right'; es verlagert Tests nicht nach vorne.
Die Zahl der Tester wird reduziert und Entwickler machen weniger Unit-Tests.
Weniger frühes Testen widerspricht Shift-Left, das den frühen Testaufwand erhöht.
Shift-Left verlagert testbezogene Aktivitäten nach vorne, z. B. Anforderungen reviewen und Tests schreiben, bevor der Code fertig ist.
Was ist der Hauptzweck des Integrationstests als Teststufe?
Die Schnittstellen und Interaktionen zwischen integrierten Komponenten oder Systemen testen.
Der Komponentenintegrationstest zielt auf Fehler in Schnittstellen und Interaktionen zwischen Komponenten.
Jede einzelne Komponente isoliert testen.
Das ist der Komponententest (Unit), eine andere Stufe.
Das vollständige System mit Endanwendern gegen die Geschäftsanforderungen validieren.
Das beschreibt den Abnahmetest, nicht den Integrationstest.
Das Verhalten des gesamten, durchgängig integrierten Systems prüfen.
Das gesamte System durchgängig zu testen ist der Systemtest, die nächsthöhere Stufe.
Der Integrationstest konzentriert sich auf Interaktionen und Schnittstellen zwischen Komponenten oder Systemen.
Ein Testteam misst, wie schnell die Anwendung unter einer Last von 500 gleichzeitigen Benutzern reagiert. Um welche Testart handelt es sich und warum?
Nicht-funktionaler Test, da er ein Qualitätsmerkmal (Performance-Effizienz) statt einer Funktion bewertet.
Antwortzeit unter Last ist ein Merkmal der Performance-Effizienz (nicht-funktional).
Funktionaler Test, weil die Anwendung ihre Berechnungen ausführt.
Der Fokus liegt auf der Geschwindigkeit, nicht auf der Korrektheit — das macht ihn nicht-funktional.
White-Box-Test, weil er auf der internen Codestruktur beruht.
Antwortzeit zu messen erfordert keine Kenntnis der internen Struktur.
Fehlernachtest, weil ein früherer Test erneut ausgeführt wird.
Der Fehlernachtest prüft einen behobenen Fehler erneut; hier ist es eine neue Performance-Messung.
Die Antwortzeit unter Last zu messen ist nicht-funktionaler (Performance-/Effizienz-)Test — geprüft wird, wie gut das System arbeitet, nicht was es tut.
Eine seit zwei Jahren betriebene Anwendung muss aktualisiert werden, weil das zugrunde liegende Betriebssystem ein Upgrade erhält. Die Funktionalität ändert sich nicht. Welche Testart wird primär ausgelöst und wie heißt der Auslöser?
Wartungstest, ausgelöst durch eine Umgebungsänderung (Betriebssystem-Upgrade).
Änderungen der Betriebsumgebung sind ein anerkannter Auslöser für Wartungstests.
Abnahmetest, ausgelöst durch eine neue Geschäftsanforderung.
Es gibt keine neue Geschäftsanforderung; die Funktionalität bleibt unverändert.
Komponententest, ausgelöst durch komplett neu geschriebenen Code.
Es wird kein neuer Funktionscode geschrieben; das System wird migriert.
Smoke-Test, ausgelöst durch den täglichen Build.
Ein täglicher Build ist hier nicht der Auslöser; das OS-Upgrade (Wartungsauslöser) ist es.
Das ist Wartungstest, ausgelöst durch eine Änderung der Umgebung (ein Betriebs-/Migrationsauslöser).
Welche ZWEI Aussagen unterscheiden den Fehlernachtest korrekt vom Regressionstest? (Wählen Sie zwei.)
Der Fehlernachtest führt die zuvor fehlgeschlagenen Tests erneut aus, um die Korrektur zu bestätigen.
Korrekt — der Fehlernachtest bestätigt, dass der ursprüngliche Fehler behoben ist.
Der Regressionstest prüft, ob die Änderung in unveränderten Teilen Fehler eingeführt oder aufgedeckt hat.
Korrekt — der Regressionstest sucht nach unbeabsichtigten Nebenwirkungen einer Änderung.
Der Fehlernachtest ist immer voll automatisiert, der Regressionstest nie.
Beide können manuell oder automatisiert sein; Automatisierung unterscheidet sie nicht.
Der Regressionstest erfolgt nur nach der Auslieferung in die Produktion.
Der Regressionstest erfolgt bei jeder Änderung von Software oder Umgebung, auf jeder Stufe.
Der Fehlernachtest prüft, ob ein behobener Fehler verschwunden ist; der Regressionstest prüft, ob die Änderung nichts anderes beschädigt hat.
Was ist in einer DevOps-Umgebung mit Continuous Integration (CI) ein zentraler Vorteil für das Testen?
Automatisierte Tests laufen bei jeder Integration und liefern schnelles Feedback mit früher Fehlererkennung.
Schnelles, automatisiertes Feedback bei jedem Commit ist ein zentraler Testvorteil von CI/DevOps.
CI macht automatisierte Regressionstests überflüssig.
CI stützt sich stark auf automatisierte Regressionstests; es macht sie nicht überflüssig.
CI garantiert, dass nie Fehler in die Produktion gelangen.
CI senkt das Risiko, kann aber fehlerfreie Releases nicht garantieren.
CI bedeutet, dass nur manuell am Sprintende getestet wird.
CI betont kontinuierliches automatisiertes Testen, nicht manuelles Testen am Sprintende.
CI liefert über automatisierte Build-und-Test-Pipelines schnelles Feedback, sodass Fehler kurz nach dem Commit erkannt werden.
Welche Aussage stellt statisches und dynamisches Testen korrekt gegenüber?
Statisches Testen findet Fehlerzustände ohne Codeausführung, während dynamisches Testen die Ausführung der Software erfordert.
Richtig — das ist die grundlegende Unterscheidung der beiden.
Statisches Testen erfordert Codeausführung, dynamisches nicht.
Das kehrt die Definitionen um.
Sowohl statisches als auch dynamisches Testen erfordern immer die Ausführung der Software.
Statisches Testen führt die Software gerade nicht aus.
Weder statisches noch dynamisches Testen kann Fehlerzustände finden.
Beide finden Fehlerzustände; sie unterscheiden sich im Wie.
Statisches Testen findet Fehlerzustände direkt in Arbeitsergebnissen ohne Codeausführung; dynamisches Testen führt die Software aus und beobachtet Fehlerwirkungen.
Welcher der folgenden Vorteile bietet statisches Testen, den dynamisches Testen typischerweise nicht bietet?
Fehler direkt in Anforderungen oder Entwurf erkennen, bevor Code ausgeführt wird.
Statisches Testen prüft Arbeitsergebnisse ohne Ausführung und findet Fehler früher und an der Quelle.
Die tatsächliche Antwortzeit des laufenden Systems messen.
Laufzeitverhalten zu messen erfordert Ausführung — das ist dynamisches Testen.
Fehlerwirkungen durch Speicherlecks während der Ausführung beobachten.
Laufzeit-Fehlerwirkungen zu beobachten erfordert Ausführung und ist dynamisches Testen.
Bestätigen, dass ein behobener Fehler zur Laufzeit keine Fehlerwirkung mehr verursacht.
Das ist der Fehlernachtest, der das Ausführen der Software erfordert.
Statisches Testen kann Fehler in Arbeitsergebnissen ohne Codeausführung finden, z. B. direkt in Anforderungen, noch bevor Code existiert.
Ein Team benötigt eine Reviewart, die am formalsten ist, einem definierten Prozess mit dokumentierten Eingangs-/Endekriterien folgt, Metriken nutzt und von einem geschulten Moderator geleitet wird. Welche Reviewart passt am besten?
Inspektion
Die Inspektion ist das formalste Review: definierter Prozess, geschulter Moderator, Rollen, Metriken und Endekriterien.
Walkthrough
Ein Walkthrough wird vom Autor geleitet und ist weniger formal, oft ohne strenge Kriterien oder Metriken.
Informelles Review
Ein informelles Review hat keinen definierten Prozess und kaum Dokumentation.
Technisches Review
Ein technisches Review ist eher formal und peer-geleitet, aber die Inspektion ist die formalste der genannten Arten.
Die Inspektion ist die formalste Reviewart, mit definiertem Prozess, Rollen, Eingangs-/Endekriterien und Metriken.
Wer ist in einer formalen Review-Sitzung dafür verantwortlich, die während der Diskussion genannten Fehler, Entscheidungen und neuen Punkte zu protokollieren?
Der Protokollführer (Scribe).
Der Protokollführer sammelt und dokumentiert Anomalien, Entscheidungen und neue Erkenntnisse während der Sitzung.
Der Moderator.
Der Moderator leitet und moderiert die Sitzung; das Protokollieren ist Aufgabe des Scribe.
Der Autor.
Der Autor hat das Arbeitsergebnis erstellt und beantwortet Fragen, protokolliert aber nicht.
Der Review-Leiter / Manager.
Der Manager entscheidet ggf. über die Durchführung von Reviews, aber das Protokollieren obliegt dem Scribe.
Der Protokollführer (Scribe) dokumentiert die im Review genannten Fehler, Entscheidungen und Punkte.
Ein Webformular akzeptiert ein Feld 'Menge' für eine Online-Bestellung. Die Spezifikation lautet: Die Bestellmenge muss eine ganze Zahl zwischen 1 und 50 einschließlich sein. Mengen von 0 oder weniger werden als 'ungültige Menge' abgelehnt; Mengen ab 51 als 'Maximum überschritten'. Wie viele Äquivalenzklassen gibt es mit der Äquivalenzklassenbildung für das Feld 'Menge', und wie viele Testfälle braucht man mindestens, um jede Klasse einmal abzudecken?
3 Klassen; 3 Testfälle.
Gültig 1–50, ungültig ≤0, ungültig ≥51 = drei Klassen; jede einmal abgedeckt = drei Testfälle.
2 Klassen; 2 Testfälle.
Das ignoriert, dass es zwei verschiedene ungültige Klassen mit unterschiedlicher Behandlung gibt.
4 Klassen; 4 Testfälle.
Es gibt nur eine gültige Klasse (1–50), nicht zwei; die Summe ist drei, nicht vier.
50 Klassen; 50 Testfälle.
Die Äquivalenzklassenbildung gruppiert gleich behandelte Werte; sie testet nicht jede ganze Zahl.
Es gibt drei Klassen (eine gültige: 1–50; zwei ungültige: ≤0 und ≥51), mindestens drei Testfälle nötig.
Für dasselbe Feld 'Menge' (gültiger Ganzzahlbereich 1 bis 50 einschließlich) wenden Sie die 2-Werte-Grenzwertanalyse (BVA) an. Der 2-Werte-Ansatz testet an jeder Grenze den Grenzwert und seinen nächsten Nachbarn auf der anderen Seite. Welche Wertemenge stellt genau die 2-Werte-BVA-Testwerte für dieses Feld dar?
0, 1, 50, 51
Untere Grenze 1 mit Nachbar 0; obere Grenze 50 mit Nachbar 51 — vier Werte.
1, 50
Das sind nur die Grenzen selbst; der 2-Werte-Ansatz braucht auch die Nachbarn 0 und 51.
0, 1, 2, 49, 50, 51
Das ist der 3-Werte-Ansatz (Grenze plus beide Nachbarn), nicht der 2-Werte-Ansatz.
1, 25, 50
25 ist ein Mittelwert (typischer EP-Wert), kein Grenzwert für BVA, und 0/51 fehlen.
Die Grenzen sind 1 und 50; der 2-Werte-Ansatz nutzt {0, 1, 50, 51}.
Ein Rabattsystem ordnet eine Treuestufe anhand des Jahresumsatzes S (ganze Euro-Beträge) zu: Bronze für 0–999, Silber für 1000–4999, Gold ab 5000. Wie viele verschiedene Testwerte sind mit dem 3-Werte-Ansatz der Grenzwertanalyse (jede Grenze mit dem Wert davor, dem Wert an der Grenze und dem Wert danach) nötig, um alle internen Grenzen zwischen den Stufen abzudecken? Betrachten Sie nur die beiden internen Grenzen (Bronze/Silber und Silber/Gold).
6 verschiedene Testwerte.
Jede interne Grenze liefert drei Werte; die Mengen {999,1000,1001} und {4999,5000,5001} überschneiden sich nicht — 6.
4 verschiedene Testwerte.
Das wäre der 2-Werte-Ansatz (zwei Werte pro Grenze), nicht der 3-Werte-Ansatz.
3 verschiedene Testwerte.
Drei Werte decken nur eine Grenze ab; hier gibt es zwei interne Grenzen.
9 verschiedene Testwerte.
Neun würde drei Grenzen voraussetzen; betrachtet werden nur zwei interne Grenzen.
Grenze 1000 → {999,1000,1001}; Grenze 5000 → {4999,5000,5001}; keine Überschneidung, also 6 verschiedene Werte.
Die folgende Entscheidungstabelle spezifiziert die Rabatt- und Gratisversand-Regeln an der Kasse eines Online-Shops. 'Member (loyalty)' = Kunde hat ein Treuekonto, 'Cart total ≥ 100' = Bestellung ≥ 100 Euro, 'Coupon valid' = gültiger Gutscheincode eingegeben. '–' bedeutet 'don't care'.
Ein Treuekunde bestellt für 120 Euro und gibt KEINEN Gutschein ein. Welche Regel gilt laut Tabelle und welche Aktionen ergeben sich?
Regel R6: 10% Rabatt und Gratisversand.
Member T, Warenkorb ≥ 100 T, Gutschein F ist genau R6 — 10% und Gratisversand.
Regel R7: 20% Rabatt und Gratisversand.
R7 erfordert einen gültigen Gutschein (Coupon=T); hier wurde keiner eingegeben.
Regel R4: 5% Rabatt und kein Gratisversand.
R4 erfordert Warenkorb ≥ 100 = F; hier sind es 120 (≥100 = T).
Regel R1: 0% Rabatt und kein Gratisversand.
R1 gilt für Nicht-Mitglieder mit Warenkorb unter 100; dieser Kunde ist Mitglied mit 120.
Member=T, Cart≥100=T, Coupon=F entspricht R6 → 10% Rabatt, Gratisversand = Ja.
Betrachten Sie erneut die Rabatt-Entscheidungstabelle der Online-Shop-Kasse.
Warum verwendet Regel R1 für die Bedingung 'Coupon valid' einen 'don't care'-Wert (–), und welche praktische Wirkung hat das auf die Spaltenzahl?
Da das Ergebnis unabhängig von der Gutschein-Gültigkeit identisch ist, werden die beiden entsprechenden Spalten zur einzigen Regel R1 zusammengefasst und die Tabelle verkleinert.
Ein 'don't care' fasst Kombinationen mit gleichen Aktionen zusammen und verkleinert die Tabelle ohne Abdeckungsverlust.
Weil die Gutschein-Bedingung eine ungültige Eingabe ist, die nie getestet werden sollte.
Die Gutschein-Bedingung ist gültig und wird anderswo getestet; '–' zeigt nur Irrelevanz für diese Regel.
Weil ein fehlender Wert bedeutet, dass die Regel nicht durchführbar ist und gelöscht werden kann.
R1 ist eine gültige, durchführbare Regel; '–' ist ein bewusstes 'don't care', kein fehlender Wert.
Weil es die Zahl der zu testenden Spalten verdoppelt.
Ein 'don't care' reduziert die Zahl der Spalten/Regeln, es erhöht sie nicht.
Wenn ein Nicht-Mitglied einen Warenkorb unter 100 hat, ist das Ergebnis unabhängig vom Gutschein gleich, sodass zwei Spalten zu einer (R1) zusammenfallen.
Das folgende Zustandsdiagramm modelliert einen einfachen Warenautomaten. Der Automat startet im Zustand 'Idle'. Eine Münze einwerfen führt zu 'HasCredit'; weitere Münzen erhöhen das Guthaben (Selbstübergang). Aus 'HasCredit' führt die Auswahl eines Produkts bei ausreichendem Guthaben zu 'Dispensing', bei unzureichendem Guthaben zu 'Refunding'. Nach Ausgabe oder Rückzahlung kehrt der Automat zu 'Idle' zurück. 'cancel' aus 'HasCredit' zahlt zurück und führt zu 'Idle'.
Welche der folgenden Ereignisfolgen ist ein GÜLTIGER Pfad durch das Diagramm (d. h. jeder Übergang existiert)?
insertCoin, insertCoin, select [credit ≥ price], dispensed.
Idle→HasCredit, Selbstübergang bei zweiter Münze, →Dispensing bei ausreichendem Guthaben, →Idle bei dispensed. Alle Übergänge existieren.
select [credit ≥ price], insertCoin, dispensed.
Aus Idle gibt es keinen 'select'-Übergang; das erste Ereignis ist ungültig.
insertCoin, dispensed.
Aus HasCredit gibt es keinen direkten 'dispensed'-Übergang; erst muss ausgegeben werden.
insertCoin, select [credit < price], dispensed.
Unzureichendes Guthaben führt zu Refunding, aus dem kein 'dispensed' erfolgt (sondern 'refunded').
insertCoin → insertCoin → select(ausreichend) → dispensed ist gültig: Idle→HasCredit→HasCredit→Dispensing→Idle.
Welche Aussage beschreibt am besten, wann eine Entscheidungstabelle ein besonders geeignetes Testentwurfsverfahren ist?
Wenn unterschiedliche Kombinationen von Eingabebedingungen zu unterschiedlichen Aktionen oder Ausgaben führen.
Entscheidungstabellen erfassen systematisch Bedingungskombinationen und ihre Aktionen.
Wenn das System nur einen einzigen numerischen Eingabebereich hat.
Ein einzelner Bereich wird besser mit Äquivalenzklassen und Grenzwertanalyse behandelt.
Wenn das Verhalten von der zeitlichen Ereignisreihenfolge abhängt.
Reihenfolgeabhängiges Verhalten modelliert man mit Zustandsübergangstests, nicht mit Entscheidungstabellen.
Wenn die interne Codestruktur zur Überdeckung durchlaufen werden muss.
Strukturüberdeckung ist White-Box-Test; Entscheidungstabellen sind eine Black-Box-Technik.
Entscheidungstabellen eignen sich, wenn das Verhalten von Kombinationen von Bedingungen abhängt, die unterschiedliche Aktionen auslösen.
Betrachten Sie diese Routine (mit Zeilennummern). Zeile 1: read x. Zeile 2: if x > 0 then. Zeile 3: y = x * 2. Zeile 4: end if. Zeile 5: if x > 100 then. Zeile 6: y = 100. Zeile 7: end if. Zeile 8: print y. Die ausführbaren Anweisungen sind die Zeilen 1, 2, 3, 5, 6, 8. Ein einzelner Test läuft mit x = 50.
Welche Anweisungsüberdeckung erreicht der einzelne Test x = 50?
Etwa 83% (5 von 6 Anweisungen).
x=50 erfüllt x>0 (Zeile 3 läuft), aber nicht x>100 (Zeile 6 übersprungen): 5/6 ≈ 83%.
100%.
Zeile 6 (y = 100) wird mit x = 50 nie erreicht, daher kann die Überdeckung nicht 100% sein.
50%.
Weit mehr als die Hälfte der Anweisungen wird ausgeführt; nur eine von sechs fehlt.
67%.
67% wären 4 von 6 Anweisungen; hier werden 5 von 6 ausgeführt.
Mit x=50 werden die Zeilen 1,2,3,5,8 ausgeführt (5 von 6 Anweisungen); Zeile 6 wird übersprungen → ~83%.
Eine Funktion enthält eine einzige Entscheidung: if (a AND b) then doX() else doY(). 'a' und 'b' sind unabhängige boolesche Eingaben. Sie wollen 100% Zweigüberdeckung (Entscheidungsüberdeckung) erreichen — sowohl das Wahr- als auch das Falsch-Ergebnis der Entscheidung muss durchlaufen werden.
Wie viele Testfälle sind mindestens für 100% Zweigüberdeckung dieser Entscheidung nötig?
2 Testfälle.
Ein Fall macht (a AND b) wahr (a=T,b=T → doX), einer falsch (z. B. a=F → doY); beide Zweige abgedeckt.
1 Testfall.
Ein Fall durchläuft nur ein Ergebnis der Entscheidung; Zweigüberdeckung braucht beide.
3 Testfälle.
Drei sind für einfache Zweigüberdeckung einer Entscheidung nicht nötig; zwei genügen.
4 Testfälle.
Vier würden alle Eingabekombinationen von a und b abdecken, mehr als Zweigüberdeckung verlangt.
Zweigüberdeckung erfordert, dass die Entscheidung wahr und falsch wird → 2 Testfälle (z. B. a=T,b=T und a=F).
Welche ZWEI der folgenden sind Merkmale von Black-Box-Testverfahren (spezifikationsbasiert)? (Wählen Sie zwei.)
Testfälle werden aus der Spezifikation oder anderen externen Verhaltensbeschreibungen abgeleitet.
Black-Box-Verfahren nutzen externe Beschreibungen, nicht die interne Codestruktur.
Äquivalenzklassenbildung und Grenzwertanalyse sind Beispiele.
Beide sind klassische Black-Box-Verfahren (spezifikationsbasiert).
Sie messen die Anweisungs- und Zweigüberdeckung des Quellcodes.
Überdeckung der Codestruktur ist ein White-Box-Merkmal.
Sie erfordern Zugriff auf und Analyse des internen Quellcodes.
Den internen Code zu benötigen ist White-Box, nicht Black-Box.
Black-Box-Verfahren leiten Tests aus Spezifikationen ohne Bezug auf die interne Codestruktur ab; Beispiele sind ÄK, BVA und Entscheidungstabellen.
Ein erfahrener Tester listet ohne formale Technik Eingaben auf, die wahrscheinlich Probleme verursachen (leere Felder, Null, negative Zahlen, sehr lange Zeichenketten, Sonderzeichen), basierend auf früheren Fehlern. Welche erfahrungsbasierte Technik ist das?
Error Guessing (intuitive Testfallermittlung).
Error Guessing nutzt die Erfahrung des Testers, um wahrscheinliche Fehler vorwegzunehmen.
Grenzwertanalyse.
BVA ist ein formales spezifikationsbasiertes Verfahren, nicht erfahrungsbasiert.
Anweisungstest.
Der Anweisungstest ist ein strukturbasiertes White-Box-Verfahren.
Checklistenbasiertes Testen.
Checklistenbasiertes Testen folgt einer dokumentierten Checkliste; hier improvisiert der Tester aus Erfahrung ohne eine solche.
Wahrscheinliche Fehler aus Erfahrung vorwegzunehmen ist die intuitive Testfallermittlung (Error Guessing).
Ein Team nutzt risikobasiertes Testen. Jedes Produktrisiko wird bewertet als Risikolevel = Eintrittswahrscheinlichkeit × Auswirkung, wobei beide je 1 (niedrig) bis 5 (hoch) bewertet werden. Vier Risiken: R1 Wahrscheinlichkeit 2, Auswirkung 5; R2 Wahrscheinlichkeit 4, Auswirkung 4; R3 Wahrscheinlichkeit 5, Auswirkung 2; R4 Wahrscheinlichkeit 3, Auswirkung 3. Das Team testet das Risiko mit dem HÖCHSTEN Risikolevel zuerst. Welches Risiko zuerst und wie hoch ist sein Risikolevel?
R2, mit einem Risikolevel von 16.
2×5=10, 4×4=16, 5×2=10, 3×3=9 → R2 (16) ist am höchsten und wird zuerst getestet.
R1, mit einem Risikolevel von 10.
R1 erreicht 10, nicht das Höchste; R2 erreicht 16.
R3, weil es die höchste Wahrscheinlichkeit hat.
Die höchste Wahrscheinlichkeit allein maximiert das Risikolevel nicht; R3 erreicht nur 10.
R1, weil es die höchste Auswirkung hat.
Die höchste Auswirkung allein maximiert das Risikolevel nicht; R1 erreicht 10, unter R2 mit 16.
R1=10, R2=16, R3=10, R4=9; das höchste ist R2 mit 16.
Welche ZWEI der folgenden sind Beispiele für PRODUKTRISIKEN (im Gegensatz zu Projektrisiken)? (Wählen Sie zwei.)
Die Software könnte Zinsen falsch berechnen und Kunden falsche Kontostände anzeigen.
Ein Fehler in der ausgelieferten Software, der die Qualität betrifft, ist ein Produktrisiko.
Unter hoher Last könnte das System für die Anwender zu langsam reagieren.
Schlechte Performance des Produkts ist ein qualitätsbezogenes Produktrisiko.
Wichtige Tester könnten das Team vor Abschluss der Testphase verlassen.
Personal/Verfügbarkeit ist ein Projektrisiko, kein Produktrisiko.
Die Testumgebung könnte vom Lieferanten nicht rechtzeitig bereitgestellt werden.
Lieferverzögerungen, die den Zeitplan betreffen, sind ein Projektrisiko.
Produktrisiken betreffen die Qualität des Produkts selbst; Projektrisiken betreffen das Projektmanagement (Termine, Personal usw.).
Ein Testmanager schätzt den Aufwand zur Ausführung einer Testsuite mit der Drei-Punkt-Technik (PERT): Schätzung = (Optimistisch + 4 × Wahrscheinlich + Pessimistisch) / 6. Optimistisch 4 Tage, wahrscheinlich 7 Tage, pessimistisch 16 Tage. Wie lautet die Drei-Punkt-Schätzung?
8 Tage.
(4 + 28 + 16) / 6 = 48 / 6 = 8 Tage.
9 Tage.
9 entstünde durch einen Rechenfehler; der korrekte gewichtete Mittelwert ist 8.
7 Tage.
7 ist nur der wahrscheinliche Wert, nicht die gewichtete Drei-Punkt-Schätzung.
9,5 Tage.
9,5 ist ein fehlerhafter einfacher Mittelwert; die PERT-Formel gewichtet den wahrscheinlichen Wert mit 4.
(4 + 4×7 + 16) / 6 = (4 + 28 + 16) / 6 = 48 / 6 = 8 Tage.
Was ist der Hauptzweck von Testüberwachung und Teststeuerung während der Testdurchführung?
Informationen über den Testfortschritt sammeln und damit Korrekturmaßnahmen zu den Testzielen steuern.
Die Überwachung sammelt Metriken; die Steuerung handelt darauf — zusammen halten sie das Testen auf Kurs.
Den Quellcode zu schreiben, der gefundene Fehler behebt.
Code zu reparieren ist Entwicklung/Debugging, nicht Testüberwachung und -steuerung.
Zu garantieren, dass das Projekt am geplanten Termin fertig wird.
Die Überwachung informiert Entscheidungen, kann aber Termine nicht garantieren.
Die Notwendigkeit eines Testkonzepts zu ersetzen.
Überwachung und Steuerung ergänzen das Testkonzept; sie ersetzen es nicht.
Die Überwachung sammelt Fortschrittsinformationen; die Steuerung nutzt sie für Korrekturmaßnahmen zur Zielerreichung.
Welche ZWEI der folgenden würden typischerweise in einem Testkonzept dokumentiert? (Wählen Sie zwei.)
Die Testziele, der Umfang und das zu nutzende Testvorgehen.
Umfang, Ziele und Vorgehen sind Kerninhalte eines Testkonzepts.
Eingangs- und Endekriterien für die Testaktivitäten.
Eingangs-/Endekriterien sind Standardelemente eines Testkonzepts.
Der vollständige Quellcode der zu testenden Anwendung.
Quellcode ist nicht Teil des Testkonzepts.
Die detaillierte Schritt-für-Schritt-Beschreibung jedes gefundenen Fehlers.
Einzelne Fehlerberichte sind eigene Arbeitsergebnisse, nicht das Testkonzept.
Ein Testkonzept dokumentiert Umfang, Ziele, Vorgehen, Zeitplan, Ressourcen und Eingangs-/Endekriterien — nicht die eigentlichen Fehlerberichte oder den Quellcode.
In einem agilen Team enthält die 'Definition of Done' für eine User Story 'alle Abnahmetests bestanden und keine schwerwiegenden Fehler mehr offen'. Welchem Testmanagement-Konzept entspricht die Definition of Done am direktesten?
Endekriterien.
Die Definition of Done legt die Bedingungen fest, die für den Abschluss erfüllt sein müssen — also Endekriterien.
Eingangskriterien.
Eingangskriterien (Definition of Ready) entscheiden, wann Arbeit beginnen darf, nicht wann sie fertig ist.
Testdaten.
Testdaten sind Eingaben zum Ausführen von Tests, ohne Bezug zu Abschlussbedingungen.
Ein Test-Charter.
Ein Test-Charter leitet eine explorative Session; er ist keine Abschlussbedingung für eine Story.
Eine Definition of Done wirkt als Endekriterien — Bedingungen, die vor dem Abschluss erfüllt sein müssen.
Welche ZWEI Informationen sind in einem guten Fehlerbericht wesentlich, damit er bearbeitbar ist? (Wählen Sie zwei.)
Klare Schritte zur Reproduktion des Problems.
Reproduktionsschritte ermöglichen es Entwicklern, die Fehlerwirkung zu beobachten und zu diagnostizieren.
Das erwartete Ergebnis und das tatsächliche (beobachtete) Ergebnis.
Erwartetes vs. tatsächliches Ergebnis definiert genau, was falsch ist.
Der Name des Entwicklers, der für den Fehler verantwortlich ist.
Schuldzuweisung ist kontraproduktiv und kein Teil eines guten Fehlerberichts.
Die Vermutung des Testers zur genauen Codezeile, die den Fehler verursacht.
Die Codezeile zu bestimmen ist die Diagnose des Entwicklers, kein Pflichtfeld.
Ein nützlicher Fehlerbericht enthält die Schritte zur Reproduktion sowie erwartetes und tatsächliches Ergebnis; Schuldzuweisung und vermutete Ursache sind nicht wesentlich.
Wie unterstützt das Konfigurationsmanagement die Testaktivitäten?
Es identifiziert und versioniert Testobjekte und Testmittel eindeutig, sodass Tests reproduzierbar und nachvollziehbar sind.
Zu wissen, welche Versionen getestet wurden, macht Ergebnisse verlässlich und reproduzierbar.
Es schreibt die Testfälle automatisch aus den Anforderungen.
Konfigurationsmanagement steuert Versionen; es erzeugt keine Testfälle.
Es garantiert, dass die Software keine Konfigurationsfehler hat.
Es verwaltet Versionen, kann aber keine Fehlerfreiheit garantieren.
Es macht das Nachverfolgen, in welchem Build ein Fehler gefunden wurde, überflüssig.
Im Gegenteil — es ermöglicht gerade das Nachverfolgen von Build/Version je Fehler.
Das Konfigurationsmanagement stellt sicher, dass Testmittel und Testobjekte identifiziert, versioniert und nachvollziehbar sind, damit Ergebnisse reproduzierbar sind.
Ein Testmanager legt fest, wie getestet wird: welche Techniken, Stufen und Arten genutzt werden, wie viel automatisiert wird und wie der Aufwand gegen Risiken verteilt wird. Wie heißt diese Gesamtheit von Entscheidungen?
Das Testvorgehen.
Das Testvorgehen definiert, wie das Testen an Kontext und Risiken angepasst und umgesetzt wird.
Die Testbedingung.
Eine Testbedingung ist ein konkret zu testender Aspekt, nicht das Gesamtvorgehen.
Der Testfall.
Ein Testfall ist eine einzelne Menge von Eingaben/Sollergebnissen, nicht die Strategie.
Das Testprotokoll.
Ein Testprotokoll hält fest, was während der Durchführung geschah, nicht wie geplant wird.
Das ist das Testvorgehen (die Teststrategie) — wie das Testen für Kontext und Risiken umgesetzt wird.
Welche ZWEI der folgenden sind Beispiele für Werkzeuge, die Testdurchführung und Protokollierung unterstützen? (Wählen Sie zwei.)
Ein Testausführungswerkzeug, das skriptbasierte Tests abspielt und Pass/Fail-Ergebnisse aufzeichnet.
Testausführungswerkzeuge führen automatisierte Skripte aus und protokollieren die Ergebnisse.
Ein Unit-Test-Framework, das Entwicklertests ausführt und Ergebnisse berichtet.
Unit-Test-Frameworks führen Tests aus und erfassen/berichten die Ergebnisprotokolle.
Ein Anforderungsmanagement-Werkzeug zum Speichern und Verfolgen von Anforderungen.
Anforderungsmanagement unterstützt Testmanagement/Nachverfolgbarkeit, nicht Ausführung und Protokollierung.
Ein statisches Analysewerkzeug, das Quellcode ohne Ausführung prüft.
Statische Analyse unterstützt statisches Testen, nicht dynamische Ausführung und Protokollierung.
Testdurchführung und Protokollierung werden von Werkzeugen unterstützt, die skriptbasierte Tests ausführen und Ergebnisse erfassen, z. B. Testausführungswerkzeuge und Unit-Test-Frameworks.
Welche Aussage beschreibt zusammengenommen einen realistischen Nutzen UND ein realistisches Risiko der Testautomatisierung?
Nutzen: weniger wiederholter manueller Aufwand und schnelleres Feedback; Risiko: Skripte erfordern laufende Wartung und Erwartungen können zu hoch sein.
Automatisierung spart wiederholten Aufwand, erhöht aber Wartungskosten und das Risiko der Überschätzung — eine ausgewogene Sicht.
Nutzen: Sie findet mehr Fehlerarten als jeder Mensch; Risiko: keines nach der Einrichtung.
Automatisierung findet nicht von Natur aus mehr Fehlerarten und birgt stets Wartungs- und andere Risiken.
Nutzen: Sie macht jeden Testentwurf überflüssig; Risiko: Sie ist langsamer als manuelles Testen.
Automatisierung braucht weiterhin guten Testentwurf und ist bei Wiederholungen meist schneller, nicht langsamer.
Nutzen: Sie garantiert ein fehlerfreies Release; Risiko: Sie ist zu billig, um sich zu lohnen.
Keine Technik garantiert ein fehlerfreies Release, und niedrige Kosten sind kein Risiko.
Automatisierung kann den wiederholten manuellen Aufwand senken (Nutzen), verursacht aber laufende Wartungskosten und kann zu Überschätzung führen (Risiko).