Du kommst in diese Fabrik, 1000 Leute sitzen da und müssen diese Tests. Ja genau, und Klick, klick, Klick, Klick, Klick Coating, Boys, Dein Podcast rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Halli Hallo und herzlich Willkommen hier wieder zur neuen Folge von den Coding Buddies. Ich bin natürlich wieder dabei, der Fabi und auch der wunderbare Tino. Moin Moin tinari, na was geht ab? Wie geht's? Wie steht's? Hast du ein gutes Energielevel
mitgebracht? Natürlich, natürlich. Ich find's witzig, dass ich immer sage, was geht und du sagst, wie geht's, wie steht's, das ist doch so ein Signature schon jetzt hier. Ich weiß auch nicht, irgendwie hat sich das eingebrannt. Ich werde es mir mal angewöhnen. Was sagst du immer was? Geht was geht okay. Dann sage ich beim nächsten Mal was. Geht und ich dann wie geht's, wie stehts? Naja gut, man muss ja erst mal reinkommen. Man muss immer erst mal reinkommen.
Ich habe mir auf jeden Fall einen kleinen Kaffee wieder mitgebracht und deswegen würde ich sagen. Ohne geht ja nicht. Ohne geht nicht. Also hatten wir auch schon ein 2 Folgen, dass der Kaffee alle war und das ist. Sagt der so n so ne Podcast Folge aufzunehmen ist so wie täglich grüßt das. Murmeltier zumindest in die Intros. Ich hoffe, es wird noch nicht langweilig. Das denke ich nicht. Ich denke, liebe Zuhörer, lieber Zuhörer, du verstehst, dass so n Intro auch gerne mal sehr
ähnlich ist. Aber jetzt kommt doch der neue Inhalt, oder? Fabi, ja klar, jetzt kommt was Neues. Wir haben ja. Schon öfter mal übers Testen geredet. Also wir sind ja Verfechter von Software testen und nicht einfach ungetestete Software einfach so lassen wie sie ist.
Und zum Beispiel auch TDD. Ist ja alles möglich, haben wir schon ne Menge drüber gequatscht, auch über in der einen Folge über die Testpyramide, wie man zum Beispiel mit TDD oder auch mit kann ja auch, es gibt ja auch andere Arten des Testings. Wie man halt seine Tests aufbauen kann. Und da ging es ja die ganze Zeit eigentlich n bisschen so um. Also das das hat ja die die Gemeinsamkeit, die da drin steckt, ist ja, dass der Entwickler oder die Entwicklerin selbst die Tests schreibt, ne?
Ja genau. Also bei unserer Vorstellung oder wie wir es thematisiert haben, ja. Richtig, richtig. Und es gibt ja aber durchaus auch zum Beispiel die Möglichkeit beziehungsweise auch manchmal den Need beziehungsweise die Anforderungen, dass auch Software extern getestet wird. Und. Was meinst du, wenn jetzt zum Beispiel Software von extern getestet wird, kann man dann also einfach mal so in Raum gestellt?
Muss ich dann meine eigenen Tests, die ich sonst geschrieben hätte könnt, lasse ich die dann weg oder wie läuft das dann? Was was sagst du dazu um jetzt mal so ein bisschen hier rein zu gleiten ins Thema? War jetzt kein Softer Einstieg auf jeden Fall, sondern direkte, knallharte Frage. It depenses immer so ne schöne Ansage dabei. Nein. Also das ist. Wie soll ich sagen, ich find das ist auch so ein bisschen fast schon eine Glaubensfrage und eine Sache.
Dass viele Entwickler da vielleicht auch unterschiedlicher Meinung sind, aber ich kann ja mal von meinem Standpunkt ausgehen. Weil ich da auch niemanden zu nahe treten möchte. Aber ich denke, dass die eigenen Entwicklertests nie ersetzbar sind, also dass nichts quasi das ersetzen kann, dass ich selbst meinen Code teste. Ich kann verstehen, dass es in gewissen Projekten. Sage ich mal. Auch Prozesse gibt, die ein externes Testing vorsehen. Das bringt halt alles vor und
Nachteile mit sich. Die können wir ja dann gerne mal auch diskutieren, weil ich denke, das ist auf jeden Fall für unsere Zuhörerinnen und Zuhörer ein spannender Punkt oder spannender. Spannende Punkte sind ja mehrere. Aber grundsätzlich kann ich verstehen, dass externes testen Anforderungen sein kann, kann aber in meinen Augen niemals das eigene Testen ersetzen oder
sollte es nicht. Und das meine ich mit, dass es so ein bisschen Glaubensfrage, weil ich kenne oder habe auch Entwickler kennengelernt, die sagen, naja, wenn es eh noch getestet wird, extern werden wir ja wissen ob da Bugs drin sind in der Software und da muss ich ja nicht selbst noch Zeit investieren. Um quasi selbst Tests zu schreiben. Aber das ist genau die falsche Herangehensweise. Das kann man ja jetzt mal.
Du können wir beide mal diskutieren, aber ich hab da eigentlich n klares Bild was da vor und Nachteile sind jedenfalls für mich und ja genau so würde ich das Ganze denn mal angehen jetzt. Ja, auf jeden Fall. Aber erstmal würde mich auch interessieren, wie du das siehst. Ja, also erstmal fand ich waren auf jeden Fall ganz gutes Intro finde ich von dir dazu zu diesem Thema. Ist ziemlich ähnlich, weil das Ding ist klar kann man sagen, mal unabhängig davon wie extern
getestet wird. Beispielsweise darüber können wir sprechen, das finde ich, hat auch viel mit den vor und Nachteilen von der ganzen Sache zu tun. Und man geht jetzt einfach mal davon aus.
OKN Prozess erfordert einfach externes testen, das ist ist ja auch durchaus manchmal verständlich, ne also zu sagen so OK, du hast jetzt ne Software, die jetzt vielleicht nicht ausschließlich weil bestimmte keine Ahnung i sonormen erfüllt werden müssen oder was auch immer da so alles in der Welt rumgeistert kann es ja durchaus sein, dass man halt sagt okay es ist erforderlich die. Meiner Meinung nach ist das wie wird dann extern getestet.
Darüber würde ich mich auch gerne noch mal heute ein bisschen in der Folge mit dir unterhalten. Weil du meintest. Oder weil ich auch gefragt hab, ob dann die eigenen Tests Entwicklerseitig wegfallen können sollen. Würde ich auch sagen, das wäre sogar. Sehr von Nachteil, weil im Endeffekt kümmert man sich um die Software und wir hatten ja auch mal gesagt, dass die Software, die man schreibt, dafür hat man die. Und dafür muss man auch quasi die Qualität gewährleisten können.
Und das wenn das extern getestet wird, dann ist ja quasi zumindest meiner Meinung nach ein großer Bruchteil der Qualitätssicherung, die man selber als Softwareentwickler oder als Softwareentwicklerin machen muss, fällt halt einfach weg. Und. Deswegen würde ich sagen, unabhängig davon. Also selbst wenn es heißt, diese Software die an der man
schreiben muss. Gestern getestet würde ich mich zum Beispiel niemals hinstellen und sagen, ja gut, dann schreib ich halt keine Tests mehr für die Software, ne? Ja, an dem Punkt würde ich gerne noch eine Sache differenzieren, wenn wir über externes Testing reden und eigene Tests, finde ich. Ist da noch ein großer Punkt? Welche Art von testen? So wie wir das ja jetzt auch im Podcast besprochen haben, geht es ja um automatisierte Tests.
Auch, sprich wir hatten ja zum Beispiel in der Testpyramide erklärt, dass man relativ viel die Unittest hat, um einfach auf Unit Ebene seine eigene Software abtesten zu können und auch eine gewisse Zuversicht zu haben, dass die Software funktioniert, also eine Sicherheit dahinter. Wenn ich ein externes Testing denke, denke ich nicht daran, dass jemand mir unit test schreibt für meine Unit, die ich entwickelt.
Also nicht du. Ich möchte jetzt mal bitte das und das Feature implementieren, dafür habe ich unit a und b. Die Implementiere ich jetzt und du schreibst mir mal bitte noch Test dafür, das ist gar nicht das Erste woran ich dabei denke, sondern oftmals an. Externes manuelles Testing, also zum Beispiel auch die Gesamtsoffen.
Ja, im technischen Bereich auch Prüfstände, Hillsysteme was es da alles gibt, aber ich denke halt daran, dass jemand aktiv Arbeitszeit braucht um diese Tests manuell durchzuführen um so auch Fehler zu finden. Vielleicht Schwächen in der. Handhabbarkeit zu finden, was denn alles quasi so kommen kann. Aber ich bin nicht gedanklich da, dass jemand wirklich Tests automatisiert für mich. Wie siehst du das?
Also das ist halt genau. Also das ist ein interessanter Punkt, weil wenn also angenommen, also für mich wäre es tatsächlich ein also wenn ich jetzt mal mein worst case Szenario beschreiben würde, angenommen ich würde in einem Projekt arbeiten und jemand würde sagen okay du schreibst die Software. Und ein anderes Team testet die Software und dann würde ich auf jeden Fall mich hinstellen und sagen okay ich werde aber auf jeden Fall meine eigenen Tests
schreiben nach tdd, das ist ja auch so das, was wir ganz gerne praktizieren. Hat sich ja für uns auf jeden Fall aus unserer Erfahrung. Als bewährt erwiesen, oder wie sagt man, hat sich bewährt? Hat sich bewährt. Genau. Genau. Aber wenn dann zum Beispiel das externe Team sozusagen wirklich diese Tests manuell durchführen würde, dann hätte ich glaube ich ein großes Problem damit. Das wäre für mich eigentlich mein worst case Szenario, weil. Manuelles Testen ist halt
unglaublich langsam. Ne, also angenommen. Also ich mein jetzt auch nicht nur die Art und Weise, dass sozusagen die Leute, die das manuell testen langsam ist. Das dauert natürlich deutlich länger als es sozusagen automatisiert zu testen. Und sondern, es geht ja darum, dass du den Leuten die Zeit einräumen musst. Sozusagen diese Tests durchzuführen.
Dann gibt es ein Feedback zurück und du als Entwickler oder Entwicklerin denkst dir OK. Ich habe jetzt also das wäre ich, ich rede vom First case Szenario ne und wenn ich dann quasi sage OK das ist mein Stand, bitte testet diesen Stand und dann heißt es ja aber bitte jetzt keine Änderung so lange wie nicht dieser stand getestet ist und ein grünes Licht gegeben wurde, weil wenn dann nämlich quasi keine Ahnung eine Woche wird getestet, dann kommt das Ergebnis zurück hier sind
übrigens 2 Bugs drin. Und diese Bugs sage ich jetzt mal, muss man erst fixen und dann geht das Ganze noch mal in diese gleiche Testrunde, wo man wieder eine Woche verbraucht und dann kommt das Ergebnis zurück und dann heißt es okay ist alles gut, jetzt darf es weitermachen, das wäre für mich worst case, weil im Endeffekt würde ich mir sagen okay es ist okay also stell dir vor, du hast deine eigenen Tests und merkst also du würdest auf deine eigenen Tests verzichten und würdest es nur
einem externen Tester Team überlassen und würdest aber mit deinen eigenen Tests die gleichen Bugs eventuell sogar in weiß ich nicht Sekunden finden. Ja genau, das ist halt auch. Ein großer Unterschied beziehungsweise Nachteil. Auf manueller Testingseite, gerade wenn die Entwicklung noch sehr frisch ist, also wenn die Software sich noch dramatisch
ändern kann. Dramatisch klingt ein bisschen überzogen, aber wenn man wirklich, sage ich mal, noch in den ersten Versionen steckt und sich vieles ändern kann, dann ist manuelles Testing richtig anstrengend, weil du kannst einen Test, also es ist ja nicht gewährleistet, dass ein Test mehrfach gleich ausgeführt wird, klar, man kann sagen, jetzt klicke ich hier, jetzt klicke ich da, aber das setzt ja voraus, dass ein Mensch keinen Fehler macht, und da sitzt er
jetzt wieder, ein Mensch vor dem vor der Software, sage ich mal, und klickt zum Beispiel verschiedene Eingaben durch. Wie? Schön, der Fehler sitzt doch immer vorm Rechner. Ja genau, und dann ist ja nicht gewährleistet, dass wenn Tester a sage ich mal 10 mal dieses Feature testet, dass es immer gleich läuft und das ist gerade am Anfang. Wenn du sagst, geht es jetzt wie
du meintest. Ah okay nee, da stimmt was nicht und du codest weiter geht's jetzt naja warte ich werde es jetzt noch mal durchklicken okay und nee geht nicht gut und klack, klack, klack, klack, 5 Zeilen dazugeschrieben geht es jetzt, das ist ja also das müsste man sich mal vorstellen, wenn ich jetzt ein Unit Test habe und der ist rot, dann. In der Grünen zu kriegen, das heißt ich Code was und lass den
Test laufen. Nee, doch nicht, lass Code ah immer noch nicht und wenn jetzt jedes Mal aber dieser Test ne Person ist die quasi sich den Softwarestand ziehen muss, die das ausprobieren muss am besten noch n Protokoll schreiben muss das. So ne Art Review, das kommt nach oben drauf genau. Also da kommt wenn wirklich der Prozess greift, bei manchen Themen so. Dieser Overhead, der dann einfach entsteht, allein.
Durch die Kommunikation und Du hast ja gesagt, das ist sehr langsam, da gehe ich mit, aber ich würde auch sagen, das ist halt allgemein für ein Projekt sehr kostenintensiv ist manuelles testen und dann noch ein Punkt, den ich bei mir halt merke ist, selbst wenn ich keine Tests schreibe, selbst wenn ich einfach nur. Irgendwie einen kleinen Prototyp baue. Weißt du, du Code ist einfach nur so ein paar Funktionen, weil du irgendwas gerade brauchst.
Ein kleines Skripte oder so. Du also man kommt doch nie an den Punkt, dass man das nicht selbst dann manuell testet. Also du willst doch in dem Moment wissen, ob das funktioniert und dann steckst du Zeit rein, es manuell zu testen, dann steckt eine andere Person rein, das noch mal. Also Zeit rein um das quasi zu testen.
Ist doch irgendwie Käse, dann kann ich doch auch einfach Tests schreiben und hab ne Gewährleistung immer wenn ich die laufen lasse, dass ich zum gleichen Ergebnis komme, also nicht im gleichen Sinne von es ist immer grün, sondern es ist deterministisch, also wenn die Funktionalität noch so ist wie sie sein soll, dann ist der Test.
Grün. Das Ding ist zum Beispiel Ach so. Sorry, aber weißt du und dann spare ich ja hinten raus so viel mehr Zeit und viele Sachen können halt einfach mit relativ simplen Unittest abgetestet werden. Das heißt nicht alles. Also es gibt definitiv auch Punkte, da können wir auch
gleich noch mal drauf eingehen. Da, wo manuelles testen auf jeden Fall Sinn macht, aber so für alles sehe ich da halt kein Lied, ja. Also das was, also wir waren ja auch gerade bei Feedbackzyklen, wenn du deine eigenen Tests hast, die du selber ausführen kannst, die automatisiert sind, dann lässt du die laufen, kriegst in kürzester Zeit eine Rückmeldung darüber, ob du ob irgendwelche Tests rot sind, also ob irgendein Fehler entstanden ist bei der Implementierung. Und das sind Sekunden.
Wenn du jetzt aber zusätzlich noch genau diese Schleife gehen musst und sagen musst, bitte hier einmal testen, ne, an das Testerteam wird es abgegeben, das heißt du hast Kommunikation, das ganze wird initialisiert. Dann wird das alles getestet.
Dann kommt irgendwann das Ganze wieder zurück, muss vielleicht noch, wie du meintest dokumentiert werden, so, das heißt der die Feedbackschleife ist ja auf jeden Fall hundertprozentig, also langsamer, wenn du das sozusagen an von externen testen lässt, außer also. Im Verhältnis zu dem, wenn du selber einfach draufklickst ne.
Natürlich muss man Erfahrung sammeln, also im Test schreiben, ne das ist klar, davon gehen wir jetzt aus, dass sozusagen diese Erfahrung gesammelt wird, aber angenommen du hast n testerteam und die Frage ist, wie wird da getestet?
Ne angenommen du hast weiß nicht 5 verschiedene Seiten auf deiner Anwendung. Wir gehen jetzt dahin und sagen, teste mal bitte Seite 1 und da ist alles OK und dann wird was die Frage ist was passiert danach wird dann nur noch Seite 2 getestet oder wird quasi je größer deine Software wird desto länger brauchen quasi auch die Tests des Tests weißt du weil wie du immer wieder alles testen musst aus dieser aus dieser Richtung, das ist eben die Frage und wer kennt es nicht, dass man
vielleicht sagt Okay. Part 1 funktioniert. Ich mach jetzt was am Part 2 und dann gibt es auf einmal ne Wechselwirkung zwischen Part 1 und part 2, dass du vielleicht, wenn du nur Part 2 Testest auf einmal n Fehler wieder n Part 1 drin hast. Ne das das ist halt die Frage. Und deswegen? Muss man halt gucken.
Und natürlich, wenn ich jetzt zum Beispiel in so einer Situation wäre, ne. Und tatsächlich hatte ich diese Situation schon mal, dass wir quasi nach TTD gearbeitet haben und dann kam hieß es ja, aber es muss noch ein externes Testerteam kommen und die wollten tatsächlich die Software manuell testen und dann haben wir gesagt und ich finde, das ist zumindest eine gute Herangehensweise, zumindest eine mögliche Problemlösung, wir haben gesagt, wollen wir uns
bitte alle zusammensetzen, wir würden Euch gerne helfen, diese
Tests zu automatisieren damit. Nicht mehr manuell das testen müsst, sondern damit die Tests sozusagen automatisiert durchlaufen, was bedeutet, dass sozusagen die Software auf einer sehr, sehr hohen Ebene testest, also unabhängig von der Implementierung. Also quasi, ich sag mal über die UI oder was auch immer ne und dann testest du das auf dieser Ebene aber automatisiert, das heißt das Testerteam schreibt Tests automatisiert für diese Anwendung.
Und da haben wir sozusagen versucht, mit denen uns n bisschen auseinanderzusetzen und sozusagen Hilfe zur Selbsthilfe zu geben, dass sie weniger Arbeit haben und wir quasi n schnelleres Feedback bekommen, weil es ist ja immer noch besser, wenn du sagst, OK, du musst jetzt, du musst n externes Tester Team haben, so ist es jetzt gesetzt, so was macht man dann natürlich möglichst versuchen die Feedbackzyklus diesen Feedbackzyklus, diese Feedbackschleife möglichst
gering zu halten, und das geht am besten, wenn man dann sagt okay, dann hilft man denen, wenn es nicht vielleicht sogar sowieso schon so ist, dass automatisiert.
Durchlaufen auch auf Seiten des Testerteams ne und ja, hat am Ende leider nicht viel gebracht, weil am Ende haben wir da 22 meetings 34 Stunden mit denen gehalten und dann hieß es dann am Ende also es war gar kein Mehrwert dahinter, das war dann so hier rein, da raus, danke tschüss und wir machen es trotzdem so wie immer, war natürlich blöd. Und dann genau. Und dann wird halt die Gesamtentwicklung halt träge dadurch die Feedbackzüge, die du ja erwähnt hattest. Ich würde aber gerne.
Mal ein paar Punkte in den Raum werfen, die für externes Testen und vor allem für manuelles Testen stehen oder Pluspunkte sind, weil. Jetzt bin ich gespannt. Ich will ja jetzt hier nicht darauf einknüpfen und sagen, das brauchen wir nicht und du kannst alles automatisieren und es ist einfach nicht notwendig irgendwas manuell zu testen. Wie gesagt auf unteren Level und.
Sachen Testing kann ich sehr, sehr viel automatisieren und das ist einfach der schnellere Weg. Also kann man mich auch gerne vom Gegenteil überzeugen, aber das ist meine Meinung. So Punkt. Nein, so weit gehe ich. Mit. Und aber wenn es nachher quasi um die Gesamtsoftware geht, weil du meintest das zu automatisieren, versteh ich auch.
Dafür gibt es denn zum Beispiel Systemtests, wo ich einfach kontrolliere, klicke ich den Button, geb vorher diese Felder ein, dann ist der zum Beispiel aktiviert, ich kann mich einloggen, wenn ich nichts eingegeben habe, in den Feldern ist der Ausgegraut disabled, ich kann mich nicht einloggen, also so so Behaviours die so gängig sind sage ich mal ja, aber was ist also inwiefern könnten automatisierte Tests helfen?
Die ich selbst geschrieben habe, um die Usability zu verbessern oder allgemein das Gefühl dieser Software für den Anwender UIUX Themen, weil im Endeffekt codiere ich ja in den Test rein, was ich erwarte in dem Moment das. Aber nicht, dass das ne zum Beispiel ne supercoole Lösung ist. So quasi die Software zu designen und ich finde, dass wenn man jetzt externe Leute das noch mal testen lässt, so auch Stichwort Betatester, ich meine sowas gibt es bis heute noch auch für Spiele und alles.
Na, dass du dir wirklich mal so ein Feedback holst und so noch versuchst. Quasi Fehler zu finden oder Optimierungspotenzial, weil eingeschriebene Tests heißt ja auch nicht, dass man ne volle Testabdeckung hat. Also es ist ja trotzdem möglich, ganz kurz. Mal kurz einhaken und gedanklich versuchen, einen kleinen Cut zu ziehen, weil die Tests sozusagen über. Ich jetzt auf jeden Fall quasi gedanklich mich fokussiert hab, sind ja Tests, die wirklich die Richtigkeit der Software testen.
Ne so das ist sozusagen sind Softwaretests die die Qualität der Software sichern, ne. Und dann gibt es ja theoretisch noch, wie du sagst, OK, das ist auf jeden Fall ist ne Art von Test, ne ne Art von Testing gebe ich dir recht, gehört auch in in die Kategorie Tests rein, würde ich aber glaube ich in ne andere Kategorie von Tests packen. Das ist ja im Endeffekt ne, also. Zum Beispiel die Usability zu
testen. Ne würde ich zum Beispiel soweit gehen, dass man sagt, OK, da nimmt man sich zum Beispiel ne UX Designer oder ne UX Designerin und lagert diesen Prozess vor, dass man zum Beispiel sagt, der UX Designer oder die UX Designerin. Erstellten Feature in einem in einer Dummy Anwendung, die quasi im Endeffekt genauso sich verhält, also noch nicht hundertprozentig genauso aber das Verhalten. Widerspiegelt und man sagt, Guck mal hier, lieber User, liebe Userin, bitte guck, probier dich
mal aus, wie würdest du das finden, findest du diese Variante besser oder diese Variante und dann quasi kannst du im Vorfeld schon mit sogenannten Click Dummies die User Feedback einholen, im Optimalfall jetzt um zu sagen okay, wie würdest du das finden? So und daran kann man diese Art von User Research betreiben und das sozusagen immer am besten vorgelagert vor der eigentlichen eigentlichen Entwicklung, weil wenn du dann nämlich weißt als Designer oder Designerin Pass
auf. Weißt du, wenn die, wenn diese Rolle dann sozusagen ins Team geht und dem Entwicklerteam sagt, Leute so und so und so, User Research ist gemacht, so und so und so entwickeln, das wäre gut so, weißt du, das heißt, du weißt schon wie deine Software, also du hast getestet wie die wie die Benutzer am besten auf diese Software und Software Features reagieren und dann kannst du ja per Tdd, vielleicht auch per externes Testerteam sozusagen den Tests
aufsetzen um dann sozusagen eine Softwarequalität Abzu sichern, weißt du? Also ich würd das n bisschen auseinanderziehen. Ja, versteh ich, aber du hast es ja im Prinzip selbst gesagt, dann hast du im Vorfeld getestet, wie das ankommt bei den Usern, also ist es ja ne Art von extern testen und wahrscheinlich auch manuelles
klicken. Das stimmt Leuten, das stimmt, das ist ja genau der Punkt was ich meine, also da an den Stellen macht es schon Sinn etwas auszulagern und auch mal manuell testen zu lassen, weil alles was ich selbst schreibe und automatisiere entspricht ja meinen, also nicht meinen Anforderungen, natürlich hoffentlich den Anforderungen, aber auch meinem Verständnis von dieser Software wie sie auszusehen hat oder von einer Designerin im Team.
Keine Frage. Aber was ich meine ist, das ist halt für mich ein Punkt wo es Sinn macht das mal nach außen zu geben, definitiv ich. Wollte nur eine Grenze ziehen zwischen diesen 2 verschiedenen Testarten. Wie gesagt, das ist manuelles testen und das ist, es ist wichtig an der Stelle, da gebe ich dir total recht, wenn es um diese User Research Geschichte geht, ist es natürlich sehr wichtig, aber es sind ja trotzdem. Also du hast ja das auf der einen Seite.
Manuelle Tests, die wichtig sind, definitiv ja, sind aber keine Qualitätstests. Und diese Tests kann man ja, und darum geht es mir auch ein bisschen, dass man sagt, man möchte ja durch externes testen nicht die Entwicklungszeit
beeinträchtigen. Und wenn du sozusagen dieses manuelle Testen im Vorfeld sozusagen bevor das Feature überhaupt schon einfließt, schon abtestest ne, also quasi Usability mäßig abtestest, um es dann in die Entwicklung einfließen zu lassen, sodass du sozusagen mit der Entwicklung voranschreiten kannst, ohne behindert zu werden.
Das wäre doch gut. Blöd wäre natürlich, wenn es heißt, wir müssen jetzt ein neues Feature entwickeln okay die Entwickler dürfen nicht weiter arbeiten, solange nicht der Designer oder die Designerin sozusagen diese diese dieses User Research durchgeführt hat, das wäre blöd. Ja, da kommen wir eigentlich auch zum anderen Punkt, den ich dabei noch hätte, an welcher Stelle es denn Sinn macht, quasi
sowas nach außen zu geben. Also du hast ja jetzt gesagt, so research mäßig, bevor ich anfange zu entwickeln, sich schon mal so einen kleinen MVP basteln im Kopf oder vielleicht auf dem Papier, dass man sagt, ja, so und so könnte es aussehen und die Leute würden das cool finden, wenn man das so und so bedienen kann. Vielleicht ganz kurz sagen, was ein MVP ist. Nur damit, falls jemand sich denkt. Was war das jetzt?
Ja, OK, kann ich machen. Also in MVP steht im Prinzip für Minimal Value Product. Wenn ich mich jetzt nicht irre und ist im Prinzip die kleinstmöglichste Form oder abgeschwächte Form von dem Produkt was ich entwickeln möchte, also was quasi die Key Features beinhaltet um einfach mal zu sehen wie würde dieses Produkt sein.
Also ich hoffe, das war jetzt verständlich, also nicht mit viel Schnickschnack, nicht mit Features BC und D, die vielleicht irgendwann mal geplant werden, sondern wirklich das Kernelement dieser Anwendung, dass das. Alle Features, die vorhanden sein müssen, damit das Produkt eigentlich auch wirklich funktioniert. Genau also zum Beispiel. Ich möchte eine neue Notiz App machen, dann sollen auch bitte nur Notizen angelegt und
geschrieben werden können. Und nicht ich kann jetzt aber auch 5000 verschiedene Arten an Notizen laden, oder ich kann jetzt auf einmal Bilder importieren oder also weißt du und wenn ich sage, lass mal ne Notiz App schreiben, dann bitte MVP ist. Ich kann ne Notiz anlegen die
beschreiben. Zum Beispiel? Danke für die Erklärung, damit man damit man auch weiß, was nur die Welt. Gelingt hat ja genau, man ist ja manchmal so im Modus. Und da macht es natürlich Sinn, diesen Research Research. Schon zu betreiben und sich vielleicht das Mal nach außen zu geben. Aber an sich finde ich, was immer ein guter Zeitpunkt ist, ist halt Release näher. Also wenn ich wirklich ein Major Release beispielsweise veröffentliche.
Wo zum Beispiel das erste von der Software oder wo wirklich grobe Änderungen drin sind, dass man das dann noch mal ins Feld gibt, aber nicht zum Beispiel bei jedem Feature, was sich zwischen meinen oder innerhalb einer relevanten Release. Zykluses Entwickel wie du meintest, das wär ja wirklich der worst case, wenn ich sage du pass auf.
Ich hab hier unsere Funktionalität erweitert, wie es gewünscht war, jetzt teste bitte normale normal alle hunderte Leute mal blöd gesagt ihr müsst das jetzt noch mal testen. Ja, aber gut, das ist ja nur n Feld dazu gekommen. Ich kann jetzt noch irgendwo n Haken setzen, ihr müsst das alle testen, weißt du, das ist halt wär ich der Meinung, dass das nicht so geeignet wäre. Du kommst in diese Fabrik, 1000 Leute sitzen da und müssen diese Tests.
Ja genau, und Klick, klick, Klick, Klick, Klick. Aber ich finde das, was ich wirklich als gutes Beispiel dabei auch empfinde, was wahrscheinlich? Unsere Zuhörer auch ganz gut nachempfinden können, weil ich meine, das ist n softwareentwicklungspodcast.
Ich glaub, die meisten unserer Zuhörerinnen und Zuhörer haben vielleicht auch mal Spiele gespielt und da ist es ja so, wenn jetzt zum Beispiel so n großes Spiel veröffentlicht werden soll, dann gibt es ja. Meinetwegen eine Alpha Testphase, ne Beta Testphase, aber das ist ja relativ spät in der Entwicklung, die also das Entwicklerteam kommt ja nicht an und sagt sowas wie Pass auf. Wir haben jetzt hier unsere erste Figur, die kann sich im Kreis drehen.
Wie findet ihr das, sondern das wird ja auch intern laufen. Aber meinst du nicht, dass zum Beispiel sagen wir mal Teil 2 eines Spiels hat ja schon einen sehr hohen User Research Anteil in durch Teil 1 zum Beispiel dann. Gehen wir davon aus, dass eine komplett neue Spielereihe. Also es gibt kein Vorprodukt in dem Sinne. Aber also weißt du was ich meine, irgendwann kommst du an den Punkt, wo dich das wirklich interessiert, dass du das nach
außen gibst, das testen. Deiner Bubble bist und ich kenne das ja auch bei unseren eigenen Projekten, dass man irgendwann eine Vorstellung hat, wie diese Software auszusehen hat. Und man testet demnach das auch ab und ich bin halt gedanklich jetzt auch wirklich viel bei UI Testing, weil man einfach sagt, so sieht meine Oberfläche aus, wenn ich hier klicke, komme ich auf die Seite, das lässt sich ja wunderbar automatisch abtesten.
Keine Frage, super Sache, ja, aber wer sagt mir denn, dass es geil ist, das so zu machen? Und das sind für mich halt Punkte, wo es halt extern Sinn macht, da irgendwie auch quasi diese Feedbackzyklen zu akzeptieren. Natürlich dauert das. Keine Frage. Wie gesagt, ich gehe da mit und sage, das ist wichtig und im optimalen Fall erzeugst du keine Feedbackzyklen. Also du erzeugst keine Wartezeit. Weil. Jetzt nicht, dass ich Däumchen drehe in der Zeit kann ich ja andere Features entwickeln.
Ganz klar. Aber ich muss ja trotzdem auf ne auf n Response warten in dem. Sinne? Ja genau, aber. Ich bin nicht blockiert, das gut, das ist der absolute Worst case. Wenn ich blockiert bin und nicht weiß, was ich in der Zeit machen soll. Das ist halt für mich das Problem, wenn man an Qualitätstesten kommt, ein externes Testerteam quasi sich um die Qualitätssicherung der Software kümmert und dann sozusagen die Weiterentwicklung
geblockt wird. Bevor die Tests nicht grünes Licht geben, weißt du, das wäre für mich halt worst case und das ist ja quasi oftmals auch leider der Fall. Also zumindest gibt es sowas auch auf jeden Fall noch viel zu oft, dass quasi genau diese Qualität sichung die Entwicklung beeinträchtigt und das ist blöd und deswegen würde ich einfach nur gucken. Also wie gesagt, das was du sagst finde ich ist auf jeden Fall absolut valide und wichtig, also Usability, Test, User Research alles wichtig.
Und ich glaube einfach, dass man zumindest bei der Qualitätssicherung für diese Tests kann ich mir vorstellen, dass die viel näher an der tatsächlichen Entwicklung des Features stattfinden. Diese User Research und Usability Testing kann man aber theoretisch versuchen möglichst vorzulagern, so dass sozusagen eine Parallelität erzeugt wird, dass man halt quasi nicht in das Blockieren der Weiterentwicklung kommt, so das. Glaube ich ist guter. Punkt. Gut zu machen ist.
Ich auch nicht immer so, aber das wäre natürlich gut. Und wenn du aber zum Beispiel die Qualität versuchst zu sichern durch dieses externe Testerteam, dann ist es ja durchaus hilfreich zu sagen, lass uns dieses, diesen, diesen, diesen feedbackzyklus halt möglichst gering halten im Sinne von hier ist wieder ein Feature fertig, bitte einmal alle Tests laufen lassen, externes Testerteam und dann kommt quasi die Antwort in kürzester Zeit, also so kurz wie möglich einfach
wieder zurück. Yo, oder? No genau, und da sind wir quasi wieder am Anfang der Folge. Gemeinden, dass es ne positive Sache sein kann und auch Mehrwert liefern kann. Definitiv, aber halt nicht die eigenen Entwicklertests ersetzen. Kann ja nach unserem Verständnis. Also wir lassen uns auch gerne also auf ne Diskussion ein.
Ja, auf jeden Fall. Falls da jemand irgendwie ne andere Ansicht hat, dann meldet euch gerne, bei uns finden wir immer spannend über sowas zu diskutieren, aber ich denke, dass es so unser Stand der Dinge dazu, aber ich hätte noch eine abschließende Sache. Und zwar. Wie stehst du denn dazu, wenn wir jetzt wirklich Release nah sind und gewissen Prozessen unterliegen, hatten wir auch genannt und wir sagen jetzt, OK, wir müssen Release ziehen und jetzt geht das an ein externes Tester Team.
Weil der Prozess davon ausgeht oder verlangt, dass quasi eine unabhängige Person von der Entwicklung da drauf schaut.
Das ist ja so oft so n Kriterium, dass man sagt, OK, die gleiche Person darf nicht den finalen Test der Software machen, also nicht die Person, die die Software entwickelt hat, das heißt muss irgendwie ein unabhängiger sein, derjenige testet die Software, schreibt ein Review dazu und du kriegst einen Testbericht dazu, das dauert klar, deswegen haben wir gesagt, hoffentlich nur nahe eines Releases.
Aber glaubst du, dass der Prozess an der Stelle Recht behält und sagt also, dass man wirklich sagen kann, nein, das muss wirklich eine externe Person machen oder ein unabhängiges kann ja auch aus dem Nachbar Team jemand sein? Glaubst du, da kommt nicht mehr bei rum am Ende als deinen eigenen Test? Ja, es ist ist halt schwierig. Also im Endeffekt denke ich mir halt so, dass das Entwicklerteam an sich im Normalfall einfach die beste Übersicht über die
Software, die zu entwickeln ist. Deswegen. Bezweifle ich manchmal, ob da jetzt noch so ein wunderbarer neuer Input kommt. Aber man soll ja auch niemals nie sagen. Also ich bin halt im Endeffekt auch eigentlich gar nicht so ein Fender von, auch wenn es manchmal wichtig oder notwendig ist, sage ich jetzt mal, dass man wirklich immer bestimmte Releases raushaut, also zum Beispiel ein Release, alles also alle halbe Jahre ein Release.
Weil du quasi innerhalb eines halben Jahres so viel wieder über sozusagen die Sachen vergisst, die in einem Release stattfinden. Dass es jedes Mal, also man kennt es ja oft genug, dass dieser Releasetag immer totaler Stress ist. Und deswegen ist es halt am besten, wenn man so eine Art cicd Pipeline hat und so weiter dass du halt eigentlich quasi so eine Art Release jeden Tag machst oder jeden Tag übst, dass man im Endeffekt gar nicht mehr in Teufels Küche kommt, wenn es zum Release kommt.
Ich bin ein bisschen abgefressen. Von der Frage aber prinzipiell, glaube ich, kann ich mir einfach nicht vorstellen, dass es so unglaublich andere Insights dann am Ende gibt. Ja, also ich finde es auch schwierig. Ich kann nur den Punkt insofern verstehen, dass es ja gut möglich ist, dass man keine
vollständige Testabdeckung hat. Es ist auch ein bisschen vermessen, immer zu sagen, ja, ich habe an alle Fälle gedacht, die so auftreten können, weil das ist sehr, sehr schwierig und vielleicht ein erfahrener Tester, der die Software auch gut kennt, das ist nämlich ein wichtiger Punkt, was du meintest. Ein Tester muss sich auch gut in der Software auskennen, weil es bringt ja nichts, wenn.
Quasi die Software gestartet wird oder die Website aufgerufen wird, je nachdem welches Produkt und da wird rumgeklickt wird und dann das Review ist ja sieht gut aus, das bringt ja auch nichts, aber wenn du einen erfahrenen Test da hast, der die Software auch gut kennt, kann ich mir vorstellen, dass es dazu führen kann, dass vielleicht irgendwelche Hases gefunden werden, die übersehen wohnen und dann ist aber auch wiederum die Frage, welcher negativer Impact dadurch entsteht oder ob das so
ein seltener Fall ist und am Ende vielleicht nur ein Anzeigenbug. Steht oder so. Weißt du also die Frage, die ist ja auch wieder n anderes Thema, aber das kann ich mir halt vorstellen, dass vielleicht nicht bedachte Fälle noch auftauchen können durch n externen Tester. Die Frage, die ich mir an der Stelle stellen würde wäre, wieso ist dieser erfahrene Tester, der aber auch Software Entwicklungserfahrung im optimalen Fall bringt mitbringt, nicht Teil des Teams?
Weil ich find's halt auch ich find's halt auch vermessen zum Beispiel zu sagen so. Gibt jetzt noch mal einen, der
am Ende drauf guckt. Also es gibt quasi du entwickelst vielleicht ein Produkt über Jahre über oder über Monate oder nimm n bestimmten Zeitraum und da wird regelmäßig getestet, automatisiert Entwickler arbeiten daran, das wird vielleicht noch ein externes Testerteam damit betreut und jetzt will eine Person am Ende noch mal sagen okay das ist cool oder nicht, frage ich mich, wie gut kann man in einer kurzen Zeit etwas testen, was quasi über schon die gesamte Entwicklungszeit regelmäßig
getestet wurde und da hoffen wir und gehen davon aus, dass natürlich auch Tests dabei sind. Also das muss man sich auch überlegen. Auf der anderen Seite. Ja, also das ist natürlich dann aber auch einfach unternehmensstrukturabhängig. Es gibt halt Jobprofile, die heißen Softwaretester, und dann testest du Software. Es gibt Profile, wo du eher unterwegs bist.
Okay wir arbeiten zum Beispiel Test Driven und schreiben unsere Tests selbst als Entwickler. Das ist ja wirklich dann Projekt und Unternehmensstruktur abhängig, aber es gibt ja definitiv softwaretester, die wirklich Software.
Testen einfach und. Ja gut, das ist natürlich ne valide Frage, wenn er da super fit ist in der Software, warum er nicht mit dran codet gut kann ich auch verstehen, die Frage aber gehen wir einfach mal davon aus, er ist wirklich einfach ein Test da also und das nicht despektierlich im Sinne. Ja ok, jetzt hast du mich ein bisschen aus dem Konzept gebracht, aber ich denke, wir haben es ausführlich besprochen. Ich kann ja noch mal zusammenfassen.
Wir sind zu dem Schluss gekommen und da sind wir auch einer Meinung. Die Entwicklertests selbst sind nicht zu ersetzen durch externes Testing Check genau weil einfach unnötige Feedbackzyklen aufgemacht werden, die wirklich nicht notwendig sind, weil man sehr sehr viel schon auf eigener entwicklertest Ebene abdecken kann, beispielsweise Unit Tests, dann kommt noch dazu, dass die Test Pyramide hatten wir besprochen, Integration Test System Test kann auch ein
Entwickler selbst schreiben und damit noch viel viel mehr Updates. So, und dann sind wir an die zu der Frage gekommen, macht es überhaupt Sinn, externes oder manuelles Testen? Da haben wir so n bisschen
bequatscht. OK, gerade was so Richtung UIUX geht, also Usability, da ist es n spannendes Thema testen im Feld nenn ich es mal, dass du wirklich ein breites Feedback die einholst würde ich jetzt auch mal einfach zum Testen zählen, aber so rein auf funktionaler Ebene wie du es vorhin schon gesagt hast, kannst du halt viel automatisieren und selbst machen. Gehst du da so weit? Mit ja, auf jeden Fall. Also ich würde mir auf jeden Fall immer überlegen Sachen. Wir dauern.
Kann man die optimieren und wenn nicht beziehungsweise wenn ich das nicht machen kann, kann ich irgendwo helfen, dass es schneller geht. Das ist natürlich, dass es halt einfach sinnvoll, diese Überlegung anzustellen und nicht zu sagen, das ist jetzt so und so, sondern.
Und das können wir nicht, weil so und so, sondern am besten ist es ja zu sagen, das wäre theoretisch das Ziel, wie können wir das erreichen, sodass wir einfach sinnvoll und dann kann man sich überlegen, ob es Lösungsmöglichkeiten dafür gibt. Genau, und da bin ich auch ganz bei dir, weil. Es gibt halt auch gewisse Entwicklungsprozesse, die eingehalten werden müssen, je nachdem wo man arbeitet oder in
welchem Projekt man ist. Und dann ist es halt auch einfach Vorschrift, dass es externe Tester gibt und da bin ich ganz bei dir, ist es natürlich wichtig. Zusammenzuarbeiten, um da einfach die bestmögliche Performance rauszuholen. Ja. Wie sieht es aus? Schön. Gesagt haben wir gut, gut, ausführlich besprochen, würde ich sagen, ja. Es war ein schönes Gespräch. Dann, ich muss die Folge beenden. Okay liebe Zuhörerinnen und liebe Zuhörer, ich hoffe, dir
hat die Folge gefallen. Du konntest dich mit dem Thema vielleicht auch identifizieren, warst schon mal bei ähnlichen Problemen oder hast dich gefragt, macht es Sinn selbst die Software zu testen oder müssen das andere machen?
Genau mit diesem Thema wollten wir uns heute einfach mal beschäftigen und wir hoffen, dass dir die Folge gefallen hat, falls ja, lasst doch gerne ein Like, da folgt uns auch auf den anderen Plattformen die links findest du in den Shownotes und auch ganz besonders ab sofort, wir coden mehr. Auf Twitch live, wo wir auch im Prinzip nach TDD arbeiten, also das, was wir euch hier erklären, werden wir da auch live zeigen,
wie wir das machen würden. Das ganze wirklich an einfachen Aufgaben von Beginner Level bis zu fortgeschritten und. Einfach folgst und einfach Teil der coolen Community da bist. Und dann können wir auch gerne weiter über das Thema Testing sprechen. Oder wie siehst du das, Fabi? Ich sag nur. Oh yeah, Oh yeah. Und deswegen ansonsten hoffen wir, du schaltest zur nächsten Folge wieder ein. Bis dahin macht ihr noch einen schönen Tag, deine Cody Buddies. Gemeinsam besser. Was?