Archiv für den Autor: Christian Alexander Graf

Über Christian Alexander Graf

Christian Alexander Graf hat Mathematik in Saarbrücken studiert und ist als freiberuflicher Berater und Trainer tätig. Seine Schwerpunkte liegen in der Qualitätssicherung, Datenanalyse und der Entwicklung von Test- und Prüfstrategien. Neben seiner Tätigkeit für die Industrie unterrichtet der Autor an verschiedenen Hochschulen und engagiert sich in Organisationen wie dem VDI, der American Statistical Association und dem ASQF.

Risikotypen und der Softwaretest

Indiana Jones oder Black Widow wirken auf viele Menschen faszinierend und anziehend. Als Charaktere in Filmen, Videospielen (oder als explorative Tester) schätzen wir sie: Die Risikotypen.
Weniger jedoch, wenn es um unsere Software und unsere Projekte geht.
Um diese zweite Art von Risikotypen geht es in diesem Beitrag. Oder anders: Wie lassen sich Risiken erfolgreich beschreiben?

Fangen wir also einfach von vorne an.

 

Definition des Risikobegriffs

Die ISO 31000:2018 definiert den Begriff Risiko in freier Übersetzung als ‚Auswirkung von Unwägbarkeiten auf ein erwünschtes Ziel bzw. Ergebnis (‚effect of uncertainty on objectives‘).

Die Auswirkung kann daher gleichwohl wünschenswerter Natur sein als auch eine Bedrohung darstellen. So spricht man z.B. im Glückspiel von einer riskanten Strategie, wenn ein Spieler ein Vorgehen wählt, bei dem er mit hoher Wahrscheinlichkeit verliert, aber im Falle des Erfolgs mit einem sehr hohen Gewinn den Spieltisch verlässt.
Nach ISO lässt sich ein Risiko durch 4 Faktoren recht gut charakterisieren:

  • Die Quelle des Risikos – z.B. ein Materialfehler oder ein Fehler in einem Computer-Programm. Im Falle des Glückspiels könnten das die Spielregeln oder gezinkte Würfel sein.
  • ein (auslösendes) Ereignis – z.B. eine mechanische Belastung einer fehlerhaften Stelle oder die Nutzung einer bestimmten Programmfunktionalität. Im Glücksspiel ist das z.B. der Wurf des Würfels und das Setzen auf ein bestimmtes Ergebnis.
  • Die möglichen Folgen des Ereignisses – z.B. die Zerstörung eines Bauteils, ein Programmabsturz oder ein finanzieller Verlust oder Gewinn. Mögliche Folgen können quantitativ oder einfach qualitativ (also auf einer Rangskala z.B. von marginal bis katastrophal) erfasst werden.
  • Eine Beschreibung oder Bewertung der Wahrscheinlichkeit (im Sinne von engl. likelihood), mit der einer oder alle der anderen beschreibenden Faktoren (Quelle, auslösendes Ereignis, Eintreten des Schadens) zutreffen. Diese Beschreibung muss nicht notwendigerweise mathematisch sein. Wahrscheinlichkeit ist lt. ISO-Anmerkungen als Wahrscheinlichkeit im Weitesten Sinne zu verstehen. Nach Duden ist das etwas, was es erlaubt „den Grad der Möglichkeit des Eintretens bzw. der Voraussagbarkeit eines Ereignisses“ zu beschreiben.
    Eine Beschreibung der Wahrscheinlichkeit kann mithin über ein mathematisches Modell erfolgen – oder aber auch unter Zuhilfenahme einer einfachen Rangskala.

 

Risikostufen und Risikoarten

Risiken können nach Eigenschaften der sie bestimmenden Faktoren (z.B. der vier aus der ISO 31000) in Klassen (Kategorien) oder Stufen eingeteilt werden.

Beispiele:

  • Der Ausgang eines Glücksspiels wirkt sich positiv oder negativ auf die Finanzen des Spielers aus, mithin haben wir es mit einem finanziellen Risiko zu tun.
  • Nutzen Mitarbeiter einer Firma einen Firmenrechner für private Zwecke, kann dies die Sicherheit der Firmen-IT beeinträchtigen und stellt damit ein IT-Sicherheitsrisiko dar.
  • Hängt ein Risiko mit Ereignissen wie Krieg, Sturmfluten oder Erdbeben zusammen wird das gerne als ‚höhere Gewalt‘ zusammengefasst.

Die Begriffe Risikostufe und Risikokategorie sind in der ISO 31000 nicht besprochen, da diese Art der Einstufung branchen- oder sogar produktspezifisch ist. Sie sind Gegenstand von entsprechenden Industrienormen wie z.B. der ISO 26262.

Wann von Risikostufen und wann von Risikokategorien oder -arten gesprochen werden sollte, ist nicht klar geregelt. Beziehen sich die Klasseneinteilungen auf Bewertungen der Schadenshöhe und/oder betrachteten Wahrscheinlichkeiten spricht man typischerweise von Risikostufen. Eine Stufeneinteilung ist aber gleichzeitig eine Kategorisierung. Risikostufen sind damit eine Untermenge der Risikokategorien bzw. Risikoarten.

 

