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?