c2b_default

ISTQB Syllabus - Advanced Level (Testmanager)

Diese Kartei enthält die wichtigsten Fragestellungen und das Grundwissen zum ISTQB Testmanager Die Fragestellungen basieren auf den aktuellen ISTQB Syllabus aus dem Jahr 2012 Erstellung: 10.10.2016 Letzte Änderung: 10.10.2016

Diese Kartei enthält die wichtigsten Fragestellungen und das Grundwissen zum ISTQB Testmanager Die Fragestellungen basieren auf den aktuellen ISTQB Syllabus aus dem Jahr 2012 Erstellung: 10.10.2016 Letzte Änderung: 10.10.2016

117
0.0 (0)

Fichier Détails

Cartes-fiches 117
Utilisateurs 20
Langue Deutsch
Catégorie Informatique
Niveau Autres
Crée / Actualisé 10.10.2016 / 16.12.2024
Lien de web
https://card2brain.ch/box/istqb_advanced_level_testmanager
Intégrer
<iframe src="https://card2brain.ch/box/istqb_advanced_level_testmanager/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
Étudier

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Was werden bei statischen Tests direkt aufgedeckt ?

Fehlerzustände

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Warum sind die Kosten für die Fehlerbeseitigung nach den statischen Tests niedriger ?

  • ... weil keine Debugging-Aktivitäten anfallen, um die Fehlerzustände zu lokalisieren.

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Welcher Gruppe werden die folgenden Testaktivitäten wie z.B. Modultests, Integrationstests und Systemtests zugeordnet ?

dynamische Testaktivitäten

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Wann spricht man von einer Fehlerwirkung bei den dynamischen Testaktivitäten, wie z.B. Modultests, Integrationstests und Systemtests ?

  • wenn eine Diskrepanz zwischen den tatsächlichen und den erwarteten Testergebnissen vorliegt.
    d.h. eine Anomalie) erkannt wird.

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Was ist in Bezug auf eine Fehlerwirkung mit einem falsch negativen Ergebnis gemeint ?

  • wenn ein Tester die Anomalie nicht bemerkt.

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Was sollte ein Tester im Fall einer Anomalie (Fehlerwirkung) als erstes tun ? 

  • der Tester sollte mit dem Erstellen eines Fehlerberichts beginnen

Die Situation muss genauer untersucht werden.

4.2 Fehlerlebenszyklus und Softwarelebenszyklus:
Bei welcher Entwicklungs-Methode werden Entwurfsspezifikationen für automatisierte Komponententests verwendet ?

  • bei einer testgetriebenen Entwicklung

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was wird in den meisten Testorganisationen für das Management der Fehlerberichte im gesamten
Fehlerlebenszyklus eingesetzt ? 

  • Es wird ein entsprechendes Werkzeug (Fehler-Workflow-Werkzeug) eingesetzt.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was hat ein Fehlerbericht während eines Fehlerlebenszyklus ?

  • einen typischen Ablauf, in dem eine Reihe von Zuständen (Status) durchläuft.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Für die meisten der Fehlerberits-Zustände (Status) gibt es einen klar Zuständigen. Was sind seine Aufgaben hierbei ?

  • ... er ist für Durchführung der erforderlichen Maßnahme(n) verantwortlich
  • ... sobald diese vollendet sind, ist er für den Übergang in den nächsten Status veranlasst

beim letzten Schritt ist der Nächste für die weiteren Massnahmen verantwortlich.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Wieso hat der Fehlerbericht im Endstatus keinen Eigentümer mehr ?

  • ... weil keine weiteren Maßnahmen mehr erforderlich sind.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