Der Risikobegriff im Certified Tester

Der ISTQB Certified Tester definiert Risiko als (vgl. ISTQB-GTB-Standardglossar, v3.2) „einen Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit.

Da neben dem ‚Faktor‘, Schadensausmaß und Eintrittswahrscheinlichkeit zwei weitere Faktoren sind (man zähle nach – das sind schon drei), widerspricht die Definition sich selbst und ist in der Praxis nicht anwendbar.

Man kann sich das auch an einem einfachen Beispiel klar machen:

  1. Wenn ich einen Gasherd einschalte, kann ich mir die Hand verbrennen.
  2. Wenn ich einen Gasherd einschalte, kann er explodieren.
  3. Wenn ich einen heißen Topf anfasse, kann ich mir die Hand verbrennen.

Wähle ich naiv den einen Faktor, der das Risiko ausmacht, so kann ich zu dem Schluss kommen, dass Situation 1 und 2 oder Situation 1 und 3 jeweils dasselbe Risiko beschreiben (Herd einschalten – Herd einschalten, Hand verbrennen – Hand verbrennen).

Eine sinnvolle Charakterisierung eines Risikos braucht daher mindestens zwei Faktoren: Eine Beschreibung einer Ursache und eine Beschreibung einer Wirkung.

In diesem Beitrag wird daher der Begriff Risiko nach ISO 31000 verwendet.

Hinweis für die Praxis: Bereits beim Sammeln (Identifizieren) von Risiken hilft es, diese mit Hilfe der Satzschablone „Wenn <Quelle/Ereignis> … dann <Wirkung/Schaden>.“ zu formulieren.

Diese Methodik hat außerdem einen vorteilhaften Seiten-Effekt: Hat man erst einmal Risikoquelle oder -ereignis (Ursache) und die Auswirkung klar beschrieben, lassen sich auch das Schadensausmaß und die Eintrittswahrscheinlichkeit viel leichter diskutieren und einschätzen.

 

Der Begriff der Risikokategorie (Risiko-Art, Risikotyp) ist im Certified Tester wie folgt definiert: „Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen.
Das kommt dem Geist der ISO 31000 sehr nahe und wird hier übernommen.

 

Produkt- und Projektrisiken

Das ISTQB-GTB-Standardglossar, v3.2 bezeichnet das Produktrisiko als „Ein Risiko, das die Qualität eines Produktes beeinträchtigt“ und ein Projektrisiko als „Ein Risiko, das den Projekterfolg beeinträchtigt“.

Dazu betrachten wir zwei Risiken:

  1. Wenn das Benutzerinterface nicht auf seine Zugänglichkeit geprüft wird, kann es sein, dass sehbehinderte Menschen nicht mit dem Produkt arbeiten können.
  2. Wenn das Benutzerinterface nicht auf seine Zugänglichkeit geprüft wird, kann es sein, dass das Produkt im Abnahmetest durchfällt.

Wir haben zwei Risikokategorien. Im ersten Fall ein Produktrisiko, nämlich ein Produkt, das (vielleicht) von einer Personengruppe nicht verwendet werden kann.

Im zweiten Fall haben wir ein Projektrisiko, nämlich das (vielleicht) verpasste wichtigste Projektziel: Die Abnahme.

 

Eine alternative Sicht auf Produkt- und Projektrisiken

Die hohe Kunst ist es, die Zusammenhänge von Projekt- und Produktrisiken zu verstehen und abzubilden. Die obige Definition erfordert für manche Produktrisiken Projekt-Maßnahmen und für andere Testmaßnahmen. Besser wäre eine Unterscheidung, die bereits klar zuordnet, ob Aktionen auf Testebene oder auf Projektebene erfolgen müssen.

Z.B. sind fehlende Kenntnisse über barrierefreies Design oder verwendete Technologien bei Entwicklern, Analysten oder Testern zunächst Projektrisiken. Diesen kann ein Projektleiter mit organisatorischen Maßnahmen wie Ausbildung und Expertenbeistand entgegenwirken. Zusätzlich ergibt sich häufig ein mit dem Projektrisiko verknüpftes Produktrisiko, dass der Testmanager durch geeignete Testmaßnahmen absichern muss.

Die folgend skizzierte strengere Definition von Produkt- und Projektrisiko illustriert, wie die Unterscheidung zwischen Prozess- und Produkt-Faktoren vorgenommen und zur Identifikation geeigneter Maßnahmen im Test als auch auf Projekt-Ebene genutzt werden kann.

 

Dazu zieht man folgende verfeinerte Kategorisierung heran:

  1. Liegt die Quelle des Risikos im Produkt inkl. Artefakten (Anforderungen, Design, möglicher Fehlerzustand) und entstehen negative Folgen beim Einsatz des Produktes, dann kann er dem mit einer geeigneten Testaktivität begegnen: Das sei fortan das Produktrisiko.
  2. Liegt die Risikoquelle und/oder das auslösende Ereignis in der Projektorganisation (z.B. ein ungeeigneter Prozess, schlecht ausgebildete Mitarbeiter usw.) und wirkt sich das Risiko auf den Projekterfolg (Zeitplan, Budget, Projektergebnis – in punkto Test z.B. die erreichbare Testüberdeckung), muss er in der Projektorganisation aktiv werden. Das sei nun das Projektrisiko.

