Kategorie ISTQB

Das Testen von Zustandsübergängen ist eine Black-Box-Testtechnik, bei der Testfälle so entworfen werden, dass sie die Zustände und Übergänge eines Zustandsautomaten abdecken.
Gegeben sei das Zustandsmodell mit den folgenden Übergängen:
* PLATZIERT -> IN DER PRODUKTION
* IN PRODUKTION -> GESTRICHEN
* IN PRODUKTION -> AUSGELIEFERT
* VERSANDT -> IN RECHNUNG GESTELLT
* IN RECHNUNG GESTELLT -> STORNIERT
* ABGEBROCHEN -> PLATZIERT
Um alle Übergänge mindestens einmal abzudecken, müssen wir eine Sequenz erstellen, die alle sechs Übergänge abdeckt.
Option A: IN PRODUKTION -> ABGESAGT -> PLATZIERT -> IN PRODUKTION -> ABGESAGT -> PLATZIERT- Verpasst die Übergänge VERSANDT -> INVOIZIERT und INVOIZIERT -> ABGESAGT.
Option B: IN PRODUKTION -> VERSANDT -> INVOIZIERT -> ABGESAGT -> PLATZIERT -> IN PRODUKTION- Deckt alle Übergänge ab.
Option C: PLACED -> IN PRODUCTION -> SHIPPED -> CANCELLED (ISTQB not-for-profit association) (Udemy)sses INVOICED -> CANCELLED transition.
Option D: PLACED -> CANCELLED -> PLACED -> CANCELLED -> PLACED -> IN PRODUCTION -> CANCELLED- Verpasst die Übergänge SHIPPED -> INVOICED und INVOICED -> CANCELLED.
Unter diesen Voraussetzungen deckt Option B alle Übergänge6†Quelle9†Quelle ab.
Referenzen:
* Certified Tester Foundation Level v4.0
* 10 Beispielprüfungen ISTQB Foundation Level (CTFL) v4.0

Sie sollten eine Testtechnik wählen, weil Sie die Art und Weise, wie Sie testen, auf den Inhalt des zu testenden Produkts abstimmen müssen. Eine Testtechnik ist eine Methode oder ein Prozess zur Ableitung und Auswahl von Testfällen auf der Grundlage bestimmter Kriterien oder Regeln. Verschiedene Testtechniken eignen sich für verschiedene Arten von Softwareprodukten, je nach deren Eigenschaften, Funktionalitäten, Anforderungen, Spezifikationen, Risiken usw. Die Auswahl einer Testtechnik hilft sicherzustellen, dass die Testfälle für das zu testende Produkt relevant, effektiv und effizient sind. Die anderen Optionen sind keine guten Gründe für die Wahl einer Testtechnik. Zeitbeschränkungen sind kein Faktor für die Wahl einer Testtechnik, sondern eher für die Priorisierung oder Optimierung von Testaktivitäten. Die Abdeckung des vollen Funktionsumfangs des Produkts ist keine Garantie für die Wahl einer Testtechnik, sondern eher ein Ziel des Testens. Die Auswahl einer Testtechnik ist keine gängige Praxis im Softwaretest, sondern eine professionelle Fähigkeit und Verantwortung. Geprüfte Referenzen: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Seite 31.

Komponententests sind eine Testebene. Eine Testebene ist eine Gruppe von Testaktivitäten, die auf der Grundlage einiger gemeinsamer Merkmale oder Ziele organisiert und verwaltet werden. Eine Testebene kann auf der Grundlage verschiedener Faktoren definiert werden, wie z. B. dem Umfang und dem Ziel des Testens, der Entwicklungsphase und dem Entwicklungsmodell, den am Testen beteiligten Akteuren und Rollen, usw. Komponententests (auch bekannt als Unit-Tests oder Modultests) sind eine Testebene, die sich auf die Überprüfung der Funktionalität und Qualität einzelner Softwarekomponenten (wie Module, Klassen, Funktionen, Methoden usw.) konzentriert. Komponententests können von Entwicklern oder Testern mit verschiedenen Techniken und Werkzeugen durchgeführt werden, je nach Art und Komplexität der Komponenten. Die anderen Optionen sind keine Testebenen. Integrationstests sind eine weitere Testebene, die sich auf die Überprüfung der Funktionalität und Qualität von Gruppen von Softwarekomponenten konzentriert, die miteinander oder mit externen Systemen interagieren. Funktionstests sind eine Art von dynamischen Black-Box-Tests, bei denen überprüft wird, ob das zu testende System seine beabsichtigten Funktionen gemäß den Anforderungen oder Spezifikationen ausführt. Erfahrungsbasiertes Testen ist eine Kategorie von Testentwurfstechniken, die sich auf das Wissen und die Intuition des Testers stützen, um Testfälle auf der Grundlage seiner Erfahrung mit ähnlichen Systemen, Technologien, Domänen, Risiken usw. abzuleiten und auszuwählen. Geprüfte Referenz: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Seite 19.

