[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:20] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:23] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:27] In dieser Episode geht es um häufige Fragen im Fachgespräch, und zwar zum Thema Testen.

[0:32] Viel Spaß!

[0:37] Hallo und herzlich willkommen zur 94. Episode des Anwendungsentwickler-Podcasts.

[0:44] Mein Name ist Stefan Macke und heute setze ich mal meine Reihe der häufigen Fragen im Fachgespräch fort,

[0:52] und zwar mit einem spannenden Thema, wie ich persönlich finde.

[0:55] Es ist eines meiner Lieblingsthemen bei der Softwareentwicklung, und zwar das Testen.

[1:00] Dazu habe ich schon so viele Sachen zusammengetragen, die man im Fachgespräch so gefragt werden kann,

[1:04] dass das mindestens mal zwei Podcast-Episoden werden.

[1:07] Heute beginnen wir mal mit den etwas allgemeineren Sachen zum Thema Testverfahren,

[1:11] also so ein bisschen Klassifikation von Testverfahren, was gibt es alles für Testverfahren,

[1:16] wer kann die durchführen und so weiter, Anweisungspfadüberdeckung, Komplexität und so weiter.

[1:21] Also ein Zeug, das gehen wir heute mal durch.

[1:23] Und dann gibt es mindestens noch eine weitere Folge, wo es dann eher so um den Bereich der Technik geht,

[1:27] nämlich die Unit-Tests, Integrationstests und so weiter.

[1:30] Wie führt man die durch und was ist ein Framework und so weiter.

[1:33] Also da kommt noch einiges an Technik.

[1:35] Heute geht es dann eher so um die etwas theoretischeren Inhalte vielleicht,

[1:40] aber trotzdem sehr, sehr wichtig und vielleicht sogar häufiger noch im Fachgespräch gefragt,

[1:44] als die konkreten Geschichten zu Unit-Tests.

[1:47] Denn das hängt ja auch immer sehr stark davon ab, ob man überhaupt Unit-Tests geschrieben hat

[1:51] und wenn ja, welches Framework man benutzt hat, welche Sprache und so weiter.

[1:54] Die haben ja alle auch ein bisschen ihre Eigenheiten.

[1:56] Von daher, da gibt es zwar auch ein paar allgemeine Sachen zum Thema Unit-Tests,

[1:59] die man so können sollte, meiner Meinung nach, als Anwendungsentwickler oder Entwicklerin.

[2:03] Aber heute geht es erstmal um die Sachen, die wirklich absolutes Grundwissen darstellen,

[2:09] die auch wirklich jeder Entwickler schon mal gehört haben sollte und auch erklären können sollte.

[2:13] Weil sie auch einfach völlig losgelöst von irgendwelchen konkreten Technologien,

[2:17] von Frameworks, Sprachen oder sonst was sind, sondern wirklich ganz allgemeine Verfahren im Bereich des Software-Tests.

[2:23] Und ich habe einfach mal so ein paar Fragen zusammengestellt und ich würde sagen,

[2:27] die gehen wir einfach mal der Reihe nach durch und dann gucken wir mal,

[2:31] ob ich heute bei den geplanten 30 Minuten lande oder ob ich die wieder hoffnungslos überziehe.

[2:37] Wir fangen einfach mal direkt an mit dem Thema Testen.

[2:41] Eine häufige Frage, die wir zum Beispiel gerne mal stellen, ist sowas wie,

[2:44] was kennen Sie denn für Testverfahren?

[2:46] Das ist jetzt so mal die Vergleichsfrage zu meinem Klassiker, was ist denn Objektorientierung?

[2:51] Die lädt dann ja den Prüfling dazu ein, dass er einfach mal 10 Minuten lang so einen kleinen Monolog hält

[2:55] und alles Mögliche erwähnt, was ich da so hören will.

[2:58] Und ähnlich würde ich es dann beim Testen machen.

[3:00] Also ich würde sowas als Einstieg nehmen, wie kann man denn Software überhaupt testen?

[3:03] Oder warum testet man denn Software? Und so weiter.

[3:06] Das wäre dann so ein lockerer Einstieg und dann erwarte ich eigentlich so eine strukturierte Antwort,

[3:09] die mir alle möglichen Testverfahren erläutert, vielleicht gewisse Eigenschaften

[3:13] und dann bis runter zum Unit-Test und Mocking und da kann man alles Mögliche zu erzählen.

[3:18] Aber das Erste, was ich jetzt heute einmal durchgehen will, ist dann das,

[3:21] woran ich mich als Prüfling festhalten würde bei der Strukturierung meiner Antwort.

[3:26] Und ich merke mir das immer so, wie lassen sich Testverfahren eigentlich klassifizieren?

[3:32] Und anhand dieser Frage kann man sich so ein bisschen entlanghangeln

[3:35] und sich dann auch hoffentlich am Ende allen Themenbereichen gewidmet haben bei der Antwort.

[3:41] Und ich stelle einfach mal so ein paar Fragen, anhand derer man eben Testverfahren einteilen kann

[3:46] und die gehen wir dann der Reihe nach durch.

[3:48] Und zwar eine Klassifizierung ist möglich.

[3:50] Was wird getestet?

[3:52] Wie werden die Tests durchgeführt?

[3:54] Wer führt die Tests durch?

[3:56] Welche Kenntnisse muss ich für die Erzeugung von Testfällen haben?

[4:00] Wann werden die Tests erstellt?

[4:02] Wird die Software für den Test ausgeführt oder nicht?

[4:06] Und welches Ziel verfolgen die Tests?

[4:08] Das wären so verschiedene Möglichkeiten, wie ich Tests eingruppieren kann.

[4:12] Ich kann zum Beispiel so etwas wie Unit Tests in mehrere dieser Kategorien einteilen.

[4:17] Zum Beispiel wird bei einem Unit Test eine einzelne Komponente getestet.

[4:21] Sie werden hauptsächlich maschinell, also automatisch durchgeführt.

[4:26] Der Entwickler führt sie durch.

[4:28] Kenntnisse sind nötig über den Code, damit ich auch weiß, welche Edge Cases und so ich testen muss.

[4:34] Wann ich die Tests erstelle, hängt z.B. ab, ob ich Tests zu den Entwicklern mache oder nicht.

[4:38] Also z.B. Test First oder Test Last.

[4:40] Bei Unit Tests wird die Software ausgeführt.

[4:44] Das ist also ein dynamisches Testverfahren.

[4:46] Und das wäre es eigentlich schon.

[4:49] Wenn ich mich anhand dieser Stichpunkte entlanghangle, komme ich auch auf die Alternativen,

[4:53] die es vielleicht zu den Testverfahren, die ich schon kenne oder die ich schon genannt habe, besser noch gibt.

[4:57] Deswegen finde ich das immer eine ganz wichtige Sache,

[4:59] so ein paar dieser Klassifizierungsmerkmale sich einfach zu merken.

[5:03] Und anhand derer kann man sich dann durch alle möglichen Testverfahren, die es da draußen gibt, durchhangeln.

[5:08] Und das mache ich jetzt auch einfach mal.

