Matthias: [00:00:01.60] Seid gegrüßt Freunde der Softwarequalität! Hier sind wieder Matthias.

Alex: [00:00:05.38] Und Alex. Willkommen zu eine neue Folge der Macht der Craft.

Matthias: [00:00:09.73] Testen ist ein wichtiger Bestandteil unserer Arbeit, deswegen wollen wir heute darüber sprechen.

Alex: [00:00:14.56] Da gibt es so viel zu erzählen, dass wir uns entschieden haben, gleich mehrere Folgen diesem Thema zu widmen.

Matthias: [00:00:21.55] In der heutigen Folge sprechen wir über manuelle und automatisierte Tests und warum wir als Entwickler diejenigen sind, die Tests schreiben und was uns das überhaupt bringt. Wieso Automatisierung wichtig und notwendig ist.

Alex: [00:00:34.27] Lerne mit uns gemeinsam die Vor- und Nachteile dieser Automatisierung und erfahre aus erster Hand, aus welchem Grund das automatisierte Testen der Software in unsere Werkzeuggürtel gehört.

Matthias: [00:00:46.09] Wir denken, dass diese Folge dir helfen wird, das Testen besser zu beherrschen.

Alex: [00:00:50.17] Viel Vergnügen dabei.

Off: [00:00:53.89] Die Macht der Craft arbeitet für dich.

Alex: [00:00:59.96] Müssen Entwickler testen? Kurz gesagt ja. Test sind ein Muss. Aber vielleicht anders, als viele sich vorstellen. Natürlich dürfen Entwickler manuell testen. Aber ich setze den Schwerpunkt bei der Entwicklung auf automatisierte Tests. Die sind für mich eigentlich die, worüber wir uns Gedanken machen müssen und die wir als Entwickler auf jeden Fall machen müssen. Heißt nicht, wir müssen nicht manuell testen, aber automatisierte Tests sind der zentrale Punkt, die ich ansprechen wollte heute. In der klassischen Entwicklung früher, nach Wasserfall-Modell und so weiter, hatte jede Phase der Entwicklung seine Zeit im Prozess. Teil für die Anforderungen, dann wurde der Entwurf gemacht. Nach der Entwurf kommt die Implementierung. Nach der Implementierung, die QS und dann kann man mal in der Wartungsphase sozusagen. Für uns hier relevant ist, dass es zuerst codiert wird und später findet die QS statt. Eine QS, in der hauptsächlich manuell getestet wird, ob die Anwendung das tut, was es soll. Fehler werden dann an die Entwicklung wieder zurückgegeben, sodass diese dann die Fehler ausbauen können und dann wieder eine Runde QS. In vielen Fallen bedeutet das aber, wenn wir die Fehler bekommen von der QS, eine Runde Debugging. Wir müssen halt mal gucken, wo der Fehler ist, wo der herkommt. Das macht man sehr oft mit dem Debugger. Das ist sozusagen „Debug Driven Development“ und das ist nicht unbedingt optimal. Was meiner Meinung nach wir uns eingestehen müssen, ist, dass Entwickler Fehler machen. Das ist eine Tatsache, würden wir keine Fehler machen, bräuchten wir weder Testen noch QS noch irgendetwas. Aber wir wissen alle, dass des net so ist. Das – das Problem mit dem vorherigen Ansatz, die ich erwähnt habe, diese zwei separate Zeitpunkte, in dem wir implementieren und testen, ist das zwischen den Zeitpunkten, den ich ein Fehler einbaue, und der Zeitpunkt, in dem der Fehler gefunden wird, eine mehr oder minder große Zeitspanne liegt. Je größer diese Zeitspanne ist, desto zeitintensiver ist die Behebung des Problems. Heißt, die Kosten in einem Fehler zu beheben sind direkt proportional zu der Zeit, der vergangen ist zwischen Fehler einbauen und Fehler finden. Würdest du sagen, das trifft zu?