Ein Risiko wird durch mehrere Faktoren charakterisiert – z.B. Ursache und Wirkung. Fällt ein Risiko in die linke Spalte, handelt es sich um ein Produktrisiko und eine Testmaßnahme kann helfen. Fällt das Risiko in die rechte Spalte ist projekt-politisches Geschick gefragt.

Im Beispiel des fehlenden Zugänglichkeits-Tests aus dem vorangegangenen Abschnitt ist Nummer 2 nach der strengeren Einteilung ebenfalls ein Projektrisiko.

Um die Frage zu beantworten, ob und welche Tests dabei sinnvoll sind, müssen die zugehörigen Produktrisiken genauer erfasst werden.

Die bisherige Formulierung von Risiko 1 reicht dazu nicht aus. Als Produktrisiko nach der neuen Definition taugt es nicht viel, auch wenn es die ursprüngliche Definition erfüllt. Es erfüllt ja nicht die zweite, enger gefasste Definition dieses Abschnitts – denn die Ursache liegt nicht im Produkt.

Eine weitere Analyse könnte z.B. zur folgenden Erkenntnis führen:

1‘. Wenn in Anforderungsdokumenten die Verwendung nicht-barrierefreier Anzeige-Formate vorgesehen ist, können sehbehinderte Menschen nicht mit dem Produkt (oder Teilen davon) arbeiten.

Hierzu kann der Testmanager Testmaßnahmen vom Anforderungs- über ein Designreview und statische oder dynamische Analysen bis hin zum explorativen Test festlegen. Ob und wieviel hängt natürlich von der Einstufung des Risikos und den weiteren Test- und Projektgegebenheiten ab.

 

Zusammenfassung

Das Kochrezept lautet zusammengefasst:

  • Jedes Risiko klar durch Angabe von Ursache und Wirkung formulieren – z.B. als ‚wenn … dann …‘ Satz.
  • Gehört ein Risiko eindeutig in die linke Spalte (Produkt), kann dem Risiko (u.a.) mit einer Testmaßnahme begegnet werden.
  • Gehört ein Risiko eindeutig in die rechte Spalte (Projekt), ist (wenn das Risiko nicht akzeptabel ist) eine organisatorische Maßnahme im Projekt erforderlich.
  • Passt das Risiko in keine der Spalten muss es weiter analysiert, genauer gefasst und ggf. weiter aufgeteilt werden.

Danach können für die identifizierten Risiken dann leichter Eintrittswahrscheinlichkeit und Schadensausmaß bewertet und geeignete Beherrschungs-Maßnahmen identifiziert werden.

 

Autor: Christian Alexander Graf, 10.06.2020

Nachtrag vom 11.06.2020:

Die in den beiden letzten Abschnitten diskutierten Ideen orientieren sich an den Definitionen des Projektrisikos nach ISO/IEC/IEEE 29119-1:2013 Software and systems engineering–Software testing–Part 1 und Part 3.
Hier werden Produkt- und Projektrisiko wie folgt definiert:

  1. Produktrisiko: ‚Risiko, dass ein Produkt einen Defekt in spezifischen Aspekten im Hinblick auf Funktionalität, Qualität oder Struktur aufweist.
  2. Projektrisiko: ‚Risiko im Zusammenhang mit dem Projektmanagement‘

Aktuelle Begriffs-Definitionen von IEEE und ISO rund um das Thema Software-Engineering können auf der Webseite https://pascal.computer.org/sev_display/index.action abgerufen werden.

Wie man eine Multiple-Choice (MC) Prüfung hackt

Es gibt die Theorie, es gibt die Praxis und –
es gibt die Multiple Choice Prüfung

Egal welches Thema – ob Requirements-Engineering, Softwaretest, Agile Vorgehensweisen, IT-Security, Data Analytics, KI und vieles mehr – vielleicht haben Sie in einem der Bereiche mehr als 10 Jahre Berufserfahrung.
Oder Sie haben ein paar tolle Bücher dazu gelesen oder ein Seminar besucht und einiges an praktischen Übungen hinter sich.

Und jetzt sagt irgendwer (vielleicht ja auch Sie selber): Sie müssen Ihre Fähigkeiten mit einem Zertifikat nachweisen können.
Das Zertifikat, gibt es natürlich erst nach Bestehen einer Multiple-Choice-Prüfung (+ Einwurf kleiner Münze).

Schließlich sitzen Sie in der Prüfung. Die Fragen scheinen so gar nichts mit dem zu tun zu haben, was Sie aus den Büchern, dem Kurs oder der Praxis kennen.
Nach der Prüfung unterhalten Sie sich mit anderen Prüflingen und stellen fest – denen ging es genauso. Bei einigen (oder allen) Fragen wusste keiner so recht, wie er die mit seinem Fachwissen angehen sollte.

Das ist kein Wunder! MC-Tests haben ihre eigenen Regeln und Besonderheiten.
Nach meiner Erfahrung gehören darum zum Bestehen eines MC-Tests:

  1. Fachwissen
  2. Eine gute Prüfungsstrategie.
