Allerdings muss auch das Software-Testing effizient und effektiv sein, betont Pichler im Interview. Ihm geht es dabei nicht nur um die eigentliche Testdurchführung, sondern darüber hinaus auch um die Automatisierung von Testimplementierung, -entwurf, -reporting und weiterer Testaktivitäten. Natürlich sprachen wir mit ihm auch über die Rolle des ATB, über Eigenheiten des österreichischen Marktes und insbesondere auch über internationale Standards sowie die Zusammenarbeit des ATB mit den Kollegen in Deutschland und der Schweiz.
- title
- Zur Person
- subtitle
- Ing. Helmut Pichler
- introduction
- Ing. Helmut Pichler unterstützt als Tester und Testmanager „aus Leidenschaft“ seit vielen Jahren Kunden und Projekte aus verschiedenen Branchen als Berater und Manager bei den Themen Softwaretest und -qualität. Der Aufbau und die Etablierung des Berufsbildes „Softwaretester“ ist eines seiner Ziele. Ein wesentlicher Bestandteil des Berufsbildes ist für den Co-Autor des Buchs „Agile Testing“ der strukturierte Wissensnachweis, idealerweise in Form international anerkannter Zertifizierungen. Als ehrenamtlicher Präsident des „Austrian Testing Board“ hat Helmut Pichler deshalb dafür gesorgt, dass das ATB die offizielle Vertretung des „International Software Testing Qualifications Board“ (ISTQB) in Österreich ist. Als Präsident des ATB ist er in mehreren internationalen Arbeitsgruppen aktiv, wo er gemeinsam mit anderen Top-Experten den internationalen Teststandard weiterentwickelt. Im Hauptberufarbeitet Pichler aktuell als QA-Engineer in Emerging-Technology-Projekten und ist verantwortlich für das gesamte Schulungsprogramm bei Nagarro, einem weltweit führenden Unternehmen für digitale Produktentwicklung.
- image
- 20210213_Helmut-3756-crop_v2
Herr Pichler, seit mehr als 15 Jahren sind Sie Präsident des „Austrian Testing Board“. Worin sehen Sie die Hauptaufgaben des ATB?
Helmut Pichler: Wir stellen primär sicher, dass alle, die es wollen, in Österreich die weltweit erfolgreichsten und anerkannten Zertifikate im QA-Bereich erwerben können. Genau deshalb ist das ATB die offizielle Vertretung des „International Software Testing Qualifications Board“ – kurz ISTQB.
Im Jahr 2002 wurde das ATB gegründet und war dann auch Gründungsmitglied des ISTQB. Das ISTQB hat mit dem Certified-Tester-Schema einen weltweit etablierten Ausbildungsstandard für das Software-Testing geschaffen. Wir haben dafür gesorgt, dass man österreichweit über unseren geprüften Exam-Provider diese Zertifikate erlangen kann – dass es also Trainingsanbieter gibt, die mit vom Board geprüften und akkreditierten Unterlagen Ausbildungen zum umfangreichen ISTQB-Portfolio anbieten. Und wir kümmern uns darum, dass die angebotenen Zertifizierungsprüfungen qualitativ hochwertig sind.
Wir fungieren außerdem als unabhängige Anlaufstelle für Tester, all die Menschen, die es noch werden wollen und nicht zuletzt natürlich auch für die gesamte Testing-Community in unserem Land. Die möchte ja auch auf dem Laufenden gehalten werden, was in Österreich beziehungsweise im DACH-Raum so abgeht.
„Die Unternehmen haben gelernt, dass eine Konformitätsnote 1 für das Befolgen der Agil-Bibel nicht reicht, wenn man professionelle Software mit guter Qualität erhalten will.“
Welche dieser Aufgaben können – und müssen Sie vielleicht sogar – national und sehr spezifisch adressieren? Und welche der ATB-Aufgaben sind eher länderübergreifend zu lösen, zum Beispiel im Rahmen des ISTQB oder mit ihren Nachbarn vom German und vom Swiss Testing Board, kurz GTB und STB?
Pichler: National gilt es einerseits, hiesige Trainingsanbieter zu finden und auch zu unterstützen, andererseits aber auch erfahrene Exam-Provider mit qualitativ hochwertigen Fragen auszustatten. Länderübergreifend fließt unsere Expertise in die Arbeitsgruppen des ISTQB ein, die Begriffe definieren und die Lehrpläne für die verschiedenen Module erstellen und weiterentwickeln.
Hinzu kommt das große Thema der Lokalisierung aller ISTQB-Materialien. Da bin ich sehr dankbar, dass wir das gemeinsam mit unseren Nachbar-Boards in Deutschland und der Schweiz – GTB und STB – umsetzen können, mit denen wir intensiv, produktiv und vor allem freundschaftlich zusammenarbeiten. Dass es beispielsweise eine deutsche Übersetzung der Lehrpläne und Begriffe gibt, ist unserer guten Zusammenarbeit zu verdanken. Alleine könnten wir das gar nicht schaffen.
Wenn Sie einen Vergleich wagen: Wie hat sich das Berufsbild des Softwaretesters in Österreich in den letzten 15 Jahren verändert?
Pichler: War anfangs oft noch Überzeugungsarbeit nötig, dass es gscheit ist, in die Ausbildung von Testern zu investieren, wurde der Softwaretest später völlig selbstverständlich. Unternehmen begannen sogar schon, ISTQB-Zertifikate als Voraussetzung für den Job als Tester zu verlangen.
Dann aber wurde die Softwareentwicklung „agil“, was zunächst für einen kleinen „Rückschlag“ sorgte. Die Ära der lupenreinen Agile-Berater brach an, die zwar keinerlei Ahnung von Software-Engineering hatten, dafür aber die „agilen Prinzipien“ rauf und runter rezitieren konnten. Und während jeder Punkt und jedes Komma im „Manifesto for Agile Software Development“ verpflichtend umzusetzen war (sonst war man ja nicht agil), wurde beim Test gerne geschludert. Der Grund ist so einfach wie banal: Im Manifesto kommen in der Team-Definition gar kein Tester vor.
„Mittlerweile sehe ich erfreulicherweise, dass das Thema Testen in den Unternehmen angekommen ist. Es werden am Markt händeringend Tester gesucht – und unser Zertifikat ISTQB CT FL ist nahezu überall ein Must-have bei den Stellenausschreibungen.“
Diese heikle Phase ist Gott sei Dank vorbei. Die Unternehmen haben gelernt, dass eine Konformitätsnote 1 für das Befolgen der Agil-Bibel nicht reicht, wenn man professionelle Software mit guter Qualität erhalten will. Und so sind nach und nach die Tester wieder ins Rennen gekommen. Aktuell gibt es kaum noch Unternehmen, in denen die Tester nicht zu den Erfolgsfaktoren zählen; hier sag ich nur Testautomatisierung.
„Der Fokus verlagert sich jedoch vom rein manuellen Test hin zu technisch versierterem Testen. Das hat wohl vor allem mit dem Setting – Stichwort ‚Agile Teams‘ – zu tun.“
Wie ist es insgesamt heute in Österreich um die Disziplin des Softwaretestens bestellt?
Pichler: Mittlerweile sehe ich erfreulicherweise, dass das Thema Testen in den Unternehmen angekommen ist. Es werden am Markt händeringend Tester gesucht – und unser Zertifikat ISTQB CT FL ist nahezu überall ein Must-have bei den Stellenausschreibungen.
Der Fokus verlagert sich jedoch vom rein manuellen Test hin zu technisch versierterem Testen. Das hat wohl vor allem mit dem Setting – Stichwort „Agile Teams“ – zu tun, weil hier die Tests direkt in die Tool-Frameworks eingebunden sind. Eines ist doch klar: Continuous Integration & Development bedeutet eben auch Continuous Testing. Falls die Tester dann auch noch Automatisierungs-Skills mitbringen, sind sie sowieso die Helden (schmunzelt). Für erfahrene technische (Agile) Tester oder Test-Automation-Engineers stehen in der deutschsprachigen Welt die Türen der Unternehmen sperrangelweit offen.
„Der Schlüssel zum Erfolg ist die seriöse Betrachtung der nichtfunktionalen Qualitätsmerkmale gemäß ISO 25010 – also Security, Portabilität, Zuverlässigkeit oder Performance, um nur ein paar zu nennen.“
Im Zuge der Modernisierung sollen selbst Legacy-Anwendungen zum Beispiel auch „Emerging Technologies“ wie KI/Machine Learning, IoT, Drohnen oder „Augmented Reality“ nutzen. Wie können die so entstehenden Softwaresysteme mit bewährten Methoden getestet werden? Oder sind dann in jedem Fall neue Methoden gefragt? Und wenn das der Fall ist: Welche?
Pichler: Das ist natürlich die Frage, die uns aktuell alle beschäftigt in der Szene. Welche Methoden eignen sich für KI/ML – und wie können wir die starke Abhängigkeit der KI- und ML-Systeme von den Hardware-Devices beim Testen sinnvollerweise berücksichtigen?
Bei Nagarro, wo ich arbeite, haben wir bereits einige Erfahrungen gesammelt. Meine „Best Practice“: Mit den altbewährten Test-Vorgehensmodellen und -Entwurfstechniken aus dem ISTQB Foundation Level sozusagen „im kleinen Finger“, verstärkt um erfahrungsbasierte-, explorative Testansätze und viel Geduld und Kreativität kann man am besten für die erforderliche Flexibilität sorgen. Außerdem werden die teilweise unberechenbaren und überraschenden Besonderheiten der „Things“ und Devices etwas planbarer.
Der Schlüssel zum Erfolg ist die seriöse Betrachtung der nichtfunktionalen Qualitätsmerkmale gemäß ISO 25010, also Security, Portabilität, Zuverlässigkeit oder Performance, um nur ein paar zu nennen – und das sowohl in der konstruktiven als in auch analytischen Qualitätssicherung. Sonst ist der aus Asterix & Obelix bekannte Gallier-Effekt bei den Piraten zu befürchten: „Sobald Gallier auftauchen, versenken die Piraten ihr Schiff“. Wir mit unseren Apps wären die Piraten mit ihrem vorauseilenden Gehorsam – und das Nicht-Berücksichtigen des Device-Verhaltens die Gallier.
„Automatisieren ist wie das Gehen über Wasser: Beides funktioniert umso besser, je mehr die Grundlage eingefroren ist.“
Inwieweit lässt sich Softwaretesten automatisieren – und wo bleiben auch in Zukunft die Kreativität, das handwerkliche Geschick und die Intuition des Menschen gefragt?
Pichler: Moderne, erfolgreiche Testautomatisierung funktioniert nicht mehr wie früher nach der Devise: „Wir kaufen ein Tool und legen los“. Angefangen hat es mit intelligenten Testautomations-Frameworks, die die Redundanzen minimieren. Diese wurden mehr und mehr professionalisiert, sind vielseitiger und toolunabhängig geworden.
Nun werden in die Automation mehr und mehr KI-Ansätze integriert, zum Beispiel zur Fehlererkennung oder zur Klassifizierung bei Automatisierungsläufen. Auch hier gilt dasselbe wie beim klassischen Test: Auf dem über Jahre gelernten und weiterentwickelten Tool- und Methoden-Set aufsetzen und „neugierig und kreativ“, also mit PI („People Intelligence“), weiterentwickeln.
Ach ja, eines noch: Automation ist mittlerweile reif geworden, quasi vom Teen (reine Testautomation) zum Erwachsenen (eigenes, integriertes Projekt im Projekt). Und das heißt auch: Für das Testen sind Vollprofis gefragt.
Wie bewerten Sie Testautomatisierung im agilen Kontext? Eigentlich schreiben Automatismen ja bestimmte Abläufe fest und gelten als Gift für agile Projekte ...
Pichler: Stimmt! Automatisieren ist wie das Gehen über Wasser: Beides funktioniert umso besser, je mehr die Grundlage eingefroren ist. Bei agilen Methoden haben wir inzwischen gelernt, dass ohne Testautomation nichts geht. Allein schon die wachsende Funktionalität bringt ein Team rasch an die Grenzen der Testkapazitäten. Hier gilt es – und das haben die „Mädls und Jungs“ aus der Testing-Community mittlerweile genial hinbekommen –, mit innovativen Ansätzen ein „Gegengift“ zu entwickeln und wirksam gegenzusteuern.
„Für den Testerfolg ist außerdem eine Form des Reporting notwendig, das möglichst kurz und bündig eine Status-Interpretation zulässt, zum Beispiel nach dem KISS- Prinzip ‚Keep It Simple & Straightforward‘ oder wie der berühmt- berüchtigte Elevator-Talk.“
Sie gelten als Pragmatiker, der Zielorientierung in Projekten höher bewertet als die Konformität der Entwicklungsprozesse zu den grundlegenden Methoden. Wie wägen Sie ab, wie viel Methode zwingend notwendig ist – und wie viel kreativen oder handwerklichen Spielraum die Entwickler und Tester haben sollten?
Pichler: Oh, hat sich das schon herumgesprochen?! Ja, manch einer ist davon überrascht. Viele erwarten: Jetzt kommt Mr. ISTQB und setzt alles aus dem Lehrplan bis auf das i-Tüpfelchen genau um. Doch dazu bin ich schon zu lange im Geschäft und habe bereits sehr früh die „Brille des Endkunden“ entdeckt, mit der ich primär an Testaufgaben und -projekte herangehe. Hier spielte mir Agil stark „in die Karten“: Mach nur das, was wirklich Wert hat oder stiftet, also wirklich wichtig ist für den Kunden und dessen kritische Geschäftsprozesse. Für den Testerfolg ist außerdem eine Form des Reporting notwendig, das möglichst kurz und bündig eine Status-Interpretation zulässt, zum Beispiel nach dem KISS-Prinzip „Keep It Simple & Straightforward“ oder wie der berühmt-berüchtigte Elevator-Talk.
Was ist das Wichtigste für den Projekterfolg?
Pichler: Das Wichtigste ist: Jede/r im Team lebt „für das Team“ und fokussiert sich zu 100 Prozent auf das gemeinsame Ziel, dem Kunden so rasch als möglich die Software zu liefern. Für das Management gilt die Devise: Vertraue ins Team! Und für alle: transparent, ehrlich (auch gegenüber dem Auftraggeber!), auf Augenhöhe, ziel- und lösungsorientiert kommunizieren! Daraus leiten sich dann auch die entscheidenden Soft Skills ab: Team-Player, Vertrauen und Kompromissbereitschaft. Wenn alle auf sich selber schauen, hilft das dem Team. Und wie heißt es zu schön: „Geht’s dem Team gut, dann geht’s auch dem Kunden und dem Projekt gut!“
Herr Pichler, vielen Dank für das Interview!
