Zum Inhalt springen

Suchen...

Swiss Testing Board

Wie entstand das ISTQB, und was gilt heute noch davon? Von Bloom-Taxonomie bis KI-Tests: was wirklich zählt, wenn Testen schneller werden muss.

7 Min. Lesezeit
Cover für Swiss Testing Board

Das Swiss Testing Board ist die Schweizer Mitgliedsorganisation des ISTQB und entstand Anfang der 2000er Jahre aus einer Arbeitsgruppe der SAQ-Fachgruppe Informatik. Es akkreditiert Trainingsanbieter, fördert die Tester-Zertifizierung und brachte von Beginn an didaktisch messbare Lernziele nach der Bloom-Taxonomie in die internationalen ISTQB-Lehrpläne ein.

Das Wichtigste in Kürze

  • Das ISTQB entstand Anfang der 2000er Jahre aus informellen Gesprächen zwischen wenigen Personen, bevor es überhaupt eine formale Organisationsstruktur gab.
  • Lernziele im Certified Tester Foundation Lehrplan wurden erst durch Blooms Taxonomie und Andersons Erweiterung messbar und prüfbar, weil ohne diese Systematik keine verlässliche Zertifizierung möglich ist.
  • Tester können eine Software nicht sinnvoll testen, wenn sie nicht verstehen, wozu sie eingesetzt wird und wie sie technisch aufgebaut ist.
  • Agilität erfordert hohe Disziplin: wer Akzeptanzkriterien nicht explizit aufschreibt und versteht, weiß auch nicht, was er eigentlich prüfen muss.
  • Systematische Testfallerstellung auf Basis klassischer Techniken bleibt unverzichtbar, weil rein intuitives Testen zwar Fehler findet, aber keine Vollständigkeit liefert.

Wie aus einer Anekdote im Red Light District eine Zertifizierung wurde

Das Swiss Testing Board entstand aus einer konkreten Nachfrage, nicht aus einem strategischen Masterplan. Anfang der 2000er Jahre hielt Thomas Müller einen Vortrag über Use Cases im Testen bei der Credit Suisse. Danach kam Silvio Moser auf ihn zu mit einer simplen Frage: Wie könnte man Tester zertifizieren?

Thomas hatte darauf keine Antwort. Er kannte aber jemanden, der eine hatte. Über Carol Frühauf, mit dem er bereits seit fast zehn Jahren in der Fachgruppe Informatik der SAQ zusammenarbeitete, kam der Kontakt zur britischen ISEB und zur amerikanischen ASQ zustande, die beide bereits an Lehrplänen für das Testen arbeiteten.

Den Ausschlag gab ein Treffen an einem regnerischen Winterabend in einem Restaurant im Zürcher Red Light District. Robert Treffny erzählte dort von Bestrebungen, die Lehrpläne von ISEB und ASQ zusammenzulegen und eine internationale Organisation zu gründen. Thomas sagte zu, ohne genau zu wissen, worauf er sich einließ.

Warum das Swiss Testing Board als lose Arbeitsgruppe begann

Das Swiss Testing Board war zu Beginn kein Verein, sondern eine Arbeitsgruppe innerhalb der Fachgruppe Informatik der SAQ. Diese pragmatische Anbindung ersparte den Gründern den Aufbau einer eigenen Organisationsstruktur.

Die Gründung des internationalen Dachverbands fand in Schottland statt. Thomas konnte aus familiären Gründen nicht teilnehmen, seine Kinder waren damals noch klein. Robert Treffny vertrat die Schweiz vor Ort. Die folgenden Treffen fanden meist im Rheingebiet statt, in Köln oder Düsseldorf, in kleiner Runde mit sechs bis sieben Leuten.

An einem dieser frühen Treffen fiel die Frage, wer die Lehrplanarbeit koordinieren würde. Thomas meldete sich, nach eigener Beschreibung als “nobody” in dieser Runde, aber mit dem passenden Hintergrund: Er hatte sich mit Lernzielen befasst und bereits Kurse aufgebaut, unter anderem zusammen mit Hans Schäfer im Rahmen von EU-Förderprogrammen in Deutschland.