Um eine Anweisungsabdeckung von 100% zu erreichen, müssen wir Testfälle entwerfen, die sicherstellen, dass jede Anweisung im gegebenen Pseudocode mindestens einmal ausgeführt wird. Wenn wir den Pseudocode analysieren, stellen wir fest, dass es Bedingungen gibt, die auf zwei Variablen basieren: Geschlecht und Alter. Um alle Anweisungen abzudecken, müssen wir die Pfade berücksichtigen, die zu jeder Zuweisung der Variablen Schuhgröße führen.
* Geschlecht = Junge, Alter <= 3 (Schuhgrößenzuordnung wird nicht erreicht, aber die Bedingung wird ausgewertet)
* Geschlecht = Junge, Alter > 3 UND Alter < 5 (Schuhgröße = 1)
* Geschlecht = Junge, Alter >= 5 UND Alter < 7 (Schuhgröße = 2)
* Geschlecht != Junge, Alter <= 3 (Auch hier wird die Zuordnung der Schuhgröße nicht erreicht, aber die Bedingung wird ausgewertet)
* Geschlecht != Junge, Alter > 3 UND Alter < 5 (Schuhgröße = 0)
* Geschlecht != Junge, Alter >= 5 UND Alter < 7 (Schuhgröße = 1)
Bei näherer Betrachtung sehen wir jedoch, dass die Tests 1 und 4 nicht zur Anweisungsabdeckung beitragen, da sie nicht zu einer Schuhgrößenzuweisung führen. Daher benötigen wir nur 4 Testfälle, um eine Anweisungsabdeckung von 100% zu erreichen, so dass Option B die richtige Antwort ist.

Ein neues Navigationssystem im Vergleich zu einem früheren System eignet sich am besten für das Testen mit Anwendungsfällen, da es ein hohes Maß an Interaktion zwischen dem Benutzer und dem System beinhaltet und das erwartete Verhalten und die Ergebnisse des Systems auf den Bedürfnissen und Zielen des Benutzers basieren. Anwendungsfälle können helfen, die funktionalen Anforderungen des neuen Navigationssystems zu spezifizieren, wie z. B. die Möglichkeit, ein Ziel einzugeben, eine Route auszuwählen, den Anweisungen zu folgen, Warnungen zu erhalten usw. Anwendungsfälle können auch dabei helfen, die Genauigkeit und Benutzerfreundlichkeit des neuen Systems mit dem vorherigen System zu vergleichen, indem die Erfolgs- und Misserfolgsszenarien, die Vor- und Nachbedingungen und die alternativen Abläufe für jeden Anwendungsfall definiert werden. Anwendungsfälle können auch dabei helfen, Testfälle zu entwerfen und auszuführen, die die Haupt- und Ausnahmepfade jedes Anwendungsfalls abdecken, und zu überprüfen, ob die Erwartungen der Benutzer erfüllt werden.
Die anderen Optionen sind nicht die am besten geeigneten Anwendungen für das Testen anhand von Anwendungsfällen, da sie kein hohes Maß an Interaktion zwischen dem Benutzer und dem System beinhalten oder das erwartete Verhalten und die Ergebnisse des Systems nicht auf den Bedürfnissen und Zielen des Benutzers basieren. Ein Abrechnungssystem, das die monatlichen Gebühren auf der Grundlage einer großen Anzahl von Teilnehmerparametern berechnet, eignet sich besser für datengesteuerte Tests, eine Technik zum Testen der Funktionalität und Leistung eines Systems oder einer Komponente unter Verwendung einer großen Menge von Eingabe- und Ausgabedaten. Die Fähigkeit eines Antivirenpakets, eine neue Bedrohung zu erkennen und unter Quarantäne zu stellen, eignet sich eher für das Testen durch exploratives Testen, eine Technik zum Testen der Funktionalität und Sicherheit eines Systems oder einer Komponente unter Verwendung eines informellen und flexiblen Ansatzes, der auf der Erfahrung und Intuition des Testers beruht. Die Eignung und Leistung eines multimedialen (audio- und videobasierten) Systems für ein neues Betriebssystem eignet sich besser für Kompatibilitätstests, bei denen die Funktionalität und Leistung eines Systems oder einer Komponente unter Verwendung unterschiedlicher Hardware-, Software- oder Netzwerkumgebungen getestet wird. Referenz = CTFL 4.0 Syllabus, Abschnitt 3.1.1, Seite 28-29; Abschnitt 4.1.1, Seite 44-45; Abschnitt 4.2.1, Seite 47-48.

Gemäß der Entscheidungstabelle in der Abbildung hat ein Preferred Guest-Karteninhaber mit einem Silberzimmer Anspruch auf ein Upgrade auf Gold Luxury (JA), während ein Nicht-Preferred Guest-Karteninhaber, unabhängig vom Zimmertyp, keinen Anspruch auf ein Upgrade hat (NEIN). Daher würde Kunde A (ein Preferred Guest-Karteninhaber mit einem Silberzimmer) ein Upgrade auf Gold Luxury erhalten, während Kunde B (ein Nicht-Preferred Guest-Karteninhaber mit einem Platinzimmer) kein Upgrade erhalten würde. Referenzen = Die Antwort ist direkt von der Entscheidungstabelle in der Abbildung abgeleitet; auf spezifische ISTQB Certified Tester Foundation Level (CTFL) v4.0 Dokumente wird nicht verwiesen.

