BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
CALSCALE:GREGORIAN
PRODID:-//WordPress - MECv7.33.0//EN
X-ORIGINAL-URL:https://www.austriantestingboard.at/
X-WR-CALNAME:Austrian Testing Board
X-WR-CALDESC:ISTQB in Österreich
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:20260329T030000
RRULE:FREQ=YEARLY;BYMONTH=03;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:20261025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=4SU
END:STANDARD
END:VTIMEZONE
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
CLASS:PUBLIC
UID:MEC-ae2a2db40a12ec0131d48acc1218d2ef@austriantestingboard.at
DTSTART;TZID=Europe/Berlin:20140507T173000
DTEND;TZID=Europe/Berlin:20140507T210000
DTSTAMP:20220526T142842Z
CREATED:20220526
LAST-MODIFIED:20220526
PRIORITY:5
SEQUENCE:0
TRANSP:OPAQUE
SUMMARY:Destruktives Testen
DESCRIPTION:\n„Testen ist ein Prozess, Programme auszuführen – mit der Intention, Fehler zu finden!“ so oder so ähnlich lässt sich „Destruktives Testen“ verstehen.\n\n\n\nWas 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“.\n\n\n\nSicher, 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?\n\n\n\nEs 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… .\n\n\n\nFü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… .\n\n\n\nIm Anschluss werden Vortragsinhalt und weiteres zu „Destruktives Testen“ moderiert diskutiert. Hans Hartmann wird gemeinsam mit 2 weiteren Fachexperten sich Ihren Fragen stellen.\n\n\n\nVortrag: Destruktives Testen\n\n\n\nWenn 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.\n\n\n\nDie 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.\n\n\n\nAls 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?\n\n\n\nUm 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.\n\n\n\nIn 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.\n\n\n\nFolgende Fragen ergeben sich:\n\n\n\nKann 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?\n\n\n\nReferent: Hans Hartmann\n\n\n\nHans Hartmann, geboren 1951, seit 2007 OBJENTIS Mitarbeiter und Prokurist, seit 2011 Geschäftsführer der serbischen Niederlassung von OBJENTIS d.o.o.\n\n\n\nIn 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.\n\n\n\nVon 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.\n\n\n\nWie 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.\n\n\n\nHerr 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.\n\n\n\nIm Gespräch\n\n\n\nHans Hartmann (OBJENTIS)Thomas Scheichenstein (OBJENTIS)Karl Kemminger (AUVA, ATB)\n\n\n\nDownloads\n\n\n\nDownload EinführungsfolienDownload Vortragsfolien\n
URL:https://www.austriantestingboard.at/events/destruktives-testen/
CATEGORIES:ATB Fluchtachterl
LOCATION:„The Stage“ im Tech Gate Vienna
END:VEVENT
END:VCALENDAR