In seinem Endstatus ist der Fehlerbericht in folgenden Stati:

  • geschlossen (Fehlerzustand behoben, durch Fehlernachtest erfolgreich verifiziert worden).
  • storniert (Fehlerbericht ungültig), 
  • nicht reproduzierbar (nicht mehr beobachtet werden kann).
  • zurückgestellt (Anomalie reproduzierbar, dieser wird während des laufenden Projekts jedoch nicht behoben).

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Bei Fehlerzuständen, die Tester im Test gefunden haben, gibt es typischerweise drei Status im
Verantwortungsbereich des Testteams. Es sind dies die folgenden:

  • Anfangsstatus
  • Zurückgewiesen
  • Fehlernachtest

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was für Tätigkeiten müssen ein oder mehrere Tester wahrnehmen, damit die zuständige Person den Fehlerbericht im Anfangsstatus (offener, neuer) übernhemen können ?

  • ... sie sammeln Informationen, damit die Fehlewirkung reproduziert werden kann.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was sind meist die Gründe für einen zurückgewiesenen Fehlerbericht ?

  • Einforderung von zusätzlichen Informationen
  • Fehlerhafte Erfassung
  • Fälschliche Erfassung (Feature)

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Wieso sollte ein Testmanager die Anzahl der zurückgewiesenen Fehlerberichte im Auge behalten ?

  • Zeigen Defizite auf: 
    • Die Tests wurden nicht genau durchgeführt
    • anfängliche Informationssammlung zu ungenügend

Aus diesem Grund sollte die Anzahl der Zurückweisungen nicht überhand nehmen.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was muss der zuständige Tester beim Erhalt eines Fehlerberichts in Status Fehlernachtest tun ?

  • Durchführung des Fehlernachtests
    • ... er hält sich beim Reproduzieren der Fehlerwirkung an die im Fehlerbericht beschriebenen Schritte

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was ist beim erfolgreichen Fehlernachtest durch den Tester zu tun ?

  • Fehlerbericht schliessen

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was ist bei einem fehlgeschlagenen Fehlernachtest durch den Tester zu tun ?

  • Fehlerbericht wieder öffnen.

4.2.1 Fehler-Workflow und Status von Fehlerzuständen:
Was geschieht, wenn ein Tester nach fehlgeschlagenem Fehlernachtest den Fehlerbericht wieder öffnet ?

  • Der Fehlerbericht geht an den früheren Eigentümer zurück, dieser muss notwendigen Massnahmen ergreifen um den Fehlerzustand zu reparieren.

4.2.2 Ungültige und doppelte Fehler managen:
Eine Anomalie muss nicht als Auswirkung eines Fehlerzustands auftreten. Welches sind mögliche Gründe hierfür ?

  • Probleme bei:
    • Testumgebung
    • Testdaten
    • irgendeinem Artefakt
    • Testmittel
  • Tester hat was falsch verstanden

4.2.2 Ungültige und doppelte Fehler managen:
Was ist ein "falsch positives Ergebnis" im Zusammenhang mit Fehlerberichten ?

  • ... wenn sich der Fehlerbericht nicht auf einen Fehlerzustand in einem zu testenden Arbeitsergebnis bezieht.

4.2.2 Ungültige und doppelte Fehler managen:
Was wird meist gemacht, wenn ein "falsch positives Ergebnis" in Zusammenhang mit Fehlerberichten vorliegt ?

  • Der Fehlerbericht wird:
    • storniert
    • geschlossen

4.2.2 Ungültige und doppelte Fehler managen:
Was wird gemacht, wenn zwei oder mehrere Fehlerberichte die selbe Grundursache haben ?

  • einer der Fehlerberichte wird behalten
    • der oder die Anderen werden auf den ersten Fehlerbericht referenziert und geschlossen.

4.2.2 Ungültige und doppelte Fehler managen:
Ungültige und doppelte Fehlerberichte sind zwar ein Indikator für ein gewisses Maß an Ineffizienz, sie
lassen sich jedoch nicht gänzlich vermeiden. Sollten diese vom Testmanager akzeptiert werden?

Ja

4.2.2 Ungültige und doppelte Fehler managen:
Was geschieht, wenn Manager versuchen ungültige und doppelte Fehlerberichte komplett auszuschließen ?

  • ... die Zahl der "falsch negativen Ergebnisse" erhöht sich.
  • ... die Tester werden davon abgehalten Fehlerberichte zu erstellen.
  • ... die Effektivität bei der Fehlerfindung verringert sich (negativ für das Unternehmen und die Testorganisation)

4.2.3 Übergreifendes Fehlermanagement:
Wer ist normalerweise Eigentümer des gesamten Fehlermanagementprozesses und des Fehlermanagementwerkzeugs ?

  • Testmanager
  • Testorganisation