Regressionstests sind eine Art von Tests, bei denen überprüft wird, ob eine zuvor getestete Software auch nach Änderungen noch korrekt funktioniert. Regressionstests können dazu beitragen, das erneute Auftreten von zuvor behobenen Fehlern zu verhindern, indem sie sicherstellen, dass diese keine neuen Fehler oder Nebenwirkungen verursachen. Die erste Empfehlung an das Unternehmen besteht darin, zu überprüfen, ob die vorhandene Regressionstestsuite angemessen ist, und sie bei Bedarf zu erweitern, um sicherzustellen, dass früher behobene Fehler in jedem nachfolgenden Build erneut getestet werden. Dies kann dazu beitragen, den Abdeckungsgrad und die Effektivität von Regressionstests zu verbessern und Regressionsfehler so früh wie möglich zu erkennen. Die Automatisierung bestehender Testsuiten kann ebenfalls dazu beitragen, den Zeit- und Arbeitsaufwand für Regressionstests zu verringern. Dies ist jedoch nicht die erste Empfehlung, da die Automatisierung möglicherweise nicht für alle Testfälle machbar oder kosteneffizient ist. Die Analyse der Produktmodule mit den meisten Fehlern und deren gründliche Prüfung und Behebung als einmalige Maßnahme kann ebenfalls dazu beitragen, die Fehlerdichte zu verringern und die Qualität dieser Module zu verbessern, doch ist dies nicht die erste Empfehlung, da die Ursache für das erneute Auftreten früher behobener Fehler nicht angegangen wird. Die Schulung oder der Austausch der Teams, die für die Entwicklung und das Testen der Module mit der höchsten Fehlerdichte verantwortlich sind, kann ebenfalls dazu beitragen, ihre Fähigkeiten oder ihre Leistung zu verbessern; dies ist jedoch nicht die erste Empfehlung, da dies möglicherweise nicht für alle Teams notwendig oder angemessen ist.
Geprüfte Referenzen: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 2, Seite 19; Kapitel 4, Seite 45.

Die richtige Antwort ergibt sich aus der Anwendung der angegebenen Regeln auf den jeweiligen Fall:
* A ist ST-zertifiziert und hat 12 Jahre Prüfungserfahrung, also mehr als 10 Jahre. Daher erfüllt A keine der Regeln und das Ergebnis ist unbekannt.
* B ist nicht ST-zertifiziert und hat 7 Jahre Prüfungserfahrung, was zwischen 5 und 10 Jahren liegt. Daher entspricht B der Regel 3 und das Ergebnis ist ein eingeschränkter Zugang.
* C ist nicht ST-zertifiziert und hat 3 Jahre Prüfungserfahrung, was weniger als 5 Jahre sind. Daher entspricht C keiner der Regeln und das Ergebnis ist unbekannt. verifizierte Referenzen: Diese Frage erfordert keine externen Referenzen, da sie auf logischen Überlegungen beruht.

Die Kommunikation von Testern über Fehler, Testergebnisse und andere Testinformationen sollte die Vorteile des Testens, wie z.B. erhöhte Qualität und reduziertes Risiko, hervorheben. Dieses positive Framing trägt dazu bei, den Wert des Testens zu verstärken und sicherzustellen, dass die Beteiligten den Beitrag des Testens zum Gesamterfolg des Projekts verstehen (ISTQB gemeinnütziger Verband):
* ISTQB Certified Tester Foundation Level Syllabus v4.0:
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTFL_Syllabus-v4.0.pdf

Die Suche nach Fehlern in einem System erfordert nicht, dass man Systemdetails ignoriert, sondern dass man ihnen Aufmerksamkeit schenkt und versteht, wie sie sich auf die Qualität, Funktionalität und Nutzbarkeit des Systems auswirken. Das Ignorieren von Systemdetails könnte dazu führen, dass wichtige Fehler übersehen oder irrelevante Aspekte des Systems getestet werden.
Das Aufzeigen von Mängeln kann als Kritik am Produkt empfunden werden, insbesondere von den Entwicklern oder Interessengruppen, die in den Erfolg des Produkts investiert haben. Das Aufzeigen von Mängeln ist jedoch nicht als persönlicher Angriff zu verstehen, sondern als konstruktives Feedback, das zur Verbesserung des Produkts beiträgt und sicherstellt, dass es den Anforderungen und Erwartungen der Benutzer und Kunden entspricht.
Die Suche nach Fehlern in einem System erfordert professionellen Pessimismus und Neugier, da die Tester die möglichen Wege, auf denen das System versagen, schlecht funktionieren oder sich unerwartet verhalten könnte, vorhersehen und erkunden müssen. Fachlicher Pessimismus bedeutet, dass man der Qualität und Zuverlässigkeit des Systems skeptisch und kritisch gegenübersteht, während Neugierde bedeutet, dass man eifrig und interessiert daran ist, die Ursachen und Folgen der Fehler herauszufinden.
Testen wird oft als eine destruktive und nicht als eine konstruktive Tätigkeit angesehen, da es darum geht, die Fehler und Schwächen des Systems zu finden und zu melden, anstatt es zu schaffen oder zu verbessern. Tatsächlich ist das Testen jedoch eine konstruktive Tätigkeit, da es zur Verbesserung, Verifizierung, Validierung und Optimierung des Systems und letztlich zur Lieferung eines qualitativ hochwertigen Produkts beiträgt, das die Bedürfnisse und Erwartungen der Benutzer und Kunden erfüllt.

Die Aussage "Rückverfolgbarkeit kann es schwieriger machen, die Auswirkungen von Änderungen zu verstehen" ist falsch. Die Rückverfolgbarkeit beim Testen erleichtert das Verständnis der Auswirkungen von Änderungen durch die Verknüpfung von Testfällen mit Anforderungen. Diese Verknüpfung trägt dazu bei, dass Änderungen an den Anforderungen in den Testfällen angemessen widergespiegelt und verifiziert werden, wodurch ein effektives Management von Änderungen und die Aufrechterhaltung der Integrität des zu entwickelnden Systems oder Produkts unterstützt wird (ISTQB Non-Profit-Organisation) (ISTQB Main Web).Referenzen:
* ISTQB Certified Tester Foundation Level Syllabus v4.0:
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTFL_Syllabus-v4.0.pdf
* Offizielle ISTQB-Website - CTFL-Zertifizierung:
https://www.istqb.org/certifications/certified-tester-foundation-level/