Matthias: [00:03:28.83] Das klingt auf jeden Fall plausibel, weil je länger ich natürlich entfernt bin von dem Punkt, wo ich den Code geschrieben habe, desto weniger ist er auch präsent und unter Umständen kommt ja auch noch dazu, wie du vorhin schon gesagt hast, man das dann häufig mit dem Debugger herausfinden musste, wo das Problem überhaupt liegt, weil ich möglicherweise gar keine automatisierten Tests hatten – hatte, die mich irgendwie bei der Suche hätten unterstützen können, sondern ich musste wirklich durch den Programmablauf durch und versuchen, die Situation nachzustellen, wie sie der Tester eben beschrieben hat. Also ja, grundsätzlich glaube ich schon, dass das tatsächlich zutrifft, ja.

Alex: [00:04:09.35] Ok, es wäre also das Beste, diese Zeit auf ein Minimum zu reduzieren, ne?

Matthias: [00:04:14.99] Ja.

Alex: [00:04:14.99] Damit tun wir uns halt einen Gefallen, weil das Fehler zu beheben einfacher ist. Das betrifft sowohl uns als Entwickler als auch dem Geschäft dem wir nachgehen. Wir tun uns leichter mit der Arbeit und wir verursachen weniger Kosten, weil wir schneller sind. Eine Lösung wäre da doch naheliegend, ne. Die Entwickler sollen gefälligst den Code manuell testen, bevor sie es für OK erklären. Wo ist da das Problem? Also ich bin nicht gut im klassischen Testen und das ist bei vielen anderen Software-Entwickler anscheinend auch so. Aber warum wird das immer behauptet, dass Entwickler schlechte Tester seien? Auf mich mag es ja so treffen, ich gebe es ja zu. Aber trifft das auch auf die Mehrheit von uns? Böse Zungen behaupten, dass es so ist.

Matthias: [00:05:03.80] Ich glaube, der entscheidende Punkt daran ist, teste ich meinen eigenen Code manuell oder teste ich den Code eines anderen Software Entwicklers manuell. Denn wenn ich meinen eigenen Code manuell teste, habe ich da eine gewisse, wie soll man sagen eine – ja, Vorbelastung. Also ich gehe weniger davon aus, dass ich selbst einen Fehler eingebaut habe, als dass ich davon ausgehe, dass jemand anders einen Fehler eingebaut hat. Und deswegen glaube ich, dass der Fokus, wie ich Code manuell teste, sich ändert, ob ich meinen eigenen oder fremden Code teste.

Alex: [00:05:39.38] Ja, das „mein Code Problem“. Code, die ich geschrieben habe, wird als ein Teil von mir wahrgenommen. Und wenn irgendjemand behauptet, das wäre fehlerhaft oder das wäre nicht gut, dann nehmen es viele Entwickler halt einfach mal persönlich. Ja, das ist ja irgendwie persönliches Versagen. Und deswegen reagiert man – ja, nicht immer gut auf solche Art von Kritik. Meiner Meinung nach mussen wir einfach weg von diese „mein Code“-Vorstellung. Der Code ist nicht mein Code ist einfach nur Code. Und vor allem muss sich jeder Entwickler klar sein, dass er Fehler macht, genauso wie jeder andere Entwickler. Fehler zu machen mag nicht schön sein. Es ist aber wie bereits erwähnt eine Tatsache, die die wir nicht leugnen können. Akzeptieren wir einfach das. Es ist nicht schlecht, Fehler zu machen. Sondern nichts daraus zu lernen, des ist eher das Problem. Also für mich wäre es das erste Problem, die Entwickler mit dem Testen haben vor allem der eigene Code, ist diese „mein Code“-Problem. Das zweite Problem, die ich da bei der Sache seh, ist, dass wir als Entwickler die Aufgabe haben, die Anforderungen, die wir bekommen, in Code zu übersetzen. Wir bauen Strukturen, um die Bedürfnisse unserer Kunden zu erfüllen. Und zwar so, dass sie auch damit arbeiten können. Wir erstellen in unserem Code Regeln, verwenden bestimmte Mustern, treffen Annahmen bezüglich, was die Kunden von uns erwarten. Wir konzentrieren uns eigentlich darauf, etwas zu bauen, das funktioniert und unseren Kunden glücklich macht. Als Tester sehe ich das aus eine ganz andere Perspektive. Jetzt geht es darum, sich Szenarien auszudenken, um zu beweisen, dass der Code nicht das erwartete Verhalten hat. Will Schwachstellen finden und die Anwendung in Anführungszeichen kaputtmachen. Natürlich nicht aus Bösartigkeit, sondern weil ich den Kunden eine solche Erfahrung sparen möchte. Ich muss alle Probleme aufdecken, so gut es mir möglich ist, damit diese nicht an den Kunden gelangen. Ich versetze mich in den User und versuche seine Probleme mit der Software vorab zu entdecken. Diese zwei Herangehensweise sind total unterschiedlich und das Wechsel zwischen beide Rollen, beide Vorgehensweisen, ist meiner Meinung nach nicht leicht.