Tipps für den MC-Test

Visualisierung der Regeln um eine MC-Prüfung zu hacken.

Beide Faktoren tragen in etwa zur Hälfte(!) zum Erfolg bei.

In diesem Beitrag habe ich meine MC Prüfungsstrategie in 7 (8) Regeln zusammengefasst. In die Regeln ist mein Knowhow über MC-Test-Theorie, rechtliche Vorgaben an MC-Tests, Checklisten für Prüfer und meine Erkenntnisse wie (manche) MC-Prüfer und Prüfungsausschüsse ticken, eingeflossen.

Die Regeln habe in den letzten Jahren konsequent und erfolgreich an Prüfungen verschiedener Anbieter und Schemata ausprobiert. Manche schlecht konstruierten Fragen ließen sich sogar ohne Ahnung vom Thema beantworten. Nur Regel 8 habe ich nur einmal angewendet – und lag daneben.

In Zertifizierungs-Seminaren bringe ich die Regeln meinen Teilnehmern bei.

Dabei werde ich praktisch jedes Mal selbst positiv überrascht, wenn Teilnehmer eine der Regeln 4, 5 oder 7 auf eine Übungsfrage anwenden können, bei der ich dachte, hier geht es jetzt aber nur mit Fachwissen allein.

 

7 (8) Regeln zum MC-Test-Hacken

Die nun folgenden Regeln sind auf Fragen anwendbar, die nicht grundsätzlich falsch sind, z.B. weil es keine richtige Antwort auf die Frage gibt oder eine der lt. Lösungsschlüssel falschen Antworten auch objektiv richtig ist.

Regel Nummer 1: Wer lesen kann ist klar im Vorteil
Genau die Frage lesen!

  • Ist die Fragestellung verneint? (z.B. Was trifft nicht zu?)
  • Sind in der Fragestellung Annahmen oder Einschränkungen getroffen? (z.B. Es ist neblig und Sie fahren innerorts auf einer gut beleuchteten Straße …)
  • Gibt es ein Szenario, in dem eventuell Einschränkungen beschrieben sind? – Siehe dazu das ‚Dr. Strange Prinzip‘ – Regel Nummer 2.

 

Regel Nummer 2: “The warnings come after the spells …” (Dr. Strange im gleichnamigen Marvel-Film)
Erst die Frage und die Antwortoptionen lesen!

  • Szenariofragen haben typischerweise etwas mit ‚Leseverstehen‘ zu tun. Das kennen Sie noch aus dem Englisch- oder Französischunterricht der Schule. Da gab es einen Text zu lesen und dann Fragen dazu – wie z.B. ‚Was hat denn der kranke Monsieur Leroc gemacht, als ihm Madame Leroc gesagt hat, dass der Doktor vor der Tür steht?‘
  • Gehört zu einer Frage ein längeres Szenario sind selten alle gegebenen Informationen relevant. Das kann mehrere Gründe haben – z.B. der Frage-Autor recycelt, verwendet also unterschiedliche Aspekte des Szenarios für unterschiedliche Fragen. Diese tauchen nicht unbedingt alle auf Ihrem Antwortbogen auf, sondern eventuell auf dem Bogen des Nachbarn. Vielleicht wurden einfach irrelevante Informationen hinzugefügt. Eine an sich vielleicht banale Frage ist dann einfach auf Grund der Masse an Text, durch die man sich kämpfen muss, schwerer zu beantworten.
  • Liest man erst die Frage und die Antwortoptionen, weiß man eher, wonach man im Text (oder Diagramm) suchen muss. Und – man findet die relevanten Informationen schneller. Eventuell lassen sich bereits Antwortmöglichkeiten eliminieren, ohne das Szenario zu lesen (siehe Regel 4, 5 und 6). Ich finde ab und zu Fragen, die sich sogar ohne Lesen des Szenarios richtig beantworten lassen.

 

Regel Nummer 3: „Tue es oder tue es nicht. Es gibt kein Versuchen.“ Yoda in „Das Imperium schlägt zurück.“

  • Entscheiden Sie direkt nach einer ersten Sichtung der Frage, ob Sie die Frage gleich beantworten oder zurückstellen. (Machen Sie sich in dem Fall eine Erinnerungsnotiz!)
  • Beginnen Sie mit einfachen Fragen. Manchmal sind Frage-Sets zufällig gemischt und in Ihrem Bogen stehen alle schweren Fragen als erstes. (Nennt sich Murphys Gesetz, wenn das scheinbar immer so ist.)
  • Wenn Sie eine Frage beantwortet haben, schauen Sie diese nicht mehr an! Sie sollten natürlich noch zählen, ob die Anzahl der angekreuzten Antworten stimmt.
    Der Grund ist folgender: Falsche Antwortoptionen werden in der MC-Theorie als Distraktoren verwendet (von lat. distrahere – zersteuen oder von engl. to distract ablenken). Sie sollen also dem Namen nach den Prüfling (also Sie) von der richtigen Antwort ablenken. Daher sind sie oft so formuliert, dass sie richtig klingen (siehe auch Regel Nr. 4 – ‚Roter Hering‘) aber trotzdem absoluter Blödsinn sind.
    Wenn Sie jetzt am Ende nochmal schnell Fragen und Ihre Antworten überfliegen, kann es sein, dass ein Distraktor plötzlich viel interessanter aussieht, als die eigentlich richtige Antwort. Setzen Sie nun noch schnell ihr Kreuz auf den Distraktor, ist Ihr X-Flügler wirklich in den Sumpf geplumpst. Vertrauen Sie der Macht – also Ihrer ersten Wahl.

 

