Testen in der Zukunft

In der Ausgabe iX 12/2018  Die Zukunft von Softwaretestern: eine Prognose prophezeit Nils Langer den Softwaretestern ein düsteres Schicksal. Er postuliert, dass es in fünf Jahren keine Tester mehr geben wird. Inzwischen sind diese fünf Jahre vergangen und Software-Tester sind definitiv nicht ausgestorben. Und dafür gibt es mehr als einen guten Grund. 

Langner stützt seine These im Wesentlichen auf drei Grundannahmen: 

• Die Arbeit des Software-Testers bestehe im Wesentlichen aus der manuellen Überprüfung manueller Eingaben. 

• Die ISTQB-Zertifizierung sei zudem langweilig und konzentriere sich auf das Protokollieren von Ergebnissen und das Kennen und Einhalten von Standards. 

• Er bemängelt auch, dass die Testaufgabe nicht von einem einzelnen Tester, sondern von einem Team durchgeführt wird.  

In allen drei Punkten hat er meiner Meinung nach Unrecht. 

Softwaretester sind Qualitätsingenieure 

Der Beruf des Softwaretesters war und ist der eines hoch qualifizierten und motivierten Qualitätsingenieurs, an den hohe Anforderungen gestellt werden. Bereits 1995 beschrieb Edward Kit sechs wesentliche Anforderungen an das Testen von Software: 

• Die Qualität des Testprozesses bestimmt den Erfolg des Tests. 

• Verhindern Sie die Ausbreitung von Fehlerzuständen durch den Einsatz von Testverfahren in einer frühen Phase des Lebenszyklus. 

• Die Zeit für Softwaretestwerkzeuge ist jetzt. 

• Eine reale Person muss die Verantwortung für die Verbesserung des Testprozesses übernehmen. 

• Testen ist eine professionelle Disziplin, die geschultes und qualifiziertes Personal erfordert. 

• Pflegen Sie eine positive Teamhaltung der kreativen Kritik. 

Quelle: Edward Kit, Software Testing in the Real World, Addison-Wesley, 1995.) 

Spätestens seit Mitte der 90er Jahre gehören daher definierte Testaufgaben, die kontinuierlich und verantwortlich weiterentwickelt werden, zu einem professionellen Testumfeld. Der frühzeitige Einsatz von Werkzeugen ist dabei unerlässlich. Grundlegend für diese Aufgabe ist die Motivation, genau das zu finden, was noch nicht möglich ist. Es geht darum, Anreize zu entwickeln, das System an seine Grenzen zu bringen: “Wo geht es nicht mehr?” Dazu muss der Ingenieur die Fähigkeit mitbringen, kreativ und pfiffig um die Ecke zu denken. In jedem guten Tester steckt auch ein bisschen Hacker. Last but not least braucht es auch eine Qualifikation. 

Die von Langner als klassisch bezeichnete Rolle des Testers (nämlich ausschließlich manuell Testfälle durchzuklicken) kenne ich nur aus Unternehmen, in denen das Qualitätsmanagement nicht in den Kinderschuhen, sondern in den Windeln steckt. 

Aber auch diese Rolle stirbt nicht aus, sondern erlebt im Crowd-Testing eine neue Renaissance. Hier macht sie auch Sinn, denn die Herausforderungen sind z.B. darin, Systeme, die auf unterschiedlichen Plattformvarianten laufen, in realen Umgebungen zu testen oder die User Experience aus Nutzersicht bewerten zu lassen. Simulationen in virtuellen Umgebungen liefern hier nicht die notwendigen Informationen. Die Vielfalt der Konfigurationen seitens der Nutzer, der Hardware und der Erwartungen kann (auch mit künstlicher Intelligenz) nicht vollständig abgebildet werden. Crowd-Tests sind typische Beta-Tests und nicht unbedingt explorativ, wie Langer behauptet. Typische explorative Tests werden bereits im Systemtest von Testspezialisten im Team durchgeführt. Dies kann man zum Beispiel in James Whittakers wunderbarem Buch „Exploratory Testing“ nachlesen (oder in einer ISTQB-Schulung lernen 😉). 

Testen auf den Punkt gebracht 