[5:10] Fangen wir doch mal mit der ersten Frage an.

[5:12] Was wird getestet?

[5:14] Da gibt es mehrere Unterscheidungen bzw. zwei, die ich jetzt noch mitgebracht habe.

[5:17] Einmal Komponente bzw. Unit, Integrationstest oder das ganze System.

[5:23] Das wäre dann ein Systemtest.

[5:25] Man kann aber auch die funktionalen Anforderungen oder die nicht funktionalen Anforderungen testen.

[5:29] Das wäre dann die zweite Möglichkeit, das zu klassifizieren.

[5:32] Gehen wir das kurz durch.

[5:33] Eine Komponente oder auch Unit, daher kommt auch der Begriff beim Unit-Test,

[5:37] ist die kleinste zu testende Einheit meiner Software.

[5:41] Meistens ist es halt eine Methode z.B. in der Objekteorientierung.

[5:44] Und die wird normalerweise in Isolation getestet,

[5:47] d.h. ohne, dass sie mit anderen Komponenten zusammenspielt.

[5:50] Sofern ich dann aber zwei Komponenten oder mehr gemeinsam teste,

[5:55] also Klassiker, eine Klasse, die irgendwie auf eine Datenbankklasse zugreift,

[6:00] dann habe ich schon einen Integrationstest,

[6:02] weil ich hier zwei Dinge teste, die zusammen nur ihre Funktionalität bereitstellen z.B.

[6:08] Und als letztes kann ich noch das gesamte System als Ganzes quasi testen.

[6:12] Das wäre dann halt der Systemtest.

[6:14] Ich habe also hier den Fokus, was teste ich.

[6:16] Etwas im Kleinen, es ist eine Komponente, sind es mehrere zusammen, ist es eine Integration.

[6:21] Und wenn ich das gesamte System teste, also z.B. über die GUI irgendwas ausführe,

[6:25] das dann bis runter in die Datenbank geht, dann mache ich einen Systemtest.

[6:29] Auf der anderen Seite kann ich dann entweder funktionale oder nicht funktionale Anforderungen testen.

[6:35] Also z.B. wenn ich irgendwo einen Taschenrechner programmiere,

[6:38] ich weiß, das werden wir in der Praxis nicht tun, aber stellen wir uns das vor,

[6:41] dann wäre natürlich eine Funktion dieses Taschenrechners die Addiere-Funktion z.B.

[6:45] Und da kann ich jetzt natürlich ganz konkret schauen, ob er denn korrekt addiert.

[6:48] Das wären also eine funktionale Anforderung, dass die Addition korrekt gemacht wird.

[6:53] Es gibt aber auch nicht funktionale Anforderungen, die wollen wir jetzt hier nicht alle durchgehen,

[6:56] aber das wäre dann sowas wie Ausfallsicherheit z.B. oder Effizienz oder Sicherheit und Performance und solche Sachen.

[7:05] Das kann man jetzt am Taschenrechner schlecht festmachen, aber wenn z.B. die Addiere-Funktion 5 Sekunden braucht,

[7:10] um zwei Zahlen zu addieren, dann wäre das glaube ich durchgefallen bei der nicht funktionalen Anforderung der Performance.

[7:15] Aber zu den Anforderungen, die es da draußen so gibt, mache ich glaube ich nochmal eine eigene Podcast-Episode.

[7:20] Das ist ganz schön umfangreich und gerade auch diese nicht funktionalen Anforderungen,

[7:23] das sind eigentlich viel, viel mehr Anforderungen als es Funktionale gibt.

[7:27] Ich habe mal so eine schöne Klassifizierung von Anforderungen gesehen.

[7:30] Da sind die funktionalen Anforderungen genau eine Gruppe und es gibt dann noch 23 andere Gruppen, die alle nicht funktional sind.

[7:38] Von daher sollte man da gut schauen, was denn da getestet werden soll.

[7:42] Denn z.B. die Performance einer Anwendung, die teste ich natürlich ganz, ganz anders als die Funktion.

[7:48] Bei der Addition, um dabei zu bleiben, da kann ich natürlich jetzt einfach zwei Zahlen reingeben und ich erwarte, dass die dritte zurückkommt.

[7:54] Aber wie teste ich denn die Performance des Taschenrechners?

[7:56] Da muss ich schon mir wirklich was Gutes überlegen.

[7:59] Ich brauche irgendwie, keine Ahnung, eine automatische Stoppuhr oder keine Ahnung,

[8:02] um irgendwie auch einen Toleranzbereich festzulegen z.B. wird das schon sehr schwierig.

[8:06] Was ist denn schnelle Antwortzeit? 10 Millisekunden, 100 oder 1000?

[8:10] Das ist also schon sehr, sehr schwierig.

[8:13] Gut, dann gehen wir weiter mit meiner nächsten Frage zur Klassifikation.

[8:16] Wie werden die Tests denn durchgeführt?

[8:18] Da gibt es eigentlich nur zwei Möglichkeiten.

[8:20] Entweder ein Mensch führt die Tests manuell aus oder halt eine Maschine.

[8:23] Der Computer führt die Tests automatisch aus.

[8:26] Und das ist natürlich auch eine wichtige Frage in der Prüfung.

[8:29] Was unterscheidet jetzt die beiden Testverfahren?

[8:31] Naja, manuelle Tests sind teuer.

[8:33] Der Mensch ist so ziemlich das Teuerste, was wir da draußen an Rohstoff, will ich jetzt nicht sagen,

[8:38] aber an Betriebsmittel, finde ich auch doof.

[8:40] Aber irgendwie das, was die Unternehmen draußen bezahlen, da ist meistens der Mensch oder die Arbeitszeit des Menschen das Teuerste.

[8:45] Das heißt, wenn ich jetzt einen Tester Vollzeit da hinsetze, der durch meine Anwendung klickt,

[8:49] dann wird das ganz schön teuer für das Unternehmen.

[8:51] Alles, was natürlich der Computer machen kann, ist demgegenüber sehr, sehr billig und vor allem auch sehr schnell.

[8:56] Bis der Mensch sich irgendwo durchgeklickt hat und irgendwas ausprobiert hat

[8:59] und dann irgendwo in einem Protokoll einen Haken gesetzt hat,

[9:01] da kann man schlecht der Computer 7000 automatische Tests durchführen in der gleichen Zeit.

[9:06] Also von daher werden automatische Tests zumindest von den Entwicklern auf jeden Fall bevorzugt,

[9:11] denn ein manuelles Testen ist natürlich auch langweilig.

[9:14] Das ist kein Job, den man gerne macht, weil man immer wieder das gleiche testen muss.

[9:18] Bei jedem neuen Release der Software muss ich eigentlich alle schon bekannten vorhandenen Funktionen nochmal testen,

[9:25] denn die könnten ja alle kaputt gegangen sein.

[9:27] Und das heißt, ich mache auf Deutsch gesagt immer wieder dasselbe.

[9:29] Und das ist natürlich jetzt nicht gerade ein Traumjob vielleicht.

[9:32] Also, wichtige Klassifizierung, entweder manuelle Tests oder automatische Tests.