Regel Nummer 4: Der rote Hering!

Merkmale von Distraktoren

  • Ein ‚Red Hering‘ bezeichnet im Englischen ein Ablenkungsmanöver, im Krimi eine falsche Fährte. Neben dem Toten waren Tulpenblätter, also muss es der Gärtner gewesen sein. Tatsächlich lagen die aber schon vor dem Mord dort und es war doch der Butler.
    Im MC-Test versucht der Autor den Prüfling mit den falschen Antwortoptionen (Distraktoren, siehe Regel Nummer 3) auf eine falsche Fährte zu locken. Oder ihm Zeit zu stehlen.
  • Es gibt ein paar typische Muster wie Autoren Distraktoren bauen – einige sind gut, andere sind zweifelhaft, dazu gehören (ohne Wertung):
    • Prozessschritte stehen in einer falschen Reihenfolge. Es tauchen also richtige Schlüsselbegriffe auf, aber deren Reihenfolge stimmt nicht. (Z.B. Erst donnert es, dann blitzt es.)
    • Richtige Aussagen im falschen Kontext. Z.B.: Bei Sonnenschein folgt auf einen Blitz der Donner.(Und nein: Bitte nicht in der Prüfung anfangen über Blitze aus heiterem Himmel nach zu denken. Dann hat der Distraktor einen weiteren Zweck erreicht – Ihnen Zeit gestohlen!)
    • Verwendung von Fantasie- oder Alltags-Begriffen, die ähnlich klingen wie ein gesuchter Begriff oder scheinbar zur Frage passen – z.B. Verlässlichkeit neben dem Qualitätsmerkmal Zuverlässigkeit. Oder ‚Feature Freeze‘, wenn ein richtiger Begriff für ein Einfrieren des Bildschirms (Fehlerwirkung) gesucht wird.
    • Fehlerhafte Verwendung von Universal-Quantoren (immer, stets, nie, alle, jeder). Bsp.: Software-Tester sollen an allen Reviews im Unternehmen beteiligt werden.
      Oder: Immer, wenn es regnet, blitzt es.
      Es gibt natürlich auch richtige All-Aussagen, wie z.B. ‚Zu jeder Entwicklungsaktivität sollte es eine korrespondiere Testaktivität geben.‘ Oder: ‚Jede natürliche Zahl hat einen Nachfolger.‘

 

Regel Nummer 5: Der blaue Elefant

  • Wenn nur in einer Antwort-Option der Schlüsselbegriff aus der Frage behandelt wird, ist das vermutlich die richtige Antwort.
    Oder anders: Wird in der Frage nach blauen Elefanten gefragt und blaue Elefanten werden nur in einer Antwortoption erwähnt, ist das (meistens) die richtige Wahl.Plattes Beispiel: Was ist eine gute Metrik, um den Testfortschritt zu bestimmen?

    • A) Die Anzahl der gefundenen Fehler.
    • B) Die Anzahl der insgesamt bis zum Release getesteten Features und nicht getesteten Features.
    • C) Der wöchentliche Fortschritt in der mit Testfällen erreichten Anforderungsüberdeckung.
    • D) Der Anteil der Fehler die vor dem Release-Termin gefunden wurden im Vergleich zur Gesamtzahl aller gefundenen Fehlern.
  • Vorsicht: Ein blauer Elefant im falschen Kontext ist ein roter Hering! Beispiel: Wenn B) so lauten würde: ‚Der Fortschritt beim Anwachsen der Anzahl der nicht getesteten Anforderungen‘ … Schlüsselwort Fortschritt plus absolut unsinnige Aussage.
    Solche Formulierungen kommen gerne mal raus, wenn Prüfunsgkommissionen versuchen Distraktoren zu optimieren – d.h. einzelne Distraktoren (!) solange zu ändern, bis sie auch Kreuze bekommen. Für mich eine Praxis, die auf eine rote Liste gehört.
  • Variante: In der richtigen Antwort werden Synonyme des Fragebegriffs oder zum Fragebegriff direkt zugehörige Konzepte verwendet.Beispiel: Was ist ein typisches Kennzeichen einer risikoorientierten Teststrategie?
    • A) Mit den Test-Aktivitäten so früh wie möglich beginnen.
    • B) Tester an Reviews von Anwendungsfällen auf Systemebene beteiligen.
    • C) Vorrangig dort Testen, wo von Fehlern hohe Schäden zu erwarten sind
    • D) Anzahl von Testfällen auf ein sinnvolles Maß reduzieren – Testfallexplosion vermeiden.
      – Nur Option C) hat einen direkten Bezug zu dem Begriff Risiko (möglicher Schaden wird erwähnt). A) B) und D) sind typische rote Heringe. Alle sind gute Testpraktiken, aber nicht notwendig Teil einer risiko-orientierten Strategie.

 