Nach dem ISTQB Certified Tester Foundation Level (CTFL) v4.0 folgt der Lebenszyklus eines Fehlers typischerweise einer Abfolge von seiner Entdeckung bis zu seiner Schließung. In der Abbildung beginnt er mit S0 (Neu), geht über zu S1 (Zugewiesen), dann zu S2 (Gelöst), gefolgt von S3 (Verifiziert). Wenn der Fehler nicht behoben ist, kann er wieder geöffnet werden (S5) und geht zurück zur Überprüfung (S3). Nach der Überprüfung wird er geschlossen (S4). Referenzen: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Abschnitt 1.4.3, Seite 17.

Testmanagement-Tools sollen die Planung, Durchführung und Überwachung des Testprozesses unterstützen.
Sie bieten Funktionen für die Verwaltung von Testfällen, Testläufen, die Verfolgung von Fehlern und die Berichterstattung über Testaktivitäten.
Die Aussage in Option C beschreibt jedoch, dass Testmanagement-Tools das Verhalten des Systems während der Testaktivitäten überwachen und darüber berichten, was nicht korrekt ist. Testmanagement-Tools konzentrieren sich auf den Testprozess selbst und nicht auf das Verhalten des zu testenden Systems.
* Werkzeuge zur Vorbereitung von Testdaten (A) erstellen und verwalten in der Tat Testdaten zur Verwendung während der Testdurchführung.
* Testausführungswerkzeuge (B) automatisieren die Ausführung von Testfällen und den Vergleich der tatsächlichen Ergebnisse mit den erwarteten Ergebnissen.
* Testkomparatoren (D) sind Instrumente, die die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen vergleichen und Abweichungen aufzeigen.
Daher ist Option C die richtige Antwort, da sie die Funktion von Testmanagement-Tools ungenau beschreibt.

Wartungstests sind Tests, die an einem Softwareprodukt nach der Auslieferung durchgeführt werden, um Fehler zu korrigieren oder die Leistung oder andere Eigenschaften zu verbessern. Wartungstests können durch verschiedene Situationen ausgelöst werden, z. B. durch Änderungen an einer freigegebenen Software oder einem System, durch die Migration der Systemdaten auf ein Ersatzsystem oder durch die Ausmusterung der Software oder des Systems. Wartungstests werden nicht durchgeführt, wenn die Anforderungen an die Wartbarkeit während der Entwicklungsphase aktualisiert werden, da es sich hierbei nicht um eine Wartungssituation, sondern um eine Änderungsanforderung handelt, die im Rahmen des Entwicklungsprozesses behandelt werden sollte. Überprüfte Referenzen: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 2, Seite 18-19.

Statische Analysewerkzeuge sind Softwaretools, die den Quellcode eines Programms untersuchen, ohne es auszuführen. Sie können verschiedene Arten von Problemen erkennen, z. B. Syntaxfehler, Verstöße gegen Kodierungsstandards, Sicherheitslücken und potenzielle Bugs12. Statische Analysetools können jedoch keine Probleme erkennen, die vom Laufzeitverhalten oder der Leistung des Programms abhängen, wie z. B. eine sehr niedrige MTBF (Mean Time Between Failure)3. MTBF ist ein Maß für die Zuverlässigkeit eines Systems oder einer Komponente. Sie wird berechnet, indem die Gesamtbetriebszeit durch die Anzahl der Ausfälle geteilt wird. MTBF gibt an, wie oft ein System oder eine Komponente während seiner erwarteten Lebensdauer ausfällt. Statische Analysewerkzeuge können die MTBF nicht messen, da sie das Programm nicht ausführen und seine Ausfälle nicht beobachten. MTBF kann nur durch dynamische Tests geschätzt werden, bei denen das Programm unter verschiedenen Bedingungen ausgeführt wird und Daten über seine Ausfälle gesammelt werden4. Daher ist eine sehr niedrige MTBF ein Problem, das mit statischen Analysetools nicht erkannt werden kann.
Die anderen Optionen, wie z. B. potenzielle Endlosschleifen, Verweise auf eine Variable mit einem undefinierten Wert und Sicherheitslücken, sind Probleme, die von statischen Analysetools erkannt werden können. Statische Analysewerkzeuge können potenzielle Endlosschleifen erkennen, indem sie den Kontroll- und Datenfluss des Programms analysieren und auf Bedingungen prüfen, die niemals falsch werden dürfen5. Statische Analysewerkzeuge können den Verweis auf eine Variable mit einem undefinierten Wert erkennen, indem sie den Umfang und die Initialisierung von Variablen überprüfen und jede Verwendung nicht initialisierter Variablen melden6. Statische Analysewerkzeuge können Sicherheitsschwachstellen aufdecken, indem sie nach häufigen Mustern von unsicherem Code suchen, z. B. Pufferüberläufe, SQL-Injections, Cross-Site-Scripting und schwache Verschlüsselung. Referenzen = Was ist statische Analyse? Statische Code-Analyse-Tools - Perforce Software, Wie statische Code-Analyse funktioniert | Perforce, Statische Code-Analyse: Techniken, Top 5 Vorteile & 3 Herausforderungen, Was ist MTBF? Mean Time Between Failures Explained | Perforce, Static analysis tools - Software Testing MCQs - CareerRide, ISTQB_Chapter3 | Quizizz, [Static Code Analysis for Security Vulnerabilities | Perforce].