[9:38] Dann ist vielleicht auch ganz wichtig für die Klassifizierung, wer führt denn diese Tests durch?

[9:42] Da kann man zum Beispiel unterscheiden zwischen Entwickler oder Fachbereich.

[9:45] Man könnte aber zum Beispiel auch noch den Kunden dazunehmen und verschiedene andere Zielgruppen.

[9:49] Ich unterscheide jetzt erstmal hier zwischen dem Entwickler.

[9:51] Da wären wir dann zum Beispiel wieder bei den Unit Tests, weil der Entwickler die natürlich programmieren muss.

[9:56] Oder eben der Fachbereich.

[9:58] Der Fachbereich wird wahrscheinlich eher manuelle Tests durchführen und auch ganz anders an die Tests herangehen.

[10:04] Das werden wir gleich dann auch sehen, welche Kenntnisse muss er denn mitbringen.

[10:07] Der Entwickler kann natürlich mit Kenntnis des Codes ganz anders testen als ein Fachbereich, der das System so ein bisschen als Blackbox versteht.

[10:14] Und da schlage ich auch direkt die Brücke zur nächsten Einteilung.

[10:17] Nämlich, welche Kenntnisse muss ich jetzt mitbringen, um die Testfälle erstellen zu können.

[10:21] Bei einem Whitebox-Test heißt das, ich kann den Sourcecode lesen.

[10:27] Ich kenne den Sourcecode und weiß, was der macht.

[10:29] Und bei einem Blackbox-Test verhält sich die Software für mich wie eine Blackbox.

[10:34] Deswegen heißt das so.

[10:35] Blackbox im Sinne von, ich kann nicht reingucken.

[10:37] Das heißt, ich gebe nur von draußen irgendetwas rein und kriege auf der anderen Seite wieder was raus.

[10:41] Aber was dazwischen so passiert ist, das sehe ich nicht.

[10:44] Das heißt, bei der Erzeugung meiner Testfälle zum Beispiel, kann ich nicht berücksichtigen, was jetzt diese Box mit meinen Daten macht.

[10:52] Ob da zum Beispiel eine Schleife durchlaufen wird oder eine Fallunterscheidung oder sonst irgendwas.

[10:55] Ich sehe nur, das gebe ich rein, das kommt hinten raus.

[10:58] Wenn ich allerdings den Code kenne, also mein System wie eine Whitebox, eine durchsichtige Box, wo ich quasi reinschauen kann, betrachte,

[11:05] dann sehe ich, oh, da wird eine Schleife gedreht.

[11:07] Und die Schleife zählt von 1 bis 10.

[11:09] Das heißt, vielleicht müsste ich auch mal irgendwie einen Test machen mit Eingangswert 11 oder sowas.

[11:14] Wenn zum Beispiel der Zähler als Variable von draußen reingegeben wird.

[11:17] Einfach um zu gucken, ob dieser Sonderfall da auch berücksichtigt wird.

[11:20] Während zum Beispiel bei der Blackbox der Fachbereich einfach sagt,

[11:23] Mensch, ich gebe da mal meine Standardwerte rein.

[11:25] Mehrwertsteuer 19 Prozent gebe ich mal rein, wird wohl passen.

[11:29] Aber er würde vielleicht nicht auf die Idee kommen, zum Beispiel als Mehrwertsteuersatz minus 19 da einzugeben.

[11:34] Einfach nur um zu gucken, ob das dann auch funktioniert.

[11:37] Und das würde mir sehr wahrscheinlich einfallen, wenn ich den Code vor mir sehe,

[11:41] weil ich dann halt genau weiß, welche Probleme dieser Code eventuell haben könnte.

[11:46] Und demnach komme ich dann auch auf ganz andere Testfälle.

[11:49] Also, es ist schon interessant, wer auch diesen Test durchführt.

[11:52] Entwickler, Fachbereich, eine Testabteilung, der Kunde vielleicht sogar.

[11:56] Das kann man also einmal heranziehen.

[11:58] Und auch, was ich über den Code wissen muss oder über das System wissen muss, um es testen zu können.

[12:03] Dann gibt es noch eine Einteilungsmöglichkeit danach, wann diese Tests erstellt werden.

[12:08] Da gibt es zum Beispiel den Test First oder den Test Last Ansatz.

[12:12] Test First haben wir zum Beispiel beim Test Driven Development.

[12:15] Da wird der Testcode geschrieben, bevor der entsprechende Produktivcode geschrieben wird.

[12:20] Und beim Test Last werden halt die Tests am Ende der Programmierung des Produktivcodes erstellt.

[12:25] Beides hat so Vor- und Nachteile.

[12:27] Wobei, ehrlich gesagt, Nachteile bei Test First kenne ich eigentlich nicht.

[12:31] Ich kenne eigentlich nur Nachteile bei Test Last.

[12:33] Und der zentrale Nachteil ist, dass es dann keiner mehr die Tests schreibt,

[12:36] weil dann der Kunde schon bezahlt hat.

[12:38] Nein, bezahlt hat nicht.

[12:39] Aber die Zeit wird knapp.

[12:41] Das Projektziel oder das Projektende nähert sich.

[12:44] Und dann sagt der Chef, Leute, wir müssen fertig werden.

[12:46] Komm, schmeiß die Tests weg.

[12:47] Wir machen nur noch Produktivcodes.

[12:49] Hier noch ein Feature.

[12:50] Da noch was Tolles rein.

[12:51] Und dann schreibt natürlich kein Mensch mehr Tests.

[12:52] Die werden vernachlässigt.

[12:53] Genauso wie die Dokumentation am Ende immer hinten runterfällt.

[12:56] Von daher ist es eigentlich immer sinnvoll, die Tests zuerst zu schreiben.

[12:59] Insbesondere als Entwickler natürlich.

[13:01] Also das Test Driven Development, finde ich, sollte schon Standard sein bei der Softwareentwicklung.

[13:06] Dadurch kann ich auch meinen Code gezielt designen.

[13:09] Deswegen heißt es auch Test Driven Development.

[13:13] Weil die Tests nämlich meine Implementierung vorantreiben und auch mein Design.

[13:17] Aber davon mal abgesehen, gibt es also zwei Möglichkeiten.

[13:19] Wenn ich zum Beispiel eine Methode testen möchte, dann kann ich den Test vor der Methodenimplementierung schreiben.

[13:25] Oder ich schreibe die Tests halt danach, wenn sie schon fertig ist.

[13:28] Und dann gibt es noch eine Möglichkeit, in einem Produktlebenszyklus vielleicht meine Tests anzuordnen.

[13:33] Zum Beispiel im Sinne eines Alpha- oder Beta-Tests.

[13:37] Je nachdem, wer diese Tests dann durchführt.

[13:40] Und zu welchem Zeitpunkt in meinem Projekt kann man zum Beispiel von einem Alpha-Test reden.

[13:44] Wenn ich quasi die erste lauffähige Version fertig habe und einfach mal testen lassen will, ob die grundsätzlich das Richtige macht.

[13:50] Und ein Beta-Test ist zum Beispiel etwas, was relativ zeitnah vor dem Release oder vor der ersten verkaufsfähigen Version durchgeführt wird.

