ISTQB in der Praxis bei Bucher und Suter

Testaufbau in Telekommunikationssoftware bedeutet, funktionale Testfälle, Lasttests und eigene Automatisierungswerkzeuge schrittweise und oft ohne fertige Marktlösungen selbst zu entwickeln. Externe Anforderungen von Partnern wie Cisco liefern dabei konkrete Exit-Kriterien. Intern sichern ISTQB-Zertifizierungen und regelmäßige Team-Reviews den Wissenstransfer und die Qualität dauerhaft ab.

Das Wichtigste in Kürze

• Fehlende Marktlösungen für spezialisierte Lasttests zwangen Bucher & Sutter dazu, ihre eigene Testautomatisierungssoftware von Grund auf zu entwickeln, weil kein verfügbares Tool die Kombination aus Voice-Gateway-Steuerung und CRM-Simulation abdeckte.
• Cisco-Vorgaben wie das 99,99-Prozent-Ziel für korrekt abgehandelte Anrufe lehrten das Team, dass gleiche Zahlen unterschiedliche Aussagen treffen können, je nachdem, wie man den Fehlerfall formuliert.
• ISTQB-Zertifizierungen bis zum Advanced Level dienen bei Bucher & Sutter als gemeinsames Vokabular im Team und stellen sicher, dass auch erfahrene Tester ihr Wissen regelmäßig überprüfen.
• Der Wechsel in die Cloud erhöht den Stellenwert von Testautomatisierung in CI/CD-Pipelines und bringt gleichzeitig neue Anforderungen an IT-Security und Datenschutz, die dedizierte On-Premise-Umgebungen nicht in dieser Form hatten.

Wenn die Testbasis fehlt, beginnt das Testen mit Forschen

Fremdsysteme ohne Dokumentation zwingen Tester zur explorativen Arbeit. Wer Schnittstellen zwischen unbekannten Plattformen testet, bekommt keine fertige Anforderungsliste, an der er sich abarbeiten kann. Stattdessen muss er das erwartete Verhalten Schritt für Schritt selbst erarbeiten.

Bei Telekommunikationslösungen, die zwischen der Cisco-Welt und großen CRM-Anbietern vermitteln, war genau das die Ausgangslage. Die anzubindenden Systeme waren teils unbekannt, die proprietären Eigenheiten kaum dokumentiert. Die Expected Results, also wie das System auf einen bestimmten Anruf oder Vorgang reagieren soll, ließen sich nicht aus Spezifikationen ableiten.

Alexander Meister beschreibt den Aufbau eines solchen Testkatalogs als Forschungsarbeit. Use Cases entstanden im wiederholten Abgleich mit den Experten der beteiligten Plattform, oft zwei- bis dreimal im Monat. Aus diesem Prozess wuchs über die Zeit ein Katalog von 400 bis 500 Testfällen, die anschließend auf die unterschiedlichen Plattformen adaptiert wurden.

Diese Art von Testfall-Erarbeitung verlangt mehr Denkarbeit als das Abhaken vorgegebener Kriterien. Du suchst nicht nur Fehler, du definierst zuerst, was überhaupt korrekt wäre.

Der Wechsel vom Entwickler zum Tester ist auch ein Rollenwechsel im Kopf

Vom Entwickeln ins Testen zu wechseln bedeutet, die eigene Perspektive umzudrehen. Ein Entwickler ist stolz darauf, was seine Software kann. Ein Tester interessiert sich für das Gegenteil.

Das, was man kann, das ist schön und recht, aber mich interessiert alles das, was nicht gut funktioniert. Mich interessiert das, was du nicht kannst.

Alexander Meister

Dieser Blickwechsel fällt am Anfang schwer. Es geht darum, Fehler nicht bei den Menschen zu suchen, sondern in der Software. Ob das eine Frage des Charakters ist oder eine Entwicklung, die man durchmacht, bleibt offen. In jedem Fall ist es eine Haltung, die man sich aneignen muss, nicht eine, die mit dem Job automatisch kommt.

Warum es für Lasttests kein Tool von der Stange gab

Maschinennahe Systeme lassen sich nicht mit Standard-Lasttools prüfen. Sobald Tests sehr tief in den Schichten ansetzen, etwa direkt an Voice Gateways, gibt es keine Oberfläche, die ein generisches Tool bedienen könnte. Der Test muss auf API-Ebene ansetzen.

Genau das machte den Aufbau der Lasttest-Umgebung aufwendig. Auf der einen Seite simulierten Lastgeneratoren die Voice-Last samt komplettem Voice-Stream, also echtem Datenverkehr über die Leitung statt reiner Pseudosignalisierung. Auf der anderen Seite musste etwas her, das die Agenten eines Callcenters und die dahinterliegende CRM-Welt abstrahiert.

Diese Gegenseite gab es nicht zu kaufen. Sie musste als eigene Automatisierungssoftware von Grund auf entstehen. Wer Lasttests in einer derart speziellen Umgebung fahren will, baut die Testroboter oft selbst.

Eine Bedingung ist dabei nicht verhandelbar: Die Testinfrastruktur muss stabiler laufen als das System, das sie prüfen soll.

Du kannst nichts testen, wenn deine Software drum herum, die du baust, vorher in die Knie geht.

Alexander Meister

Eine Lastumgebung gehört abgeschottet, sonst testest du Phantome

Geteilte Infrastruktur verfälscht Langzeit-Lasttests. Wer einen 48-Stunden-Lauf auf einer Umgebung startet, die nebenbei für andere Zwecke offensteht, riskiert Abbrüche aus völlig sachfremden Gründen.