Das Ausbildungsschema des ISTQB konzentriert sich auf einen risikobasierten Ansatz. In praktisch allen ISTQB-Lehrplänen ist risikobasiertes Testen der zentrale Aspekt. Ziel der in den Lehrplänen beschriebenen Testprozesse ist es, sicherzustellen, dass die projekt- und produktrelevanten Eigenschaften des Systems getestet werden - unabhängig davon, ob agil oder nicht-agil gearbeitet wird. Zentrale Aktivitäten sind dabei die kontinuierliche Identifikation und Bewertung von Risiken und die Ableitung entsprechender Tests – die sich nicht nur auf die Funktionalität beschränken dürfen. Neben einer detaillierten Beschreibung aller für ein effizientes Testen notwendigen Aktivitäten bieten die ISTQB-Lehrpläne einen vielfältigen Methodenkatalog, wie unterschiedlichste Produkteigenschaften getestet werden können. Diese werden in den Seminaren aktiv geübt – und zwar an praktischen Beispielen. 

Übrigens: Auch Nils Langner fordert einen risikobasierten Ansatz und beschreibt dazu genau die Vorgehensweisen, die bereits seit 20 Jahren in den ISTQB-Lehrplänen enthalten sind. 

Ein wesentliches Alleinstellungsmerkmal des ISTQB-Schemas ist das über Jahrzehnte sorgfältig gepflegte Glossar, das einen weltweit einheitlichen Austausch über Testthemen ermöglicht. So kann ein Certified Tester z.B. eine Teststufe wie den Beta-Test (eine Form des Abnahmetests) von einem Testverfahren wie exploratives Testen unterscheiden. Das ist für einen Tester so wichtig, wie für einen Koch der Unterschied zwischen einer Pfanne und einer Herdplatte. 

Das Team übernimmt die Aufgaben der Entwickler 

In Scrum gibt es weder die Rolle des Entwicklers noch die Rolle des Testers. Es gibt die Rollen Product Owner, Scrum Master und Entwicklungsteam. Das Entwicklungsteam ist funktionsübergreifend („cross-functional“), d.h. im für die Erstellung eines Produkts notwendigen Kompetenzen müssen im Team vorhanden sein – einschließlich des notwendigen Architektur-, Programmier- und Test-Know-hows (vgl. hierzu z.B. den Scrum Primer von Deemer et al.). 

Die Behauptung Tester (oder Entwickler) würden nicht benötigt, gehört ebenso in die Kategorie typischer agiler Missverständnisse, wie die immer wieder geäußerte Behauptung in einem SCRUM-Team müsse jeder alles können. Damit wäre jeder ersetzbar. Dies steht im direkten Widerspruch zum ersten Leitsatz des agilen Manifests: „Individuen und Interaktionen stehen über Prozessen und Werkzeugen“. Das Ziel dieses Leitsatzes ist folgendes zu unterstreichen: Prozesse und Vorgehensweisen sollen so angepasst werden, dass sie reale Menschen (Individuen), die tatsächlich im Team sind, mit all ihren Stärken und Schwächen optimal unterstützen. Und dazu gehört eben auch jemand, der sich mit dem Testen wirklich gut auskennt und entscheiden kann, wann welche Eigenschaft am effizientesten getestet werden kann.  

Nicht zuletzt müssen gute Tests unabhängig sein, denn wer seinen eigenen Code testet, testet in der Regel seine eigenen Erwartungen und ist damit betriebsblind. 

Fazit 

Meine bescheidene Meinung ist, dass das, was vor 20 Jahren galt auch noch in 5 und in 25 Jahren noch gelten wird: 

• Gutes Testen hängt von professionell beherrschten und verstandenen Testprozessen ab. 

• Gutes Testen braucht hervorragend ausgebildete und motivierte Testexpertinnen und -experten. 

• Gutes Testen braucht Erfahrung, Spezialisierung und lebenslanges Lernen. 

Und so wie sich die KI in den letzten fünf Jahren entwickelt hat, sieht es ohnehin ganz danach aus, dass Testerinnen und Tester unverzichtbar werden. Auch wenn es vielleicht bald keine Softwareentwickler mehr braucht, weil die KI die Software schreibt, wird es immer Menschen brauchen, die sie am Ende (nur) noch testen. 

Auf jeden Fall freue ich mich auf den nächsten Film mit Arnold Schwarzenegger und Linda Hamilton.