[14:00] Einfach um so die letzten Fehler auszumerzen.

[14:03] Und je nachdem, wo man das in der Projektlaufzeit dann macht, kann man das eventuell halt Alpha- oder Beta- oder Gamma- oder was auch immer Test nennen.

[14:12] Eine weitere Klassifikationsmöglichkeit ist dann die Frage, ob die Software bei den Tests durchgeführt wird oder ausgeführt wird, besser gesagt.

[14:19] Oder nicht.

[14:20] Und so unterscheiden sich dann die dynamischen und die statischen Testverfahren.

[14:24] Dynamische Testverfahren bedeutet, da wird der Code ausgeführt tatsächlich.

[14:29] Und statisch heißt, der Code wird einfach nur von draußen quasi untersucht, analysiert und vielleicht auch Fehler geprüft.

[14:36] Aber dazu wird eben nicht die Software ausgeführt.

[14:38] Daran kann man auch schon einiges unterscheiden.

[14:40] Zum Beispiel ein dynamisches Testverfahren wären die Unit-Tests, weil die die Software definitiv ausführen.

[14:44] Ein statisches Testverfahren wäre alles, was zum Beispiel der Mensch mit dem Code macht, weil er sich den einfach durchliest.

[14:50] Ein Code-Review zum Beispiel.

[14:52] Oder auch statische Code-Analyse, so etwas wie Find-Bugs oder PMD in der Java-Welt.

[14:58] Oder zum Beispiel FX-COP heißt es glaube ich für .NET, wo dann zum Beispiel die Sharp-Code untersucht wird, ob da irgendwelche Fehler drin sind.

[15:07] Das wäre dann halt ein statisches Testverfahren, wo die Software eben nicht ausgeführt wird.

[15:12] Was es auch gibt, wäre sogar eine mathematische Verifikation.

[15:15] Es gibt Programmiersprachen, wo ich die Korrektheit des Codes beweisen kann.

[15:19] Und zwar einfach mit, ich will jetzt nicht sagen simpler Mathematik, aber es gibt dann gewisse Verfahren, da muss ich die Software nicht mehr ausführen.

[15:26] Ich gucke mir den Code an und kann quasi, frag mich nicht genau wie das funktioniert, beweisen, dass der Code dann auch korrekt ist.

[15:34] Die letzte Möglichkeit, die ich noch habe, ist, welches Ziel verfolgen die Tests.

[15:38] Da gibt es jetzt zum Beispiel die Möglichkeit, Regressionen zu verhindern oder eine Last zu simulieren oder vielleicht sogar eine Abnahme durchzuführen.

[15:46] Aber in den meisten Fällen wird das Ziel wohl sein, irgendwelche Fehler zu finden.

[15:50] Das finde ich auch immer ganz interessant.

[15:52] Das Testen von Software kann keine Fehler verhindern oder beziehungsweise beweisen, dass die Software fehlerfrei ist.

[15:59] Sie kann halt nur nachweisen, dass gewisse Sachen funktionieren, aber halt eben nicht, dass alles hundertprozentig korrekt ist.

[16:06] Denn ein sogenanntes erschöpfendes Testen, das heißt alle Sonderfälle, alle überhaupt denkbar möglichen Fälle meiner Software, die kann ich niemals in der Praxis komplett testen.

[16:18] Das kann man sich allein schon anhand eines simplen Beispiels, nämlich gerne wieder die Additionsfunktion, herleiten.

[16:24] Wenn wir zum Beispiel sehen, wir haben eine Additionsfunktion, da gehen zwei Integer rein.

[16:28] Das bedeutet schon, dass ich einen riesen Haufen an nötiger Testfälle habe, um diese eine Funktion zu testen.

[16:34] Ich müsste zum Beispiel einen positiven Integer nehmen, vielleicht den Wert 0.

[16:39] Ich müsste einen negativen nehmen, ich müsste einen riesengroßen Wert nehmen, zum Beispiel genau der Maximalwert für Integer.

[16:45] Dann muss ich aber auch den Maximalwert für Integer plus 1 nehmen, um zu gucken, dass er auch mit ungültigen Werten klarkommt.

[16:51] Ich kann vielleicht, wenn ich wirklich ein Integer benutze, auch null dort rein geben.

[16:55] Das war noch lange nicht alles, was ich da reingeben kann.

[16:58] Und jetzt müssen wir aber gucken, wenn wir zwei Integer als Parameter haben, dann muss ich ja für den zweiten Parameter genau die gleichen Werte theoretisch reingeben und dann potenzieren sich die Testfälle schon.

[17:08] Ich muss nämlich zum Beispiel für Parameter A und für Parameter B jeweils eine positive Zahl nehmen.

[17:15] Dann muss ich für A eine positive, für B eine negative, für A eine negative, für B eine positive, für A null, für B null und so weiter und so fort das nehmen.

[17:23] Das heißt, wir haben sofort schon n hoch k nötige Testfälle, um diese lächerlich kleine Methode erschöpfend testen zu können.

[17:33] Und daraus resultiert schon einfach für die Praxis, dass es einfach unmöglich ist, eine Software komplett zu testen.

[17:39] Das geht einfach nicht, weil es viel, viel, viel zu, nicht zu kompliziert, sondern es ist unmöglich, weil wir so viele Testfälle brauchen.

[17:48] Und das führt mich auch gleich zur nächsten Frage, nämlich, was sind Anweisungszweig und Pfadüberdeckung?

[17:55] Wenn man das kennt, dann sieht man auch nochmal, wie viele Tests eigentlich nötig sind, um eine Software zu testen.

[18:00] Also alle drei erstmal, das sind Maße für die Testabdeckung meines Codes und bei der sogenannten Anweisungsüberdeckung oder auch C0-Abdeckung genannt, also der Buchstabe C und dann die Zahl 0, da wird jede Anweisung im Code mindestens einmal durchlaufen.

[18:16] Das heißt, wenn ich so ein simples Konstrukt habe, wie hey, Printline, Printline, Printline und ich kriege irgendwie einen Testfall, wo alle diese drei Statements ausgeführt werden, dann habe ich schon eine komplette Anweisungsüberdeckung in meinem Code.

[18:28] Habe ich allerdings zum Beispiel eine kleine if-Anweisung in meinem Code und der Testfall führt nur den if-Zweig aus, aber nicht den else-Zweig, dann habe ich schon ein Problem, weil die Anweisung in dem else-Zweig nicht durchlaufen wird.

[18:42] Das heißt, ich habe dann keine vollständige Anweisungsüberdeckung.

[18:46] Davon aber mal abgesehen, ist es relativ einfach, eine Anweisungsüberdeckung hinzubekommen.

[18:52] Ich muss nämlich einfach nur einen kleinen Testfall ergänzen, der dann auch den else-Zweig durchläuft und so weiter.

[18:56] Oder zum Beispiel, wenn ich eine Schleife habe, einfach sicherstellen, dass die Schleife mindestens einmal durchlaufen wird und dann habe ich alle Anweisungen überdeckt und bin fertig.

