Günstigere Software durch weniger Tests?! // deutsch

[@haukekern5474]

Du sprichst mir aus der Seele und bringst es auf den Punkt. Habe 10 Jahre als Entwickler in meiner Firma gearbeitet und letzten Monat genau aus diesem Grund gekündigt, nachdem ich festgestellt habe, dass ich mich damit nicht arrangieren kann/will. Haben mehrere Projekte umgesetzt und immer wieder dieses Problem gehabt. Beim nächsten Projekt hieß es immer "diesmal machen wir es anders", es wurde aber nie konsequent durchgezogen. Das Resultat waren immer viele Überstunden, eine Software die schwer wartbar ist und alle Parteien waren unzufrieden.

[@gamerdachs]

Sehr gutes Video. Ich bin QA Engineer und kenne das aus alten Unternehmen leider nur zu gut. Aus Zeitdruck werden "kleine Änderungen im Backend" mal eben ohne QA durchgewunken, oder ich wurde gebeten doch nicht so genau hinzuschauen. Ich war damit nie so einverstanden, aber wenn es der PO oder so sagt, dann macht man es eben. Die große Überraschung (welche eigentlich ja keine ist), kommt dann beim Kunden, wo Fehler auffallen, der jeder Tester gefunden hätte. Es kommen also Bugfixes, welche mehr Zeit und somit auch Geld fressen, als wenn man einfach direkt alles getestet hat. Jetzt bin ich als einziger QA Engineer in einem kleinerem Entwickler-Team, und hier wird auf das Testen viel Wert gelegt, und mir auch die nötige Zeit eingeräumt und auch vor der Geschäftsführung vertreten. Das Ergebnis: wir schaffen es dennoch alles im zeitlichen Rahmen, aber deutlich entspannter, und mit einer guten Qualität und vor allem dem Wissen, dass wir gute Qualität liefern. Und wenn man das drei, vier Mal gemacht hat, ist der Kunde auch nicht böse wenn man sagt, dass man mal zwei Wochen länger braucht, immerhin weiß er, dass dann was gutes bei rum kommt.

[@IAmFeO2x]

Hervorragend auf den Punkt gebracht. Dieses Video sollte zum Pflichtvideo werden für alle Personen, die in Softwareprojekten arbeiten.

[@wanieldeiss]

Hey Golo, wieder einmal ein gutes Video und super erklärt! Ich kenne das Problem nur zu gut, wenn ein solches Projekt größer und älter wird... dass die Entwicklung neuer Features signifikant mehr Zeit in Anspruch nimmt und oft dieser Faktor mit unerfahreneren Entwickler ausgeglichen wird. Das bringt erstmal nur noch mehr Chaos rein und kostet umso mehr Zeit bei den Code Reviews und abnahmen der Pull Requests. Disclaimer: Als unerfahrene Entwickler will ich niemanden abwerten. Aber bei einem großen uralt Legacy Zombie, der keine Dokumentation hat und bei dem alle Ursprünglichen Entwickler abhanden gekommen sind... Zählt man eben auch als Spezialist mit 10+ Jahren Berufserfahrung als "unerfahren"

[@st0ox]

Ich bin bei meinen 5 Software-Jobs die ich in meinen Leben hatte noch nie eingearbeitet worden. Es wurde einfach immer erwartet, dass man sich nicht dokumentiertes firmeninternes Wissen innerhalb kürzester Zeit selber beibringt. Bei einer Firma gab es sogar den Insiderjoke der zwischen zwei Entwicklern immer so ablief: "Wie verwende ich nochmal deine Klasse XY?" "Guck doch einfach in den Unit Test, der ist quasi die Doku." "Aber die Klasse hat doch gar keinen Unit Test" "Wir haben generell keine Unit Tests" Und danach lachen beide wie Antagonisten aus einem Cartoon ^^

[@AlexSchiessl]

Ein wunderbares Video für meine "Ihr solltet Euch das mal ansehen" - Video Liste, die ich für Kunden und "Leadership" bereithalte, wenn Sie wieder mal mit BS und abstrusen Ideen über "agile" SW Entwicklung, Teambuilding, Testing, etc. daher kommen. Und btw. ja habe das in meinen 32 Jahren in der I.T. und in den letzten Jahren als Scrum Master und Agile Coach oft so erlebt. Danke für diese sehr gute und kompakte Zusammenfassung. Schade das Ihr nicht vor 20 Jahren schon am Markt gewesen seit, als ich noch Developer war. Da wäre sicherlich eine Bewerbung von mir bei Euch drin gewesen. In so einer aufgeklärten Firma will man doch gerne arbeiten. Anyway, hoffe mal Ihr lebt das bei Euren Projekten besser, auch wenn ich aus Erfahrung weiß, bei Kundenprojekten ist das sicherlich ein ewiger Kampf... Weiter so und Danke...

