25. Oktober 2012

== 4. Baden-Württemberg Testing Day - "Test the Best"==

Zum 4. Mal: das Treffen für Alle, die mit Testen zu tun haben - nicht nur in Baden-Württemberg!

<i>Änderungen möglich!!!</i><br><br>

==Veranstaltungsdaten==

<b>Datum:</b> Donnerstag, den 25. Oktober 2012

<b>Beginn:</b> 13:30 Uhr

<b>Ort:</b> [http://www.tae.de TAE Esslingen], An der Akademie 5,  73760 Ostfildern. [https://maps.google.de/maps?q=TAE+Esslingen&ll=48.716988,9.290314&spn=0.009089,0.023024&oe=utf-8&client=firefox-a&fb=1&gl=de&hq=TAE+Esslingen&cid=0,0,2327450662765479394&t=m&z=16 (Google Maps)]

<b>Anmeldung:</b> bitte melden Sie sich bis spätestens zum 22. Oktober 2012 über die [https://www.asqf.de/fachgruppentermine-anzeige/events/id-18102012-4-baden-wuerttemberg-testing-day.html ASQF Anmeldeseite] an!
<br>

==Agenda==

{| class="wikitable" style="text-align:center"
|- class="hintergrundfarbe5"
! Uhrzeit !! Track 1 !! Track 2
|-
| 13:30 || colspan="2" align="center" | Registrierung mit Imbiss
|-
| 14:00 || colspan="2" align="center" | <b>Keynote<br> Software-Test Gestern, Heute, und Morgen</b><br> (Prof. Mario Winter)
|-
| 15:00 || <b>Ein Programmierer sieht rot: <br> Was tun bei fehlerhaften JUnit-Tests? </b><br> (Oliver Böhm / T-Systems)|| <b>Agile Software-Entwicklung und Test mit <br> Automotive Open System Architecture (AUTOSAR)</b><br> (Peter Wagner / Bosch)
|-
| 15:30 || colspan="2" align="center" | Pause mit Ausstellung
|-
| 16:15 || <b>Testen von variantenreichen Systemen</b><br>(Dr. Sebastian Oster / CGI Logica)|| <b> Continous Integration mit Jenkins</b><br> (Prof. Dr. Simon Wiest / HdM Stuttgart)
|-
| 17:00 || colspan="2" align="center" | Pause mit Ausstellung
|-
| 17:45 || <b>Performancemessungen und -analysen bei 3-Tier-Systemen <br> Ein praktisches Beispiel</b><br> (Prof. Dr. Dörsam / HdM Stuttgart) || <b>Agiles Testen - ein Erfahrungsbericht</b><br> (Michael Fischlein / Sogeti)
|-
| 18:35 || colspan="2" align="center" | <b>Wie Impro Theater einem Tester das Leben retten kann</b><br> (Lars Metze/CGI Logica)
|-
| 19:00 || colspan="2" align="center" | Come Together mit Ausstellung & Verlosung
|}

==Inhalt und Ziel der Veranstaltung==

<i>Informationen dazu kommen ganz bald.</i>

<br>

==Aussteller==

- ASQF - Arbeitskreis Software-Qualität und -Fortbildung e.V. [http://www.asqf.de/ www.asqf.de]<br>
- eXept Software AG (expecco/expeccoNET) [http://www.exept.de/ www.exept.de]<br>
- GFB Softwareentwicklungsgesellschaft mbH (Q-up) [http://www.gfb-softwareentwicklung.com/Produkte.html/ www.gfb-softwareentwicklung.com]<br>
- Logica Deutschland GmbH & Co. KG  [http://www.logica.de/ www.logica.de]<br>
- Sogeti Deutschland GmbH [http://www.sogeti.de/ www.sogeti.de]<br>
- NEOTYS<br>
- iSQI GmbH<br>

und weitere

==Sprecher==

===Keynote: Software-Test Gestern, Heute und Morgen===
(Prof. Dr. Mario Winter / FH Köln)<br>
<br>
'''Zusammenfassung:''' <br>
Vor über 30 Jahren erschien unter dem Titel »The Art of Software Testing« von Glenford Myers die erste Monographie zum Thema Softwaretest, die seitdem zigfach unverändert nachgedruckt wurde. Seitdem ist die Literatur zum Softwaretest förmlich explodiert. Dieser Beitrag beleuchtet die geschichtliche Entwicklung des Softwaretests von den ersten Anfängen der Computerei bis hin zu aktuellen Forschungsthemen wie modellbasierten und heuristischen Verfahren zur Testfallermittlung. Verknüpfungen zum Stand des Softwaretests in der Praxis runden den Beitrag ab.<br>
<br>

'''Zur Person:''' <br>Prof. Dr. Mario Winter ist am Institut für Informatik der
Fachhochschule Köln und dort Mitglied des Forschungsschwerpunkts
»Software-Qualität«. Er ist Gründungsmitglied des German Testing
Board e.V. und war von 2003 bis 2011 Sprecher der GI-Fachgruppe
»Test, Analyse und Verifikation von Software«. Seine Lehr- und
Forschungsschwerpunkte sind Softwareentwicklung und Projektmanagement,
insbesondere die modellbasierte Entwicklung und Qualitätssicherung
von Software. Er ist Autor und Mitautor zahlreicher Publikationen
im Bereich Softwareentwicklung und Softwaretest.<br>
<br>

===Ein Programmierer sieht rot - Was tun bei fehlerhaften JUnit-Tests?===
(Oliver Böhm / T-Systems)<br>
<br>
'''Zusammenfassung:''' <br>
Dank agiler Methoden dringen Unit-Tests (zu recht) immer mehr ins Bewusstsein vieler Entwickler. Was aber macht man, wenn Testfälle fehlschlagen und der Urheber nicht mehr greifbar ist? Reparieren oder wegschmeißen? Dies ist nur eines von vielen Problemen, das auch beim Reaktivieren längst verschollener Testfälle auftreten kann. <br>
Andere sind:<br>
* Tests dauern zu lange<br>   
* auf meinem Rechner gibt es keine Datei X:\boehm\testdat.ei  <br> 
* Tests laufen lokal, aber nicht auf dem Build-Rechner   <br>
* u.v.m.<br>
Einige der Problem lassen sich durch Nachdenken und JUnit-Boardmitteln lösen. Für andere Probleme bietet PatternTesting eine Reihe von Hilfsmittel, um wieder grünes Licht für's Testen zu erringen.<br>
<br>
'''Zur Person:''' <br> Oliver Böhm studierte Informatik an der Universität Stuttgart . Nach C++-Entwickung im Unix-Bereich beschäftigt er sich mit Java-Entwicklung unter Linux und Aspekt-Orientierte SW-Entwicklung . Er ist u.a. Autor der Bücher " JavaSoftware Engineering unter Linux " ( millin Verlag ) und " Aspekt-Orientierte Programmierung mit AspectJ 5 " ( dpunkt.verlag ). Neben seiner hauptberuflichen Tätigkeit als JEE-Architekt bei T-Systems gibt er AOSD-Vorlesungen und ist Board-Mitglied der JUGS (Java User Group Stuttgart). <br>
<br>

===Testen von variantenreichen Systemen===
(Dr. Sebastian Oster / CGI Logica)<br>
<br>
'''Zusammenfassung:''' <br>
Der Automobilbereich beherbergt aktuell die variantenreichsten Systeme der produzierenden Gewerbe. Mittelklassemodelle eines süddeutschen OEMs kommen auf eine mögliche Anzahl von Varianten im Milliardenbereich, so dass jedes Auto dieser Baureihe, allein mit Hinblick auf den installierten Softwarestand, ein Unikat sein kann. Eine besondere Herausforderung bei dieser Entwicklung stellt dabei das Testen solcher Softwarestände dar. Alle Varianten müssen ausgiebig getestet werden. Dabei spielen Standards wie ISO 26262 eine besonders wichtige Rolle, denn sie verlangen, dass gegen jede Anforderung an die Produktlinie korrespondierende Tests erstellt und ausgeführt werden. Daher muss die Variabilität sowohl in den Anforderungen als auch im Test berücksichtigt werden.<br>
In diesem Vortrag werden Methodiken und Konzepte vorgestellt, wie man trotz der hohen Anzahl von Varianten systematisch und effizient testen kann. Dabei werden sowohl mathematische Heuristiken beleuchtet, die den Testraum einschränken, als auch Methoden, wie die Klassifikationsbaummethode und modellbasiertes Testen um die Wiederverwendung von Testartefakten zu forcieren.<br>
<br>
'''Zur Person:''' <br> Dr. Sebastian Oster promovierte an der Technischen Universität Darmstadt in dem Themenbereich Qualitätssicherung variantenreicher Systeme. Während seiner Promotion war er als Berater mit dem Fokus Variantenmanagement im Soft- und Hardwarebereich im Umfeld der Automatisierungstechnik und Automotive tätig. Seit dem Abschluss seiner Promotion arbeitet Sebastian Oster als Managing Consultant und Projektleiter bei der Firma Logica, now part of CGI und ist dort in verschiedenen Projekten im Automotive-Umfeld unterwegs. Zudem ist er Stellvertreter der ASQF Fachgruppe Automotive und regionaler Fachgruppenleiter in Baden-Württemberg.<br>
<br>

===Agile Software-Entwicklung und Test mit Automotive Open System Architecture (AUTOSAR)===
(Peter Wagner / Bosch)<br>
<br>
'''Zusammenfassung:''' <br>
Automobilhersteller, Zulieferer und Tool-Anbieter gründeten die Entwicklungspartnerschaft AUTOSAR, um einen offenen Standard für Embedded-Middleware (anwendungsneutrale Lösung) zu definieren. AUTOSAR fasst Informationen über Software-Komponenten, ihre Schnittstellen, die Hardware-Topologie und die Verteilung der Software-Komponenten auf die Steuergeräte in einem Modell zusammen. Der Beitrag beschreibt die Arbeiten von Bosch und ETAS für AUTOSAR. Bosch realisiert die Basissoftware-Entwicklung über das Projekt CUBAS (AUTOSAR Compliant Basic Software) mit Beteilung von Bosch India und ETAS. ETAS bietet zur virtuellen Ausführung von AUTOSAR Software-Komponenten das Werkzeug INTECRIO-VP an. <br>
<br>
'''Zur Person:''' <br>Der Referent Peter Wagner, arbeitet seit 1988 als in der Automobil-Industrie Forschung und Entwicklung als Qualitätsingenieur Schwerpunkt Software Test. Das Aufgabegebiet umfasst die Erforschung neuer Methoden, Praktiken und Verfahren in der modernen Softwareentwicklung. Seit 2007 ist er Mitglied des Leitungsgremiums der Gesellschafft für Informatik TAV (Test, Analyse und Verifikation).<br>
<br>

===Continous Integration mit Jenkins===
(Prof. Dr. Simon Wiest / HdM Stuttgart)<br>
<br>
'''Zusammenfassung:''' <br>
Hand aufs Herz: Gute Software zu entwickeln ist ja schon nervenzehrend genug. Wäre es da nicht schön, einen Butler zu haben, der einem den lästigen Routinekram abnimmt? Jenkins ist die Weiterentwicklung von Hudson, einem Java-basierten Continuous-Integration-Server, der in den letzen Jahren rasante Verbreitung gefunden hat. Entwickler und Teamleiter können damit einfach und zuverlässig wichtige Aspekte der Softwareerstellung automatisieren und so mehr Transparenz in IT-Projekte bringen. Kein Wunder also, dass Firmen wie eBay, Yahoo, Hewlett-Packard, Xerox, JBoss, Goldman Sachs oder die Deutsche Telekom den Continuous-Integration-Server zum festen Bestandteil ihrer Werkzeugketten gemacht haben. Jenkins muss den Vergleich mit den „üblichen Verdächtigen“ seiner Gattung wie etwa CruiseControl nicht scheuen. Im Gegenteil: In zahlreichen Fällen etabliert sich Jenkins als deren Ablösung. Für sein Potenzial spricht auch die Auszeichnung mit dem „Duke‘s Choice Award“ in der Kategorie „Developer Solutions“ auf der JavaOne 2008. Jenkins ist kostenlos, Open Source, und wird von einer äußerst rührigen Entwicklergemeinde vorangetrieben. Vor allem aber ist Jenkins praxiserprobt.

Im Vortrag werden wir – durchgehend unterstützt von Live-Demos – folgende Fragen behandeln:
* Was bringt kontinuierliche Integration überhaupt?
* Was macht Jenkins so besonders?
* Passt Jenkins zu meiner Arbeitsgruppe/Firma?
* An welchen Stellen wird momentan am intensivsten weiterentwickelt?

Und natürlich dürfen auch dieses Mal eXtreme-Feedback-Devices (XFDs) wieder nicht fehlen… <br>
<br>
'''Zur Person:''' <br>
Prof. Dr. Simon Wiest ist Jenkins-Evangelist und Committer in den Projekten Jenkins und Hudson. Seine Beiträge wurden mit einem Sun Microsystems Community Innovation Award ausgezeichnet. Zu Jenkins/Hudson spricht er regelmäßig bei Firmen, auf Fachkonferenzen und in Java User Groups. In seinem anderen Leben unterrichtet er als Professor für Informatik im Fachbereich „Electronic Media“ an der Hochschule der Medien in Stuttgart. Seine Schwerpunkte liegen dort im Bereich Internet sowie interaktive und mobile Medien. Er ist außerdem Autor des gerade erschienenen, ersten deutschsprachigen Buch über Continuous Integration mit Fokus auf Jenkins/Hudson („Continuous Integration mit Hudson“, dpunkt.verlag, 2011). <br>
<br>

===Performancemessungen und -analysen bei 3-Tier-Systemen - Ein praktisches Beispiel===
(Prof. Dr. Dörsam / HdM Stuttgart)<br>
<br>
'''Zusammenfassung:''' <br>
''Kennen Sie diese Situation? Sie leben in Ihrer Organisation einen modernen Softwareentwicklungsprozess, haben eine ausgereifte Testumgebung  und ein eingespieltes Entwicklerteam, das  seit Jahren zuverlässig hoch qualitative Software ausliefert. Sie sind überzeugt,  alles Mögliche für die Qualitätssicherung ihres Tools gemacht zu haben.  Ein neues Release der Software wird an einen Kunden ausgeliefert – und der Kunde ist entsetzt, weil das Tool in seiner Produktivumgebung so langsam ist, dass fast alles zum Erliegen kommt.

Was tun? Wie stellt man in so einer Situation kurzfristig das Vertrauen des Kunden wieder her? Wie findet man zuverlässig die Ursachen für die scheinbar plötzlichen Performanceprobleme? Und was muss das Entwicklerteam ab jetzt anders machen?

Der Vortrag zeigt den steinigen Weg eines Entwicklungsteams zu einem performance-bewussten Team sowie die technischen, organisatorischen und menschlichen Probleme auf, die auf diesem Weg bewältigt werden müssen. Die Vortragende wird Ihnen einige typische Beispiele von Dos und Don’ts für performancekritische Projekte vorstellen.''<br>
<br>
'''Zur Person:''' <br> Prof. Dr. Barbara Dörsam ist Professorin im Bereich "Print & IT" des Studiengangs Druck- und Medientechnologie an der Hochschule der Medien Stuttgart. Ihre Schwerpunkte sind Softwareentwicklung und Softwaretests.
Davor war sie mehrere Jahre Leiterin der Softwareentwicklung in einem Unternehmen der Automotive-Branche.

===Agiles Testen - ein Erfahrungsbericht===
(Michael Fischlein / Sogeti)<br>
<br>
'''Zusammenfassung:''' <br>
Auch in der agilen Softwareentwicklung – hier am Beispiel von SCRUM – ist der Test ein wichtiger Bestandteil – nur wie, wann, wo wird er umgesetzt, in welchem Umfang und wer führt in aus? Fragen, die viele Antworten ermöglichen die hier exemplarisch vorgestellt werden. Selten auch beginnt die Aufgabenstellung für ein agiles Projekt auf der grünen Wiese. Gerade in der langjährigen Produktentwicklung existiert oft ein klassischer Softwareentwicklungsprozess, darin eingebunden ein klassischer Testprozess und das entsprechende Minde Set der beteiligten. Der Weg von Klassisch zu Agil ist ein interessanter und steiniger Weg. Wie sieht das Zusammenspiel der Prozesse aus bei einer Teilumstellung – vor allem aus Testsicht? Welche Schwierigkeiten sowohl technisch als auch menschlich lauern auf dem Weg? Im Vortrag von Herrn Fischlein werden Ansätze für Lösungen aus existierenden Projekten vorgestellt und auch gerne diskutiert.<br>
<br>
'''Zur Person:''' <br>
Der Referent Michael Fischlein, arbeitete viele Jahre als verantwortlicher Tester und Testmanager in einer Softwareentwicklung für eine Standardsoftwareprodukt. Seit 2010 ist er als Senior Consultant bei Sogeti in agilen Projekten im Einsatz. Ende 2010 übernahm er die Aufgabe des Technical Managers für Sogeti München. Neben seiner beruflichen Aktivitäten ist kommt er auch über seine Tätigkeiten im ASQF Software-Test Südbayern sehr stark mit dem Thema Softwaretest, -qualität und Testen im agilen Umfeld in Berührung.<br>
<br>

===Closing Talk: Wie Impro Theater einem Tester das Leben retten kann===
(Lars Metze / CGI Logica)<br>
<br>
'''Zusammenfassung:''' <br>
Jedes Projektmitglied befindet sich in einem sozialen und politischen Spannungsfeld sobald das Projekt seine Arbeit aufnimmt. Für einen Tester ist es häufig eine Projekttätigkeit zwischen Hammer und Amboss:
* Anforderungen kommen unverständlich, unpräzise oder verspätet.
* Testläufe werden verkürzt, verschoben oder in letzter Minute inhaltlich verändert.
* Programmierer fühlen sich angegriffen, überwacht oder fremdbestimmt.
Alles wird gerne auf den Tester geschoben und es entsteht der Wunsch, Tests einfach abzuschaffen. Wer könnte sich diesem Druck schon widersetzen? Da muss schon ein echter Held her – so wie in einem Theaterstück oder einem Film. Sie sagen, den gibt es nicht? Ich denke doch und beweise Ihnen, dass sie diese Rolle schon tagtäglich erfüllen! Aber jetzt wird es Zeit, dem Helden auch den richtigen Platz in ihrem täglichen Stück einzuräumen. Folgen Sie mir auf der Reise des Helden – und ich zeige Ihnen, wie Sie die Welt wenigstens ein kleines bisschen verändern können.<br>
<br>
'''Zur Person:''' <br>
Der Referent Lars Metze absolvierte 2008 sein BA-Studium der Wirtschafsinformatik bei der Firma Behr GmbH & Co. KG. Bei der Logica ist er seit Abschluß des Studiums für Projekte in den Bereichen IT-Servicemanagement, Prozessmanagement und Requirements Engineering tätig. Aus Leidenschaft für das Schauspiel startete er ein Schauspielstudium in Paris und nutzt heute seine Erfahrungen in Dramaturgie und Improvisation, um auch aus schwierigen Situationen das Beste für Kunden und Projekte zu holen.
<br>