Matthias: [00:08:08.73] Ja, erfordern ja, vielleicht sogar komplett andere Skills. Also, weil ich kenne tatsächlich Leute, die haben ein super Talent dafür, Anwendungen kaputt zu machen. Was ich persönlich nicht so einfach schaffe, weil ich bisschen mehr Gefühl dafür hab, wie Software tickt und so. Aber jemand, der das von einer anderen Seite betrachtet und – ja – einfach Dinge macht, mit denen ein Entwickler halt nicht rechnet, kann die gesamte Anwendung kaputt machen.

Alex: [00:08:38.90] Wie ist es bei dir? Also findest du diese Wechsel leicht oder schwer, oder?

Matthias: [00:08:44.06] Also bei meinem eigenen Code finde ich ihn unglaublich schwer. Bei fremden Code nicht so sehr, tatsächlich. Weil – also wenn jetzt ein Kollege zu mir kommt und mich bittet, sein Feature, das er umgesetzt hat, zu testen, dann habe ich keinerlei Insides, wie dieser Code entstanden ist, was da passiert ist, sondern ich nehme mir einfach den den Stand, den er mir zur Verfügung stellt. Lass den bei mir lokal laufen und probier einfach aus. Und dann ist es wiederum was Anderes. Aber wenn ich selber der Erschaffer dieser – dieses Features bin, dann weiß ich ja, was ich erwartet habe, das passiert. Und dann werde ich mich auch, wenn ichs bediene, entsprechend verhalten. Also nochmal kurz gesagt bei meinem eigenen Code finde ich es verdammt schwierig, bei fremden Code find ichs etwas leichter, aber ich glaube trotzdem, dass ich nicht der talentierteste Tester bin. Also es gibt mit Sicherheit Leute, die das besser können.

Alex: [00:09:39.90] Ja, du hast vorher auch erwähnt, die Skills die man braucht sind auch unterschiedlich. Und obwohl wir eventuell gewisse Skills als Tester besitzen, sind Menschen, die dafür ausgebildet wurden, haben deutlich bessere Skills oder andere Skills, nicht bessere halt.

Matthias: [00:09:59.99] Ja, genau die sehen halt zum Beispiel ein Eingabefeld und denken sich „Hah was kann ich denn jetzt bösartiges mit diesem Eingabefeld machen?“ Und denen fallen halt 100 Sachen ein, wo mir halt vielleicht nur 20 einfallen.