[@thenativeweb]

[gr] Vielen Dank 😊 Vor 20 Jahren war ich leider noch an der Uni … 😉

[@danielgrana7487]

Hallo Golo, ich kann an dieser Stelle zwar nicht von praktischen Erfahrungen mit Kunden sprechen, aber unabhängig von der relevanten IT-Erfahrung gehöre ich zum Peronenkreis, der Qualität vor Quantität stellt. Dabei kann ich mir lebhaft vorstellen, dass dieser Druck, einerseits will man Qualität bieten, abe auf der anderen Seite ist die Zeit der Gegener, sodass man letzten Endes gegen seine eigene Entwicklermoral agiert und sich mit weniger guter Software begnügt und unter dem Gesichtspunkt, dass man das auch noch weiß, sprich unter vollem Bewusstsein seiner Tätigkeit. Ich denke auf dauer könnte das einen Entwickler:in psychisch zerfressen oder mitnehmen, weshalb das Arbeitsklima sehr darunter leiden wird. An dieser Stelle sehe ich einen schleichenden Prozess.

[@thenativeweb]

[gr] Ja, das ist leider richtig - und hier kommt natürlich auch die Eigenverantwortung zum Tragen (das wurde ja auch in einem anderen Kommentar schon angemerkt): Es gehören immer zwei, dazu, einer der drängelt, und einer, der sich drängeln lässt. Entwicklerinnen und Entwickler müssten IMHO viel häufiger "nein" sagen, und Tests als nicht diskutabel deklarieren.

[@MrThommythommy]

Hallo Golo, Hier kann ich wirklich jeden Satz unterschreiben. Sehr gut auf den Punkt gebracht! Ich kenne solche Diskussionen. So etwas ist oft ein Kampf gegen Windmühlen, da die Gegenseite oft keinen Plan hat und daher aus Unsicherheit oft mit dieser Arroganz reagiert. Das ist für mich ein absolutes Warnsignal ! Hier ist oft nichts zu machen. Von daher: Sucht Euch gute Jobs, bei Firmen die wissen, was Ihr wert seid. Wo Eure Meinung und Erfahrung absolut respektiert wird.

[@thenativeweb]

[gr] "Von daher: Sucht Euch gute Jobs, bei Firmen die wissen, was Ihr wert seid. Wo Eure Meinung und Erfahrung absolut respektiert wird." - genau das 😊

[@zimsbert]

Golo, du hast so recht und ich kenne das Thema leider nur zu gut. Erwähnenswert ist auch, dass nicht nur die Qualität in Sachen Testen beeinträchtigt ist, sondern auch die Security der Software. Features, Features und noch mal Features zu pushen führt leider auch zu einer Qualitätsminderung in Sachen Security; auch wenn man sich dann ein oder zwei Sprints Zeit nimmt, sich dem Thema gnädigerweise zu widmen. Tests, Doku und Security sollten ein integraler Bestandteil der Softwareentwicklung sein m.E. und von Beginn an eingeplant werden! Zum Thema Security: Es genügt nicht, einen Virenscanner (end-point-security) und ein Firewallkonzept am Start zu haben als Firma. Die eingesetzte Software muss auch Security-Richtlinien entsprechen. Die teuerste Firewall kann z.B. nicht erkennen, welche WebSocket-Messages herumfleuchen im Netzwerk und welche Daten übertragen werden (weil man z.B. in der Software verabsäumt, dass man Subscribes von Websockets sichert). V.a. nicht, wenn man https (end-to-end security) einsetzt, und das sollte man ja bekanntlich.

[@thenativeweb]

[gr] Das mit der Security ist ein sehr guter Punkt - das ist ja ohnehin schon schwierig, das alles richtig zu machen, und wenn dann noch Zeitdruck hinzukommt beziehungsweise Sparen am falschen Ende, dann gute Nacht … Gute Anmerkung 😊

[@jamespeterson7979]

Das mag wohl daran liegen das für Zeit, Umfang und Kosten jeweils ein Eingabefeld in der Planungssoftware vorhanden ist. Und weil die da sind müssen auch alle drei ausgefüllt werden 🧐 .. denn man will sich ja nichts nachsagen lassen.

