Latest / Coding Buddies | Tech & Dev-Mindset / Automatisierung vs. Manuell - Die innere Testbalance

Transcript

Automatisierung vs. Manuell - Die innere Testbalance · Coding Buddies | Tech & Dev-Mindset

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