Das anschauliche Beispiel: Ein Lauf läuft 46 Stunden, dann zieht jemand über einen offenen Network-Share ein Update herunter, und der Test ist hinüber. Du fängst von vorne an, ohne dass je ein echter Defekt im Spiel war.

Die Konsequenz ist ein dediziertes Lastsystem. Eigener Core-Switch, eigene Server, das Rack ausschließlich für diesen Zweck, von außen nicht zugänglich, Zugriff nur über eine Konsole. Erst diese Abschottung sorgt dafür, dass ein fehlgeschlagener Test auf einen echten Fehler zeigt und nicht auf eine Störung von außen.

Vorgegebene Exit-Kriterien zwingen zur Präzision

Bei OEM-gelabelten Produkten gibt der Auftraggeber die Testkriterien vor. Die Test-Exit-Criteria standen fest, weil das Produkt unter fremdem Label lief. Damit waren die Schritte, die erreicht werden mussten, nicht Verhandlungssache, sondern Lieferbedingung.

Solche Vorgaben erzeugen wöchentliche Abnahmen, bei denen sich zeigt, was funktioniert und was nicht. Sie zwingen außerdem zu sprachlicher Genauigkeit. Ein Beispiel: 99,99 Prozent der Anrufe müssen korrekt abgehandelt werden. Ist das dasselbe wie die Aussage, 0,01 Prozent dürfen fehlschlagen?

Bei zehn Millionen Anrufen rechnet sich der Unterschied schnell aus. Was zunächst wie Haarspalterei klingt, wird bei großen Volumina zu einer handfesten Differenz. Genau solche Diskussionen formen die Art, wie ein Testteam Kriterien liest und definiert.

Qualität bleibt Teamsache, auch wenn es Testspezialisten gibt

Testen skaliert nicht als One-Man-Show. Was 2006 mit einer Person begann, wuchs früh: 2007 kam die erste Mitarbeiterin dazu, heute kümmern sich neun Leute um Test und Qualitätssicherung.

Der Stellenwert der Qualitätssicherung wurde von Anfang an erkannt, samt dem Aufwand, den sie verursacht. Qualitätssicherung passiert nicht von allein, sie ist kein Selbstläufer. Diese frühe Einsicht hat den Aufbau des Teams getragen.

Wichtig dabei: Es gibt zwar Testspezialisten, aber die Verantwortung für Qualität liegt beim ganzen Team. Spezialisierung ersetzt nicht die geteilte Verantwortung, sie ergänzt sie.

Wie Wissenstransfer in einem Testteam organisiert wird

Wissen fließt am besten über feste Austauschformate, nicht zufällig. Im Testteam laufen dafür zwei Rhythmen parallel.

• Einmal pro Monat das ganze Team: Hier werden testspezifische Themen durchleuchtet, etwa Probleme aus dem laufenden Monat oder neue Software, die interessant sein könnte. Alles rund ums Testen kommt auf den Tisch.
• Alle zwei Wochen Einzelgespräche: Im Wechsel sitzt der QS-Verantwortliche mit jeder Person zusammen, um projektspezifische Themen zu klären. Was dort auftaucht, kann als Punkt in die nächste Teamrunde wandern.

So bleibt der Austausch über die Projektteams hinweg gewährleistet. Verantwortlichkeiten und die passenden Kompetenzen werden gezielt einzelnen Leuten zugeordnet, statt diffus im Raum zu schweben.

Zertifizierung schafft eine gemeinsame Sprache

ISTQB-Zertifizierungen dienen vor allem einem gemeinsamen Vokabular. Wenn alle vom Selben sprechen, reden Tester über Begriffe nicht aneinander vorbei. Das Foundation Level bildet dafür die Basis, die neue Teammitglieder mitbringen oder nachholen.

Der Nutzen wirkt in beide Richtungen. Neue Leute steigen mit dem gemeinsamen Begriffsgerüst ein. Wer schon länger dabei ist, bleibt durch den wiederkehrenden Kontakt mit frisch Zertifizierten am Ball.

Darauf bauen die weiteren Stufen je nach Schwerpunkt auf. Wer Richtung Testmanagement geht, nimmt einen anderen Pfad als jemand mit Fokus auf technische Tests oder Testanalyse. Das Ziel ist, die Leute bis zum Advanced Level zu zertifizieren, damit sie diese Basis als Rucksack mitnehmen.

Neben dem Know-how-Aufbau zählt der Kontakt zur Testwelt außerhalb der eigenen Firma. Über solche Bekanntschaften entsteht ein Austausch, der intern allein nicht zu haben wäre.

Die Cloud verschiebt den Fokus auf Automatisierung und Datenschutz

Der Schritt in die Cloud hebt Testautomatisierung auf eine neue Stufe. Mit CI/CD wird der Aufbau sauberer Pipelines zentral, damit Tests verlässlich durchlaufen und ins Rollen kommen. Automatisierung bekommt dadurch einen höheren Stellenwert, weil sie zur Voraussetzung der Auslieferung wird.

Parallel rückt IT-Security und Datenschutz in den Vordergrund. In der Cloud stellt sich diese Frage anders als bei einem System, das dediziert auf dem eigenen Server läuft. Wer Daten und Dienste verlagert, muss Sicherheit und Schutz neu durchdenken.

Beide Themen, Automatisierung und Sicherheit, sind die aktuellen großen Brocken. Sie zeigen ein Muster, das sich durch den gesamten Aufbau zieht: Jede neue Plattform bringt ihre eigenen Herausforderungen mit, und das Testen wächst mit ihnen.