Regressionstests sind eine Art von Tests, bei denen überprüft wird, ob eine zuvor getestete Software auch nach Änderungen noch korrekt funktioniert. Regressionstests können dazu beitragen, das erneute Auftreten von zuvor behobenen Fehlern zu verhindern, indem sie sicherstellen, dass diese keine neuen Fehler oder Nebenwirkungen verursachen. Die erste Empfehlung an das Unternehmen besteht darin, zu überprüfen, ob die vorhandene Regressionstestsuite angemessen ist, und sie bei Bedarf zu erweitern, um sicherzustellen, dass früher behobene Fehler in jedem nachfolgenden Build erneut getestet werden. Dies kann dazu beitragen, den Abdeckungsgrad und die Effektivität von Regressionstests zu verbessern und Regressionsfehler so früh wie möglich zu erkennen. Die Automatisierung bestehender Testsuiten kann ebenfalls dazu beitragen, den Zeit- und Arbeitsaufwand für Regressionstests zu verringern. Dies ist jedoch nicht die erste Empfehlung, da die Automatisierung möglicherweise nicht für alle Testfälle machbar oder kosteneffizient ist. Die Analyse der Produktmodule mit den meisten Fehlern und deren gründliche Prüfung und Behebung als einmalige Maßnahme kann ebenfalls dazu beitragen, die Fehlerdichte zu verringern und die Qualität dieser Module zu verbessern, doch ist dies nicht die erste Empfehlung, da die Ursache für das erneute Auftreten früher behobener Fehler nicht angegangen wird. Die Schulung oder der Austausch der Teams, die für die Entwicklung und das Testen der Module mit der höchsten Fehlerdichte verantwortlich sind, kann ebenfalls dazu beitragen, ihre Fähigkeiten oder ihre Leistung zu verbessern, aber dies ist nicht die erste Empfehlung, da dies möglicherweise nicht für alle Teams notwendig oder angemessen ist. Überprüfte Referenz: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 2, Seite 19; Kapitel 4, Seite 45.

Eine Inspektion ist eine Art von Überprüfung, die einem definierten Prozess mit formalen Eingangs- und Ausgangskriterien sowie Rollen und Verantwortlichkeiten für die Teilnehmer folgt. Eine Inspektion kann von Peers mit unterschiedlichen Rollen durchgeführt werden, z. B. als Moderator, Autor, Prüfer und Schreiber. Die folgende Aussage über eine Inspektion ist nicht zutreffend:
* B) Der Hauptzweck einer Inspektion besteht darin, Lösungen für die Probleme zu finden. Diese Aussage ist nicht zutreffend, da der Hauptzweck einer Inspektion darin besteht, Fehler oder Probleme in einem Arbeitsprodukt zu finden, und nicht, Lösungen für die Probleme zu finden. Die Suche nach Problemlösungen ist eine Fehlersuch- oder Problemlösungsaktivität, die normalerweise vom Autor oder Entwickler nach Erhalt des Inspektionsberichts durchgeführt wird. Die folgenden Aussagen über Inspektion sind wahr:
* A) Eine Inspektion kann von einem geschulten Moderator geleitet werden, der nicht der Autor sein darf. Diese Aussage ist zutreffend, da eine Inspektion eine Moderatorenrolle erfordert, die den Inspektionsprozess leitet und sicherstellt, dass er den Regeln und Normen entspricht. Der Moderator sollte in Inspektionstechniken geschult sein und nicht der Autor des zu inspizierenden Arbeitsprodukts sein, um Befangenheit oder Interessenkonflikte zu vermeiden.
* C) Eine Inspektion kann von Gleichrangigen durchgeführt werden. Diese Aussage ist richtig, da eine Inspektion ein Peer-Review beinhaltet, was bedeutet, dass das zu inspizierende Arbeitsprodukt von Personen bewertet wird, die ähnliche Aufgaben oder Fachkenntnisse wie der Autor haben, aber nicht direkt an der Erstellung oder Änderung des Arbeitsprodukts beteiligt sind.
* D) Eine Inspektion erfolgt nach einem formalen Verfahren auf der Grundlage von Regeln und Checklisten mit Eingangs- und Ausgangskriterien.
Diese Aussage ist richtig, denn eine Inspektion folgt einem formalen Prozess, der aus sechs Hauptschritten besteht:
Planung, Kick-off-Meeting, individuelle Vorbereitung, Review-Meeting, Nacharbeit und Follow-up. Für jeden Schritt gibt es definierte Regeln und Checklisten, um die Teilnehmer anzuleiten und Konsistenz und Qualität zu gewährleisten. Jeder Schritt hat außerdem Ein- und Ausstiegskriterien, um sicherzustellen, dass die Voraussetzungen und Ziele erfüllt sind, bevor man zum nächsten Schritt übergeht. Geprüfte Referenzen: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Kapitel 3, Seite 28-29.

* Die Aufwandsschätzung hängt nicht vom Budget des Projekts ab, sondern vom Umfang, der Komplexität und der Qualität des Softwareprodukts und der Testaktivitäten1. Das Budget ist eine Einschränkung, die sich auf die Durchführbarkeit und Genauigkeit der Aufwandsschätzung auswirken kann, aber es ist kein Faktor, der die Aufwandsschätzung bestimmt. Die Aufwandsschätzung ist der Arbeitsaufwand, der für die Durchführung der Testaktivitäten erforderlich ist, gemessen in Personenstunden, Personentagen oder Personenmonaten2.
* Die anderen Optionen sind richtig, weil:
* A. Sobald der Testaufwand abgeschätzt ist, können die Ressourcen ermittelt und ein Zeitplan erstellt werden, da dies miteinander verbundene Aspekte des Testplanungsprozesses sind3. Ressourcen sind die Personen, Werkzeuge, Geräte und Einrichtungen, die für die Durchführung der Testaktivitäten benötigt werden4. Der Zeitplan ist der Zeitrahmen und die Abfolge der Testaktivitäten, die mit den Meilensteinen und Terminen des Projekts abgestimmt sind5.
* B. Die Aufwandsschätzung kann ungenau sein, weil die Qualität des zu testenden Produkts nicht bekannt ist, da sie die Anzahl und Schwere der gefundenen Fehler und die zu ihrer Behebung erforderlichen Nacharbeiten beeinflusst6. Qualität ist der Grad, in dem das Softwareprodukt die festgelegten Anforderungen erfüllt und den Bedürfnissen und Erwartungen der Benutzer und Kunden entspricht7.
* D. Die erfahrungsbasierte Schätzung ist eine der Schätzungstechniken, die sich auf das Urteilsvermögen und das Fachwissen der Tester und anderer Projektbeteiligter stützt, um den Testaufwand auf der Grundlage ähnlicher Projekte oder Aufgaben aus der Vergangenheit zu schätzen. Die erfahrungsbasierte Schätzung kann nützlich sein, wenn es an historischen Daten, formalen Methoden oder detaillierten Informationen über das Softwareprodukt und die Testaktivitäten mangelt.
Referenzen =
* 1 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 154
* 2 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 155
* 3 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 156
* 4 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 157
* 5 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 158
* 6 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 159
* 7 ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 16
* [8] ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 160
* [9] ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, S. 161

