Florian Fieber ist Gründer und Geschäftsführer der QualityDojo IT-Consulting GmbH in Berlin und seit knapp 20 Jahren als Berater und Trainer im Bereich der Qualitätssicherung von Softwaresystemen tätig. Seine Schwerpunkte liegen dabei im Testmanagement, der Verbesserung von Testprozessen sowie der Businessanalyse von Enterprise-Anwendungen. Gemäß der Unternehmensvision “Zufriedene Anwender durch bessere Software” unterstützt er seine Kunden durch strategische Beratung und operative Projektunterstützung sowie bei der Qualifizierung von Mitarbeitern und Teams. er engagiert sich außerdem ehrenamtlich im German Testing Board e.V. für die Weiterentwicklung des “ISTQB Certified Tester”-Schemas und ist aktuell Vorsitzender des GTB.
Wenn ich in die Zukunft unserer Profession blicken soll, blicke ich zunächst auf unsere Vergangenheit und meine persönlichen Erfahrungen zurück und versuche daraus Ableitungen für die Zukunft vorzunehmen. Ich gehe daher davon aus, dass sich unsere (technologische) Welt immer schneller und disruptiver ändern wird und wir in immer kürzeren Zeiträumen mit bedeutenden neuen Herausforderungen konfrontiert sein werden.
Ich weiß nicht, was konkret kommen wird. Ich weiß aber, dass sich die Dinge weiterentwickeln und verändern werden. Zum Beispiel haben wir heute einen gewissen “Common Sense”, wie man Projekte sinnvollerweise organisieren sollte. Das sah vor zwanzig Jahren noch ziemlich anders aus und wird sich in zwanzig Jahren wahrscheinlich ebenso stark von heute unterscheiden. Das gleiche gilt für die von dir erwähnten Schlagwörter wie KI, AR oder Blockchain. Dies alles sind für uns als Softwaretester Randbedingungen, welche wir nicht direkt beeinflussen, mit denen wir aber umgehen können müssen. Selbst beeinflussen können wir hingegen die Art und Weise, wie wir als Softwaretester arbeiten.
Ich sehe somit zwei große Herausforderungen, denen wir uns als Softwaretester stellen müssen: Zum einen muss ich mit den eben beschriebenen technologischen Veränderungen Schritt halten. Ich muss mein theoretisches und praktisches Wissen kontinuierlich ausbauen und mich mit den Themen, die sich am Horizont abzeichnen, frühzeitig und ernsthaft beschäftigen. Das ist der Teil, den wir typischerweise unter “lebenslanges Lernen” verbuchen und der erstmal gar nicht so spezifisch für Software Testing ist.
Zum anderen – und das empfinde ich aus Softwaretester-Sicht den wichtigeren Aspekt – sollte ich mein Handwerk insbesondere so beherrschen, dass es robust für die Zukunft ist, dass es nicht nur heute funktioniert, sondern wahrscheinlich auch in Zukunft funktionieren wird. Die grundlegenden Prinzipien, Methoden und Denkweisen eines Softwaretesters sind idealerweise unabhängig von konkreten Domänen, Systemen, Vorgehensweisen oder Werkzeugen und haben insbesondere eine wesentlich längere Haltbarkeit.
Ich weiß also nicht, was in zwanzig Jahren der “Common Sense” bei der Organisation von Projekten sein wird und mit welcher konkreten technologischen Disruption wir es dann zu tun haben werden – ich versuche aber, die grundlegenden Prinzipien des Softwaretester-Handwerks heute so zu beherrschen, dass es wahrscheinlich auch in zwanzig Jahren noch Gültigkeit haben wird und ich es “nur” noch an die dann gültigen Randbedingungen anpassen muss.
Zum Beispiel ist es nett, wenn ich heute ein konkretes Testmanagementwerkzeug beherrsche, es hilft aber nichts für die Zukunft, wenn ich die zugrundeliegenden Testmanagementmethoden nicht verstehe. Es ist heute gut, wenn ich eine bestimmte Testautomatisierungsplattform bedienen kann, hilft mir aber in der Zukunft nicht, wenn ich die grundlegenden Prinzipien der Testautomatisierung nicht beherrsche. Umgekehrt bin ich aber für die kommenden Testmanagementwerkzeuge und Testautomatisierungsplattformen gerüstet, wenn ich bereits heute die zugrundeliegenden Prinzipien und Methoden beherrsche.
Wie beschrieben, müssen wir das Testing der Zukunft prinzipiell nicht komplett neu erfinden. Trotzdem gibt es nicht das “eine” Testing, so wenig wie es das eine “Today Testing” gibt, wird es das eine “Future Testing” geben. Testing wird sich weiterentwickeln und bestimmte Trends und Schwerpunkte werden zukünftig sicher eine noch größere Rolle spielen.
Testen hat heute schon eine starke Akzeptanz, ich denke, dass sich das weiter festigen wird und Testen noch besser mit den anderen Entwicklungsaktivitäten verzahnt werden wird und sich vor allem in den frühen Phasen der Softwareentwicklung immer weiter etablieren wird. Außerdem wird sich der Fokus weiter auf den Test von Qualitätsanforderungen und nicht-funktionalen Aspekten richten, insbesondere in den Bereichen IT-Security, Usability und Interoperabilität. Und nicht zuletzt haben wir in den vergangenen zwei Jahren große Veränderungen bei den Möglichkeiten der virtuellen und verteilten Zusammenarbeit erlebt und erlernt. Das Pendel wird sicherlich nicht wieder von 100% Remote zu 100% On-Site zurückschwingen. Wir haben aber gesehen, dass Remote funktionieren kann und müssen uns daher noch stärker mit den technischen und sozialen Herausforderungen bei verteiltem Testen auseinandersetzen, um die richtigen Rahmenbedingungen zu schaffen und zu erhalten.
Neben dem lebenslangen Lernen, einer richtigen Denkweise und dem Beherrschen der richtigen Prinzipien und Methoden hilft es uns in der Community vielleicht, wenn wir uns manchmal weniger mit Rollen, als mit Aufgaben beschäftigen würden. Bspw. ist es aus meiner Sicht müßig und energieraubend sich mit der Frage zu beschäftigen, ob “man heutzutage noch eine/n Testmanager/in braucht”. Wir sollten uns dabei von der Frage nach der richtigen Rollenbezeichnung lösen und uns damit beschäftigen, welche Aufgaben wichtig sind und wie wir diese Aufgaben bestmöglich und nachhaltig in unserem spezifischen Projektkontext abbilden können. Es wird auch in Zukunft klassische Organisationsformen geben, in denen Projekte hierarchisch organisiert sind und “man eine/n Testmanager/in braucht” – ob man das persönlich gut oder schlecht findet, spielt dabei überhaupt keine Rolle. Und gleichzeitig wird es daneben holokratische Organisationsformen geben, die völlig anders funktionieren werden. In beiden Formen müssen wir jedoch Software Testing adäquat abbilden und es würde jeder Seite helfen, den eigenen Arbeitsalltag weniger dogmatisch zu betrachten.