1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Softwareentwicklung: Wenn…

In Wahrheit wurscht, welche Methode man wählt...

  1. Thema

Neues Thema Ansicht wechseln


  1. In Wahrheit wurscht, welche Methode man wählt...

    Autor: FaultErrorFailure92 20.04.21 - 12:53

    ...wenn sich nicht alle im Team daran halten.

    Habe selbst des öfteren miterlebt, dass sowohl konservative Ansätze nach V-Modell oder neuere (agile) Methoden fehlgeschlagen sind, weil ein paar Leute im Team etwas anderes für besser hielten. Schlussendlich ist kein Ansatz perfekt, lediglich nur eine Näherung.

    Wichtig ist halt auch, dass man in jeder Projekt-Phase die entsprechenden Tests und Methoden durchführt... So kann man zB. schon vor der Erstellung jeglicher Requirements oder Use-Cases mal Ideen sammeln, welche potentiellen Ausfälle die Software/das Produkt/das System erzeugen kann und welcher Schaden dabei entsteht und auf Basis dessen bereits erste Tests verfassen.

  2. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Itchy 20.04.21 - 12:59

    Außerdem kann man praktisch jede Methode auch falsch bzw. unzureichend anwenden.
    Das Beispiel hier im Artikel zeigt das ganz gut. Leider gibt es genügend IT Manager, die glauben, wenn nur die Line und Branch Coverage der Tests hoch genug ist, dann auch das Produkt fehlerfrei sein muss.

  3. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Tintenpatrone 20.04.21 - 13:02

    In dem Projekt in dem ich gerade tätig bin, wurde die Methode "keine Tests" gewählt und daran hält sich jeder (leider)...



    1 mal bearbeitet, zuletzt am 20.04.21 13:02 durch Tintenpatrone.

  4. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: ibsi 20.04.21 - 13:10

    Das könnte ich mittlerweile gar nicht mehr

  5. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Dino13 20.04.21 - 13:28

    Tintenpatrone schrieb:
    --------------------------------------------------------------------------------
    > In dem Projekt in dem ich gerade tätig bin, wurde die Methode "keine Tests"
    > gewählt und daran hält sich jeder (leider)...

    Wir haben da eine etwas bessere "Taktik" gewählt, jeder schreibt Tests wie er will und wenn jemand den Test kaputt macht muss man sich selbst kümmern, dass er geht.
    Es gibt also eine sehr große Motivation Tests zu schreiben.

  6. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: mnementh 20.04.21 - 13:55

    FaultErrorFailure92 schrieb:
    --------------------------------------------------------------------------------
    > ...wenn sich nicht alle im Team daran halten.
    >
    > Habe selbst des öfteren miterlebt, dass sowohl konservative Ansätze nach
    > V-Modell oder neuere (agile) Methoden fehlgeschlagen sind, weil ein paar
    > Leute im Team etwas anderes für besser hielten. Schlussendlich ist kein
    > Ansatz perfekt, lediglich nur eine Näherung.
    >
    Das ist wohl wahr. Also gute Softwareentwicklung setzt auf Methoden, bei denen im Team auch Akzeptanz und mehr als oberflächliche Befolgung tatsächlich stattfinden. Deshalb bin ich kein Fan von diesen Metriken wie Testabdeckung, außer man macht die für sich selbst. Aber wenn ein Manager fordert "90%" Testabdeckung, dann schreibt jeder Pro-Forma Tests.

  7. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Eheran 20.04.21 - 14:00

    >jeder schreibt Tests wie er will und wenn jemand den Test kaputt macht muss man sich selbst kümmern, dass er geht.
    >Es gibt also eine sehr große Motivation Tests zu schreiben.

    Die Schlussfolgerung erschließt sich mir anhand der Aussage nicht. Schreibt man keinen oder nur einen sehr einfachen/oberflächlichen (und damit robusten) Test, dann muss man sich auch nicht kümmern, dass er wieder geht?
    Bemüht man sich um einen unfangreichen Test hat man dann nochmal Arbeit, wenn was ist.

    Wobei mir ich nicht ganz sicher bin, ob "sich selbst" den Test-Schreiber oder den Testenden meint. Würde aber an meiner Aussage nichts ändern, gespart hätte der Test-Schreiben auch dann, nur der zusätzliche Mehraufwand wäre dann woanders.

  8. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: dontcare 20.04.21 - 14:10

    Meisten Kunden wollen eh nur minimal Tests haben.
    Wer hat den schon Lust für Tests genau so viel zu Zahlen wie für die Implementierung selbst ?
    Dann gibts halt paar Bugs die reported werden und nachträglich gefixed \o/

  9. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: FaultErrorFailure92 20.04.21 - 15:04

    Kommt halt auch wieder schwer auf die Branche an.
    Ich kann immer nur von meiner Erfahrung sprechen - da ist der Test und die Spezifikation oft wichtiger als die Implementierung. Nur Zeit wird halt nie einberechnet und das Know-How ist auch oft sehr knapp bemessen. Und dann beginnt man halt zu sparen, obwohl auch die Norm klare Vorgaben machen würde...

  10. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: FaultErrorFailure92 20.04.21 - 15:22

    die Testabdeckung wird wiederum auch oft von der Norm gefordert. Und ich sehe das eigentlich auch als etwas positives, aber man muss es auf richtiger Ebene machen. Auf Systemebene Testabdeckung zu erreichen wird oft nicht ganz funktionieren - auf Modul/Komponentenebene wohl eher.

  11. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Dino13 20.04.21 - 15:37

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > >jeder schreibt Tests wie er will und wenn jemand den Test kaputt macht
    > muss man sich selbst kümmern, dass er geht.
    > >Es gibt also eine sehr große Motivation Tests zu schreiben.
    >
    > Die Schlussfolgerung erschließt sich mir anhand der Aussage nicht. Schreibt
    > man keinen oder nur einen sehr einfachen/oberflächlichen (und damit
    > robusten) Test, dann muss man sich auch nicht kümmern, dass er wieder geht?
    >
    > Bemüht man sich um einen unfangreichen Test hat man dann nochmal Arbeit,
    > wenn was ist.
    >
    > Wobei mir ich nicht ganz sicher bin, ob "sich selbst" den Test-Schreiber
    > oder den Testenden meint. Würde aber an meiner Aussage nichts ändern,
    > gespart hätte der Test-Schreiben auch dann, nur der zusätzliche Mehraufwand
    > wäre dann woanders.

    Na ja, kannst dir ja vorstellen wie es mit den Tests ist.
    Derjenige der den Test schreibt, ist auch zuständig, dass er läuft, d.h. die Tests müssen echt robust sein, wenn du sie dann schon schreibst.

  12. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Trockenobst 20.04.21 - 15:38

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Testabdeckung, außer man macht die für sich selbst. Aber wenn ein Manager
    > fordert "90%" Testabdeckung, dann schreibt jeder Pro-Forma Tests.

    Sehr großes Projekt. Nach einiger Zeit waren es 1000sende von rein technischen Tests. Diese haben wir durch einen Generator massiv automatisiert. Das war auch durch die schiere manuelle Arbeit nicht mehr zu rechtfertigen.

    Die meistens "Bugs" kamen nicht von technischen, sondern fachlichen Fehlern. Wir haben dann die Fachlichkeit aus 100enden von Stories so nicht mehr abbilden können. Es gab dann ein spezielles Tool, das die Fachabteilungen und Tester bespielen konnten. Dort war die Wahrheit für jeden Usecase abgebildet und daraus leiteten wir die Regeln ab. Fehler gabs eigentlich nur noch im Codegenerator oder wenn das Tool komplexe Situationen nicht visuell abbilden konnte.

    Das war so ein Gamechanger das ich aktuell bei einem grüne Wiese Prototypen auch massiv mit Codegeneration arbeite. Am Ende hat man 80% dumme Formulare, Listen und Knöpfe, die man aus einer handvoll jsons generiert.

  13. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Dino13 20.04.21 - 15:45

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Testabdeckung, außer man macht die für sich selbst. Aber wenn ein
    > Manager
    > > fordert "90%" Testabdeckung, dann schreibt jeder Pro-Forma Tests.
    >
    > Sehr großes Projekt. Nach einiger Zeit waren es 1000sende von rein
    > technischen Tests. Diese haben wir durch einen Generator massiv
    > automatisiert. Das war auch durch die schiere manuelle Arbeit nicht mehr zu
    > rechtfertigen.
    >
    > Die meistens "Bugs" kamen nicht von technischen, sondern fachlichen
    > Fehlern. Wir haben dann die Fachlichkeit aus 100enden von Stories so nicht
    > mehr abbilden können. Es gab dann ein spezielles Tool, das die
    > Fachabteilungen und Tester bespielen konnten. Dort war die Wahrheit für
    > jeden Usecase abgebildet und daraus leiteten wir die Regeln ab. Fehler gabs
    > eigentlich nur noch im Codegenerator oder wenn das Tool komplexe
    > Situationen nicht visuell abbilden konnte.
    >
    > Das war so ein Gamechanger das ich aktuell bei einem grüne Wiese Prototypen
    > auch massiv mit Codegeneration arbeite. Am Ende hat man 80% dumme
    > Formulare, Listen und Knöpfe, die man aus einer handvoll jsons generiert.

    Welches Tool verwendest du denn für die Codegeneration?

  14. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Trockenobst 20.04.21 - 15:54

    FaultErrorFailure92 schrieb:
    --------------------------------------------------------------------------------
    > beginnt man halt zu sparen, obwohl auch die Norm klare Vorgaben machen
    > würde...

    Das Problem der Zeit ist doch meistens, dass die Komplexität einiger Module irgendwann exponentiell steigt und die Meetings, Stories immer kranker und länger werden. Die verschwindet nicht, die Zeit. Dann gibt es falsche Entscheidungen, falsche Tools, falsche Umsetzungsanweisungen und schon geht noch mehr Zeit raus.

    Einfaches Beispiel: ein manueller Tester braucht eine Woche für den finalen Test.
    Nach zwei Jahren braucht er plötzlich 4 Wochen also wird ein zweiter Tester hinzugefügt.
    Die nerven aber die ganzen Simplen Klickereien und dann wird spontan beschlossen die einfachen Tests zu automatisieren. Das dauert einen Mannmonat eines Profis. Für das Geld hätte man hungernde Studenten hinsetzen können die monatelang die Releases durchklicken, während sie Spotify hören. Stattdessen drehen wir anderen Überstunden.

    Diese Entscheidungsprobleme sind inzwischen in meinen Projekten 60% der Grund warum Zeit nach hinten weg läuft. 20% sind Softwaredesign und falsche Tools, 20% irgendein Quatsch.

  15. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Sybok 20.04.21 - 15:59

    Dino13 schrieb:
    --------------------------------------------------------------------------------
    > Eheran schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > >jeder schreibt Tests wie er will und wenn jemand den Test kaputt macht
    > > muss man sich selbst kümmern, dass er geht.
    > > >Es gibt also eine sehr große Motivation Tests zu schreiben.
    > >
    > > Die Schlussfolgerung erschließt sich mir anhand der Aussage nicht.
    > Schreibt
    > > man keinen oder nur einen sehr einfachen/oberflächlichen (und damit
    > > robusten) Test, dann muss man sich auch nicht kümmern, dass er wieder
    > geht?
    > >
    > > Bemüht man sich um einen unfangreichen Test hat man dann nochmal Arbeit,
    > > wenn was ist.
    > >
    > > Wobei mir ich nicht ganz sicher bin, ob "sich selbst" den Test-Schreiber
    > > oder den Testenden meint. Würde aber an meiner Aussage nichts ändern,
    > > gespart hätte der Test-Schreiben auch dann, nur der zusätzliche
    > Mehraufwand
    > > wäre dann woanders.
    >
    > Na ja, kannst dir ja vorstellen wie es mit den Tests ist.
    > Derjenige der den Test schreibt, ist auch zuständig, dass er läuft, d.h.
    > die Tests müssen echt robust sein, wenn du sie dann schon schreibst.

    So zum Beispiel?

    try:
    do_something()
    except:
    pass

    return 0

    ^Also diese Methode ist auf jeden Fall unschlagbar robust!

    Ach und bevor Du jetzt zu laut lachst: Ich habe solche Tests in meiner Laufbahn schon mehrfach gesehen, und jedes Mal in die Tischkante gebissen.



    1 mal bearbeitet, zuletzt am 20.04.21 16:06 durch Sybok.

  16. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Trockenobst 20.04.21 - 16:05

    Dino13 schrieb:
    --------------------------------------------------------------------------------
    > Welches Tool verwendest du denn für die Codegeneration?

    Damit machen wir aber nur noch die Grundgerüste
    http://www.eclipse.org/xtend/documentation/index.html

    Für die regulären Fälle haben wir früh Poet benutzt:
    https://github.com/square/javapoet
    Gibt es auch für Kotlin von Square
    https://square.github.io/kotlinpoet/

    Für die komplexeren Logiken Papyrus
    https://www.eclipse.org/papyrus/
    Die UML .xmi/xml Dateien haben wir direkt geparst, das war etwas Arbeit ja

  17. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Dino13 20.04.21 - 16:09

    Sybok schrieb:
    --------------------------------------------------------------------------------
    > So zum Beispiel?
    >
    > try:
    > do_something()
    > except:
    > pass
    >
    > return 0
    >
    > ^Also diese Methode ist auf jeden Fall unschlagbar robust!

    Bei meinem alten Arbeitgeber musste ich ein Projekt übernehmen, welches zwar fertig war aber noch nicht im Einsatz. Ich musste dann feststellen, dass der Typ der größte Blender weit und breit war/ist. Nichts hatte funktioniert und ich musste die nächsten 3 Monate mit Bugfixing/Neuschreiben verbringen. Das Beste waren seine Tests:
    90% waren assertTrue(true);
    Robuster geht es nun wirklich nicht.

  18. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Sybok 20.04.21 - 16:42

    Dino13 schrieb:
    --------------------------------------------------------------------------------
    > Sybok schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > So zum Beispiel?
    > >
    > > try:
    > > do_something()
    > > except:
    > > pass
    > >
    > > return 0
    > >
    > > ^Also diese Methode ist auf jeden Fall unschlagbar robust!
    >
    > Bei meinem alten Arbeitgeber musste ich ein Projekt übernehmen, welches
    > zwar fertig war aber noch nicht im Einsatz. Ich musste dann feststellen,
    > dass der Typ der größte Blender weit und breit war/ist. Nichts hatte
    > funktioniert und ich musste die nächsten 3 Monate mit
    > Bugfixing/Neuschreiben verbringen. Das Beste waren seine Tests:
    > 90% waren assertTrue(true);
    > Robuster geht es nun wirklich nicht.

    :-D Ja, genau das Schema. (Ob nun Assertions verwendet wurden oder nicht, ist ja für die Nützlichkeit in dem Fall erst mal unerheblich.)

  19. Re: In Wahrheit wurscht, welche Methode man wählt...

    Autor: Steffo 20.04.21 - 22:46

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Einfaches Beispiel: ein manueller Tester braucht eine Woche für den finalen
    > Test.
    > Nach zwei Jahren braucht er plötzlich 4 Wochen also wird ein zweiter Tester
    > hinzugefügt.
    > Die nerven aber die ganzen Simplen Klickereien und dann wird spontan
    > beschlossen die einfachen Tests zu automatisieren. Das dauert einen
    > Mannmonat eines Profis. Für das Geld hätte man hungernde Studenten
    > hinsetzen können die monatelang die Releases durchklicken, während sie
    > Spotify hören. Stattdessen drehen wir anderen Überstunden.

    Klar und kurz vor Release soll dann alles nochmal durchgetestet werden, um dann herauszufinden, dass da viele gravierende Bugs sind. Tester und Entwickler sind total angespannt und gestresst...
    Alles schon erlebt. Alles Mist.
    Schreib einfach von Anfang an Tests und Fehler fallen schneller auf. Wenn ein Tester ein Fehler findet, schreibe einen Unit- oder Integrations-Test, um das nachzuvollziehen.
    Ein Test-Case, der vom Tester definiert ist, sollte am Besten automatisch ablaufen. Der Tester klickt auf Test Case X, dieser läuft automatisch ab und der Tester setzt ein Häkchen. Hier und da testet er manuell.
    Das alles spart für alle Nerven und nebenbei auch Zeit und Geld.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Beratung & Support für Baustellen und Konzernstandorte (m/w/d)
    STRABAG BRVZ GMBH & CO.KG, Berlin
  2. Mitarbeiter Arbeitszeitmanagement / Projektleitung (w/m/d)
    Medizinische Einrichtungen des Bezirks Oberpfalz - medbo KU, Regensburg, Parsberg, Wöllershof
  3. Senior Developer R&D Applications (f/md)
    Beiersdorf AG, Hamburg
  4. Senior IT Systems Engineer Backup (w/m/d)
    noris network AG, Nürnberg, München, Aschheim, Berlin (Home-Office)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 2,99€
  2. 5,99€
  3. 379€ (Vergleichspreis 415,38€)
  4. 149€ (Bestpreis mit MediaMarkt & Saturn. Vergleichspreis 219,19€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dragonbox-Pyra-Macher im Interview: Die Linux-Spielekonsole aus Deutschland
Dragonbox-Pyra-Macher im Interview
Die Linux-Spielekonsole aus Deutschland

Mit viel Verspätung ist die Dragonbox Pyra erschienen. Entwickler Michael Mrozek musste ganz schön kämpfen, damit es überhaupt dazu kam. Wir haben ihn in Ingolstadt zum Gespräch getroffen.
Ein Interview von Martin Wolf


    Förderung von E-Autos und Hybriden: Wie viel Geld bekomme ich für den Kauf eines Elektroautos?
    Förderung von E-Autos und Hybriden
    Wie viel Geld bekomme ich für den Kauf eines Elektroautos?

    Ein E-Auto ist in der Anschaffung teurer als ein konventionelles. Käufer können aber Zuschüsse bekommen. Wir beantworten zehn wichtige Fragen dazu.
    Von Werner Pluta

    1. Elektromobilität Rennserie E1 zeigt elektrisches Schnellboot
    2. Elektromobilität Green-Vision gibt Akkus aus Elektroautos neuen Zweck
    3. Elektromobilität Italien testet induktive Ladetechnik unterm Straßenbelag

    Army of the Dead: Tote Pixel schocken Zuschauer mehr als blutrünstige Zombies
    Army of the Dead
    Tote Pixel schocken Zuschauer mehr als blutrünstige Zombies

    Army of the Dead bei Netflix zeigt Zombies und Gewalt. Viele Zuschauer erschrecken jedoch viel mehr wegen toter Pixel auf ihrem Fernseher.
    Ein Bericht von Daniel Pook

    1. Merchandise Netflix eröffnet Fanklamotten-Onlineshop
    2. eBPF Netflix verfolgt TCP-Fluss fast in Echtzeit
    3. Urteil rechtskräftig Netflix darf Preise nicht beliebig erhöhen