Ein Testfall ist ein Satz von Eingabewerten, Ausführungsvoraussetzungen, erwarteten Ergebnissen und Ausführungsnachbedingungen, der für ein bestimmtes Ziel oder eine bestimmte Testbedingung entwickelt wurde. Ein Testfall ist eine Abfolge von Aktionen für die Testausführung, die von einem Tester oder einem Testautomatisierungswerkzeug befolgt werden kann. Ein Testfall wird während der Testimplementierungsaktivität spezifiziert, d. h. der Aktivität, die die für die Testdurchführung benötigte Testware vorbereitet. Ein Testfall enthält keine tatsächlichen Ergebnisse, da diese während der Testdurchführung ermittelt und mit den erwarteten Ergebnissen verglichen werden. Ein Testfall beschreibt keine zu testenden Elemente oder Ereignisse, da diese während der Testanalyse aus der Testbasis abgeleitet werden. Ein Testfall wird nicht während der Testentwurfsaktivität abgeleitet, da dies die Aktivität ist, die die Testbedingungen oder -ziele spezifiziert, die getestet werden müssen. Überprüfte Referenz: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 3, Seite 23-24; Kapitel 4, Seite 34.

Systemtests sind eine Ebene von Tests, die durchgeführt werden, um das Verhalten und die Qualität eines gesamten Softwareprodukts oder -systems zu bewerten. Systemtests können verschiedene Arten von Tests umfassen, wie z. B.:
* I) Gebrauchstauglichkeitstests: Eine Art von Test, bei dem bewertet wird, wie einfach, effizient und zufriedenstellend die Nutzung des Softwareprodukts oder -systems aus der Sicht des Nutzers ist.
* II) Anforderungsbasiertes Testen von Szenarien: Eine Art des Testens, bei der durch die Ausführung realistischer Szenarien oder Arbeitsabläufe überprüft wird, ob das Softwareprodukt oder -system die spezifizierten Anforderungen oder User Stories erfüllt.
Systemtests umfassen nicht die folgenden Arten von Tests, da sie eher für niedrigere Testebenen wie Unit-Tests oder Integrationstests geeignet sind:
* III) Testen von Teilen des Codes in Isolation: Eine Art des Testens, bei der die Funktionalität und Qualität einzelner Software-Komponenten oder -Einheiten überprüft wird, indem sie von anderen Komponenten oder Einheiten isoliert werden.
* IV) Korrekte Reihenfolge der Parameter in API-Aufrufen: Eine Art des Testens, bei der die Funktionalität und Qualität von Softwarekomponenten oder -einheiten, die über Anwendungsprogrammierschnittstellen (APIs) miteinander kommunizieren, durch Überprüfung der korrekten Reihenfolge und des Formats von Parametern in API-Aufrufen überprüft wird. Geprüfte Referenzen: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 2, Seite 20-21; Kapitel 4, Seite 34-35.

Erfahrungsbasierte Techniken (EBT) sind Techniken, die das Wissen, die Intuition und die Fähigkeiten der Testingenieure nutzen, um Tests zu entwerfen und durchzuführen. EBT verwenden Tests, die aus den früheren Erfahrungen der Testingenieure mit ähnlichen Technologien, Domänen, Anwendungen oder Systemen abgeleitet sind. EBT basieren nicht auf der Fähigkeit des Testingenieurs, verschiedene Testtechniken zu implementieren, sondern vielmehr auf seinem persönlichen Urteil und seiner Kreativität. EBT werden nicht als zweite Stufe des Testens durchgeführt, nachdem das nicht erfahrungsbasierte Testen stattgefunden hat, sondern eher als Ergänzung oder Alternative zu anderen Techniken. EBT erfordern ein breites und tiefes Wissen sowohl über das Testen als auch über die Anwendung oder den technologischen Bereich, da dies dem Testingenieur helfen kann, potenzielle Risiken, Szenarien oder Fehler zu erkennen. Geprüfte Referenzen: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Kapitel 5, Seite 48-49.