Lernziele müssen messbar sein, genau wie Anforderungen

Der erste inhaltliche Eingriff von Thomas in die Lehrplanarbeit betraf die Messbarkeit der Lernziele. Die ursprünglichen Formulierungen waren nicht prüfbar, und das war für ihn ein Widerspruch zum eigenen Fach.

Sein Argument an die Gruppe: Wer weiß, wie man Anforderungen an Software prüfbar spezifiziert, kann dasselbe Prinzip auf Lernziele anwenden. Als methodische Grundlage dienten die Taxonomie-Modelle von Bloom und die Erweiterung von Anderson, deren Anhänger Thomas war. Diese kognitiven Stufen, die K-Level, wurden zur Basis der Lernziele im Certified Tester.

Der Hintergrund dafür lag weiter zurück. Anfang der 90er Jahre, während seiner Zeit bei der Schweizerischen Kreditanstalt, hatte Thomas an der ETH ein Didaktikstudium absolviert. Professor Frey machte aus der Frage “Wie misst man?” ein zentrales Anliegen, und diese Prägung trug Thomas in die Lehrplanarbeit hinein.

Die Gruppe von der Messbarkeit zu überzeugen, war nicht das Schwierige. Den richtigen Detaillierungsgrad der Texte zu finden, führte dagegen zu massiven Auseinandersetzungen. Am Schreiben beteiligt waren Native Speaker wie Dorothy Graham vom UK Board und Erik van Veenendaal aus den Niederlanden. Finnland und Schweden brachten von Beginn an Vertreterinnen aus den Hochschulen ein.

Die Schweiz war früh Spitze bei den Zertifizierungen

Gemessen an der Einwohnerzahl gehörte die Schweiz zeitweise zur Top-Nation bei der Zahl der zertifizierten Tester. Die Nachfrage kam vor allem aus dem Bankensektor, mit der Credit Suisse als Mitinitiatorin und Silvio Moser als Teil des Boards.

Drei Trainingsanbieter wurden zuerst akkreditiert, sie hatten ein starkes Eigeninteresse, weil sich die Kurse gut verkaufen ließen. Das Marketing übernahmen nicht das Swiss Testing Board, sondern die Trainingsprovider selbst. Adrian Zwingle wird hier als besonders aktiver Treiber genannt. Ein Zertifikat kostete damals rund 400 Franken, ein für den Markt unproblematischer Preis.

Einen Schub gab die General Assembly 2007 in Zürich-Oerlikon. Viele Nationen reisten an, die Inder waren zum ersten Mal dabei. Die Schweiz als Tagungsort wirkte als zusätzlicher Anreiz. Diese Dynamik flachte später ab. Es setzten Sättigung und kritische Fragen ein, was die Zertifizierung konkret bringt.

Eine Branche blieb Thomas trotz aller Bemühungen verschlossen: die Pharmaindustrie, sein damaliges Hauptarbeitsfeld. Dort galt allein, ob etwas FDA- und GXP-zertifiziert war. Inhaltlich floss vieles ein, eine Testing-Zertifizierung interessierte dort schlicht niemanden.

Die Konzepte der Pioniere gelten weiter

Die grundlegenden Testkonzepte haben ihre Bedeutung behalten, auch wenn sich das Umfeld stark verändert hat. Was Pioniere wie Glenford Myers und Bill Hetzel formuliert haben, ist nach Einschätzung von Thomas weiterhin relevant für die Frage, was man wie testet und woran man denken muss.

Ein konkretes Beispiel ist das kombinatorische Vorgehen bei der Systemintegration. Hier geht es darum, auf hoher Ebene zu prüfen, welche Systeme wie miteinander kommunizieren und welche Datenelemente betroffen sind.

