Destruktives Testen
„Testen ist ein Prozess, Programme auszuführen – mit der Intention, Fehler zu finden!“ so oder so ähnlich lässt sich „Destruktives Testen“ verstehen.
Was sind die Schattenseiten dieses prinzipiell „OK“ Ansatzes? Nun, um in einem Software System Fehler im Sinne oben stehender Definition zu bekommen, brauchen wir auch z.B. Testdaten, die an den internen Zustandsübergängen unserer Software liegen – also Grenz- und Extremwerte. Oder wir konfrontieren unsere Software mit Abläufen, für die sie aber auch ggf. nicht gebaut ist. Damit sind wir auf der sicheren Seite und wir bekommen „schön viele Fehler“.
Sicher, damit bekommen wir „erfolgreich“ viele Fehler serviert und könnten als TesterIn glücklich sein. Können wir? Oder nur ein bisschen? Oder gar nicht?
Es ist richtig, destruktiv zu Testen, wenn das Ziel dafür passt. Aber im Regelfall auch falsch nur Fehler zu suchen. Denn auch die korrekte Funktionsweise der Lösung kann einen Software Tester ganz schön glücklich machen… .
Für diesen ATB Expertentreff hat sich Hans Hartmann, OBJENTIS Prokurist und Geschäftsführer der serbischen Niederlassung von OBJENTIS d.o.o. bereit erklärt, Klarheit in diese Aufgabenstellung aus dem Tester Alltag zu bringen: Er wird im Rahmen seines Vortrags „Destruktives Testen“ zeigen, was man sich im Kontext beim Testen fragen muss und wie man die Schwachstellen seines Testobjekts identifiziert und auslotet. Hans Hartmann, quasi der bad guy im Projekt, mit dem Ziel die Software zu „brechen“ – bevor es andere tun… .
Im Anschluss werden Vortragsinhalt und weiteres zu „Destruktives Testen“ moderiert diskutiert. Hans Hartmann wird gemeinsam mit 2 weiteren Fachexperten sich Ihren Fragen stellen.
Vortrag: Destruktives Testen
Wenn man sich von der relativ einfachen Fehleinschätzung trennen kann, dass Testen durch “Ausprobieren, ob es geht” beschrieben ist, gelangt man sehr rasch zur Fragestellung, was denn beim Testen wirklich zu tun ist. Die Zielsetzung, Fehler zu finden, kann akzeptiert werden, wenn der gesamte Prozess der Fehlererkennung, Fehlerbehebung und des Umgangs mit Change-Requests reglementiert ist.
Die Untersuchung, wie den Fehler am leichtesten zu finden sind hat in der Vergangenheit ergeben, dass es dazu einer “destruktiven Kreativität” bedarf. Der Begriff der destruktiven Kreativität wird heute von einigen genutzt, er hat auch seine Verwendung im biologischen Umfeld in Bezug auf Parasiten gefunden.
Als die bösartigsten Programmfehler können heute wohl jene angesprochen werden, welche die Sicherheitsbarrieren zu geschlossenen Systemen aufweichen, d.h. gutartigen aber auch bösartigen Hackern das Eindringen in fremde EDV-System und deren Datenbanken ermöglichen. Um diese Fehler zu finden, muss sich die Testerin in die Gedankenwelt eines Hackers einfühlen können und seine Methoden kennen. Im Weiteren können sich schwere Fehler aber selbst ohne Eingriffe von außen dahingehend auswirken, eine Datenbank sich über kurz oder lang selbst korrumpiert. Die Frage, die sich die Testerin stellen muss, ist daher: Was kann denn überhaupt passieren? Was ist das Schlimmste, was passieren kann? Wenn das testsystemische Denken an diesem Punkt angelangt ist, heißt es: Wie kann ich einen entsprechenden Zustand simulieren?
Um diesen Denkvorgang zu veranschaulichen geht der Vortrag von einer Zeit aus, als noch mit Hardware “gerechnet” wurde, einer Zeit als Logiksignale mit dem Oszilloskop und später mit Logic-Analyzern verfolgt wurden. Im Jahr 1977 wurde der erste Signatur-Analysator von HP auf den Markt gebracht. Mit den Werten, die bei korrekt verarbeitenden Schaltungen, abgelesen werden konnten, wurde das Prinzip der “Fault-Injection” ermöglicht. Eine Schaltung wurde bewusst in einen unmöglichen Zustand gebracht, um zu sehen, wie das Gesamtsystem reagieren würde.
In der heutigen Zeit denkt keiner an diese Hardware-Analogie. Doch Bücher wie “How to Break Software” (James A. Whittaker, 2003, Addison-Wesley) und “How to Break Web Software” (Mike Andrews, James A. Whittaker, 2006, Addison-Wesley) lassen, verbinden die alten Fault-Injections mit den Möglichkeiten heutiger Software-Tools.
Folgende Fragen ergeben sich:
- Kann man Destruktivität lernen?
- Gibt es systematische Vorgehen, die genau destruktives Testen unterstützen?
- Letztlich geht es um die Frage, wer kann die Software früher (zer)stören? Der Tester oder der Hacker?
Referent: Hans Hartmann
Hans Hartmann, geboren 1951, seit 2007 OBJENTIS Mitarbeiter und Prokurist, seit 2011 Geschäftsführer der serbischen Niederlassung von OBJENTIS d.o.o.
In weiteren Funktionen leitet Herr Hans Hartmann Test Director den technischen Test bei OBJENTIS. Zu seinen Schwerpunkten zählt die Unterstützung von Softwareunternehmen beim Aufbau und der Reorganisation von Testteams sowie bei der Einführung und Optimierung von Testprozessen.
Von 1997 bis 2002 war Hartmann bei einem Versicherungsunternehmen als Leiter des Softwaretests und von 2002 bis 2007 als Chief Architect beschäftigt. In beiden Funktionen hat Herr Hartmann direkt der Geschäftsleitung bzw. dem IT und Finanz-Vorstand berichtet.
Wie kaum ein anderer Experte verbindet Herr Hartmann Kenntnisse und Erfahrungen aus der IT-Architektur im Software Test mit Management- und Teamleitungsfähigkeiten. Ganz besonders zeichnet ihn strategisches Denken aus.
Herr Hartmann ist Lektor an der TU Wien und der TU Leipzig (Software Engineering großer betrieblicher Informationssysteme), er hat auf Konferenzen in den USA, in Deutschland und Österreich und letztlich Serbien zahlreiche IT-Vorträge gehalten.
Im Gespräch
- Hans Hartmann (OBJENTIS)
- Thomas Scheichenstein (OBJENTIS)
- Karl Kemminger (AUVA, ATB)
Downloads