Ein Teststatusbericht sollte Folgendes enthalten: die Gesamtzahl offener und geschlossener Fehler, den tatsächlichen Arbeitsaufwand sowie die Anzahl der durchgeführten, fehlgeschlagenen und blockierten Tests. Ein Teststatusbericht ist ein Dokument, das Informationen über die Ergebnisse und den Status der Testaktivitäten für einen bestimmten Zeitraum oder eine bestimmte Phase enthält. Ein Teststatusbericht sollte Informationen enthalten, die für die vorgesehene Zielgruppe und den vorgesehenen Zweck relevant, genau und zeitnah sind. Einige der Informationen, die in einen Teststatusbericht aufgenommen werden sollten, sind: die Gesamtzahl der offenen und geschlossenen Fehler, die Aufschluss über den Fehlertrend und die Fehlerdichte des Softwareprodukts geben können; der tatsächliche Arbeitsaufwand, der Aufschluss über die Produktivität und Effizienz des Testprozesses geben kann; die Anzahl der durchgeführten, fehlgeschlagenen und blockierten Tests, die Aufschluss über den Testfortschritt und die Testabdeckung des Softwareprodukts geben können. Folgendes sollte nicht in einen Teststatusbericht aufgenommen werden: Schätzungsdetails, Fehlerberichte und Auswirkungsanalysen. Schätzungsdetails sind nicht Teil eines Teststatusberichts, sondern vielmehr Teil eines Testplans oder eines Testschätzungsdokuments. Schätzungsdetails liefern Informationen über die erwartete Zeit, die Ressourcen und die Kosten für Testaktivitäten, nicht über die tatsächlichen Ergebnisse oder den Status der Testaktivitäten. Fehlerberichte sind nicht Teil eines Teststatusberichts, sondern separate Dokumente, die detaillierte Informationen über einzelne während des Testens gefundene Fehler enthalten. Fehlerberichte enthalten Informationen wie Fehlerbeschreibung, Fehlerschwere, Fehlerpriorität, Fehlerstatus, Fehlerbehebung usw. Fehlerberichte können in einem Teststatusbericht referenziert oder zusammengefasst werden, sind aber nicht in vollem Umfang enthalten. Die Auswirkungsanalyse ist nicht Teil eines Teststatusberichts, sondern vielmehr Teil einer Risikobewertung oder eines Priorisierungsprozesses. Die Auswirkungsanalyse liefert Informationen über die möglichen Auswirkungen oder Folgen einer Änderung oder eines Fehlers auf das Softwareprodukt oder das Projekt.
Die Auswirkungsanalyse kann verwendet werden, um die Menge oder den Umfang der durchzuführenden Tests zu bewerten, aber nicht, um die Ergebnisse oder den Status der Testaktivitäten zu melden. Geprüfte Referenzen: Ein Studienführer zum ISTQB Foundation Level
2018 Syllabus - Springer, Seite 141.

Der grundlegende Testprozess des ISTQB besteht aus fünf Hauptphasen, wie im ISTQB Foundation Level Syllabus, Version 4.0, 2018, Abschnitt 2.2, Seite 15 beschrieben:
* Testplanung und -steuerung: Diese Phase umfasst die Festlegung der Testziele, des Umfangs, der Strategie, der Ressourcen, des Zeitplans, der Risiken und der Messgrößen sowie die Überwachung und Steuerung der Testaktivitäten und -ergebnisse während des gesamten Testprozesses.
* Testanalyse und -entwurf: In dieser Phase wird die Testbasis (z. B. Anforderungen, Spezifikationen oder User Stories) analysiert, um Testbedingungen (z. B. Merkmale, Funktionen oder Szenarien) zu identifizieren, die getestet werden müssen, und es werden Testfälle und Testverfahren (z. B. Eingaben, erwartete Ergebnisse und Ausführungsschritte) entworfen, um die Testbedingungen abzudecken. Diese Phase umfasst auch die Bewertung der Testbarkeit der Testbasis und der Testelemente (z. B. Software- oder Systemkomponenten) sowie die Auswahl und Implementierung von Testtechniken (z. B. Äquivalenzpartitionierung, Grenzwertanalyse oder Zustandsübergangstests), um die Testziele zu erreichen und die Testabdeckung und -effizienz zu optimieren.
* Testimplementierung und -durchführung: In dieser Phase werden die Testumgebung (z. B. Hardware, Software, Daten oder Werkzeuge) und die Testware (z. B. Testfälle, Testverfahren, Testdaten oder Testskripte) für die Testdurchführung vorbereitet und die Testverfahren oder Skripte entsprechend dem Testplan und dem Zeitplan ausgeführt. In dieser Phase werden auch die Ergebnisse der Testdurchführung protokolliert, die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen verglichen und etwaige Abweichungen als Vorfälle (wie Defekte, Fehler oder Ausfälle) gemeldet.
* Auswertung der Abschlusskriterien und Berichterstattung: In dieser Phase wird überprüft, ob die geplanten Testaktivitäten abgeschlossen und die Ausstiegskriterien (z. B. Qualität, Abdeckungsgrad oder Risiko) erfüllt wurden, und die Testergebnisse werden den Beteiligten mitgeteilt. In dieser Phase werden auch Empfehlungen für die Freigabe- oder Abnahmeentscheidung auf der Grundlage der Testergebnisse ausgesprochen und etwaige Restrisiken (z. B. bekannte Fehler oder nicht getestete Bereiche) identifiziert, die behoben oder gemindert werden müssen.
* Testabschlussaktivitäten: In dieser Phase werden die Testsoftware und die Testumgebung für eine spätere Wiederverwendung fertiggestellt und archiviert, und der Testprozess und das Testprojekt werden anhand der Testziele und des Testplans bewertet. In dieser Phase werden auch die Erfahrungen und bewährten Verfahren ermittelt und die Ergebnisse und Verbesserungsvorschläge an die zuständigen Stellen weitergeleitet.
Referenzen = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Abschnitt 2.2, Seite 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, Seiten 37-38; ISTQB CTFL 4.0 - Sample Exam - Answers, Version 1.1, 2023, Frage 88, Seite 32.

