Wir haben heute einen langen Nachmittag vor uns, also zweimal anderthalb Stunden. Es wird auf jeden

Fall eine Pause zwischendrin geben. Ich kann nicht ganz genau abschätzen auf die Minute genau,

wann wir irgendwie die Pause machen werden. Der Vortrag ist aber auch zweigeteilt. Der erste

Teil, der wird nun in die Richtung gehen, Grundlagen von Entwicklertesten, testgetriebene

Entwicklung und im zweiten Teil werde ich so das ein oder andere, wenn man will, Advanced-Thema

ansprechen. Ja, aber auch da hängt auch davon ab, wie viele Fragen Sie stellen, wie weit wir

in die Details gehen. Also der Foliensatz ist, wie er ist. Insofern, da sind hoffentlich die

wichtigsten Informationen drauf, um vor allen Dingen nachher auch noch tiefer einzusteigen in das Thema

irgendwo am Ende habe ich auch noch die Quellen. Insofern hoffe ich, dass das ausreichend Material

liefert, dass Sie in der Richtung weitermachen können. Da kann ich ja auch ein bisschen schneller

über diese einführenden Teile rübergehen. Ich denke, wir werden alle trotzdem ein bisschen

behandeln, dass sie auch auf Zelluloid sind, auf Silikon sind sozusagen. Okay, also wenn,

das bin ich, das ist mein Twitter-Hände, da kann man was über mich erfahren. Der Teil,

der Ihnen vielleicht am meisten bringt, der kommt jetzt gleich und zwar das ist mein Titel,

den Sie sich einfach klauen können. Sie müssen damit nicht mal fertig studiert haben. Also Sie

dürfen sich einfach, so wie ich Software-Therapeut nennen. Wenn man guckt, das ist kein Hinweis auf

fachliche Kompetenz in keiner Art und Weise. Er ist aber nicht gesetzlich geschützt, also auch

heute Studium abbrechen, sich Software-Therapeut nennen, rausgehen und die Leute therapieren. Es

also die Software-Therapien natürlich, keine Menschen. Also das ist sozusagen das, was ich

mich nenne. In der Praxis helfe ich Teams dabei, Software zu entwickeln und testen ist ein ganz

wesentlicher Aspekt darunter. Die Frage, die man sich stellen kann, gerade wenn man vielleicht noch

nicht viel Erfahrung mit größeren Projekten hat, die tatsächlich eingesetzt werden, die vielleicht

auch Teil eines Produkts sind und weiterentwickelt werden, kann man sich fragen, warum muss ich denn

sowas wie Tests überhaupt automatisieren. Ich als Entwickler teste ja mein Programm sowieso auf die

ein oder andere Weise, entweder weil ich irgendwas eingebe oder weil ich eine Main-Funktion schreibe,

die mein Programm ausführt. In irgendeiner Form teste ich es ja sowieso und dann gibt es ja immer

noch, wenn man in Firmen geht, viele Firmen haben immer noch sowas wie eine Qualitätssicherung oder

Testabteilung, die am Ende, ja kurz bevor wir das Produkt an die Kunden geben, sowieso testen.

Im Prinzip kann man das so machen, man kann also immer sozusagen eine Software entwickeln und am

Ende gucken, funktioniert die und wenn sie nicht funktioniert, dann wird halt noch mal weiterentwickelt

und Bugs gefixt und sowas. Das hat auch bis vor vielleicht 10, 20 Jahren ganz gut funktioniert,

das also ganz gut ist relativ. Es hat funktioniert und es sind Softwareprodukte dabei rausbekommen.

Wenn ich mir aber anschaue, wie sich auch die Anforderungen an die Art, wie Projekte und

Produkte entwickelt werden geändert haben in der letzten Zeit, da geht das dann gar nicht mehr.

Also hier habe ich zwei Begriffe mal aufgegriffen, das ist Continuous Delivery und Continuous

Deployment und Continuous Delivery heißt eigentlich nichts anderes als, dass wenn irgendjemand,

jemand in der Entwicklung, eine Programmiererin sagt, jetzt habe ich ein neues Stück Feature

fertig entwickelt, dass sie auf den Knopf drückt, macht ein Git-Commit-Push, irgendwas in diese

Richtung und dann läuft der Automatismus los und am Ende ist vielleicht ohne irgendwelches menschliches

Zutun vielleicht, also wenn wir hier unten bei Continuous Deployment sind, völlig automatisch

geht dieses Stück gut und alles andere, was vorher auch schon da war in Produktion. Und jetzt wissen

Sie sicherlich, Software kann so gebaut sein, dass wenn ich an der einen Ecke irgendwas drehe,

dass es an der anderen Ecke kaputt geht. Das heißt, wenn ich verhindern will, dass sozusagen

sehr oft, wenn am Ende das Ding wirklich automatisch in die Produktion geht, Dinge nicht mehr funktionieren.

Offensichtlich nicht mehr funktionieren oder auch nur sehr subtil funktionieren, dann brauche ich

zwischendrin Schritte, die mir mit einer hohen Wahrscheinlichkeit sagen können, dass nichts

wesentliches kaputt gegangen ist an meinem Produkt. Und wenn man sich anschaut, was hier ist,

das ist alles automatisiert und hier stehen mindestens zwei Aspekte, wo direkt Test dabei steht.

Hier steht jetzt Unit Test und das steht Acceptance Test. Es gibt also Dinge, die wir automatisiert

überprüfen müssen an unserer Software, dass sie noch tut. Ansonsten können wir diese