ISTQB Foundation (CTFL v4.0) Probeprüfung #2 — 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.
Eine Reihe von Regressionstests läuft seit vielen Releases unverändert und findet nun selten neue Fehlerzustände. Welcher Testgrundsatz erklärt das?
Das Pestizid-Paradoxon.
Richtig — unveränderte Tests werden mit der Zeit weniger wirksam beim Finden neuer Fehlerzustände.
Vollständiges Testen ist unmöglich.
Das betrifft die Unmöglichkeit, alles zu testen, nicht das Nachlassen wiederholter Tests.
Fehlerzustände treten gehäuft auf.
Beschreibt die ungleiche Verteilung von Fehlerzuständen, nicht den schwindenden Wert wiederholter Tests.
Testen ist kontextabhängig.
Wahr, aber ohne Bezug zum Wirksamkeitsverlust wiederholter Tests.
Das Pestizid-Paradoxon: Dieselben Tests zu wiederholen findet keine neuen Fehlerzustände mehr; Tests müssen überprüft, aktualisiert und ergänzt werden.
Sicherheitskritische Medizinsoftware wird weit strenger getestet als eine einfache interne Marketing-Website. Welcher Testgrundsatz wird damit veranschaulicht?
Testen ist kontextabhängig.
Richtig — Umfang und Art des Testens hängen vom Kontext und Risiko ab.
Der Trugschluss der Fehlerfreiheit.
Der betrifft das Bauen des falschen Produkts, nicht die Anpassung der Strenge an den Kontext.
Frühes Testen spart Zeit und Geld.
Betrifft den Zeitpunkt des Testens, nicht die kontextabhängige Strenge.
Vollständiges Testen ist unmöglich.
Betrifft die Unmöglichkeit vollständigen Testens, nicht die kontextuelle Anpassung.
Testen ist kontextabhängig: Das durchgeführte Testen hängt von Faktoren wie Risiko, Domäne und Kritikalität ab.
Ein Tester führt viele Tests an einem Modul aus und findet keine Fehlerwirkungen. Was lässt sich korrekt schließen?
Das Modul kann weiterhin Fehlerzustände enthalten, die diese Tests nicht aufgedeckt haben.
Richtig — bestandene Tests beweisen nicht die Abwesenheit von Fehlerzuständen.
Das Modul ist nun nachweislich fehlerfrei.
Kein Testumfang kann die Abwesenheit von Fehlerzuständen beweisen.
Weiteres Testen dieses Moduls ist sinnlos.
Zusätzliche, besonders neue Tests können weiterhin Fehlerzustände finden.
Die Anforderungen müssen perfekt gewesen sein.
Testergebnisse sagen nichts über die Korrektheit der Anforderungen aus.
Testen kann die Anwesenheit von Fehlerzuständen zeigen, aber nie deren Abwesenheit beweisen; bestandene Tests senken das Risiko, garantieren aber kein fehlerfreies Modul.
Welche ZWEI der folgenden Aussagen verwenden die ISTQB-Begriffe Fehlhandlung, Fehlerzustand und Fehlerwirkung korrekt? (Wählen Sie zwei.)
Eine Fehlhandlung kann dazu führen, dass ein Fehlerzustand in den Code gelangt.
Richtig — eine Fehlhandlung kann einen Fehlerzustand in einem Arbeitsergebnis verursachen.
Eine Fehlerwirkung tritt auf, wenn ein Fehlerzustand im Code ausgeführt wird.
Richtig — Fehlerwirkungen sind der beobachtbare Effekt der Ausführung eines Fehlerzustands.
Eine Fehlerwirkung im Code verursacht immer eine Fehlhandlung.
Die Kausalkette verläuft Fehlhandlung → Fehlerzustand → Fehlerwirkung, nicht umgekehrt.
Jeder Fehlerzustand im Code führt immer zu einer Fehlerwirkung.
Ein Fehlerzustand führt nur dann zu einer Fehlerwirkung, wenn der betroffene Code unter passenden Bedingungen ausgeführt wird.
Eine Fehlhandlung einer Person kann einen Fehlerzustand in einem Arbeitsergebnis verursachen; das Ausführen des Fehlerzustands kann eine Fehlerwirkung (beobachtbares Fehlverhalten) hervorrufen.
Welche Frage beantwortet die Validierung, im Gegensatz zur Verifizierung?
Bauen wir das richtige Produkt für die Bedürfnisse der Nutzer?
Richtig — die Validierung prüft die Eignung für den beabsichtigten Gebrauch und die Nutzerbedürfnisse.
Entspricht das Produkt seiner schriftlichen Spezifikation?
Das ist Verifizierung, nicht Validierung.
Befolgt der Code die Programmierrichtlinien?
Die Konformität mit Richtlinien ist ein Verifizierungsanliegen.
Wurde jedes Modul gemäß seinem Entwurf gebaut?
Die Konformität mit dem Entwurf ist Verifizierung.
Die Verifizierung fragt „Bauen wir das Produkt richtig?“ (Konformität mit der Spezifikation). Die Validierung fragt „Bauen wir das richtige Produkt?“ (erfüllt die Nutzerbedürfnisse).
Welche der folgenden Beschreibungen trifft auf die „Testbasis“ am besten zu?
Die Informationsquelle, aus der Testfälle abgeleitet werden.
Richtig — die Testbasis (Anforderungen, Entwürfe usw.) ist die Quelle, aus der Tests abgeleitet werden.
Die Hardware, auf der die Tests ausgeführt werden.
Das ist die Testumgebung, nicht die Testbasis.
Die Menge der erwarteten Ergebnisse der Tests.
Erwartete Ergebnisse stammen aus der Testbasis, sind aber nicht die Basis selbst.
Die Liste der bisher gefundenen Fehlerzustände.
Fehlerdaten sind ein Ergebnis des Testens, nicht die Testbasis.
Die Testbasis ist die Wissensbasis, die für Testanalyse und -entwurf genutzt wird (z. B. Anforderungen, Entwurf, User Storys, Risikoanalyse).
Was ist ein anerkannter Vorteil eines angemessenen Maßes an Unabhängigkeit beim Testen?
Unabhängige Tester erkennen wahrscheinlich andere Arten von Fehlerwirkungen als der Autor.
Richtig — Unabhängigkeit bringt eine andere Perspektive und reduziert die Voreingenommenheit des Autors.
Unabhängige Tester können ein fehlerfreies Produkt garantieren.
Kein Maß an Unabhängigkeit kann die Abwesenheit von Fehlerzuständen garantieren.
Unabhängigkeit macht das Testen durch den Autor überflüssig.
Autoren profitieren weiterhin vom Testen ihrer eigenen Arbeit; Unabhängigkeit ergänzt es.
Maximale Unabhängigkeit ist immer die beste Wahl.
Zu viel Unabhängigkeit kann Kommunikationsprobleme verursachen und ist nicht immer optimal.
Unabhängige Tester erkennen tendenziell andere Arten von Fehlerwirkungen und sind weniger von den Annahmen des Autors beeinflusst; zu viel Unabhängigkeit kann jedoch die Kommunikation erschweren.
Wie unterscheiden sich Qualitätssicherung (QA) und Testen?
QA konzentriert sich auf den Prozess zur Erreichung von Qualität, während Testen eine produktbezogene Tätigkeit der Qualitätslenkung ist.
Richtig — QA ist prozessorientiert (Vorbeugung); Testen ist produktorientierte Qualitätslenkung.
QA und Testen sind genau dasselbe.
Sie sind verwandt, aber verschieden; QA ist breiter und prozessorientiert.
Testen ist prozessorientiert, während QA nur das Produkt untersucht.
Das kehrt die korrekten Definitionen um.
QA erfolgt nur nach der Freigabe, Testen nur davor.
Beide können den gesamten Lebenszyklus umspannen; der Unterschied ist Prozess- vs. Produktfokus.
QA ist prozessorientiert und zielt auf angemessene Qualität über den gesamten Prozess; Testen ist eine Tätigkeit der Qualitätslenkung mit Fokus auf das Produkt/die Arbeitsergebnisse.
Ein Entwickler schreibt automatisierte Tests, die eine einzelne Funktion isoliert prüfen und ihre Abhängigkeiten durch Stubs ersetzen. Welche Teststufe ist das?
Komponententest.
Richtig — eine einzelne Komponente isoliert mit Stubs zu prüfen ist Komponententest.
Systemtest.
Der Systemtest prüft das gesamte integrierte System, nicht eine isolierte Funktion.
Abnahmetest.
Der Abnahmetest stellt die Einsatzbereitschaft für Nutzer/Kunden fest.
Integrationstest.
Der Integrationstest prüft Interaktionen zwischen Komponenten, nicht eine isolierte Komponente.
Der Komponententest prüft einzelne Komponenten isoliert, oft mit Stubs/Treibern als Ersatz für Abhängigkeiten.
Nachdem ein Fehlerzustand behoben wurde, führt das Team eine breite Menge zuvor bestandener Tests erneut aus, um sicherzustellen, dass die Änderung anderswo keine neuen Fehlerzustände eingeführt hat. Welche Testart ist das?
Regressionstest.
Richtig — Tests erneut auszuführen, um ungewollte Nebenwirkungen einer Änderung zu erkennen, ist Regressionstest.
Fehlernachtest (Bestätigungstest).
Der Fehlernachtest wiederholt den konkreten fehlgeschlagenen Test zur Bestätigung der Behebung, nicht eine breite Menge.
Smoke-Test.
Der Smoke-Test ist eine oberflächliche Prüfung, ob der Build stabil genug zum Weitertesten ist.
Abnahmetest.
Der Abnahmetest stellt die Einsatzbereitschaft fest, nicht Nebenwirkungen einer Behebung.
Der Regressionstest prüft, dass eine Änderung unveränderte Teile nicht negativ beeinflusst hat. Der Fehlernachtest (Bestätigungstest) prüft, dass der konkrete Fehlerzustand tatsächlich behoben ist.
Welche der folgenden Beschreibungen trifft auf einen „Shift-Left“-Ansatz beim Testen am besten zu?
Testaktivitäten früher im Lebenszyklus durchführen, etwa Anforderungen prüfen und Tests entwerfen, bevor Code geschrieben wird.
Richtig — Shift-Left verlagert den Testaufwand nach vorn, um Fehlerzustände früher zu finden.
Alles Testen bis kurz vor der Freigabe verschieben.
Das ist das Gegenteil von Shift-Left.
Das gesamte Testen in ein separates unabhängiges Team verlagern.
Shift-Left betrifft den Zeitpunkt, nicht die organisatorische Unabhängigkeit.
Manuelles Testen vollständig durch Automatisierung ersetzen.
Shift-Left betrifft den Zeitpunkt des Testens, nicht manuell vs. automatisiert.
Shift-Left bedeutet, Testaktivitäten früher im Lebenszyklus durchzuführen (z. B. Anforderungen prüfen, Tests vor dem Code schreiben), um Fehlerzustände früher zu finden.
Welches der folgenden löst typischerweise einen Wartungstest aus?
Eine Änderung wie ein Patch, eine Erweiterung oder eine Migration in eine neue Umgebung für ein Produktivsystem.
Richtig — Änderungen und Migrationen eines Produktivsystems lösen Wartungstests aus.
Die allererste Entwicklung eines brandneuen Systems.
Erstentwicklung ist keine Wartung; Wartung betrifft bestehende Produktivsysteme.
Das Schreiben der ursprünglichen Anforderungsspezifikation.
Das ist eine frühe Entwicklungsaktivität, kein Wartungstest.
Der Entwurf der allerersten Komponententests.
Das gehört zur Erstentwicklung, nicht zur Wartung.
Der Wartungstest wird an einem in Betrieb befindlichen System aufgrund von Änderungen, Migration oder Außerbetriebnahme der Software durchgeführt.
Wie unterscheidet sich das Testen in einem iterativ-inkrementellen Lebenszyklus (z. B. Agile) typischerweise von einem sequenziellen (z. B. V-Modell)?
Das Testen erfolgt kontinuierlich innerhalb jeder kurzen Iteration, mit häufigem Regressionstest.
Richtig — iterative Ansätze integrieren das Testen über jede Iteration hinweg.
Das Testen erfolgt nur einmal, ganz am Ende des Projekts.
Das ähnelt eher einem schlecht geführten sequenziellen Modell und ist für iterative Entwicklung untypisch.
Es ist nie ein Regressionstest nötig.
Häufige Änderungen machen den Regressionstest wichtiger, nicht weniger wichtig.
Teststufen und Testarten gelten nicht mehr.
Teststufen und -arten gelten weiterhin; nur Zeitpunkt und Takt ändern sich.
In der iterativ-inkrementellen Entwicklung erfolgt das Testen kontinuierlich innerhalb kurzer Iterationen mit häufigem Regressionstest, statt überwiegend nach einer langen Entwicklungsphase.
Bei einem Test-First-Ansatz überführen Tester, Entwickler und Fachvertreter gemeinsam die Akzeptanzkriterien einer User Story in Tests, bevor die Story umgesetzt wird; diese Tests leiten dann die Entwicklung. Welcher Ansatz ist das?
Acceptance Test-Driven Development (ATDD)
Richtig — ATDD geht von den mit den Stakeholdern vereinbarten Akzeptanzkriterien aus und überführt sie vor der Umsetzung in Tests.
Test-Driven Development (TDD)
TDD ist ebenfalls Test-First, aber entwicklerzentriert: Zuerst werden Unit-Tests für ein kleines Codestück geschrieben, dann der Code, der sie erfüllt. Ausgangspunkt sind nicht die Akzeptanzkriterien der Stakeholder.
Behaviour-Driven Development (BDD)
BDD ist ein eng verwandter Test-First-Ansatz, kennzeichnend ist jedoch die Beschreibung des gewünschten Verhaltens in einer strukturierten natürlichsprachlichen Form (Given/When/Then), die direkt automatisiert werden kann, und nicht die Ableitung aus den Akzeptanzkriterien als solchen.
Regressionstest
Der Regressionstest ist ein änderungsbezogener Test, der nach Vorliegen des Codes durchgeführt wird, um unbeabsichtigte Nebenwirkungen zu finden. Er ist kein Test-First-Entwicklungsansatz.
Acceptance Test-Driven Development (ATDD) leitet Tests gemeinsam aus Akzeptanzkriterien ab, bevor implementiert wird. TDD ist entwicklerzentriert und beginnt mit Unit-Tests; BDD beschreibt das gewünschte Verhalten in einer strukturierten Given/When/Then-Notation.
Bei welchem Review-Typ leitet üblicherweise der Autor die Sitzung, geht das Arbeitsergebnis durch und sammelt Rückmeldungen, oft um ein gemeinsames Verständnis aufzubauen?
Walkthrough.
Richtig — Walkthroughs werden meist vom Autor geleitet, um durchzugehen und Rückmeldungen zu sammeln.
Inspektion.
Inspektionen werden von einem geschulten Moderator geleitet, nicht vom Autor, und sind das formellste Review.
Audit.
Ein Audit bewertet die Konformität mit Standards/Vorschriften, kein vom Autor geleitetes Durchgehen.
Statische Analyse.
Die statische Analyse ist eine werkzeuggestützte Codeprüfung, keine Review-Sitzung.
Ein Walkthrough wird meist vom Autor geleitet und dient dazu, Fehlerzustände zu finden, Wissen zu teilen und Konsens zu schaffen; er ist weniger formell als eine Inspektion.
Welche Reihenfolge ordnet die Aktivitäten eines formalen Reviews korrekt?
Planung, Initiierung, individuelle Prüfung, Kommunikation und Analyse, Behebung und Berichterstattung.
Richtig — das ist die Standardreihenfolge der formalen Review-Aktivitäten.
Behebung, Planung, individuelle Prüfung, Berichterstattung, Initiierung.
Behebung kann nicht vor Planung und Prüfung erfolgen; die Reihenfolge ist falsch.
Individuelle Prüfung, Planung, Behebung, Initiierung, Kommunikation.
Planung und Initiierung müssen vor der individuellen Prüfung kommen.
Kommunikation, Behebung, Planung, individuelle Prüfung, Initiierung.
Die Planung muss zuerst erfolgen; diese Reihenfolge ist falsch.
Ein formales Review folgt: Planung, Initiierung (Kick-off), individuelle Prüfung (Vorbereitung), Kommunikation und Analyse (Review-Sitzung) sowie Behebung/Berichterstattung.
Welche ZWEI der folgenden sind anerkannte Review-Typen? (Wählen Sie zwei.)
Technisches Review.
Ein anerkannter, meist peer-/expertenbasierter Review-Typ.
Inspektion.
Der formellste anerkannte Review-Typ.
Kompilierung.
Die Kompilierung übersetzt Code; sie ist kein Review-Typ.
Komponententest.
Der Komponententest ist dynamisches Testen, kein statischer Review-Typ.
Anerkannte Review-Typen sind u. a. informelles Review, Walkthrough, technisches Review und Inspektion. „Kompilierung“ und „Komponententest“ sind keine Review-Typen.
Welches der folgenden ist ein Erfolgsfaktor für Reviews?
Gefundene Fehlerzustände werden begrüßt und sachlich, in einer vorwurfsfreien Atmosphäre, geäußert.
Richtig — eine konstruktive, vorwurfsfreie Kultur ist ein zentraler Erfolgsfaktor für Reviews.
Das Review dient der Bewertung der Leistung des Autors.
Reviews zur Beurteilung von Personen zu nutzen untergräbt sie; Reviews zielen auf das Arbeitsergebnis.
Das größtmögliche Dokument wird in einer einzigen Sitzung geprüft.
Zu viel auf einmal zu prüfen senkt die Wirksamkeit; Sitzungen sollten angemessen dimensioniert sein.
Nur der Autor nimmt teil, um Zeit zu sparen.
Reviews brauchen geeignete Gutachter; der Autor allein verfehlt den Zweck.
Erfolgreiche Reviews haben klare Ziele, die richtigen Beteiligten, eine konstruktive (vorwurfsfreie) Atmosphäre, und gefundene Fehlerzustände werden als Verbesserungschance gesehen.
Wie viele Testfälle sind für dieselbe Routine (ein IF ohne ELSE, gefolgt von einer Anweisung) mindestens nötig für 100% Zweig-/Entscheidungsüberdeckung?
2
Ein Test macht die Entscheidung wahr, der andere falsch.
1
Ein Test deckt nur ein Ergebnis ab.
3
Zwei Ergebnisse brauchen nur zwei Fälle.
5
Entspricht der Anweisungszahl, nicht der Zweigüberdeckung.
Ein Test für IF-wahr und einer für IF-falsch = 2.
Der Player befindet sich gemäß dem folgenden Zustandsübergangsdiagramm des Media-Players im Zustand S2 (Playing). Welches der folgenden Ereignisse wird in diesem Zustand NICHT akzeptiert (hat keinen definierten Übergang)?
play
Richtig — für 'play' gibt es im Zustand Playing keinen Übergang im Diagramm.
pause
'pause' ist ein definierter Übergang von Playing zu Paused.
stop
'stop' ist ein definierter Übergang von Playing zu Stopped.
Sowohl pause als auch stop sind undefiniert.
Beide sind definierte Übergänge von Playing, daher falsch.
Von S2 (Playing) definiert das Diagramm 'pause' (zu S3) und 'stop' (zu S1). Für 'play' gibt es von S2 keinen Übergang, daher wird 'play' im Zustand Playing nicht akzeptiert.
Wie hoch ist die zyklomatische Komplexität des folgenden Kontrollflussgraphen? (Verwenden Sie V(G) = Kanten − Knoten + 2.)
2
Richtig — 7 Kanten − 7 Knoten + 2 = 2; es gibt einen Entscheidungspunkt (Knoten 2).
1
Eine einzelne Entscheidung ergibt V(G) = 2, nicht 1; 1 würde keine Entscheidungen bedeuten.
3
Es gibt nur einen Entscheidungsknoten, also ist der Wert 2, nicht 3.
7
7 ist die Anzahl der Kanten, nicht die zyklomatische Komplexität.
Der Graph hat 7 Knoten und 7 Kanten (1-2, 2-3, 2-4, 4-5, 3-6, 5-6, 6-7). V(G) = 7 − 7 + 2 = 2, passend zu einer einzigen Entscheidung an Knoten 2.
Betrachten Sie die folgende Entscheidungstabelle für Versicherungen. Ein Fahrer ist 30 Jahre alt und hat im letzten Jahr einen Schaden gemeldet. Welche Aktion gilt laut Tabelle?
Einen Zuschlag erheben (Regel R3).
Richtig — R3 hat F (nicht unter 25) und T (Schaden gemeldet) und löst den Zuschlag aus.
Einen Schadenfreiheitsrabatt gewähren (Regel R4).
R4 verlangt keinen Schaden im letzten Jahr (F); dieser Fahrer hatte einen Schaden (T).
Keine Aktion gilt.
R3 erhebt für diese Kombination ausdrücklich einen Zuschlag.
Zuschlag erheben und Rabatt gewähren.
Diese Aktionen schließen sich über die Regeln gegenseitig aus; unter R3 gilt nur der Zuschlag.
Alter unter 25 = F und Schaden im letzten Jahr = T entspricht Regel R3 (F, T), deren Aktion 'Apply surcharge' (Zuschlag) ist.
Ein Feld akzeptiert ganze Zahlen von 10 bis 20 einschließlich. Welche Werte sollten bei der Drei-Werte-Grenzwertanalyse rund um die untere Grenze 10 getestet werden?
9, 10, 11
Richtig — die Drei-Werte-GWA testet die Grenze (10) und ihre unmittelbaren Nachbarn (9 und 11).
10, 11, 12
Lässt den Wert direkt unter der Grenze (9) aus.
8, 9, 10
Lässt 11 aus und enthält einen nicht angrenzenden Wert (8).
9, 11
Die Drei-Werte-GWA muss auch den Grenzwert 10 selbst enthalten.
Die Drei-Werte-Grenzwertanalyse testet die Grenze und die Werte auf jeder Seite. Für die untere Grenze 10 sind das 9, 10 und 11.
Das Feld „Land“ eines Webformulars akzeptiert einen von 195 gültigen Ländernamen; alles andere wird abgelehnt. Wie viele Äquivalenzklassen sind bei der Äquivalenzklassenbildung mindestens sinnvoll zu identifizieren?
Zwei: eine gültige und eine ungültige Klasse.
Richtig — akzeptierte Länder bilden eine Klasse, alles Abgelehnte eine andere.
195: eine Klasse je gültigem Land.
Jedes gültige Land wird gleich behandelt und gehört daher zu einer einzigen gültigen Klasse.
Eins: nur gültige Eingaben müssen getestet werden.
Ungültige Eingaben bilden eine eigene Klasse und müssen ebenfalls getestet werden.
196: je gültigem Land eine plus eine ungültige.
Gültige Länder brauchen unter der ÄKB nicht jeweils eine eigene Klasse.
Die ÄKB gruppiert gleich behandelte Eingaben. Hier gibt es eine gültige Klasse (jedes akzeptierte Land) und eine ungültige Klasse (alles Abgelehnte) = zwei Klassen.
Warum ist es wertvoll, beim Zustandsübergangstest Testfälle für ungültige (unerwartete) Übergänge zu entwerfen?
Um zu prüfen, dass das System Ereignisse korrekt behandelt, die im aktuellen Zustand nicht erlaubt sind.
Richtig — Tests ungültiger Übergänge prüfen die robuste Behandlung unzulässiger Ereignisse.
Um die Gesamtzahl der Zustände im Modell zu verringern.
Das Testen von Übergängen ändert die Zahl der Zustände im Modell nicht.
Weil gültige Übergänge nie Fehlerzustände enthalten.
Auch gültige Übergänge können Fehlerzustände enthalten und müssen getestet werden.
Um automatisch 100 % Anweisungsüberdeckung zu erreichen.
Der Zustandsübergangstest ist Black-Box und garantiert für sich keine Anweisungsüberdeckung.
Das Testen ungültiger Übergänge prüft, ob das System Ereignisse, die im aktuellen Zustand nicht erlaubt sein sollten, korrekt ablehnt oder behandelt — eine häufige Fehlerquelle.
Eine Entscheidungstabelle hat drei unabhängige boolesche Bedingungen. Wie viele verschiedene Regeln (Spalten) enthält die vollständige Tabelle vor jeder Vereinfachung?
8
Richtig — 2^3 = 8 Kombinationen von drei booleschen Bedingungen.
6
2^3 ist 8, nicht 6 (Verwechslung von Multiplikation und Potenzierung).
3
3 ist die Anzahl der Bedingungen, nicht der Regeln.
9
9 ist 3 zum Quadrat; die Zahl der Kombinationen ist 2 hoch 3 = 8.
Für n unabhängige boolesche Bedingungen hat die vollständige Tabelle 2^n Regeln. Für 3 Bedingungen sind das 2^3 = 8.
Welche Aussage über Anweisungs- und Zweigüberdeckung (Entscheidungsüberdeckung) ist korrekt?
100 % Zweigüberdeckung garantiert 100 % Anweisungsüberdeckung, aber nicht umgekehrt.
Richtig — die Zweigüberdeckung schließt die Anweisungsüberdeckung ein.
100 % Anweisungsüberdeckung garantiert 100 % Zweigüberdeckung.
Die Anweisungsüberdeckung kann 100 % sein, während einige Zweige (z. B. ein leeres else) ungenommen bleiben.
Die beiden Maße sind immer gleich.
Sie können sich unterscheiden; die Zweigüberdeckung ist meist schwerer zu erreichen.
Die Maße haben keinerlei Bezug zueinander.
Sie sind verwandt: die Zweigüberdeckung schließt die Anweisungsüberdeckung ein.
100 % Zweigüberdeckung garantiert 100 % Anweisungsüberdeckung, aber nicht umgekehrt; die Zweigüberdeckung ist das stärkere Kriterium.
Ein Tester nutzt eine übergeordnete Liste von zu prüfenden Bereichen, Regeln und Bedingungen, die aus Erfahrung abgeleitet ist, um das Testen zu lenken, ohne genaue Schritte vorzugeben. Welche Technik ist das?
Checklistenbasierter Test.
Richtig — eine erfahrungsbasierte Checkliste zur Lenkung des Testens zu nutzen ist checklistenbasiertes Testen.
Grenzwertanalyse.
Die GWA zielt auf die Ränder von Eingabebereichen, nicht auf eine Checkliste von Bereichen.
Entscheidungstabellentest.
Entscheidungstabellen erfassen Bedingungskombinationen, keine erfahrungsbasierten Checklisten.
Anweisungstest.
Der Anweisungstest ist eine White-Box-Überdeckungstechnik.
Der checklistenbasierte Test nutzt eine erfahrungsbasierte Checkliste abzudeckender Punkte; es ist eine erfahrungsbasierte Technik.
Ein Eingabefeld akzeptiert einen Rabatt-Prozentsatz als Ganzzahl von 1 bis 100 einschließlich. Wie viele unterschiedliche Testwerte sind bei der Drei-Wert-Grenzwertanalyse (je Grenze der Grenzwert sowie der Wert direkt darunter und darüber) nötig, wenn sich keine überschneiden?
6
Drei Werte je Grenze mal zwei Grenzen = sechs unterschiedliche Werte.
4
4 ist die Zwei-Wert-BVA (zwei Werte je Grenze), nicht die Drei-Wert-BVA.
2
2 deckt nur die Grenzwerte selbst ab.
8
Zu viel; die Drei-Wert-BVA braucht drei Werte je Grenze, nicht vier.
Untere Grenze 1 → 0, 1, 2; obere Grenze 100 → 99, 100, 101. Das sind sechs unterschiedliche Werte.
Welches der folgenden ist das beste Beispiel für ein Eingangskriterium für den Systemtest?
Ein stabiler Build ist in einer konfigurierten, verfügbaren Testumgebung bereitgestellt.
Richtig — dies ist eine Vorbedingung (Eingangskriterium) für den Beginn des Systemtests.
Alle geplanten Systemtests sind bestanden.
Das ist ein Ausgangskriterium, das den Abschluss beschreibt, nicht den Eingang.
Es bleiben keine Fehlerzustände mit hoher Schwere offen.
Ebenfalls ein Ausgangskriterium, keine Eingangsbedingung.
Der Testabschlussbericht ist abgenommen worden.
Die Abnahme erfolgt am Ende, daher ist dies kein Eingangskriterium.
Eingangskriterien sind die Vorbedingungen, die erfüllt sein müssen, bevor das Testen sinnvoll beginnen kann, etwa ein stabiler Build, der in einer bereitstehenden Testumgebung bereitgestellt ist.
Welche Verteilung automatisierter Tests legt das Modell der „Testpyramide“ im Allgemeinen nahe?
Viele Tests auf niedriger Ebene (Unit-/Komponententests), weniger Integrationstests und wenige End-to-End-UI-Tests.
Richtig — die Pyramide bevorzugt eine breite Basis schneller Tests auf niedriger Ebene.
Überwiegend End-to-End-UI-Tests mit sehr wenigen Unit-Tests.
Das ist das umgekehrte „Eistüten“-Antimuster, nicht die Pyramide.
Eine gleiche Anzahl von Tests auf jeder Ebene.
Die Pyramide hat bewusst mehr Tests auf den niedrigeren Ebenen.
Nur manuelle Tests auf allen Ebenen.
Bei der Pyramide geht es um die Verteilung automatisierter Tests über die Ebenen.
Die Testpyramide legt viele schnelle Tests auf niedriger Ebene nahe (z. B. Unit-/Komponententests), weniger Integrations-/API-Tests und vergleichsweise wenige langsame End-to-End-UI-Tests auf hoher Ebene.
Wie verwendet risikobasiertes Testen typischerweise das bewertete Risikoniveau?
Elemente mit höherem Risiko erhalten mehr und früheres Testen als Elemente mit geringerem Risiko.
Richtig — der Aufwand wird im Verhältnis zum Risiko zugewiesen.
Jedes Element erhält unabhängig vom Risiko genau denselben Testumfang.
Das ignoriert das Risiko und ist kein risikobasiertes Testen.
Elemente mit geringerem Risiko werden immer zuerst getestet.
Risikobasiertes Testen priorisiert Elemente mit höherem Risiko, nicht solche mit geringerem Risiko.
Risikoniveaus werden nur nach der Freigabe verwendet, niemals während des Testens.
Das Risiko wird verwendet, um das Testen durchgehend zu planen und zu steuern, nicht nur nach der Freigabe.
Risikobasiertes Testen priorisiert Elemente mit höherem Risiko und weist ihnen mehr, früheres und tiefergehendes Testen zu, während Elementen mit geringerem Risiko weniger Aufwand zugewiesen wird.
Welche Rolle spielt das Konfigurationsmanagement zur Unterstützung des Testens?
Es identifiziert Testobjekte und Testmittel eindeutig und versioniert sie, sodass Tests gegen bekannte Versionen ausgeführt werden.
Richtig — das Konfigurationsmanagement wahrt die Integrität und Nachverfolgbarkeit von Objekten und Testmitteln.
Es schreibt die detaillierten Testfälle für jede Anforderung.
Der Testentwurf erstellt Testfälle; das Konfigurationsmanagement verwaltet Versionen und Integrität.
Es entscheidet, welche Fehlerzustände behoben werden.
Die Fehlertriage entscheidet über Behebungen; das Konfigurationsmanagement steuert Versionen und Konfigurationen.
Es schätzt den für das Testen erforderlichen Aufwand.
Die Schätzung ist eine Planungstätigkeit, kein Konfigurationsmanagement.
Das Konfigurationsmanagement stellt sicher, dass Testmittel (Testware) und die Testobjekte identifiziert, versioniert und nachverfolgbar sind, sodass Tests gegen bekannte Versionen ausgeführt werden.
Was ist der Unterschied zwischen der Schwere und der Priorität eines Fehlerzustands?
Die Schwere ist die Auswirkung auf das System; die Priorität ist, wie dringend er behoben werden sollte.
Richtig — bei der Schwere geht es um die Auswirkung, bei der Priorität um die Dringlichkeit, und sie können voneinander abweichen.
Schwere und Priorität haben immer denselben Wert.
Ein Fehlerzustand mit hoher Schwere kann eine niedrige Priorität haben und umgekehrt.
Die Priorität ist die technische Auswirkung; die Schwere ist die geschäftliche Dringlichkeit.
Dies kehrt die Definitionen um.
Beide Begriffe beziehen sich nur darauf, wie reproduzierbar der Fehlerzustand ist.
Die Reproduzierbarkeit ist ein von Schwere und Priorität getrenntes Attribut.
Die Schwere spiegelt die Auswirkung des Fehlerzustands auf das System wider; die Priorität spiegelt wider, wie dringend er aus geschäftlicher Sicht behoben werden sollte. Sie sind voneinander unabhängig.
Welche der folgenden Aufgaben liegt typischerweise in der Verantwortung eines Testmanagers und nicht eines Testers?
Erstellen und Prüfen des Testplans und der übergreifenden Teststrategie.
Richtig — Planung und Strategie sind Aufgaben des Testmanagements.
Entwerfen und Realisieren einzelner Testfälle.
Dies ist typischerweise eine Aufgabe des Testers.
Durchführen von Tests und Protokollieren der Ergebnisse.
Durchführung und Protokollierung werden typischerweise von Testern übernommen.
Einrichten von Testdaten für einen bestimmten Testfall.
Das Vorbereiten von Testdaten ist üblicherweise eine Aufgabe des Testers.
Der Testmanager plant, überwacht und steuert die Testaktivitäten (Strategie, Planung, Berichterstattung), während Tester Tests entwerfen, realisieren und durchführen.
Ein Team schätzt den Testaufwand, indem es den für das Testen aufgewendeten Aufwand in mehreren früheren, ähnlichen Projekten analysiert. Um welchen Schätzansatz handelt es sich?
Ein metrikbasiertes Schätzverfahren.
Richtig — die Verwendung historischer Daten aus ähnlichen Projekten ist eine metrikbasierte Schätzung.
Ein expertenbasiertes Schätzverfahren.
Die expertenbasierte Schätzung stützt sich auf das Urteil von Experten, nicht auf historische Metriken.
Grenzwertanalyse.
Die Grenzwertanalyse (BVA) ist ein Testentwurfsverfahren, kein Schätzansatz.
Exploratives Testen.
Exploratives Testen ist ein Testverfahren, keine Schätzmethode.
Die metrikbasierte Schätzung verwendet Daten aus früheren oder ähnlichen Projekten (z. B. früherer Aufwand, Fehlerraten), um den benötigten Aufwand zu prognostizieren.
Welche ZWEI der folgenden werden häufig als Metriken für die Testüberwachung verwendet? (Wählen Sie zwei.)
Prozentsatz der durchgeführten geplanten Testfälle.
Ein Standardmaß für den Testfortschritt.
Anzahl der gefundenen Fehlerzustände, gruppiert nach Schwere.
Fehlermetriken sind ein zentraler Bestandteil der Testüberwachung.
Anzahl der Wörter in der Marketingbroschüre.
Keine Testmetrik.
Die Bürotemperatur während des Testens.
Für die Testüberwachung irrelevant.
Die Testüberwachung verwendet Metriken wie den Fortschritt der Testfalldurchführung, Fehlerinformationen (Anzahl, Dichte, Trends) und die erreichte Überdeckung. Zeilen von Marketingtexten und Bewertungen der Teammoral sind keine Standard-Testmetriken.
Ein Testmanager wendet die Drei-Punkt-Methode (PERT) auf eine Aufgabe an: optimistisch = 2 Tage, wahrscheinlich = 5 Tage, pessimistisch = 14 Tage. Wie hoch ist der Schätzwert nach E = (O + 4M + P) / 6?
6 Tage
(2 + 20 + 14) / 6 = 36 / 6 = 6.
5 Tage
5 ist der wahrscheinliche Wert, nicht der gewichtete PERT-Schätzwert.
7 Tage
7 ist der einfache Mittelwert (2+5+14)/3, nicht der gewichtete PERT-Wert.
8 Tage
Passt nicht zur Formel; der korrekte gewichtete Schätzwert ist 6.
E = (2 + 4×5 + 14) / 6 = (2 + 20 + 14) / 6 = 36 / 6 = 6 Tage.
Zu welcher Kategorie gehört ein Werkzeug, das vordefinierte automatisierte Skripte gegen die Anwendung ausführt und die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen vergleicht?
Testdurchführungswerkzeuge.
Richtig — das Ausführen automatisierter Skripte und das Vergleichen von Ergebnissen ist die Aufgabe von Testdurchführungswerkzeugen.
Werkzeuge für die statische Analyse.
Die statische Analyse untersucht Code, ohne ihn auszuführen.
Werkzeuge für das Anforderungsmanagement.
Diese verwalten Anforderungen und Nachverfolgbarkeit, nicht die Testdurchführung.
Werkzeuge für die Testdatenvorbereitung.
Diese erzeugen oder maskieren Testdaten; sie führen keine Tests aus.
Testdurchführungswerkzeuge führen automatisierte Tests gegen das Testobjekt aus und vergleichen die tatsächlichen mit den erwarteten Ergebnissen, was das Regressionstesten unterstützt.
Warum ist es eine gute Praxis, ein Pilotprojekt durchzuführen, bevor ein neues Testwerkzeug in der gesamten Organisation ausgerollt wird?
Um zu beurteilen, wie gut das Werkzeug zu den bestehenden Prozessen passt, und um vor einer breiteren Einführung zu lernen, wie man es effektiv einsetzt.
Richtig — ein Pilotprojekt verringert das Risiko, indem es zunächst die Eignung bewertet und Know-how aufbaut.
Um zu garantieren, dass das Werkzeug sämtliches manuelles Testen überflüssig macht.
Werkzeuge unterstützen das Testen, machen die Notwendigkeit manuellen Testens aber nicht überflüssig.
Um zu beweisen, dass das Werkzeug jeden Fehlerzustand im System finden kann.
Kein Werkzeug kann jeden Fehlerzustand finden; ein Pilotprojekt erhebt diesen Anspruch nicht.
Weil Werkzeuge nach der Installation niemals Wartung erfordern.
Werkzeuge und ihre Skripte erfordern fortlaufende Wartung.
Ein Pilotprojekt bewertet, wie gut das Werkzeug zu den Prozessen und der Infrastruktur der Organisation passt, legt Nutzungsstandards fest und beurteilt Kosten und Nutzen vor einem vollständigen Rollout.