Alex: [00:10:13.83] Okay, das ist der Grund, dass wir so schlecht oder ich, ich bin schlecht, bei manuelles testen. Ich will jetzt nicht jeden da mit belasten. Warum ich der Meinung bin, dass automatisiertes Testen eine super Sache ist. Warum ich Tests automatisiert mache, anstatt dass ich sie manuell tu. Was ist das Ziel von automatisierte Tests? Ich denke, was wir damit erreichen wollen, ist, dass wir die Menge an Tests, die wir manuell durchführen, reduzieren können. Wichtig ist zu erwähnen automatisierte Tests sind nicht da, um manuelle Tests zu ersetzen. Das können sie nicht. Aber automatisierte Tests können immer wiederkehrende Testfälle oder des, was ich immer wieder testen muss, auslagern, sodass die Menschen, die dann manuelle Tests machen müssen, entlastet sind, weil sie mit Sicherheit wissen diese immer wiederkehrende Themen sind eh schon abgedeckt und sie können sich dann auf andere Sachen konzentrieren. Manuelles Testen ist in meinen Augen auch sehr zeit- und kostenintensiv, also kostenintensiv, weil zeitintensiv, ist aber deutlich leichter von der Hand zu bringen als automatisierte Tests. Für automatisierte Tests brauchst du ein Entwickler oder ein Tester, die entwickeln kann oder der diese Tests entwickeln kann? Also manuelles Testen ist zeit- und kostenintensiver als automatisierte Testen, zumindest auf lange Sicht. Früher als wir noch Wasserfall benutzt haben, gab es eine relativ große Zeitspanne zwischen „ich entwickel“ und „ich teste“. Es ist heute nicht mehr so. Mit diese DevOps Prinzip oder diese DevOps Methoden, indem wir kontinuierlich oder sehr schnell ausliefern wollen und Änderungen vornehmen. Da gibt’s halt ein anderes Problemchen, nämlich eben das, wenn jedesmal wo ich ausliefere das ganze testen muss, die ganze Anwendung testen muss. Da sind unsere Tester irgendwann mal überfordert mit Arbeit, weil jede 2 Wochen alles testen mussen oder jede paar Tage alles testen muss. Des is irgendwie, nicht schön. Wichtig ist für mich klarzustellen, dass Testautomatisierung eine Sache, die gut ist, weil Qualität und Geschwindigkeit in der Entwicklung auf längere Sicht verbessert und sogar in manchen Fällen ermöglicht. Manche Sachen traut man sich gar nicht mehr anzufassen. Nach ein paar Jahre, wenn wir keine Tests haben. Was sind für dich die Vorteile von Test Automatisierung?

Matthias: [00:13:02.90] Also erstmal ganz klar die sehr kurze Feedback Schleife die ich hab, in meiner täglichen Arbeit. Sobald ich an meinem Code was änder und ich mache damit was kaputt, habe ich im Idealfall einen automatisierten Test, der mir das sofort mitteilt. Und unabhängig davon, in welchem Teil des Systems sich dieser Fehler dann letztendlich oder das, was ich kaputt gemacht habe, befindet. Durch dieses schnelle Feedback kann ich persönlich viel sicherer und schneller arbeiten, weil ich mir letztendlich ohne manuelle Prüfungen zu einem gewissen Grad sicher sein kann, nichts kaputt gemacht zu haben. Darüber hinaus ist es dann natürlich auch so, dass diese automatisierten Tests zu einem gewissen Grad ja auch was so ein bisschen einen psychologischen Beitrag zu meiner täglichen Arbeit liefern können. Denn man sollte es auch nicht unterschätzen, was dieses immer wieder etwas grün machen auch an Endorphinen z.B. ausschütten kann. Will nur sagen, es hat auch so ein bisschen was von einer Gamification gleich zu einem gewissen Grad von der täglichen Arbeit. Und ich erlebe das auch immer wieder, dass sich Leute seh, die sich richtig freuen, wenn sie ihren ersten Test grün gemacht haben.

Alex: [00:14:24.54] Dann ja schnellen Feedback. Das ist ein guter Punkt. Ja, da der Feedback so schnell ist, wir kriegen gleich mit, dass es ein Problem gibt. Das ein Fehler ist und das bedeutet, dass wir weniger Fehler ausliefern, weil wir sie sofort merken. Also haben wir weniger Fehler. Es mach unsere QS-Kollegen oder unsere Tester Kollegen glücklicher, weil sie weniger Fehler finden müssen. Aber auch die Kunden. Weil auch jeder Tester, egal wie gut der ist, kann nicht alle Fehler in der Software finden. Deswegen, wenn wir schon von vornherein manche ausschließen können – ja -, ist es schön.