[@yt7042]

Vielen Dank für Video. Da triffst du wohl wieder auf einen wunden Punkt. Beitragen kann ich selbst zu dem Thema nicht viel, aber ich glaube es gibt Unternehmen die das mit Absicht vernachlässigen, da der Wechsel des Projekts zu einem anderem AN durch mangelnde Tests, Doku, ... so erschwert wird. Und man kann bei Ausschreibungen auch Dumping Preise machen. Es ist halt auch ein Unterschied ob es ein eigenes Projekt ist oder ein Auftragsprojekt ist. Mit deinen Erfahrungen und Wissen könntest du gut als "Vermittler" zwischen AG und AN auftreten und solche Probleme vermeiden helfen.

[@florianfeilmeier1017]

Absolut! Da spricht ganz klar jemand mit Erfahrung 👍

[@jensjensen2896]

Unterhaltsam wie immer.

[@DogzDeDoggy]

Evergreens aus dem Projektalltag: "Dokumentation machen wir hinterher", "Dieser Randfall kommt nie vor", "Testen machen wir manuell, die Software wird nur einmal / nicht lange benutzt", "Wir nehmen doppelt so viele Entwickler, dann geht es doppelt so schnell", "Kollege x ist da der einzige Spezialist, sein Wissen brauchen wir nicht teilen", "Den Prototyp / POC werfen wir dann weg" und am Ende in der Folge eigentlich immer "ja, das ist gewachsene Software", "warum ist der Aufwand so hoch? Ich wollte doch nur x?" .. der Kampf gegen diese Mythen ist gerade als Berater zeitraubend und nervig.

[@Massenhaft1]

Testabdeckung und E2E-Tests sind ein Wettbewerbsvorteil, weil so schneller released werden kann. Der Kundennutzen ist somit schneller beim Kunden. Ein Produkt von uns braucht fast 300PTs in der QA, das kostet Unsummen :).

[@perschinski]

Hallo Golo, das höre ich jetzt schon seehr lang. Ich glaube, der Entwicklung ist dies aus eigener Erfahrung schon längst klar. Aber es ist dennoch gut, es gebetsmühlenartig zu wiederholen, denn ich habe ein wenig die Vermutung, dass diese Erkenntnisse nach ca. 50 Jahren Software-Entwicklung doch laaangsam im Management ankommen. Umgekehrt weiß die Entwicklung, dass die perfekte vergoldete Lösung häufig keinen Mehrwert bringt. Ich sehe die Entwicklung daher inzwischen optimistisch :)

[@martinruegg9367]

Es ist nicht nur in der Softwareentwicklung so, auch in vielen anderen Bereichen, wird Fachwissen und Erfahrung zuwenig richtig eingeschätzt!! Man muss auch sagen, dass Wissen und Erfahrung nicht visibel sind! Sie sind immateriell! Und erst mit dem Einsatz davon sieht man die Ergebnisse!

[@dirkk.6828]

Hallo, tolles Video! ich hätte einen Vorschlag für ein neues Video, Thema "Software-Dokumentation"... Wäre echt Cool

[@thenativeweb]

[gr] Vielen Dank für das Lob und Dein Feedback 😊 Was genau stellst Du Dir darunter vor, beziehungsweise was würdest Du Dir wünschen? Prinzipiell haben wir zu dem Thema ja schon Videos gemacht, zum Beispiel: - Architektur-Entscheidungen dokumentieren: kzbin.info/www/bejne/eIWcnKJpi9yCqpo - Tipps für die technische Dokumentation: kzbin.info/www/bejne/eH-ldZ5_f913o5I Vielleicht hilft das ja auch schon 😊

[@dirkk.6828]

Mich würde interessieren wie Ihr Projekte dokumentiert. Cool wäre auch wenn ihr ein Projekt-Beispiel habt ….

[@nicolausriebl8026]

Ich kenne das nur zu gut, wenn auch in einem anderen Zusammenhang: Wenn man Projekt mit Krankenhaus und Entwickler*in mit Krankenpfleger*in ersetzt, erzählt das genau die Situation, in der ich mich selbst befand. Personalmangel, Überstunden und Einspringen wird erwartet. Da das ja so gut funktioniert, ist eine Entlastung nicht nötig. Leute gehen, es wird einfach irgendwer eingestellt, keine vernünftige Einarbeitung. Die Arbeit muss gemacht werden, egal wie. Der Laden ist mit hoher Geschwindigkeit dabei, an die Wand zu fahren und das Management hinter dem Steuer feiert sich für die erreichte Geschwindigkeit und erkennt das Problem nicht. Du hast in Kurzfassung erzählt, wie ich aus meinem Job als Krankenpfleger zu meinem Cyber Security Studium gekommen bin :)