Regel Nummer 6: Ausschlussprinzip und Das Prinzip des geringsten Bullshits

Anwendbar, wenn alle Antwortmöglichkeiten sehr, sehr ähnlich klingen. Nicht alle Prüfungsautoren sind Meister der Sprache und manche formulieren ungeschickt.
Andere spielen Thomas Mann und ergehen sich in Schachtelsätzen, die genau betrachtet, sieht man einmal von Deutsch-Abiturprüfungen, die wiederum nicht als MC-Tests gestaltet sind und auch anders benotet werden, oder Latein-Grammatik-Tests, wo dies sinnvoll sein kann, ab, nichts in einem MC-Test und genau so wenig in einem Blogbeitrag, verloren haben. (Entschuldigung – ich konnte wirklich nicht widerstehen …)

Sehr ähnliche Antwortoptionen kommen allerdings auch gerne vor, wenn ein Prüfungsautor versucht hat Distraktoren über mehrere Runden zu optimieren. Dabei passt er falsche und richtige Antworten mehrfach an, bis diese alle wirklich fast gleich sind. (Liebe Prüfer, wenn ihr so rumbasteln müsst, taugt die Frage nix. Also wegwerfen und eine andere Frage ausdenken.)

3 Strategien:

  • Mit den Prinzipien 1-5 kann man die Antwort herausfiltern, die am wenigsten falsch ist, d.h. am besten zu Szenario, Lehrmaterial und Fragestellung passt.
  • Oder: Überlegen, wie man seine beiden Top-Optionen selbst als richtige Antwort formuliert hätte. Die Option wählen, die dem am nächsten kommt.
  • Oder: Wirklich ähnliche Antwortoptionen unterscheiden sich nur in ganz wenigen Worten. Diese Worte unterstreicht man und wendet Regel 4, Regel 5 oder Regel 7 an.

 

Regel Nummer 7: Wenn sonst nichts hilft – suche nach abstrakten Mustern – wenn das auch nicht hilft, wirf eine Münze.

Im absoluten Notfall gehe ich die Frage wie das Erkennen eines abstrakten Musters in einem IQ-Test an.
These ist dabei:
Eine Antwort ist sicher anders als die anderen.
Was ist das abstrakte Muster, das sie unterscheidet?

Diese Technik ist damit eigentlich die Verallgemeinerung des ‚blauen Elefanten.‘

Triviales Beispiel:

Ist eine Antwort auffällig kürzer oder als die anderen? Dieses Muster führt sehr selten zum Erfolg, da es auf praktisch jeder Checkliste für Prüfungsautoren steht. Die meisten Prüfungsausschüsse und Prüfer achten beim Testdesign darauf, dass sich die richtige Antwort nicht durch eine ungewöhnliche Länge verrät.
Andere Muster entgehen den Autoren und Gutachtern gelegentlich.

Beispiele aus der Prüfungs-Realität:

In einer Prüfungsfrage ging es um Informationen, die in einem Formular fehlen. Diese waren benannt und durchnummeriert aufgelistet . Zusätzlich war ein Formularmuster mit einem Teil der Nummern aus der Liste abgebildet. Ich hatte die Frage mehrfach gelesen und immer noch nicht verstanden, was der Frageautor eigentlich wollte. Schließlich wählte ich die  Antwortoption, in der nur die Nummern aus dem Formularmuster vorkamen. Das war tatsächlich die richtige Antwort.

Die richtige Antwort unterschied sich von der falschen in einem anderen Fall dadurch, dass in der richtigen Antwort ein geschlossenes mathematisches Intervall angegeben war. In den falschen Antwortoptionen waren durchweg offene Intervalle angegeben.

Das Schöne an Regel 7 ist: Je mehr ein Frage-Autor bemüht ist, Muster zu vermeiden, z.B. um die Regeln 4 oder 5 auszuhebeln, desto eher baut er ein anderes deutliches Muster in seine Frage ein, das für ihn (und seine Gutachter) unsichtbar ist.

 

Regel Nummer 8: B ist meistens richtig – ist eine Urban Legend!

Der wahre Grund warum so oft B empfohlen wird, ist z.B. hier zu finden: https://www.youtube.com/watch?v=Jy4gdM6ya0U.

 

Teststrategien

In der Spieltheorie nach John von Neumann (Ungarisch-Amerikanischer Mathematiker, 28.12.1903 – 08.02.1957) ist eine Strategie ein vollständiger Plan eines Spielers, der für alle Eventualitäten, z.B. mögliche Gegenzüge oder Umwelteinflüsse den Spieler eine geeignete Handlungsweise auswählen lässt und dabei den Kenntnisstand des Spielers optimal berücksichtigt. Ziel der Strategie ist natürlich das Spiel zu gewinnen. Im Schach z.B. gibt es unzählige Studien über Eröffnungen, Mittel- und Endspiele. Diese können einem Spieler helfen, für jedes Spiel eine eigene, passende Strategie zu entwickeln.