Matthias: [00:15:04.95] Da fällt mir tatsächlich noch ein anderer Punkt ein. Nämlich, wenn der Tester was gefunden hat und ich mein Fehlerbericht zurück bekomme, dann habe ich mit automatisierten Tests natürlich die Möglichkeit, diesen Fehler in einen automatisierten Test zu gießen, der dann erst einmal rot ist, um ihn dann grün zu machen und damit sicherzustellen, dass dieser Fehler bei einem manuellen Test in Zukunft nicht mehr auftauchen wird. Weil das ist ja auch häufig ne Geschichte gewesen früher, dass Fehler, die mal behoben worden sind, auf einmal wieder auftauchen. Dann dieses – dieses klassische das hat doch schon mal funktioniert. Hat glaube ich jeder schon mal gehört.

Alex: [00:15:44.97] Ich finde, das ist ein sehr guter Punkt. Was ich sonst noch für Vorteile da erwähnen könnte, ist die Software wird stabiler. Und zwar, weil dadurch, dass wir diese Test automatisch laufen lassen, sorgen wir dafür, indem wir z.B. jeden Tag die Tests laufen lassen oder bei jedem Commit, bei jeder Version die wir bauen. Da werden die Test ja immer durchgeführt, und zwar nicht nur die Tests, die wir jetzt gerade neu dazu gemacht haben, sondern alle, die wir haben, wenn wir irgendetwas woanders kaputt gemacht haben. Mit dem Code, die wir gerade einfügen, kriegen wir es auch gleich mit. Manuelle Tests, die jede paar Wochen oder Monate gemacht werden, bieten uns auch nicht dieses schnelle Feedback, wie du gesagt hast, sodass die Software nicht so stabil wird, wie es sein könnte. Dann ich hätte noch das Thema Kosten: da sind zwei Themen, die ich ansprechen wollte. Das eine ist für die Tests, die wir automatisiert haben. Die Ausführungszeiten, wenn wir die oft wiederholen und so weiter sind kostengünstiger als die manuell zu machen.

Matthias: [00:17:01.84] Und es muss kein Tester dafür bezahlt werden, mit Stundenlohn und so weiter und so fort.

Alex: [00:17:07.28] Ja gut, der Tester braucht man aber eh, weil den können wir nicht ersetzen. Es ist auch nicht das Ziel der Testautomatisierung.

Matthias: [00:17:14.08] Nee nee, aber er kann sich halt anderen Dingen widmen. Also er muss jetzt nicht irgendwie jeden Furz überprüfen, sondern kann sich vielleicht auf neue Features konzentrieren. Das ist ja zum Beispiel dann der Vorteil.

Alex: [00:17:29.34] Durch diese schnellen Feedback kriege ma halt die Fehler früher zu Gesicht und je früher ein Fehler gefunden wird, desto günstiger ist den zu beheben. Bist du auch da der Meinung?

Matthias: [00:17:42.54] Absolut, ja.