4.2.3 Übergreifendes Fehlermanagement:
Es kann in gewissen Projekten ein übergreifendes Team für das Management der berichteten Fehlerzustände zuständig sein. Welche Rollen sind meist Teil eines solchen übergreifendes Team (Fehlermanagement-Ausschuss oder Fehler-Triage-Ausschuss) ?

  • Testmanager
  • Stakeholder aus Entwicklung
  • Projektmanagement
  • Produktmanagement
  • sonstige Stakeholder, die ein Interesse an der Software haben, die entwickelt wird.

4.2.3 Übergreifendes Fehlermanagement:
Wie lauten mögliche Bezeichnungen eines übergreifenden Teams das für das Management der berichteten Fehlerzustände zuständig ist ?

  • Fehlermanagement-Ausschuss 
  • Fehler-Triage-Ausschuss

4.2.3 Übergreifendes Fehlermanagement:
Was sind die Aufgaben eines "Fehlermanagement-Ausschusses" oder "Fehler-Triage-Ausschusses" ?

  • ... er sollte:
    • regelmäßig oder in kritischen Fehlerfällen sofort zusammentreffen
    • bestimmen, ob der Fehlerbericht auf Fehlerzustände hinweist
    • bestimmen, ob Fehlerzustände behoben oder zurückgestellt werden müssen.

4.2.3 Übergreifendes Fehlermanagement:
Welche Punkte muss ein der Fehlermanagement-Ausschuss bei der Entscheidung in Zusammenhang mit der Beseitigung bzw. der Nichtbeseitigung der Fehlerzustände berücksichtigen ? 

  • Nutzen
  • Risiken
  • Kosten

4.2.3 Übergreifendes Fehlermanagement:
Wer kann den Fehlermanagement-Ausschuss bei Einschätzung der relativen Wichtigkeit eines Fehlerzustands kompetent Auskunft geben und objektive Informationen zur Verfügung stellen ?

  • Testmanager
  • Testteam

4.2.3 Übergreifendes Fehlermanagement:
Das Testteam und der Testmanager können dem Fehlermanagement-Ausschuss zur Seite stehen. 
Bei welchen Fragestellungen können sie unter anderem Unterstützung bieten ?

  • ... bei der Einschätzung der relativen Wichtigkeit eines Fehlerzustands 
  • ... objektive Informationsbeschaffung

4.2.3 Übergreifendes Fehlermanagement:
Welche sind die drei unerlässlichen Eckpfeiler für ein effektives und effizientes Fehlermanagement ?

  • Kommunikation
  • geeignete Werkzeugunterstützung
  • ein engagierter Fehlermanagement-Ausschuss

4.2.3 Übergreifendes Fehlermanagement:
Kann ein Fehlerverfolgungswerkzeug eine gute Kommunikation ersetzen ?

Nein

4.2.3 Übergreifendes Fehlermanagement:
Können die Besprechungen des Fehlermanagement-Ausschusses ein Ersatz sein für die effektive Verwendung eines guten Fehlerverfolgungswerkzeugs ?

Nein

4.3 Informationen im Fehlerbericht bzw. Fehlermeldung:
Was sollte der/die Zuständige(n) tun, wenn während eines statischen Tests ein Fehlerzustand oder während eines dynamischen Tests eine Fehlerwirkung beobachtet wird ?

  • Sammeln von kohärenten Daten welche in den Fehlerbericht aufgenommen werden müssen.

4.3 Informationen im Fehlerbericht bzw. Fehlermeldung:
Wozu dienen die gesammelten Daten/Informationen, welche im Fehlerbericht enthalten sind ?

  • Management des Fehlerberichts im gesamten Fehlerlebenszyklus
  • Bewertung des Projektstatus 
    • besonders hinsichtlich Produktqualität und Testfortschritt
  • Bewertung der Prozessreife

4.3 Informationen im Fehlerbericht bzw. Fehlermeldung:
Wieso sollten die gesammelten Daten/Informationen bezüglich eines Fehlerberichts projektübergreifend konsistent sein ?

  • ... um einen aussagekräftigen Vergleich von Fehlerdaten aller Projekte zu ermöglichen.

4.3 Informationen im Fehlerbericht bzw. Fehlermeldung:
Wie sollten die wesentlichen Daten/Informationen, welche im Laufe des Lebenszyklus gesammelt werden strukturiert sein ?

einheitlich

Étudier