Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Heute bei mir zu Gast Alex Meister von der Firma Bucher & Sutter, einer Firma, die sich auf
Telekommunikationslösungen spezialisiert hat. Alex ist seit 2006 für das Thema Test und QoS verantwortlich und gibt uns einen Einblick in die Aktivitäten, die sie seitdem betrieben haben, um ihre Produkte besser zu machen, wie sie mit Fremdanforderungen umgegangen sind, ob sie Tools eingekauft oder selbst entwickelt haben und welche Ausbildungen die Tester genießen. Viel Spaß bei der Folge. Hallo Alex, schön, dass du da bist. Hallo Ritzi, danke für die Einladung.
Ja, sehr gerne. Du wurdest mir vom Swiss Testing Board von unserem gemeinsamen Bekannten Alessandro eben wärmstens empfohlen als Gesprächspartner und als wir im Vorgespräch waren, habe ich mir gedacht, ja das passt auch richtig gut, weil ihr sozusagen ein Paradebeispiel seid, wie man Testaktivitäten strukturiert aufsetzen, einführen kann ins Unternehmen und da wollen wir uns heute ein bisschen über eure Reise auch unterhalten, aber vorneweg, sag mal, du bist bei der Firma Buch und
Suchter, was macht ihr denn, dass wir mal so einen Rahmen haben?
Ja, was machen wir? Wir machen eigentlich Softwarelösungen im Bereich Kommunikation, Telefonie, Anbindungen vor allem zwischen der Cisco-Welt, sage ich mal, und den größeren CRM-Anbietern, die weltweit aktiv sind und da versuchen wir halt diese zwei Welten zusammenzubringen mit diversen Produkten, Software, die wir selber schreiben, die wir selber entwickeln und versuchen da natürlich die Kunden möglichst zu unterstützen, halt mit Features, die halt die Basissoftware nicht hergibt.
Ja, okay, aber auch sehr integrativ das alles dann, also wenn du da verschiedene Elemente zusammenbringst. Genau, das ist halt auch eine große Herausforderung auf der einen Seite, weil wir halt sehr prokrietäre Sachen dann haben. Ja, ich höre einen Hund im Hintergrund, hat er vergessen Gassi zu gehen? Nee, der ist gerade mit dem Kleinen beschäftigt. Normalerweise sind sie sehr ruhig, das ist halt die
Schwachen, die sie haben. Manchmal muss man sich auch da bemerkbar machen. Ja, sehr schön. Erzähl mal, also du bist ja QS-Lead und was war denn so eure Herausforderung? Wo habt ihr quasi begonnen, dem Thema mehr Energie zu geben und das dann auch als Druckgerät davon abzutreiben?
Das ist schon ein paar Jahre her. Ich bin ja damals 2006 zu Bukasuta gekommen, quasi direkt vom Studium und die Firma Bukasuta hat damals Indikationen geschrieben, vor allem für Microsoft und das war das erste, ich sag mal, große internationale Projekt, wo sie gemacht haben und ich war da im Prinzip Teil vom Entwicklungsteam damals. Und ja, da war Testing noch nicht institutionalisiert bei uns. Das war komplett fremd, sag ich mal, im Sinn von Struktur und so
weiter. Das war neu und ich war vielleicht ein halbes Jahr oder so in der Entwicklung tätig, wurde ich angefragt, wie das ausschaut, ob ich Lust hätte, mir das mal zu Gemüte zu führen. Ich habe natürlich etwas Vorwissen gehabt vom Studium her, aber natürlich nicht in dem Ausmaß und halt nur in der Theorie. Und ja, Cisco, wo wir halt da mit an Bord hatten, hat natürlich viel mehr Know-how gehabt, viel mehr Hintergrund gehabt schon und das wurde uns teilweise halt dann
aufs Auge gedrückt, dass ich das, was ich zu erfüllen habe. Das sind unsere Standards, die wir vorgehen und Machtmal. Und aus dem Machtmal wurde dann halt, schau dir das mal an, geh mal bei Cisco vorbei, lass dir das mal zeigen und dann gehen wir halt mal schrittweise an das Thema ran und fangen das bei uns dann halt auch ein. Das war dann halt so quasi der Startschuss 2006.
Naja, und was waren denn dann so die Steps, die dann so gegangen sind, die ihr so gegangen seid? Wo habt ihr denn angefangen in dem Ganzen? Also damals war natürlich primär klar, es waren manuelle Tests. Du musstest halt mal die ganzen Testfälle aufskizzieren, Testfälle beschreiben. Da die Plattformen oder die Anzubinden der CRMs noch unbekannt waren, da musste man halt einiges auch explorativ erarbeiten, gerade was halt die Expected Results angeht.
Wie sollte was reagieren? Das musste man halt dann einfach auch Step by Step quasi erarbeiten und mal schauen, wie das denn tut, wenn es dann mal läuft und so weiter. Also es spricht aber halt wirklich viel Hirnschmalz im Testcase-Erarbeiten verlangt. Das war am Anfang halt viel neu, sag ich mal.
Und dann hat man halt sehr oft, häufig sage ich mal, vielleicht zweimal im Monat, dreimal im Monat, hat man dann mit den Leuten von Cisco zusammengesessen und hat das dann auch mit durchgeschaut, ob sie noch
weitere Ideen hätten, Use Cases hätten, die man noch abdecken soll und so weiter. Und so hat sich das Step by Step ergeben, bis man dann irgendwie halt einen Testkatalog hatte von 400, 500 Use Cases oder Testfällen, die man halt dann abarbeitet hat, auf die unterschiedlichen Plattformen dann adaptiert.
Ja, das ist total spannend, dass du das sagst, weil ich finde, das ist ja, also wenn man jetzt nicht gerade die Testbasis so hingelegt bekommt in Form von ganz vielen wunderbaren Requirements, wo man sich abarbeiten kann, ist es ja immer so ein bisschen suchen und forschen, was sollte denn eigentlich gehen.
Und das habt ihr natürlich noch extrem, weil da noch ein anderes System da ist, das ihr vielleicht gar nicht gut kennt und sich das quasi erst on the fly mit erarbeiten, auch die ganzen Testfälle dazu zu überbauen. Also das ist natürlich ein ganz explorativer Ansatz. Und parallel dazu auch das ganze Testthema noch mit aufzuziehen und die Testfälle zu schreiben. Also ich kann mir vorstellen, dass das ganz schön herausfordernd auch war.
Es war sehr spannend, auf jeden Fall. Es war nie langweilig und die Erfahrungen halt am Anfang waren schon prägend auf eine Art, weil ich meine, ich komme aus der Welt des Entwicklers. Da ist man grundsätzlich mal stolz drauf, was man alles geleistet hat und will zeigen, was man alles kann oder was die Software alles kann, was sie gut macht. Und dann kommt halt die andere Welt und sagt, naja, das, was man kann, das ist ja schön gut und recht, aber mich interessiert
alles das, was nicht gut funktioniert. Mich interessiert das, was du halt nicht kannst. Und das war am Anfang schon, das war nicht ganz so einfach. Ich weiß nicht, ob man da gewisse Charaktereigenschaften braucht dafür oder nicht oder ob das halt eine Entwicklung ist, die man durchmacht. Aber das war am Anfang schon nicht einfach, quasi die Fehler zu suchen. Nicht die Fehler zu suchen bei den Leuten, sondern halt in der Software.
Ja, also wie ging es denn dann weiter für euch? Habt ihr dann die ersten paar hundert Just-Case-Test-Szenarien gehabt? Genau. Und dann war natürlich Last-Test ein riesengroßes Thema. Parallel dazu oder parallel dazu. Ergänzend. Hinten raus dann. Wenn man dann mal funktionell das so hingebracht hat, dass man gut dasteht. Die Test-Exit-Criteria, die wurden vorgegeben von Cisco,
weil es auch ein OEM-gelabeltes Produkt war von ihnen. Sprich, da haben wir schon mal so quasi die Schritte, die wir erreichen müssen, haben wir vorgegeben bekommen. Plus dann, wenn wir mal funktionell das abgedeckt hatten, wo erwartet wurde, war natürlich Last-Test ein großes Thema. Last-Test, am Anfang eher Memory-Leak-Test, wo man halt mal schaut, wie es so tut. Das war dann noch einmal eine neue Baustelle.
Noch einmal zusätzlich was Neues. Mit der Herausforderung, dass man halt, wir haben lange gesucht, wir haben viel angeschaut, aber es gab nichts, wo man quasi vom Markt nehmen konnte, wo es funktioniert. Wo man hätte sagen können, okay, mit ein bisschen Konfigurations-Hirnschmalz und Arbeitsstunden bringen wir das zum Laufen.
Es gab es nicht, weil du hattest halt zwei Welten. Man war sehr tief unten, ich sage mal, von den Layern her. Man war halt wirklich sehr maschinennah teilweise mit den Voice-Gateways und so weiter, die man programmiert hat. Und da konntest du nicht irgendein Tool nehmen, wo dir stupide halt irgendeine Oberfläche bedient hat, weil es die gar nicht gab.
Sprich, man musste auf API-Basis was machen. Und da kam dann halt wieder der nächste Schritt. Wir haben auf der einen Seite Last-Generatoren von Cisco gekriegt, wo halt die Voice-Last entsprechend simuliert mit komplettem Voice-Stream und so weiter, der aufgebaut wird. Also wirklich, dass halt auch was über die Leitung geht,
nicht nur Pseudosignalisierung. Und da mussten wir halt auf der Gegenseite auch etwas haben, was halt quasi das Call-Center oder halt die Agenten simuliert, das CRM abstrahiert. Also wenn du jetzt als Beispiel ein SAP anhängst, dann mussten wir was haben, was halt die ganze SAP-Welt quasi simuliert und abstrahiert. Und da fing man dann an, quasi die eigene Software zu machen, zu schreiben,
für die Testautomatisierung. Wir mussten dann halt wirklich Automatisierungssoftware halt von Grund auf aufbauen. Und die musste am Ende auch rock-solid laufen, weil du kannst nichts testen, wenn deine Software drum herum, die du baust, vorher in die Knie geht. Und da waren wir doch eine Weile beschäftigt damit, dass wir das sauber hingekriegt haben, dass wir da auch die verschiedensten Szenarien abbilden konnten und dann halt auch 24 und 48 Stunden überlebt haben.
Das war dann die Herausforderung, die große Herausforderung. Die haben wir dann mit entsprechendem Hirnschmalz hingekriegt. Wir haben halt einiges investieren müssen, um diese Roboter zu schreiben. Aber das war dann schon einiges an Aufwand, das wir tätigen mussten. Aber ein spannendes Umfeld.
Ich kann mir das echt vorstellen, weil das ist ja was anderes, als ob ich jetzt eine Website automatisiere und dann habe ich auch meine Loadbalancer, alles Mögliche, da kann ich meine Infrastruktur, da gibt es mittlerweile so viele Möglichkeiten. Aber ich stelle mir auch das von der Testinfrastruktur ja total komplex vor. Ich meine, so ein SAP ist ja jetzt nicht irgendwie einfach hingestellt. Das ist ja nicht das einzige System, das andere.
Du simulierst die Agenten rundherum und auf der anderen Seite diese Voice-Gyms, wo wahrscheinlich auch in meiner Welt relativ viele Daten sind, die dann auch auf einmal da sind. Das muss man ja alles irgendwo orchestrieren und nicht den Test dann scheitern lassen, nur weil irgendwo irgendein Switch dann irgendwie unterdimensioniert ist.
Netzwerkseitig, das ist echt eine Baustelle gewesen, das sagst du schon richtig. Am Anfang haben wir da einfach mal, naja, wir nehmen das, was wir gebraucht haben zum Entwickeln der Umgebung. Wenn da irgendwo halt ein Networkshare offen war oder irgendwas, dann wenn du 48 Stunden laufen lässt und nach 46 Stunden zieht einer irgendwo ein Update runter, dann war es das, dann fängst du wieder vorne an.
Und das endete halt damit, dass du wirklich ein dediziertes Load-System hast mit eigenem Core-Switch, mit eigenen Servern. Das Rack ist nur für das und ist von außen auch nicht zugänglich. Also du musst dann quasi über eine Konsole rein und das schottest du komplett ab, damit du dann wirklich nicht Fehler nachlängst, wo eigentlich gar kein Sinn da ist.
Ja, und ich glaube auch hier nochmal ist ja auch die Schwierigkeit, für mich mit Cisco oder mit so einer anderen Firma, die da im Hintergrund ist oder die quasi die Vorgaben macht, was laufen muss. Ich meine, die sind ja jetzt auch nicht irgendwie ein Startup, was ganz frisch ist, sondern die werden wahrscheinlich auch Vertragswerke haben und da müssen die Sachen quasi abnahmemäßig auch passen, die ja nachweisen müssen.
Ja, auf jeden Fall. Also du hast halt Resultate zu liefern. Das war teilweise dann so, dass du halt einmal die Woche ein Meeting hattest, wo es halt hieß, Hosen runter. Jetzt musst du zeigen, was du kannst oder nicht kannst. Und da gab es dann halt schon auch, naja, es gab Diskussionen. Ich kann mich an eine erinnern. 99,99% der Anrufe mussten durchkommen, also mussten korrekt abgehandelt werden.
Also ist es jetzt dasselbe, wie 0,01% können fehlschlagen. 0,01% schlugen fehl, ist aber nicht dasselbe, wie 99,99% sind korrekt. Man muss ja nicht so haarspalterisch sein, aber wenn du dann 10 Millionen Calls abhandelst, ist am Ende halt 99,99% nicht dasselbe, wie 0,01% schlagen fehl. Und das waren dann halt so Diskussionen, die einen dann auch gelehrt und geformt haben am Ende, weil sie sagen Schluss, Strich drunter, das passt oder geht zurück, passt noch nicht, nochmal drüber.
Ja, ich meine, aber muss man auch sehen, im Endeffekt führt das natürlich auch alles zu einer sehr guten Qualität, die dann da rauskommt. Also der ganze Invest ist ja jetzt nicht irgendwie bloß, sondern das bringt ja auch was. Wenn du jetzt so drauf schaust, du hast damals ja alleine den Job bekommen, kümmer dich jetzt mal ums Testen. Machst du das heute noch immer als One-Man-Show oder hast du ein Team, das dich ein bisschen unterstützt?
Nein, das wäre nicht mehr möglich, One-Man-Show. Es wurden natürlich mehr Produkte, das war auch nicht lange eine One-Man-Show. Ich habe 2006 angefangen, habe zuerst entwickelt, 2007 kam dann die erste Mitarbeiterin schon dazu und das ist dann stetig gewachsen natürlich. Auch mit den Aufgaben. Wir hatten immer das Glück, dass relativ früh 2006 erkannt wurde, den Stellenwert von der Qualitätssicherung und was das auch für Aufwand generiert.
Aber es ist ja nicht ein Selbstläufer, es passiert ja nicht von alleine. Und zu der Zeit war Testautomatisierung noch weit hinten. Gab es nicht viel, auf unserem Bereich sowieso nicht. Da kamen immer mehr Leute dazu und inzwischen hat man zwar Test-Spezialisten in dem Sinne, aber sicher dann immer das ganze Team, das am Ende für die Qualität gerade steht.
Aber jetzt hier, wir sind jetzt alles in allem neun Leute, die sich da drum kümmern, die sich das zu Gemüte führen, die halt dafür sorgen, dass auch die Qualität stimmt. Wie macht ihr das beim Team von neuen Test- und Test-Spezialisten und alle, die sich da in dem Thema Qualität auseinandersetzen? Verwendet ihr da irgendwelche Schulungen? Macht ihr das on the job? Wie kriegt ihr da den Wissenstransfer und die Weiterbildung organisiert?
Es ist so, dass wir natürlich stetig gewachsen sind. Wir haben eigentlich schon relativ früh auf ISTQB gesetzt, auf die Zertifizierungen, natürlich auch auf die Weiterbildung entsprechend. Kurse, externe wie interne Kurse und dann ist halt sehr viel Wissenstransfer passiert dann intern, wo wir halt dann wirklich gewisse Verantwortlichkeiten definiert haben.
Die beiden Leuten liegen, auch die Kompetenzen dazu ihnen entsprechend geben und dann haben wir einmal pro Monat, also setzen wir das ganze Team zusammen, wo wir halt dann, ich sag mal, testspezifische Themen durchleuchten.
Vielleicht mögliche Probleme, die in dem Monat aufgetaucht sind, vielleicht neue Software, die spannend sein könnte und so weiter. Alles, was rund ums Testen geht, setzen wir einmal im Monat das ganze Team zusammen und alternieren dann halt alle zwei Wochen, was eigentlich auch dann einmal im Monat ergibt.
Sitze ich noch mit jedem persönlich zusammen, dass wir halt, wenn jetzt wirklich projektspezifische Themen auftauchen, dass wir das noch durchleuchten können und vielleicht dann auch entsprechend definieren können, dass das dann im Kurs sinkt quasi, dann ein Bulletpoint auf der Liste ist, wo wir halt dann im Detail anschauen, dass der Austausch halt auch über die Projektteams hinweg gewährleistet ist.
Ja, verstehe. Du hast jetzt IST-Copy auch erwähnt, wenn du sagst, das ist, was hat denn euch das gebracht oder welche Zertifizierungen nutzt ihr da oder welche Ausbildungen davon, die haben ja einige und wo sagst du, ist da der Nutzen für euer Team? Also sicherlich, was sicherlich was bringt. Wir fangen mal ganz unten an beim Tester. Das ist halt mal so die Basis-Zertifizierung, die die Leute bei mir entweder schon gemacht haben oder halt machen müssen, in Anführungszeichen.
Damit wir mal vom selben sprechen. Zum einen, damit wir ein ähnliches oder gleiches Vokabular benutzen, hilft natürlich denjenigen, die das schon etwas länger gemacht haben, am Ball zu bleiben. Wenn du immer wieder Leute hast, die das frisch machen, die halt neu dabei sind, hilft also vor allem auch denen, die länger dabei sind, am Ball zu bleiben. Dann geht es halt weiter, je nachdem, was die Person halt für Schwerpunkte kriegt.
Ob das dann Test-Management ist, wo man dann weitergeht auf dem Advanced-Level oder ob das dann Test-Analyst ist, Technik-Test-Analyst. Das geht dann schon, je nachdem, was er halt macht oder in welche Richtung man sich entwickeln will. Das geht dann eigentlich auf der Basis weiter. Am Ende versuchen wir natürlich schon, dass die Leute bis mit dem Advanced-Level durchzertifiziert sind. Dass sie das mal als Rucksack mitnehmen können und als Basis halt dient.
Und das ist sicherlich da mal das eine. Man bleibt auch mit den Leuten in Kontakt, mit der Welt in Kontakt. Man tauscht sich auch aus, über diese Bekanntschaften dann sicherlich ein großer Nutzen und halt Know-How-Refresh, Know-How-Aufbau.
Ja, ich finde es auch ganz schön gerade da, das ist ja so wie ein bisschen ein Buffet auch. Diese ganzen Test-Methoden, die ganzen Stufenarten, das ganze Zeug, was wir rauf und runter spielen können. Da kann man sich dann immer wieder auch ein bisschen challengen, was brauche ich denn eigentlich, was muss ich machen.
Du hast ja viele Last-Tests gemacht und dann guckt man sich da wieder mal die ISO-25-10 an und denkt, Security ist wahrscheinlich bei euch auch ein Thema, das wird wahrscheinlich auch einen gewissen Fokus haben. Und so einfach die Sachen immer wieder auch dagegen zu halten und zu schauen, wo haben wir denn vielleicht noch Lücken, wo müssen wir ein bisschen mehr machen, wo können wir noch besser werden.
Jetzt, du hast ja quasi einige Dinge ja gemeistert, also quasi von dieses explorative Reinarbeiten in die ganzen Systeme, da überhaupt mal das ganze Test-Framework aufzubauen, jetzt mal logisch und auch technisch diese ganzen Last-Tests, da habt ihr ja sehr viel selber entwickelt. Was ist denn aktuell gerade so euer Fokus, wenn du jetzt so auf die Test- und QoS-Aktivitäten bei euch schaust? Wo habt ihr gerade so ein Vorhaben oder was wollt ihr gerade irgendwie auch angehen?
Naja, langweilig wird es nicht. Das hat jetzt nicht unmittelbar gestartet, aber Test-Automatisierung wird natürlich immer gern gesehen und groß geschrieben. Hat jetzt nochmal einen neuen Stellenwert gekriegt mit dem Schritt in die Cloud und mit CCD. Also das ist im Moment sehr zentral, dass man die ganzen Pipelines aufbaut und so weiter, dass das entsprechend sauber abgehandelt wird und auch ins Rollen kommt.
Aufgrund dessen CCD ist natürlich klar, dass Test-Automatisierung einen höheren Stellenwert kriegt. Das ist sicherlich der eine größere Brocken und das andere, wie du schon gesagt hast, IT-Security-Data-Protection, das ist halt auch mit der Cloud nochmal ganz etwas anderes, als wenn du das dediziert bei dir in deinem Server laufen hast. Ja, klar. Das sind nochmal ein paar andere Herausforderungen. Naja, spannend. Dann wird euch ja auf jeden Fall nicht langweilig.
Ich hoffe es nicht. Ich sage auch, das sind spannende Themen. Man macht das halt in meiner Persönlichkeit Schritt für Schritt alles mal mit und durch. Es hat alles seine Herausforderungen.
Ja, genau. Ja, sehr schön. Alex, vielen lieben Dank, dass du hier mal Rede und Antwort gestanden hast. Ich finde das immer total spannend, auch mal so einfach einen Deep Dive in ein Unternehmen rein, dass das quasi so über die Jahre mal aufgebaut hat, so ein bisschen die Meister uns umgesetzt hat und für sich erarbeitet hat, weil ich finde, so muss es sein.
Das ist immer schön, wenn man auch so Erfolgserlebnisse präsentieren kann. Ich glaube, das hilft dem einen oder anderen weiter, da auch zu sagen, okay, den Weg gehen wir weiter. Das macht Sinn auf jeden Fall. Also ich danke dir herzlich, dass du hier im Podcast warst und ich wünsche dir für die weiteren Vorhaben viel Erfolg und bis bald. Ja, vielen Dank und bis bald. Dankeschön.