Alex: [00:17:43.77] Also die Test Automatisierung hilft und Kosten zu sparen. Das Ausführung der Tests nach jeder Versionsänderung oder nach jeden Commit, wenn ihr wollt, oder nach jede CI Durchlauf. Diese automatisierte Tests laufen tatsächlich schnell. Das ist nicht eine Sache, die über mehrere Stunden läuft, sondern die sind in Minuten durch. Wir können sie sehr schnell durchführen. Das ist noch ein wichtiger Bestandteil von dieser Automatisierung, dass die schnell sind. Und da können wir tatsächlich die sehr oft ausführen und auch in sehr kurzer Zeit, sodass wir – nochmal – schnell Feedback bekommen. Durch dieses schnelle Feedback kriegen wir stabilere Software. Kriegen wir weniger Kosten für die Behebung, kriegen wir weniger Fehler. Die sind auch jederzeit durchführbar. Ich brauche keine Menschen, die da ist, um den Test durchzuführen. Ich kann in meine Tests mit in der Nacht einfach laufen lassen, ohne dass der arme Tester wach bleiben muss, und die Tests manuell machen zu müssen, sondern die laufen einfach automatisch über Nacht, was auch immer, auch ein Vorteil. Tests, die wie automatisiert und geschrieben haben – Sagen wir mal der Test prüft das, wenn ich A reingebe B rauskommt. Des macht er immer. Er macht immer das gleiche. Es ist ja Code, die wir geschrieben haben. A rein, B raus, fertig. Und das macht er immer gleich. Bei manuellen Test ist das nicht unbedingt gegeben. Vor allem kann sich nach den Zehntausendenmal, wo ich das Gleiche teste, eine gewisse Betriebsblindheit einstellen, in den ich nicht mehr so genau teste. Und der Code ist Code ist da, der macht das fertig. Dadurch, dass wir die ganze Sache automatisiert haben, haben wir als Entwickler und als Tester mehr Zeit für andere Sachen. Also, haben wir alle was davon. Und vor allem wollte ich nochmal erwähnen, das Thema mit der mit der Entlastung der Tester. Wenn wir die ganze Anwendung jede 2 Tage testen müssen, da ist die Arbeitslast, die die Tester haben, enorm. Da brauchen wir entweder viele Tester oder die Tester müssen sehr viele Stunden arbeiten, um mit diesem Pensum überhaupt nachzukommen. Deswegen durch diese Automatisierung entlasten wir die Tester, weil wir diese immer wiederkehrende Aufgaben halt automatisch oder größtenteils automatisch erledigen können, sodass die Tester, wie vorher gesagt hast, sich auf andere Bereiche des Testens konzentrieren können.

Matthias: [00:20:31.56] Genau.

Alex: [00:20:34.13] Das letzte, was ich noch erwähnen wollte, ist Durch den Einsatz der Test Automatisierung erreichen wir viel mehr Bereiche. Weil die Test, die wir durchführen, sind halt automatisiert, sind in Code gegossen, sodass sie immer da sind. Wir vergessen sie nicht oder wir müssen kein Protokoll führen: Hab ich den Test schon ausgeführt? Den Test scho ausgeführt? Sondern die sind da, die werden ausgeführt, die bleiben immer da. Die wachsen mit der Zeit, sodass immer mehr Testumfang vorhanden ist. Es ist manuell meistens einfach nicht möglich immer mehr Tests durchzuführen, ne, weil irgendwann einmal ist die die Kapazität unsere – unsere Leute, die das testen halt einfach mal erschöpft.

Matthias: [00:21:18.39] Ja, des skaliert nur horizontal. Da kannst du nur neue Leute daneben setzen und dann wird’s halt eben wieder teurer.

Alex: [00:21:26.28] Okay, wir haben jetzt viele die Vorteile von diese Testautomatisierung und was wir davon haben. Der Testumfang um schnelles Feedback, kürzere Testzeiten, dass sich die jederzeit ausführen kann und so weiter und so fort. Aber gibt es auch Nachteile? Was denkst du?

Matthias: [00:21:43.07] Naja, wenn die Entwickler in dem Projekt noch nie mit Tests gearbeitet haben z.B. wird es natürlich erstmal den Eindruck erwecken, als würde alles langsam werden. Man würde nicht mehr vorwärts kommen, weil man eben eine gewisse Lernkurve sehen wird, die erst mal genommen werden muss, damit die ganze Arbeitsweise so in Fleisch und Blut übergeht, dass man wieder auf einer ähnlichen Geschwindigkeit ist, von der Entwicklung vorher. Auf der anderen Seite ist es natürlich auch so: Wenn ich diese ganze Automatisierung haben will, brauche ich natürlich auch Mechanismen, die diese Automatisierung auslösen – durchführen. Also das sind ja klassischerweise Continuous Integration Server zum Beispiel, die eben unter bestimmten Voraussetzungen dann anfangen, Tests auszuführen, Abhängigkeiten zu installieren und diesen ganzen Build Prozess auch durchlaufen. Dadurch entstehen dann letztendlich natürlich Kosten, die nicht da wären, wenn ich auf automatisierte Tests verzichten würde. Allerdings sollte sich das natürlich ausgleichen, wenn nicht sogar ins Positive übergehen nach einer gewissen Zeit, weil ich ja, wie vorhin schon erwähnt, die manuellen Tests dadurch entlaste. Und die sind deutlich teurer, wenn man jetzt auf die reine Arbeitszeit geht. Weil der Server, der diese Tests automatisiert ausführt, der kostet mich halt im Monat, sage ich mal den Preis, wofür ich keinen einzigen manuellen Tester beschäftigen könnte. Also das heißt, über die Laufzeit von so einem Projekt werden irgendwann diese diese anfängliche Kurve die es geben wird, also wo erst mal der Anschein da sein wird, dass es langsamer wird. Wenn der überwunden ist, wird sich das ganze in meinen Augen ins Gegenteil verkehren und man wird auf Dauer günstiger fahren.