[@zickzack987]

Ich kenne genügend Projekte und Produkte, bei denen genau diese Vorgehensweise mehr oder weniger wirtschaftlich erfolgreich praktiziert wird. Und es ist sehr wohl auch im Management bekannt, dass schlechte Qualität später negative Auswirkungen haben kann. Dies wird aber bewusst hingenommen. Am Ende reduziert es sich, gerade in großen Unternehmen, immer auf deine letzte Aussage: hinnehmen oder gehen.

[@morgadoapi4431]

Mir wurde gesage, Take it, change it, leave it. Bin "ge-leaved" mit Positiven Resultaten. Nach 2 wechsel verdiene ich jetzt das Doppelte und hab ein Team und Management gefunden wo Wert auf Qualität gelegt wird. Wohlgemerkt hab ich nur Erfahrungen mit Inhouseprodukten, bei Softwareschmieden ist das vermutlich anders.

[@NaderiosTNT]

Amen! 🙏🏻

[@cod3r1337]

Immerhin tröstlich, dass ich mit diesen Schmerzen nicht allein dastehe und viele andere täglich die gleiche Geschichte erleben

[@orange-vlcybpd2]

Die Tests erleichtern auch den Übergang des Projekts von einem Dienstleister zum anderen. Man kann natürlich alle solche Projektrisiken ausblenden und mit dem niedrigen Preis gehen. Dann nimmt man aber beim Eintritt eines beliebigen von den möglichen Projektrisiken direkt hohen Schaden. Es kann theoretisch aber auch Strategie sein, den Preis so tief zu drücken dass selbst drei gescheiterte günstige Projekte immer noch günstiger sind, als ein sorgfältig durchgeplantes. Solche Low Cost/High Risk Spiele sind aber eher untypisch. Weil die Nebenkosten eines Projekts doch spürbar sind, im Vergleich zu bswp. Börsespielen.

[@Baldur1975]

Das kenne ich leider nur zi gut. Am Ende bewirkte es, dass ich die Lust an einem Job komplett verlor. Man ist selbst unzufrieden mit dem was man macht. Der Druck wird immer mehr, trotzdem ist es nie genug. Wäre ich nicht gegangen, wär ich wohl in der klapse gelandet, da ich kurz vorm Burnout Stand. Bis heute habe ich nicht mehr als Entwickler gearbeitet und werde es auch wohl nie wieder tun. Diese zehn Jahre haben mich irgendwie kaputt gemacht. Mittlerweile existiert die Entwicklungsabteilung der Firma in der ich arbeitete nicht mehr.

[@morgadoapi4431]

Ich glaube als Entwickler hat man großen einfluss drauf ob hochwertige Produkte Entwickelt werden. Der Markt ist schon seit Jahrzehnten ein Arbeitnehmermarkt. Entwickler unterschätzen Stark ihren Wert in der freien Wirtschafft aber wenn wir wollten könnten wir wann immer wir wollen einfach wechseln. Würden wir dies Konsequenter durchziehen würden die Firmen sehr bald sich entweder ändern oder aussterben. Natürlich muss man vor dem gehen ganz klar auflisten wieso man geht and was die Firma verbessern müsste um zurück zu kommen.

[@oachkatzlschoas7941]

Könntest du das bitte mal in meiner Firma vortragen? Dem kleinen Programmierer wird ja nicht geglaubt. Netter Spruch den ich mal wo gelesen habe: "The bitterness of poor quality remains long after the sweetness of low price is forgotten"

[@thenativeweb]

[gr] Mache ich gerne - wobei ein weniger konfrontatives Vorgehen eventuell zielführender sein könnte 😉 Aber im Ernst: Wenn wir uns darüber einmal konkret(er) unterhalten sollen, melde Dich gerne jederzeit bei uns per E-Mail unter hello [at] thenativeweb [dot] io

[@legonz5047]

Amen!

[@christians6248]

Tests first. TDD. Wenn man sich darauf im Team verständigen kann hat man viele Diskussionen im Keim erstickt. Oder: Ohne Test kein PR, fertig. Muß man sich (nur noch 😀) dran halten...

[@thenativeweb]

[gr] Klar, die (eigene) Disziplin ist hier stets die größte Schwachstelle …

[@Massenhaft1]