[19:04] Aber, wenn ich jetzt mal weitergehe, dann muss ich mir überlegen, allein die Anweisung zu durchlaufen reicht nicht.

[19:11] Ich muss auch jeden Zweig, der möglich ist, in meiner Software durchlaufen.

[19:15] Bleiben wir also bei dem if.

[19:17] Wenn ich sowohl den if-Zweig als auch den else-Zweig durchlaufen habe, dann habe ich eine Zweigüberdeckung.

[19:23] Dann bin ich komplett bei jeder Möglichkeit, wo sich mein Pfad in zwei Pfade aufteilt, durchlaufen.

[19:32] Und dann habe ich alles abgedeckt, was dort passieren kann in meinem Code.

[19:37] Und das ist immer so, dass die Zweigüberdeckung, die heißt auch C1-Überdeckung, dass die

[19:43] automatisch die Anweisungsüberdeckung, also C0, mit inkludiert.

[19:47] Das heißt, ich kann keine Zweigüberdeckung haben ohne eine komplette Anweisungsüberdeckung.

[19:51] Das inkludiert sich also immer.

[19:53] Ist auch genau das Beispiel von eben, wenn ich alle Pfade zum Beispiel bei einem IF durchlaufen

[19:57] habe, dann habe ich auch automatisch jede Anweisung in meinem Code mit abgedeckt.

[20:02] Das letzte, was ich aber dann noch am besten noch obendrauf bräuchte, wäre die Pfadüberdeckung.

[20:08] Das wäre die C2-Überdeckung und dort werden alle Pfade durch den Code getestet.

[20:13] Und was ist das jetzt noch für ein, was macht das noch mehr als die Zweigüberdeckung?

[20:18] Na da denken wir jetzt zum Beispiel mal an Schleifen.

[20:20] Wenn ich eine Schleife habe, die von 1 bis 10 zählt, dann bräuchte ich theoretisch

[20:25] 10 Tests, weil ja, die Schleife bis 1 zählen kann oder bis 2 oder bis 3 oder bis 4.

[20:31] Je nachdem, was zum Beispiel da das Abbruchkriterium ist bei der Schleife.

[20:35] Also bräuchte ich so viele Tests, dass alle möglichen Pfade durch diese Schleife und

[20:40] das sind 10, dass die alle abgedeckt sind.

[20:43] Und dann sehen wir schon, dass wir hier relativ viele Testfälle brauchen, um das überhaupt

[20:47] hinzukriegen.

[20:48] Und die Pfadüberdeckung ist jetzt genau wie bei Zweig- und Anweisungsüberdeckung, die

[20:53] inkludiert automatisch die Zweigüberdeckung.

[20:55] Das heißt, sie sind alle so ein bisschen inkludierend.

[20:57] C2 enthält automatisch C1 und C0 und C1 enthält automatisch C0, wenn ich das fertig habe.

[21:04] Und da kann ich aber auch noch ein paar Artikel, die ich in die Show Notes gepackt habe, dir

[21:07] dringend empfehlen, denn die Pfadüberdeckung ist schon etwas, was in der Praxis eigentlich

[21:11] nicht mehr umsetzbar ist.

[21:12] Ich kann meinen Code nicht erschöpfend testen und jeden einzelnen Pfad, den man sich vorstellen

[21:18] kann, durch meinen Code abbilden.

[21:20] Das ist einfach viel zu komplex.

[21:22] Das geht nicht.

[21:23] Und wenn wir schon beim Thema sind, das kann man jetzt gut verbinden mit einer weiteren

[21:27] Frage, nämlich, was ist die zyklomatische Komplexität?

[21:31] Und die zyklomatische Komplexität, oder auch MACCAPE-Zahl genannt, das ist ein Maß für

[21:36] die Anzahl der möglichen Pfade, die mein Code halt eben nehmen kann.

[21:41] Und stellen wir uns jetzt ein ganz einfaches Beispiel vor, mit einer IF-Anweisung und einer

[21:45] Schleife, die bis 10 zählt, dann habe ich automatisch schon 20 Pfade durch meinen Code.

[21:51] Denn das IF könnte einmal in den True- oder einmal in den False-Zweig quasi gehen, also

[21:56] einmal in den IF, einmal in den Else-Zweig und danach würde sie vielleicht eine Schleife

[22:00] durchlaufen, die 10 mögliche Durchläufe haben kann.

[22:05] Dann könnte es so sein, dass ich beim IF in den IF-Zweig gehe und danach bis 1 zähle

[22:10] oder in den Else-Zweig gehe und bis 2 zähle oder in den IF und bis 5 zähle und so weiter.

[22:15] Du siehst, du musst alles kombinieren, was da möglich ist.

[22:17] Das heißt, beim IF gibt es zwei unterschiedliche Möglichkeiten und bei der Schleife gibt es

[22:21] 10.

[22:22] Das heißt, die müssen jetzt multipliziert werden, um auf die Gesamtanzahl aller Pfade

[22:27] zu kommen.

[22:28] Und diese Anzahl, das ist jetzt sehr vereinfacht, das ist jetzt nicht identisch mit der zyklomatischen

[22:34] Komplexität, aber die zyklomatische Komplexität ist eine Maßzahl, die mir sagt, wie komplex

[22:39] mein Code ist, also wie viele Möglichkeiten es gibt, um diesen Code zu durchlaufen.

[22:44] Das ist nicht hundertprozentig das, was ich gerade gesagt habe, also nicht einfach 2 mal

[22:47] 10 und dann bin ich fertig, aber so grob kann man das schon sagen, dass das so berechnet

[22:51] wird.

[22:52] Je komplexer mein Code, umso mehr Möglichkeiten gibt es, diesen Code zu durchlaufen und umso

[22:58] mehr Testfälle brauche ich, um das abzudecken.

[23:01] Und, das ist jetzt eigentlich das interessante an der zyklomatischen Komplexität, umso schwieriger

[23:05] wird es für den Menschen, den Code zu verstehen, weil ich einfach nicht mehr 20 verschiedene

[23:10] Wege durch den Code in meinem Kopf halten kann und verstehen kann und abgleichen kann.

[23:14] Von daher, je höher die Komplexität, umso schwieriger zu testen und umso unverständlicher

[23:19] wird das Programm.

[23:21] Oh, dann bin ich schon bei meiner letzten Frage für heute und zwar, das ist jetzt so

[23:24] der Killer, welche sonstigen Testverfahren gibt es denn sonst noch so?

[23:28] Damit kann man jetzt alles erschlagen, was noch nicht genannt wurde und ich habe jetzt

[23:32] einfach mal ein paar noch mitgebracht, vier kleine Testverfahren, die du vielleicht schon

[23:37] mal gehört haben solltest und das sind zum Beispiel der Abnahmetest, der Lasttest, der

[23:41] Smoketest und das Explorative Testen, die gehen wir jetzt mal kurz der Reihe nach durch.

[23:48] Der Abnahmetest oder auch gerne genannt Akzeptanztest bzw. so modern englisch User Acceptance Test,

[23:57] das ist der finale Test des Kunden, der unsere Software quasi kauft oder abnimmt, also abnehmen