Alex: [00:23:46.31] Ok, ich fass mal kurz zusammen: Für mich wäre der erste Nachteil in Anführungszeichen. Es gibt initial Kosten und zeitliche Aufwand und zwar, um die Testautomatisierung erfolgreich einsetzen zu können. Man muss halt lernen diese Testautomatisierungs-Tools zu verwenden in den Entwicklungsumgebung mit den Programmiersprachen, die man verwendet. Also da ist eine gewisse Lernkurve, wie du sagst, das kostet Zeit und, – wie du aber wohl gesagt hast des ist Initialphase. Wenn du da drin bist und diese Technologien oder diese Tools dir angeeignet hast, dann sollte in eine relativ kurze Zeit sich rentieren. Und der zweite Problem war, dass die technische Komplexität größer wird. Weil die Einführung von der Testautomatisierung ist eben mit diesen neuen Tools mit neuen Technologien verbunden, auch wie du wohl gesagt hast, z.B. mit die Verwendung von ein CI-Server, Schulungsbedarf, Anpassungen an die Organisation oder in den Entwicklungsteams. Also wird am Anfang bisschen teuerer, danach rentiert sich aber ziemlich schnell.

Matthias: [00:25:07.15] Ja genau. Und diese Ersparnis kommt in meinen Augen in erster Linie daher, dass sich tatsächlich die Tester auf die elementaren Sachen konzentrieren können. Nämlich jetzt, wenn wir mal zum Beispiel im Scrum Modus, also agilen Modus denken, dass zum Ende von einem Sprint halt die neuen Features, die entwickelt worden sind, von den manuellen Tester eher im Fokus stehen. Und nicht die Sachen, die bis dahin entwickelt worden sind, sondern die können, eben dann durch die automatisierten Tests sichergestellt werden, dass die noch funktionieren. Und da kommt dann letztendlich in meinen Augen der große Benefit.

Alex: [00:25:50.60] Auch denke ich nicht nur, dass sie sich auf das konzentrieren können, was wir gerade gemacht haben, sondern auch das Thema exploratives Testen oder andere Geschichte sind ein Thema, wo sie halt einfach mehr Zeit haben, solche Themen durchzugehen. Für mich auch ganz ganz ganz wichtig zu erwähnen, weil da entstehen öfters Missverständnisse, hab ich vorher eh schon erwähnt, aber ich wollte es jetzt nochmal kurz erwähnen. Automatisierte Test sind nicht da, um manuelles Testen zu ersetzen. Wir wollen Tester nicht überflüssig machen. Es ist nicht das Ziel. Es wird auch nicht passieren, weil es gibt unterschiedliche Arten von Testen, die gar nicht sinnvoll automatisiert werden können. Ich denke jetzt – keine Ahnung – an Abnahme Tests oder das Thema Usability. Kann der Kunde mit dem, was wir da programmiert haben oder erstellt haben – kommt er zurecht, kann er es gut nutzen. Das kann mal total schlecht automatisieren, weil der Rechner ist ja kein Nutzer. Auch irgendwas einfach so zu testen. Uns ist eingefallen, dieses Fall funktioniert, der ist ist der berücksichtig worden? Da kann ein Adhoc Test sozusagen einfach Anwendung laufen lassen, gucken auch funktionieren und nötig sein. Und wenn es nicht geht, dann diese Tests zu automatisieren, damit es nicht nochmal passiert, wie du vorher erwähnt hast. Also es gibt für die Tester genug zu tun, meiner Meinung nach. Nur diese monotone, langweilige Aufgaben können einfach automatisiert werden, sodass sie eben andere Sachen machen können.