Hoffentlich darf man das noch schreiben:): Kommt das Kind zu langsam auf die Welt, dann muss man nur neuen schwangere Frauen in einen Raum stellen und schon ist das "Kind" in einem Monat da! Gutes Video!

[@thenativeweb]

[gr] Das ist die Logik von Aufgaben aus den Mathebüchern: 20 Bauarbeiter brauchen 3 Tage, um ein Loch zu graben - wie lange brauchen 100 Bauarbeiter? So ungefähr …

[@X39]

Ich möchte hier mal eine unpopuläre Meinung einbringen: der beschriebene Fehler liegt nicht im Management, das Druck ausübt oder bei der sales Abteilung (ok.. Der initial Fehler, aber nicht die Folge) sondern bei genau den Entwicklern, die Tests skippen usw. Die erledigen hier nämlich ihren Job nicht ordentlich und zeigen nur aufs Management. Wenn das Management also sagt "wie können wir das noch erreichen" darf die Antwort eben nicht sein "naja, wir könnten tests streichen und bisl unsauber arbeiten" sondern "hoffen und beten" Software-Entwicklung ist ein Handwerk mit Denken.. Also quasi ein Denkwerk Wir haben Richtlinien und Wege, die unsere Arbeit zum Erfolg führen und man kann entweder pfuschen (und das auch genau so und nicht anders) kommunizieren oder ordentlich arbeiten Der Schreiner geht auch nicht hin und sägt jetzt die Hälfte ab und modelliert im Anschluss mit bauschaum, sondern der sagt halt "puh, wird schwierig. Könnte mehr arbeiten aber das wird halt teurer" und genau so ist es auch in der Software Industrie Dafür werden wir bezahlt, das ist unser Job. Nein zu sagen bei dummen Sachen. Um das Beispiel von Onkel Bob mal zu nennen: niemand würde dem Chirurg sagen, wie er schneiden soll und wenn, würde er eine entsprechende Antwort bekommen (aka: durch den Fuß komme ich aber nicht ans Herz)

[@thenativeweb]

[gr] Tatsächlich finde ich persönlich diese Sicht gar nicht so unpopulär, denn wie ich auch schon in einem anderen Kommentar geschrieben habe, gehören immer zwei dazu: Einer, der drängt, und einer, der sich drängen lässt. Insofern kann (muss?) man natürlich auch den Entwicklerinnen und Entwicklern, die nicht rechtzeitig "nein" sagen, einen Vorwurf machen. "Nein" sagen zu können ist extrem wichtig, siehe auch kzbin.info/www/bejne/qHurqGmNet14qs0 Aber: Es gibt natürlich auch immer einen Grund, warum das nicht passiert. Und der ist selten, dass den Entwickler:innen die Qualität egal wäre - sondern dass zum Beispiel die Angst im Raum steht, den eigenen Job dann zu verlieren, wenn man sich zu sehr querstellt. In einer idealen Welt würde man natürlich sagen "ist mir egal" und dann halt gehen, in der Praxis kommen dann aber so Sachen dazu wie "kann ich mir das gerade erlauben". Vielleicht gibt es in der Gegen nicht so viele Jobs, vielleicht hat man gerade erst gewechselt, vielleicht hat man eine hohe finanzielle Verantwortung in der Familie, was auch immer … Meiner Erfahrung nach liegen die Gründe in der Regel nicht bei den Entwickler:innen, die es sich zu einfach machen. Das greift zu kurz. Das ist also schon richtig, aber eher nur Symptom und nicht Ursache.

[@X39]

@@thenativeweb es mag stimmen dass Angst ein großer Faktor ist, allerdings ist es im Interesse eines teams dass die Qualität oben bleibt und wir, als Industrie, sind inzwischen zu relevant als das für mich persönlich solche ausflüchte, die in erster Linie den Weg des geringsten Widerstand darstellen, noch valide sind. Man stelle sich vor, der Arzt würde regelmäßig Patienten ablehnen, weil das Krankenhaus an diesen nicht genug verdient. Persönlich glaube ich, dass wir aus der Situation generell nur noch mit einer zentralen Institution ähnlich der Bswp. Ärztekammer wirklich raus kommen, sodass ein jeder Software-Entwickler einer moralischen Entität unterstellt ist, auf die er sich im Zweifel eben auch berufen kann. Am Ende sind wir halt alle nicht in die Branche gegangen, weil wir die Kommunikation und Konfrontation mit Menschen so mögen, sondern alle eigentlich diese täglichen puzzle lieben... Naja... Bevor das passiert, müsste irgend ein riesen Unglück geschehen, wodurch die Software Industrie vollständig durch und durch per Gesetz geregelt ist... Ich hoffe eigentlich nur, dass wir dem großen Unglück noch ausreichend zuvor kommen, um nicht in die irrelevanz reguliert zu werden