Ein eigenes Thema in der Pharmaindustrie ist das Sampling. Viele Beteiligte übertragen das Denken aus der Hardwareproduktion auf Software und fragen nach zulässigen Abweichungen, als würden Nägel hergestellt. Thomas hält dem einen klaren Satz entgegen: Software ist kein Nagel. Stichprobenlogik aus der Fertigung lässt sich nicht eins zu eins auf Software übertragen.

Geschwindigkeit ist die zentrale Herausforderung im Testen heute

Die größte Veränderung im Software-Testing ist das Tempo. Testen muss von Beginn an vollständig in den Entwicklungszyklus integriert sein, nicht als nachgelagerter Schritt.

Das beginnt bei den Anforderungen. Wer mit Acceptance Criteria, User Requirements oder User Stories arbeitet, sollte sich früh fragen, ob sich eine Anforderung überhaupt testen lässt. Der alte Grundsatz, dass Requirements testbar sein müssen, bleibt gültig.

Die Testautomatisierung bringt eine eigene Frage mit sich, gerade in regulierten Umfeldern: Ist das, was die Testautomaten ausgeben, auch qualifiziert und validiert? Wie stellt man sicher, dass die Ergebnisse korrekt sind?

Mit künstlicher Intelligenz und Machine Learning verschiebt sich die Grundlage weiter. Hier lässt sich nicht mehr rein deterministisch vorgehen, und es gelten andere Prüfkriterien als bei klassischer Software.

Ohne Verständnis für das Produkt kannst du nicht testen

Der wichtigste Rat von Thomas an Tester lautet: Verstehe, was du vor dir hast, wozu es verwendet wird und wie es gebaut ist. Wer das nicht weiß, kann eine Software oder ein Embedded System nicht sinnvoll prüfen.

Er illustriert das an einem Beispiel aus dem Schiffbau. Eine Firma sollte die Software für Antriebsmotoren von Containerschiffen prüfen, Maschinen so groß wie eine Küche, in Schiffen, die rund 150 Millionen kosten. Die größte Hürde war zunächst, überhaupt zu verstehen, worum es ging. Erst dieses Verständnis machte das Prüfen und Simulieren möglich, gerade weil so ein Antrieb über 20 Jahre an neue Umweltvorgaben angepasst werden muss.

Für Tester im Low-Level-Bereich kommen technische Fähigkeiten dazu: optimale Prozesse, der Aufbau von Deployment-Modellen, die Arbeit mit Werkzeugen wie GitLab. Tester sollten sich auch in angrenzenden IT-Fachgebieten auskennen.

Hier liegt der Vorteil der erfahrenen Tester. Sie wissen aus Erfahrung schon viel, und ein Blick auf das reale Produkt wirkt oft als Augenöffner, für Entwickler wie für Tester.

Systematik schlägt Bauchgefühl

Modellierung ist im Testen unterrepräsentiert, obwohl sie hohen Wert hat. Wer nicht modellieren kann, testet nach Gefühl oder nach dem, was gerade einfällt.

Gefühle sind schon wichtig, da habe ich nichts dagegen. Doch Systematik ist etwas Extremes. Thomas Müller

Intuitives Testen bringt durchaus gute Tests hervor, manchmal kommt dabei etwas Wertvolles zum Vorschein. Aber es fehlt ein Teil, wenn die systematische Annäherung an eine Anforderung wegfällt. Die Basistechniken dafür wurden von Myers und anderen frühen Vertretern des Fachs definiert.

Auch Agilität entlässt niemanden aus dieser Disziplin. Agil heißt nicht “einfach los”, sondern erfordert hohe Disziplin. Wer seine Akzeptanzkriterien aufschreibt und verstanden hat, weiß auch, was er prüfen muss. Frühzeitig, frühzeitig, frühzeitig, so bringt Thomas das Prinzip auf den Punkt.

Diese Seite teilen

Ähnliche Beiträge