Ziel einer Strategie im Softwaretest ist es die bestmögliche Information über die Qualität des Testgegenstandes zu liefern – unter Berücksichtigung aller Randbedingungen.

Die Handlungs-Elemente, die eine Teststrategie festlegen, sind im Einzelnen:

  • Testprozesse – Wann werden welche Testaktivitäten ausgeführt?
  • Testmethoden – Welche prüfende Maßnahmen (Reviews, statische und dynamische Analysen, Blackbox-, Whitebox- und erfahrungsbasierte Tests) werden eingesetzt?
  • Testarten – Welche Ziele werden mit den Testmaßnahmen verfolgt?
  • Teststufen – Auf welchen Integrationsstufen der Software wird getestet?
  • Testorganisation – Wer ist am Test beteiligt?
  • Testmittel – Welche Werkzeuge und Umgebungen werden benutzt? Wie wird dokumentiert? Wie müssen die Testdaten und das Testdatenmanagement beschaffen sein?

Die ISO/IEC/IEEE 29119-3 nennt u.a. diese Punkte als Inhalte für die gleichnamigen Dokumente auf Organisations- und Projektebene.

Auch das Entwerfen von Teststrategien können Sie üben.

Die folgenden Übungen werden Ihnen ein Gespür dafür geben, worauf es bei einer Teststrategie ankommt. Ein Tipp: Versuchen Sie von vornherein Ihre Antworten zu strukturieren. Malen Sie sich kleine Tafelbilder oder strukturieren Sie Ihre Lösungen mit Hilfe eines Mindmaps.

Beide Methoden setze ich ein, wenn ich reale Strategien und Testhandbücher entwerfe.

 

(c) Christian Alexander Graf, 03.03.2018

 

Schattenboxen-Übung Strategie 1 – Wo stehen Ihre Spielfiguren?

Notieren Sie sich für Ihr Projekt/ Ihre Organisation zu jeder Kategorie die derzeit bestehenden Elemente. Die folgenden Fragen können Ihnen dabei helfen:

Testprozesse:

  • Welche Testaktivitäten folgen auf Entwicklungsaktivitäten? Wodurch werden Sie ausgelöst? Wann erfolgen Sie?
  • Welche Aktivitäten werden außerdem im Test durchgeführt? Wann?
  • Wie sind Testaktivitäten mit Produkt- und Projektrisikomanagement verknüpft?

Testmethoden/Testmittel:

  • Was wird reviewt? Wann? Von wem?
  • Werden statische Analysen durchgeführt? Wann? Womit? Wer wertet sie aus?
  • Welche Testentwurfsverfahren werden eingesetzt? Wann? Von wem? Wie wird der Testentwurf dokumentiert? Wird der Testentwurf durch Werkzeuge, Checklisten, usw. unterstützt?

Testarten/Testmittel:

  • Welche Features (Funktionen, Qualitätsmerkmale, Struktur) werden geprüft?
  • Wann wird nach Änderungen getestet? (Nach- und Regressionstests)
  • Welche dynamischen Analysen werden durchgeführt? Welche Werkzeuge kommen zum Einsatz?

Teststufen

  • Testen Sie Komponenten? Schnittstellen? Geschäftsprozesse? Integrationen in bestimmte Soft- oder Hardware-Umgebungen? Wann finden diese Tests statt? In welcher Reihenfolge?

Testorganisation

  • Betrachten Sie die vorangegangenen Aktivitäten. Wer führt diese durch?

Testmittel/Testorganisation:

  • Welche Werkzeuge setzen sie für Anforderungs-, Fehler- und Testmanagement ein? Verwenden Sie Werkzeuge zur Testautomatisierung, Testdatenmanagement und/oder eigens konstruierte Testumgebungen? Wer nutzt die Werkzeuge? Wer reviewt Testdokumente? Wer bewertet die Art und Weise der Nutzung von Werkzeugen?

Bitte beachten Sie bei dieser Übung die Grundprinzipien des Schattenboxens. Sie können jedem Strategieelement zwei oder drei tägliche Einheiten widmen. D.h. beantworten Sie die Fragen zu jedem Element mindestens zweimal – aber lassen Sie mindestens einen Tag vergehen.

 

Schattenboxen-Übungen Strategie 2 bis 6 – Handlungsalternativen bewusst machen!

Betrachten Sie Ihre Antworten aus der ersten Übung jeweils Elementweise.

  1. Notieren Sie für jeden Punkt den Sie notiert haben eine Alternative zur aktuellen Vorgehensweise.
  2. Notieren Sie für jeden Punkt eine Aktivität, die Sie zusätzlich durchführen könnten.
  3. Notieren Sie für jeden Punkt eine alternative Aktivität, die von einer anderen Rolle ausgeführt wird, als es derzeit der Fall ist. Bewerten Sie die Alternative. Besser? Schlechter? Oder werden einfach andere Informationen geliefert?
  4. Notieren Sie die wichtigsten Features und Eigenschaften des Systems, das Sie testen. Notieren . Sie zu jedem Feature passende Prüfaktivitäten. Welche davon werden tatsächlich durchgeführt? Von wem? Wann?
  5. Notieren Sie alle Projektaktivitäten zur Anforderungserhebung und Entwicklung. Finden Sie zu jeder dieser Aktivitäten eine zugehörige passende Prüfaktivität. Wer könnte diese durchführen? Welche Werkzeuge könnten denjenigen dabei unterstützen?