Die Frage zielt darauf ab, ein Beispiel dafür zu finden, wie das Testen zu einer höheren Qualität beiträgt. Qualität ist der Grad, in dem eine Komponente, ein System oder ein Prozess die festgelegten Anforderungen und/oder die Bedürfnisse und Erwartungen der Benutzer/Kunden erfüllt1. Testen ist der Prozess, der aus allen statischen und dynamischen Lebenszyklusaktivitäten besteht, die sich mit der Planung, Vorbereitung und Bewertung von Softwareprodukten und verwandten Arbeitsprodukten befassen, um festzustellen, ob sie die spezifizierten Anforderungen erfüllen, um zu zeigen, dass sie für den Zweck geeignet sind, und um Fehler zu entdecken2.
Daher trägt das Testen zu einer höheren Qualität bei, indem es verifiziert und validiert, dass die Softwareprodukte und die zugehörigen Arbeitsprodukte die spezifizierten Anforderungen erfüllen, zweckmäßig sind und keine oder zumindest eine geringere Anzahl von Fehlern aufweisen. Testen liefert auch Informationen über die Qualität der Softwareprodukte und der zugehörigen Arbeitsprodukte für die Beteiligten, die auf der Grundlage der Testergebnisse fundierte Entscheidungen treffen können3.
Von den vier gegebenen Aussagen ist nur Option D ein Beispiel dafür, dass das Testen zu einer höheren Qualität beiträgt, da sie zeigt, dass das Testen einen Fehler (einen Fehler in einer Komponente oder einem System, der dazu führen kann, dass die Komponente oder das System die erforderliche Funktion nicht erfüllt4) entdeckt hat und dass der Fehler vor der Freigabe (Auslieferung des Softwareprodukts an den Kunden oder Endbenutzer) behoben (behoben und bestätigt) wurde. Das bedeutet, dass das Testen verhindert hat, dass ein potenzieller Fehler (ein Ereignis, bei dem eine Komponente oder ein System eine erforderliche Funktion nicht innerhalb bestimmter Grenzen erfüllt) in der Betriebsumgebung auftritt, und somit die Qualität des Softwareprodukts verbessert hat.
Option A ist kein Beispiel dafür, dass Testen zu einer höheren Qualität beiträgt, da es sich um eine Berichtsaktivität handelt, die die Testergebnisse zusammenfasst und die Testziele bewertet, aber keinen direkten Einfluss auf die Qualität des Softwareprodukts oder damit verbundener Arbeitsprodukte hat. Ein zusammenfassender Testbericht ist ein Dokument, das die Ergebnisse von Testaktivitäten aufzeichnet und kommuniziert, einschließlich Testabschlusskriterien, Testergebnisse, Berichte über Zwischenfälle, Testzusammenfassung und -auswertung sowie gewonnene Erkenntnisse.
Option B ist kein Beispiel dafür, dass Testen zu einer höheren Qualität beiträgt, da es sich dabei um eine Planungsaktivität handelt, bei der die für Testaktivitäten benötigten Ressourcen und die dafür benötigte Zeit geschätzt werden, die sich jedoch nicht direkt auf die Qualität des Softwareprodukts oder damit verbundener Arbeitsprodukte auswirkt. Eine Schätzung des Testaufwands ist ein Näherungswert für den Arbeitsaufwand und/oder die Zeitdauer, die für die Durchführung von Testaktivitäten erforderlich ist.
Option C ist kein Beispiel dafür, dass Testen zu einer höheren Qualität beiträgt, da es sich um eine Vorbereitungsaktivität handelt, die die Testumgebung einrichtet (eine Umgebung, die Hardware, Instrumente, Simulatoren, Softwaretools und andere für die Durchführung eines Tests benötigte Unterstützungselemente enthält), aber keinen direkten Einfluss auf die Qualität des Softwareprodukts oder der damit verbundenen Arbeitsprodukte hat. Eine Testumgebungsinstallation ist ein Prozess der Installation und Konfiguration der Testumgebung gemäß der Testumgebungsspezifikation.
Referenz:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 10
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 11
3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 12
4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 13
5: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 13
6: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 77
7: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 78
8: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 79
9: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 80
10: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 81
11: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 82
12: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 83
13: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 84
14: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 85
15: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 86
16: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 87
17: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 88
18: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 89
19: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 90
20: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 91
21: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 92
22: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 93
23: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 94
24: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 95
25: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 96
26: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 97
27: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 98
28: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 99
29: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 100
30: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 101
31: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 102
32: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 103
33: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 104
34: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 105
35: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 106
36: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, S. 107

* In der Frage geht es um die Auswahl der richtigen Testwerte für x auf der Grundlage der Äquivalenzaufteilung.
Die Äquivalenzpartitionierung ist eine Technik des Softwaretestdesigns, die die Eingabedaten einer Softwareeinheit in Partitionen äquivalenter Daten unterteilt, aus denen Testfälle abgeleitet werden können. In diesem Fall sind die gegebenen Äquivalenzklassen:
* (x \leq -100)
* (-100 < x < 100)
* (100 \leq x < 1000)
* (x \geq 1000)
Option D liefert einen Wert aus jeder dieser Partitionen:
* Für (x \leq -100) ergibt sich -1000.
* Für (-100 < x < 100) ergibt sich -100 und 100.
* Für (100 \leq x < 1000) ergibt sich 500.
* Für (x \geq 1000) ergibt sich 1500.
Option D deckt also alle vier gegebenen Äquivalenzklassen mit entsprechenden Werten ab.
Referenzen: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Dokumente erhältlich bei ISTQB und ASTQB.
* 1: ISTQB Foundation Level Syllabus 2018, Version 4.0, S. 38
* 2: ISTQB Foundation Level Syllabus 2018, Version 4.0, S. 39
* : ISTQB Foundation Level Syllabus 2018, Version 4.0, S. 40