[24:04] im Sinne von kaufen, nicht im Sinne der Abnahme, darum geht es ja hier, aber der führt diesen

[24:09] Test durch, bevor er uns quasi die Kohle überweist, darum geht es nämlich eigentlich.

[24:13] Das heißt, du hast jetzt deine Auftragsarbeit erledigt, du hast deine Software produziert

[24:17] und jetzt soll der Kunde natürlich sicherstellen, dass er auch das gekriegt hat, was er haben

[24:20] wollte und was muss er machen?

[24:22] Dazu muss er die Software testen, ausprobieren, schauen, ob die das macht, was er haben will

[24:27] und wenn dieser Abnahmetest jetzt bestanden ist, dann bedeutet das, der Kunde hat dir

[24:32] gesagt, jo, du hast deine Pflicht erfüllt, das Produkt, was ich in Auftrag gegeben habe,

[24:37] das setzt genau die Sachen um, die ich haben wollte, das bescheinige ich dir durch diesen

[24:42] Abnahmetest und damit werde ich jetzt quasi zahlungspflichtig und muss dir deine Rechnung

[24:48] bezahlen, weil du jetzt ja deinen Job gemacht hast, also bin ich jetzt dran und darf dir

[24:51] das Geld überweisen.

[24:52] Das ist also etwas, was quasi auch eine wichtige Hürde darstellt in so einem Projekt, das

[24:57] bedeutet nämlich, jetzt ist das Projekt beendet und quasi der Vertrag ist jetzt erfüllt von

[25:02] deiner Seite.

[25:03] Der nächste Begriff, den ich hatte, das war der Lasttest, ein Lasttest ist eine Möglichkeit,

[25:09] um ein System, wie der Name schon sagt, unter Last zu bringen, das heißt, es wird möglichst

[25:14] versucht, ganz, ganz viele gleichzeitige Zugriffe zum Beispiel auszuprobieren, mehrere User

[25:18] da drauf zu lassen oder automatisiert natürlich am besten ganz viele Zugriffe zu erzeugen

[25:23] und zu gucken, wie verhält sich denn das System unter hoher Last, denn wenn ich das

[25:27] auf meinem Entwicklersystem alles toll programmiere und ich klicke da einfach mal ein, zweimal

[25:32] im Menü rum, ist das natürlich was anderes, als wenn tausend User gleichzeitig irgendwie

[25:36] die Web-Requests auf meinen Server loslassen und dann müsste ich vielleicht schon mal

[25:40] im Vorfeld testen, ob mein System denn unter so einer hohen Last noch vernünftig arbeitet,

[25:45] ob die Response-Time noch vernünftig ist oder ob das Ding einfach super langsam wird

[25:49] oder ob es vielleicht sogar abstürzt, weil halt der Server die Last nicht mehr aushalten

[25:54] kann und das wäre natürlich sehr, sehr ungünstig, gerade in heutigen Zeiten, wenn

[25:57] wir viele Web-Anwendungen bauen und wir stellen so ein Ding online, da kann es halt innerhalb

[26:01] von ein paar Stunden, Tagen, wie auch immer sein, dass da massig User auf die Software

[26:06] gehen und wenn wir das vorher nie getestet haben und auf einmal alle einfach nur noch

[26:10] Fehlerbildschirme kriegen, das wäre sehr, sehr ungünstig. Von daher gibt es dann zum

[26:14] Beispiel auch Tools, die automatisiert, zum Beispiel für den Apache-Server, einfach massenweise

[26:20] Requests erzeugen, da sagt man einfach hier, mach mal mit 10 Threads parallel ganz viele

[26:25] Zugriffe pro Sekunde auf die und die URL und dann kann man mal gucken, ob der Server

[26:29] am Ende noch steht oder ob er irgendwie die Grätsche gemacht hat. Dann einen schönen

[26:33] Begriff, den man häufig nochmal hört, das ist der Smoke-Test und das kann man sich eigentlich

[26:39] schön merken anhand der Bezeichnung. Smoke-Test, wo kommt das eigentlich her? Das gibt es auch

[26:43] in anderen Branchen, nicht nur in der Software-Branche und der eigentliche Name kommt wohl daher,

[26:48] wenn du zum Beispiel ein Rohr verlegt hast, ja, als Klempner und du willst sicher sein,

[26:54] dass das Rohr dicht ist, dass an den ganzen Verschraubungen und Verschweißungen und ich

[26:58] weiß nicht, was da alle gemacht wird, ob alle Muffen richtig sitzen oder wie das heißt,

[27:02] da kannst du zum Beispiel, bevor du da jetzt den großen Wasserdruck drauflässt, einfach

[27:06] mal ein bisschen Smoke, ein bisschen Rauch durch die Rohre schicken und der Rauch müsste

[27:11] sich dann an allen Stellen, wo das Rohr undicht ist, quasi seinen Weg nach draußen bahnen

[27:15] und da könntest du dann direkt erkennen, ob du alles richtig gemacht hast oder ob

[27:18] es halt noch Lücken in deinem Rohr gibt. Genau dazu ist jetzt auch der Smoke-Test

[27:24] in der Software-Entwicklung da. In diesem Fall ist es allerdings ein bisschen anders

[27:27] zu verstehen, also der Smoke-Test bei so einem Rohr wäre wirklich der erste Test,

[27:30] der gemacht wird, um zu gucken, ob das Rohr potenziell dicht ist oder nicht. Und genau

[27:35] so kannst du es auf die Software übertragen. Das ist so ein erster grober Test der Software,

[27:40] um zu entscheiden, ob das Ding potenziell überhaupt lauffähig ist oder nicht. Also,

[27:44] ob du es überhaupt installieren kannst, ob du das Menü aufmachen kannst, ob, keine Ahnung,

[27:47] beim Datei öffnen auch ein Dialog aufgeht oder ob das Ding beim ersten Klick abraucht im Prinzip,

[27:52] ja. Das ist der Smoke-Test. Also es geht hier jetzt nicht darum, irgendwie was kaputt zu machen

[27:56] oder sowas, sondern es geht darum, ist das Produkt potenziell grundsätzlich überhaupt

[28:01] lauffähig oder ist es schon noch nicht mal startbar oder so. Und wenn das Ding grundsätzlich läuft,

[28:06] wenn der Smoke-Test also erfolgreich war, dann kann ich auch einsteigen in die tieferen Tests,

[28:11] dann kann ich in die Details gehen, in die automatischen Tests und so weiter und so fort.

[28:14] Aber wenn ich das Ding schon direkt nach dem ersten Klick quasi als kaputt identifiziere,

[28:19] dann brauche ich den ganzen anderen Kram gar nicht mehr testen. Dafür ist der Smoke-Test ganz gut.

[28:24] Zum Schluss noch ein Begriff, das Explorative Testen. Was ist das? Kann man eigentlich auch

[28:29] aus dem Wort herleiten, Explore auf Englisch. Das heißt ja sowas wie erkunden, erforschen und hier

[28:36] geht es auch genau darum, dass ein erfahrener Benutzer so ein bisschen mal rumprobiert,