Matthias: [00:27:39.83] Ich mein, wir können ja auch mit automatisierten Tests nicht 100 Prozent garantieren, dass 100 Prozent der Anwendungen immer funktionieren. Und wir können ja eigentlich nur sicherstellen, dass das, was wir getestet haben, funktioniert. Und da gibt’s ja immer noch das Problem, dass man nicht an alles denkt. Und da komme ich dann, – kommt dann eben wieder für mich der manuelle Tester ins Spiel, weil die haben ganz häufig den Skill, an Sachen zu denken und die ich net denk, ja. Also die probieren halt dann mal aus – Was passiert denn, wenn ich in dieses Eingabefeld, wo eigentlich jetzt ne Email-Adresse reingehört, was passiert denn, wenn ich da -1 reingeb? Einfach nur mal so blöd gesagt. Und wenn dein Code nicht damit umgehen kann, dann macht es da kurz bumm und hast du irgendne weiße Seite oder sonst irgendwas? Das kann ich im vorraus vielleicht jetzt bei dem speziellen Fall könnte man es mit ner, – wenn es einem schon mal passiert ist im Voraus vielleicht erahnen und dafür schon ein Test geschrieben haben. Aber ganz häufig ist es halt doch so, dass Sachen manuell dann gefunden werden und wenn man es sich dann anschaut, warum das im Code so passiert, dann ist das so eine Kleinigkeit. Dann hat da eine kleine Prüfung gefehlt. Und – aber für sowas kann ich dann eben im Nachgang nen weiteren automatisierten Test schreiben, wie vorhin auch schon erwähnt. Und so kann ich dieses Sicherheitsnetz um meinen Code immer immer enger stricken und das eben in Zusammenarbeit mit den manuellen Tests und nicht – manchmal hat man auch so das Gefühl, dass das so ein, – wie so ein gegeneinander wirkt, also dass die Entwickler das Gefühl haben, die Tester haben Spaß daran, irgendwie ihnen die Fehler um die Ohren zu hauen oder so ich würd es tatsächlich mehr als ein Miteinander sehen. Und ja, die manuellen Tests bringen mir teilweise Erkenntnisse, die ich halt alleine vorher nicht erlangt hab. Und ich habe aber dann im Nachgang die Möglichkeit, das in meine automatisierten Tests mit einfließen zu lassen. Und wie du vorhin auch schon erwähnt hast, somit das Gesamtsystem einfach ein bisschen stabiler machen kann.

Alex: [00:29:43.70] Super, Super, ganz gut, ganz gut erklärt, finde ich. Tester und Software arbeiten nicht gegeneinander, sondern miteinander, um die Qualität des Produkt höher zu kriegen. Sehr gut.

Matthias: [00:29:55.93] Und wieder einmal sind wir am Ende unserer Folge angekommen. Heute im Vergleich zu den letzten Malen etwas kürzer, weil wir uns ja vorgenommen haben, dieses Thema ein bisschen mehr auf zu splitten in mehrere Folgen. Uns es aber wirklich wichtig ist es einzeln zu beleuchten, damit man hier auch klarere Konturen sieht.

Alex: [00:30:15.31] Du hast heute erfahren, was du von diesen Tests hast und vor allem warum es sinnvoll ist, diese zu schreiben und zu automatisieren.

Matthias: [00:30:22.21] Wir hoffen, du hattest eine gute Zeit und freuen uns natürlich, wenn du ein Abo da lässt und diese Folge deinen Kolleginnen und Kollegen auch weiterempfiehlst.

Alex: [00:30:30.70] Beim nächsten Mal kommt die zweite Folge dieser Reihe mit dem Thema „Wie viel muss ich wo testen?“ und hoffen, dass du auch dann wieder rein hörst.

Off: [00:30:40.72] Die Macht der Craft arbeitet für dich.