Warum Testfälle systematisch entwerfen?

Einen vollständigen Test durchzuführen bedeutet folgendes:
Der Tester verifiziert alle möglichen Eingaben zusammen mit allen möglichen Ausgaben für alle Konfigurationsmöglichkeiten (z.B. Spracheinstellungen, Layout-Einstellungen, ein- oder ausgeschaltete Plugins, etc.) eines Programmes.

Als Beispiel dient eine Variante des oft zitierten Dreiecksprogramm aus dem Buch von Myers (Glenford Myers: ‚The Art of Software Testing‘, John Wiley & Sons, 1979):

Ein Programm akzeptiert die Eingabe dreier ganzer Zahlen und interpretiert diese als Seitenlängen eines Dreiecks. Die Programmausgaben sind entweder eine Fehlermeldung oder die Art des Dreiecks unterschieden nach ‚allgemein‘, ‚gleichschenklig‘ oder ‚gleichseitig‘.
Als weitere Einschränkung gelte, dass das Programm nur Eingaben vom Typ ‚unsigned short‘ mit einem Zahlbereich von 0 bis 65535 akzeptiert.

Betrachten wir zunächst die Tests aller möglichen gültigen Eingabeformate (d.h. keine Buchstaben, keine Sonderzeichen, keine zu kleinen oder zu großen Zahlen, keine falsche Anzahl an Eingaben, usw.). Schätzen Sie wieviel Testfälle benötigt würden – die Antwort finden Sie weiter unten (unter Antwort 1)

Angenommen, wir hätten diese tatsächlich erstellt und per Skript oder Unit-Test automatisiert.

Was schätzen Sie, wie lange die automatisierte Testdurchführung läuft, wenn ein einzelner Testfall eine Mikrosekunde (1.0e-6 s, der Millionste Bruchteil einer Sekunde) in der Durchführung benötigt? (Antwort 2 unten)

Dieser Test wäre nicht einmal wirklich vollständig.
Ein vollständiger Test würde neben den gültigen Eingaben eben auch alle möglichen ungültigen Eingaben testen.
Bereits für dieses einfache Programm ist ein vollständiger Test daher (mit unseren derzeitigen technischen Mitteln) nicht realisierbar.

Das Beispielprogramm von Myers lässt sich in gängigen Programmier- oder Skriptsprachen mit 10-20 Codezeilen leicht implementieren. Reale Computerprogramme besitzen mehrere tausend bis hin zu mehreren Millionen Quellcodezeilen und oft mehrere tausend Konfigurationsmöglichkeiten, die den Programmablauf wesentlich beeinflussen.

Kann ein Tester dann Software überhaupt ‚vernünftig‘ testen?
Die Antwort ist ein klares: JA!

Vernünftig meint in diesem Zusammenhang, dass der Tester in der Lage ist, erfolgreich Fehler aufzudecken und nach erfolgtem Test eine auf Fakten basierende, nachvollziehbare Einschätzung von verbleibenden Risiken abzugeben. (Was er nicht kann, ist die Fehlerfreiheit zu garantieren.)
Dazu sind systematische und erfahrungsbasierte Testentwurfsverfahren entwickelt worden.

Der systematische Testentwurf beginnt damit, das erwartete Verhalten des Systems im Guten, wie im Schlechten (z.B. bei Fehlbedienungen, Stress, usw.) zu modellieren. Aus den erstellten Modellen (ja – Plural, ein Modell reicht meist nicht aus alle wichtigen Aspekte eines Systems zu testen) werden repräsentative Testfälle abgeleitet, anhand derer das tatsächliche Systemverhalten mit den Erwartungen des Testers aus dem Modell abgeglichen wird.

Systematische (Blackbox-, Whitebox- und erfahrungsbasierte Verfahren) sind in Büchern und in Standards wie der ISO/IEC/IEEE 29119-4 ausführlich beschrieben. Andere Standards wie die IEC 61508-3 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems) oder die ISO 26262 enthalten Richtlinien und Vorgaben zum Einsatz der Verfahren.

 

Antwort 1 (Markieren Sie die Zeile mit dem Cursor zum Lesen): Sie benötigen 65536³, das sind mehr als 2,8 Billionen Testfälle.

Antwort 2 (Markieren Sie die Zeile mit dem Cursor zum Lesen): Mehr als 8,9 Jahre. Benötigt der Durchlauf eines einzigen Testfalls statt einer Mikro- eine Millisekunde (eine Tausendstel Sekunde), würde die Testdurchführung mehr als 8.900 Jahre dauern.

Aktuelle Workshops …

Derzeit sind keine offenen Seminartermine vorgesehen.

Sie können jederzeit ein Online-Seminar oder ein Online-Coaching für sich oder Ihre Mitarbeiter buchen.
Mehr Infos zu Inhouse-Seminaren, Anmeldung, Preise und Teilnahme finden Sie unter
Schattenboxen-Workshop