[28:41] ein bisschen die Software erforscht und einfach mal hin und her klickt und Sachen ausprobiert,

[28:46] einfach mal falsche Werte eingibt oder auch mal richtige und einfach mal wirklich mit seinem

[28:50] Hintergrundwissen und seiner Erfahrung probiert, die Software kaputt zu machen,

[28:54] auf Deutsch gesagt. Das heißt, wir verlassen uns hier nicht auf irgendwelche Prinzipien wie

[28:59] Äquivalenzklassen oder Pfadüberdeckung oder sonstige ganz tolle mathematische Verfahren,

[29:05] sondern wir setzen einfach einen Menschen an die Software und der probiert einfach mal aus.

[29:09] Das sollte natürlich jetzt nicht so sein, dass er einfach mal nur den Standardweg ausprobiert

[29:14] und guckt, ob die Funktionalität da ist, sondern er soll natürlich wirklich dieses

[29:17] Hintergrundwissen mitbringen und zum Beispiel gucken, wenn ich irgendwo ein Datum eingebe,

[29:21] ah, dann ist es sehr häufig so, wenn ich ein Datum in der Zukunft wähle,

[29:24] dass es vielleicht ein Problem gibt mit der Software. Also probiere ich das mal aus. Oder

[29:28] wenn ich den Namen eingebe, gebe ich da einfach mal ein Sonderzeichen ein, das eigentlich gar

[29:32] nicht erlaubt sein sollte in meinem Namen und so weiter. Das heißt, ich brauche eigentlich

[29:35] erfahrene Tester, die so ein bisschen was mitbringen, wissen, was häufig zu Fehlern führt

[29:41] bei der Software und dann halt einfach mal ein bisschen drauf los testen. Und das würde ich

[29:45] auch immer tatsächlich meine User am Ende mal machen lassen oder beziehungsweise meine QA,

[29:49] meine Qualitätssicherungsabteilung, wenn ich mit der Programmierung fertig bin. Denn die Entwickler

[29:56] und auch die Benutzer, die testen häufig nur das, was sowieso funktioniert. Also die Standard

[30:02] Geschichten. Aber so erfahrene Tester, die haben halt im Hinterkopf, sehr häufig hat zum Beispiel

[30:07] der Entwickler vergessen, hier eine kleine Validierung einzubauen, also mache ich mal

[30:11] ein ungültiges Zeichen hier rein und schwupp stürzt das Ding ab. Und das sind häufig Dinge,

[30:16] die halt so Standardentwickler oder Benutzer eben vergessen zu testen. Und deswegen würde

[30:22] ich unbedingt mal einen erfahrenen Tester drauf loslassen, der halt nach solchen Lücken sucht.

[30:27] Okay, dann wäre heute die erste Episode zum Thema Testen im Fachgespräch auch abgehakt. Und wenn ich

[30:35] auf die Uhr schaue, habe ich das auch ziemlich gut eingehalten mit meinen 30 Minuten. Da bin

[30:39] ich schon mal sehr zufrieden. Ich fasse aber nochmal kurz zusammen, was wir heute gehört

[30:42] haben. Erstmal kann man Testverfahren klassifizieren anhand verschiedener Klassifikationsmerkmale. Und

[30:51] zwar, was wird getestet? Wie werden die Tests durchgeführt? Wer führt sie durch? Welche

[30:55] Kenntnisse brauche ich dafür? Wann werden die Tests erstellt? Wird die Software dafür ausgeführt

[31:00] oder nicht? Und welches Ziel verfolge ich mit den Tests? Und anhand dieser Kriterien kann ich jetzt

[31:04] verschiedene Testverfahren erläutern oder beziehungsweise auch eingruppieren. Ich hatte

[31:09] das am Beispiel der Unit-Tests gemacht. Dann haben wir uns detaillierter einmal den Unterschied

[31:14] zwischen Blackbox und Whitebox-Test angeguckt. Blackbox heißt, ich weiß nicht, wie die Software

[31:19] intern funktioniert. Ich weiß nur, was ich reingebe und was ich rauskriege. Und beim

[31:23] Whitebox-Test kenne ich die Struktur. Dann haben wir uns die Anweisungszweig- und

[31:28] Pfadüberdeckung angeschaut. Die Anweisungsüberdeckung bedeutet, dass jede Anweisung meines Codes mindestens

[31:32] einmal durchlaufen werden muss. Bei jeder Zweigüberdeckung muss jeder Zweig, also zum

[31:37] Beispiel bei einer IF-Anweisung der IF- und der ELS-Zweig durchlaufen werden. Und bei der

[31:42] Pfadüberdeckung sogar jeder individuelle Pfad, also zum Beispiel bei Schleifen auch jedes mögliche

[31:48] Abbruchkriterium in der Schleife, also wenn sie bis 10 zählt, von 1, 2, 3, 4, 5 bis 10, also zehn

[31:54] mögliche Pfade durch den Code. Dann haben wir noch über die zyklomatische Komplexität eine Maßzahl

[32:00] für die Komplexität meiner Software gesprochen, auch MAC-CAPE-Zahl genannt. Und die stellt halt

[32:08] dar, wie komplex meine Software ist, wie viele Wege es durch die Software gibt und wie schwer

[32:13] verständlich sie für den Menschen dadurch wird. Und dann haben wir noch ein paar separate kleine

[32:18] Testverfahren uns angeschaut, nämlich die Abnahmetest, den Lasttest, den Smoketest und das

[32:22] Explorative Testen. Der Abnahmetest ist durch den Kunden durchzuführen, bevor er uns quasi das Geld

[32:27] überweist für unser fertiges Produkt. Der Lasttest untersucht, ob das System auch unter

[32:32] hoher Last noch funktioniert oder abstürzt. Und der Smoketest ist der erste grobe Test der Software,

[32:38] um entscheiden zu können, ob weitere detaillierte Tests überhaupt sinnvoll sind, also ob die Software

[32:43] grundsätzlich läuft oder nicht. Und das Explorative Testen, das ist quasi ein Rumprobieren erfahrener

[32:48] Tester oder Benutzer, um gezielt nach, oder beziehungsweise nicht so gezielt, aber so ein

[32:54] bisschen zufällig auch auf Lücken vielleicht in der Software zu stoßen. Zu einigen dieser Begriffe

[32:59] habe ich auch ein paar Links in die Shownotes gepackt. Die findest du wie immer unter

[33:03] anwendungsentwicklerpodcast.de slash 94 für die heutige 94. Episode. Und als zentrale Literatur

[33:12] Empfehlung zu dem ganzen Kram hier habe ich ein sehr interessantes Buch von Peter Liggesmeier in

[33:18] die Shownotes gepackt, und zwar Softwarequalität testen, analysieren und verifizieren von Software.

[33:23] Das hat mich bei meiner eigenen Masterarbeit damals schon begleitet. Ich habe über Test-Driven

[33:27] Development geschrieben und das fand ich ein ganz tolles Buch, weil da auch absolute Grundlagen

[33:32] erläutert werden. Auch alle Begriffe, die wir heute hier gehört haben, sind da detailliert