[@heinrichschiller4673]

Die Situation kenne ich leider nur zu gut, weil ich mehrmals in solchen Firmen arbeiten musste. Die Initiatoren eines Projektes sind schon lange weg, es gibt keine Dokumentation, teilweise nicht einmal eine Versionsverwaltung. Der Code ist schon lange weder wartbar noch lesbar und die verbliebenen Entwickler haben auch keinen durchblick mehr. Komischerweise bewirbt sich auch niemand mehr bei ihnen so wirklich und wenn es doch, dann wird seltsamerweise irgendwie gemeckert und nach dem Vorstellungsgespräch zeigt sich der Bewerber auch nie mehr wieder. Dann wird nämlich selbst ausgebildet. Fatalerweise hat das ganze Chaos aber seinen Grund, wird der Code doch von Menschen geschrieben, und aus neuen Entwicklern werden nicht unbedingt neue oder neue und gute Entwickler, wenn die alten Entwickler schon keinen guten Job machten. Das ist eine Spirale die unausweichlich nach unten führt. Ein Fehler ist es wenn man länger als nötig in einer solchen Firma bleibt. Wenn man nämlich die Probezeit nicht übersteht oder nach einem Jahr schon wieder aufhört, muss man das in nächsten Vorstellungsgespräch auch wieder verteidigen oder gut begründen müssen. Du darfst als Bewerber nämlich nicht sagen, das die vorherige Firma kacke war. Sondern sowas absondern wie, "Ich konnte im Unternehmen nicht weiter wachsen". Oder so. Also dann vielleicht doch, Zähne zusammenbeißen, schlecht verdienen und jeden Tag eine neue, aber eigentlich vermeidbare, Katastrophe lösen. Auch wenn es nicht paar Minuten, wie angenommen, gelöst werden kann, sondern in Tagen oder Wochen. Oder gar nicht :D

[@morgadoapi4431]

Mit dem Aktuellen Mitarbeitermarkt für Entwickler ist meine Erfahrung genau andersherum. Bei neuen Arbeitgebern sage ich so Objektiv wie möglich was im letzten Unternehmen falsch lief, welche verbesserungsvorschläge ich hatte, usw. Das neue Unternehmen ist daran Interessiert, dass du initiative zeigst und dass du deine Arbeit Ordentlich machen möchtest. Sie schätzen wenn du weiterlernen willst und man sieht dass du dir mühe gibst. Die Firmen die nicht sowas schätzen gibt es immer wieder, aber sie werden dir auch absagen solange du Ehrlich bleibst und das ist im Endeffekt besser für beide Parteien. Die einzige Situation wo du ein Kompromiss mit deinen Prinzipien eingehen solltest ist wenn du das Geld dringend nötig hast, deswegen legt man aber auch 6 Monate Nettogehalt beiseite und man bildet sich weiter damit man nie abhängig von einem Arbeitgeber ist.

fullack 👍

[@ZuvielDrama]

Ich finde die Testabdeckung ist vom Einsatzzweck der Software Abhängig. Geht es um Medizinprodukte, dann halte ich eine hohe Testabdeckung für absolut wichtig. Software für die Raumfahrt, Kernkraftwerke usw. Absolut notwendig! Bei wirtschaftlicher Software macht es keinen Sinn! Da machst du alles richtig, wenn du deine Kerngeschäftslogik abdeckst und nach SOLID entwickelst, sprich Tests aus der Notwendigkeit heraus nachholst, weil die Software eine hohe Kohäsion aufweist und die Erfahrung aus dem Produktlebenszyklus testwürdige Bereiche offen gelegt hat!. Alles andere ist für mich falscher Idealismus und weltfremd!

[@marcotroster8247]

Du hast die noch schlimmste Situation "Entwicklung fremd vergeben und jedes halbe Jahr das Entwicklungsbüro austauschen" vergessen. Es geht leider immer nochmal schlimmer, wenn Idioten am Werk sind 😅

[@bsdooby]

Oooo jaaaa.

[@al_x_mq]

Projektmanagern gefällt dieses Video nicht 😂

[@thenativeweb]

[gr] Haha 🤣

[@siriusmarz512]

Aus dem wahren Leben 😂