[33:36] beschrieben und noch viel viel mehr. Also zum Beispiel auch, ich weiß nicht, Code-Reviews und

[33:40] statische Code-Analyse und der macht also da einen riesen Fass auf. Ist auch ein paar hundert Seiten

[33:45] dick, das Buch. Ich glaube 500 Seiten, meine ich, nur zum Thema Testen. Also wirklich absolut

[33:50] empfehlenswert, meiner Meinung nach. Aber ich muss auch dazu sagen, ist vielleicht für eine

[33:54] fachinformatiker Ausbildung ein bisschen sehr tiefgehend. Also das, was wir heute besprochen

[33:58] haben, so in der Tiefe, das müsstest du schon für eine Abschlussprüfung wissen. Aber jetzt noch mal

[34:03] wirklich tiefer reingehen und zum Beispiel bei der C2-Abdeckung noch die Untergruppen, die es dann

[34:08] noch gibt. Also das führt ehrlich gesagt dann auch zu weit. Aber falls du zum Beispiel besonderen Wert

[34:14] auf das Testen von Software liegst oder vielleicht sogar später mal oder jetzt sogar in der

[34:18] Testabteilung arbeitest, ja Softwareentwickler können ja auch Software-Tester später mal werden,

[34:22] dann lege ich dir das Buch definitiv ans Herz. Hat mir sehr gut gefallen damals und ich finde,

[34:27] es ist immer noch eines der Standardwerke, zumindest im deutschsprachigen Raum, für

[34:31] Software-Tests. Das Buch findest du, wie gesagt, in den Shownotes. Schau doch einfach mal rein und

[34:36] wenn du da schon gerade unterwegs bist im Blog, dann schau doch einfach mal auch in dem Blog-Artikel

[34:41] von letzter Woche. Da habe ich nämlich die Projektpräsentation meiner dualen Studentin

[34:46] Elena hochgeladen. Die hat dafür 98 Prozent abgesahnt bei der IHK Osnabrück und ich finde,

[34:52] es ist ein ganz ganz tolles Beispiel. Schön visuell gemacht, eigene Fotos eingebaut und

[34:56] wirklich eine tolle Präsentation. Schau doch mal rein, wenn du ein bisschen Inspiration für deine

[35:01] eigene Prüfung suchst. Letzte Woche habe ich im Blog auch noch ein paar Links veröffentlicht zum

[35:07] Thema Rückengesundheit. Ich bin ja auch so ein Verwächter von ökonomischer Hardware und

[35:12] gesundem Arbeiten und so weiter. Da kannst du auch mal reingucken. Da habe ich noch ein paar

[35:16] nette Rückentraining-Übungen verlinkt. Von Ergotopia waren sie, glaube ich. Wenn du noch

[35:23] ein paar mehr Hinweise hast, dann kommentiere gerne zu den beiden Episoden. Kommentiere auch

[35:28] gerne zu den beiden Blog-Artikeln. Zu der heutigen Episode kannst du mir auch gerne einen Kommentar

[35:33] schreiben, wenn du noch weitere Ergänzungen zum Thema Testverfahren hast oder irgendwelche

[35:39] möglichen Fragen fürs Fachgespräch dir vielleicht einfallen. Wenn du sofort informiert werden willst,

[35:44] wenn ich was Neues habe auf meiner Website, wie zum Beispiel auch diese Woche mein Azubi Jonas,

[35:51] der hat einen eigenen Fachartikel zum Thema Testen geschrieben und zwar für Unit-Tests mit

[35:56] Wiremock. Wiremock, das ist ein Framework zum Mocken von Rest-Schnittstellen zum Beispiel. Also

[36:01] wenn du Rest-Services benutzt in deiner Programmierung, dann kannst du mit Wiremock

[36:05] diese Rest-Schnittstellen rausmocken. Also der fährt einfach quasi zur Laufzeit einen Server

[36:10] hoch und antwortet auf Anfragen, die deine Software an eigentlich eine andere URL stellt.

[36:15] Also ein richtig cooles Ding, finde ich. Und da hat Jonas ein Artikel drüber geschrieben. Wenn du über

[36:19] diese Dinge und über alles andere, was ich auf der Website noch so veröffentliche, regelmäßig und

[36:23] zeitnah informiert werden willst, dann trag dir doch einfach mal ein Newsletter ein. Unter anderem

[36:28] ist der nicklaupodcast.de slash Newsletter. Kannst du das machen. Kostet auch nichts. Kannst du

[36:32] jederzeit wieder austragen, wenn du nicht mehr willst. Und dann kriegst du immer einmal die Woche

[36:36] am Montagmorgen von mir Info zu den Neuigkeiten und auch zu einigen Links, die ich die Woche über

[36:42] so gesammelt habe. Die kriegst du dann alle von mir in einem netten, kleinen, manchmal auch sehr

[36:49] langen Newsletter. Ich hoffe, es ist ein bisschen was für dich dabei. Und außerdem, wenn wir heute

[36:53] schon über das Fachgespräch reden, das ja Teil der Abschlussprüfung ist. Wenn du dich für den

[36:57] Newsletter anmeldest, kriegst du natürlich auch direkt Zugriff auf meine Artefakte zur Projektarbeit.

[37:04] So, meine Checklisten zur Projektdokumentation, Präsentation und so weiter. Kriegst direkt in der

[37:09] ersten Mail nach der Anmeldung den Zugriff darauf zugeschickt. Ja, was gibt es noch zu sagen? Ja,

[37:15] bald ist Episode 100 am Start. Das hatte ich schon mal angekündigt. Bis dahin sammle ich

[37:20] noch fleißig Fragen. Und zwar genau deine Fragen rund um die Ausbildung oder die Abschlussprüfung.

[37:26] Schick mir einfach eine Mail, schreib mich bei Twitter an, bei Facebook oder als Kommentar zur

[37:30] Episode. Du kannst mir alles rüberschicken und ich werde dann versuchen, das in Episode 100

[37:35] gesammelt zu beantworten. Würde mich freuen, wenn ich bis dahin noch ein bisschen was zusammenkriege.

[37:40] Also, her mit deinen Fragen. Schreib mich einfach an. Nächste Woche geht es dann hier weiter mit den

[37:47] häufigen Fragen im Fachgespräch. Dieses Mal mit Bezug zu Unit Tests. Das hatte ich ja schon gesagt,

[37:53] dass mir die heute hier fehlen. Und deswegen machen wir das dann nächste Woche, holen das

[37:58] nach. Und darauf die Woche am 13.03. gibt es dann auch schon den nächsten Buchclub zum Handbuch für

[38:04] Fachinformatiker. Und zwar geht es da um das Kapitel 10, die Konzepte der Programmierung.

[38:09] Das wird dann der vorletzte Teil des Buchclubs sein. Also, wenn du da noch mitmachen möchtest,

[38:13] dann lies dir doch das Kapitel durch. Kapitel 10, Konzepte der Programmierung bis zum 13.03.,

[38:18] da bespreche ich das hier im Podcast. Ansonsten sage ich für heute erst mal

[38:24] vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss!