Diskussion:Programmfehler
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.Fehler in der Einleitung / zu Fehlverhalten
BearbeitenIn der Einleitung wird im ersten Satz von "Fehlverhalten" eines Computerprogramms gesprochen. Wird dieses Fehlverhalten entsprechend bestraft? Ist die Einleitung hier nicht sachlich völlig daneben? Brauchen wir "bildhafte" Sprache für eine klare Definition wie im 3. Satz? --2001:A62:1A86:2101:7D2B:AD57:1EE9:B918 14:00, 26. Jun. 2021 (CEST)
- Mit 'Fehlverhalten' soll wohl ausgedrückt werden, dass das Programm durch sein TUN (= sein 'Verhalten') zu einem ~unerwünschten Ergebnis führt. Demnach wäre also ein 'Fehler' in einer Kommentarzeile des Programmcodes kein Programmfehler - ja, das könnte man auch anzweifeln. Was wäre Dein Vorschlag? --VÖRBY (Diskussion) 15:24, 26. Jun. 2021 (CEST)
- Besser wärs natürlich es auf "unerwünschtes" oder "nicht den Anforderungen entsprechendes" Verhalten zu ändern. --Sebastian.Dietrich ✉ 12:02, 27. Jun. 2021 (CEST)
- Zahlreiche andere Quellen verwenden 'Fehlverhalten' auch, zB. auch Bitkom [1]. Insofern würde ich das erstmal nicht ersetzen. --VÖRBY (Diskussion) 09:42, 28. Jun. 2021 (CEST)
- Ein Programm verhält sich nicht falsch oder 'fehl'. Es verhält sich genau so, wie es geschrieben wurde. Immer.
- Die Anforderungen sind dann nochmal eine ganz andere Sache, die interessieren das Programm auch überhaupt nicht. Das Programm liest sie sich nichtmal durch.
- Insofern ganz klar PRO einer formal und sachlich-korrekten Definition. Fehler machen immer nur Menschen. Das muss besser dargestellt werden. --98.158.248.22 12:59, 30. Jun. 2021 (CEST)
- POV. Das hängt davon ab, wie man die Begriffe 'Fehler', 'Fehlverhalten', 'fehlerhaftes Programm' definiert.
- Abhängig davon kann oder kann-nicht ein Programm sich 'fehlerhaft verhalten'.
- Bzgl. des Begriffs "Fehlverhalten" wurde eine Quelle genannt.
- --arilou (Diskussion) 12:05, 1. Jul. 2021 (CEST)
Ein Programm kann hinsichtlich seiner Qualität (inkl. Fehler) nicht losgelöst von den Anforderungen betrachtet werden. Wurde es falsch 'geschrieben', egal warum, so liegt eben ein Programmfehler vor - und damit bei Ausführung im Ergebnis (siehe 'Fehlerwirkung') ein Fehlverhalten. Gilt damit als ERLEDIGT. --VÖRBY (Diskussion) 09:53, 8. Jul. 2021 (CEST); kl. Korr: --VÖRBY (Diskussion) 12:16, 9. Jul. 2021 (CEST)
- NICHT erledigt. Wie Benutzer @Sebastian.Dietrich: als auch @VÖRBY: als auch die IP oben anmerken, liest sich der erste Satz der Einleitung ganz anders, und schiebt eine "Schuld" (Fehlverhalten = POV) auf eine Sache. Gerade Laien und Omas werden dabei in die Irre geführt, obwohl die Problemtik - uns allen bewusst - komplex ist. Würdet ihr auch schreiben: "Der Stein verhielt sich falsch."? Vielleicht war's ja auch die schludrige QA, die sich falsch verhielt? Das ist POV und Ermessenssache, wie auch @Arilou: darstellt, und die Disk dazu sollten wir gerade in einem einführenden Satz vermeiden. Tatsächlich wäre sie einen eigenen Abschnitt wert. Konkreter Vorschlag:
- "Ein Programmfehler (...) bezeichnet bei Computerprogrammen im Allgemeinen eine unerwartete Abweichung."
- Der Rest passt eigentlich. --199.247.39.63 15:18, 9. Jul. 2021 (CEST)
- POV ist auf jeden Fall, dass "immer nur Menschen Fehler machen können". Was wäre dann ein > Systemverhalten - mit den dort beschriebenen Ereignissen und Zustandsveränderungen (bei Programm = System also die 'Fehlerwirkung' - richtig oder falsch). Ein Stein ist in diesem Sinn kein 'System'; doch selbst hier gilt: je nach Belastung kann er brechen - evtl. im Gegensatz zum erwarteten Verhalten: Ein 'Fehlverhalten' (anders als gefordert/erwartet) liegt vor. --VÖRBY (Diskussion) 16:45, 9. Jul. 2021 (CEST); ergänzt: --VÖRBY (Diskussion) 17:19, 9. Jul. 2021 (CEST)
- Nachtrag: Der vorstehende Disk-Beitrag befasst sich lediglich mit der Aussage "nur Menschen können Fehler machen", Dinge .. könnten sich demnach nicht "falsch verhalten". Auch ist die Schuldfrage ein vom Verhalten des Programms unabhängiger Aspekt (siehe 'Fehlhandlung > Fehlerzustand > Fehlerwirkung').--VÖRBY (Diskussion) 13:31, 10. Jul. 2021 (CEST)
- Wir sprechen aber hier nicht vom Systemverhalten, sondern vom "Programm"fehler. Das Programm macht einen Fehler gegenüber der Spezifikation. Es gibt darüber hinaus noch viele weitere Arten von Fehlern rund um Software: Spezifikationsfehler ("die Schnittstelle meint hier sicher Zentimeter" - oje, jetzt ist die Rakete abgestürzt) oder auch technische Fehler ("verwenden wir doch die alte Version des Frameworks" - oje ReCaptcha funkt damit ab heute nicht). In beiden Fällen zeigt das Programm ein Fehlverhalten, aber es handelt sich nicht um einen Programmfehler.
- Die Quelle passt hier nicht, da sie nicht "Programmfehler" sondern "Fehler" definiert: "Fehler (engl. “Defect” oder “Deficiency”) ist nicht explizit definiert; es wird aber zwischen technischem Fehlverhalten von Hardware, Software, Dokumentation, Auslieferung, Service, Rechnungsstellung etc. und zwischen Handhabungsproblemen (engl. „Procedural Error“) unterschieden, die z. B. aus inkorrekten Systemeingaben, fehlerhaften Installationsschritten, Nichtbefolgen der Arbeitsweise entspr. der Benutzerdokumentation usw." --Sebastian.Dietrich ✉ 19:01, 9. Jul. 2021 (CEST)
- Die ISTQB meint dazu [2] Fehlerwirkung: "Abweichung einer Komponente/eines Systems von der erwarteten Lieferung, Leistung oder dem Ergebnis. [Nach Fenton]" --Sebastian.Dietrich ✉ 19:06, 9. Jul. 2021 (CEST)
- Sollten wir also die Aussage 'Fehlverhalten' ersetzen? MIT FV beschreiben das aber zahlreiche andere Quellen, vlt auf der Grundlage von WP? Der Fenton-Satz klingt unlogisch; er müsste wohl lauten "Abweichung der tatsächlichen von der erwarteten Lieferung, Leistung oder dem Ergebnis einer/s Komponente/Systems".--VÖRBY (Diskussion) 13:31, 10. Jul. 2021 (CEST)
- Den Fenton-Satz bzw. den englischen Satz der ISTQB haben sie vermulich falsch übersetzt. Die Quelle sagt dazu auf Englisch: "failure = Deviation of the component or system from its expected delivery, service or result [after Fenton]." Die ISTQB unterscheidet übrigens defect von failure mit "defect führt zu einem failure". D.h. "Programmfehler" ist gar kein Fehlerzustand, sondern nur ein Fehler im Programm der - wenn der Code ausgeführt wird - erst zu einem Fehlerzustand führt. P.S. Wortdeutung.info ist natürlich eine schlechtere Quelle als ISTQB --Sebastian.Dietrich ✉ 18:15, 11. Jul. 2021 (CEST)
- Auch der Englische Text erscheint mir fragwürdig: "Die Abweichung des Systems von s(!) seinem erwarteten Ergebnis ..." vergleicht Äpfel mit Birnen; System und Ergebnis sind zwei unterschiedliche Begriffsebenen. Mit erscheint aber die Beschreibung nach EN ISO 9000:2005 ausreichend; sie besagt wohl dasselbe.
- Die Dreiteilung nach ISTQB ist wohl exakt zutreffend: Damit ist ein Fehler in einem Programm (verursacht durch eine 'Fehlhandlung') zunächst 'Fehlerzustand' ("defect"), erst mit der Ausführung wird daraus ggf. eine 'Fehlerwirkung' ("failure").
- Die - zugegebenermaßen - schwache Quelle ist nur eine von vielen, die 'Fehlverhalten' verwendet. Deshalb halte ich auch den ersten Satz mit "bezeichnet im Allgemeinen" passend - und dass auch ein Programm ein 'Verhalten' hat, haben wir oben schon mehrfach erörtert.--VÖRBY (Diskussion) 09:30, 12. Jul. 2021 (CEST)
- Der Text-Vorschlag oben vom 9. Juli scheint alle Aspekte zu berücksichtigen und v.a. den Leser erstmal 'breit' (und neutral) an die Thematik heranzuführen? --98.158.248.97 17:55, 13. Jul. 2021 (CEST)
- 'unerwartete Abweichung' ist zu unpräzise: Wer erwartet was? Abweichung von was?--VÖRBY (Diskussion) 12:50, 14. Jul. 2021 (CEST)
- Der Text-Vorschlag oben vom 9. Juli scheint alle Aspekte zu berücksichtigen und v.a. den Leser erstmal 'breit' (und neutral) an die Thematik heranzuführen? --98.158.248.97 17:55, 13. Jul. 2021 (CEST)
- Den Fenton-Satz bzw. den englischen Satz der ISTQB haben sie vermulich falsch übersetzt. Die Quelle sagt dazu auf Englisch: "failure = Deviation of the component or system from its expected delivery, service or result [after Fenton]." Die ISTQB unterscheidet übrigens defect von failure mit "defect führt zu einem failure". D.h. "Programmfehler" ist gar kein Fehlerzustand, sondern nur ein Fehler im Programm der - wenn der Code ausgeführt wird - erst zu einem Fehlerzustand führt. P.S. Wortdeutung.info ist natürlich eine schlechtere Quelle als ISTQB --Sebastian.Dietrich ✉ 18:15, 11. Jul. 2021 (CEST)
- Sollten wir also die Aussage 'Fehlverhalten' ersetzen? MIT FV beschreiben das aber zahlreiche andere Quellen, vlt auf der Grundlage von WP? Der Fenton-Satz klingt unlogisch; er müsste wohl lauten "Abweichung der tatsächlichen von der erwarteten Lieferung, Leistung oder dem Ergebnis einer/s Komponente/Systems".--VÖRBY (Diskussion) 13:31, 10. Jul. 2021 (CEST)
Der Ausdruck 'Fehlhandlung' wird in zahlreichen Quellen als Erläuterung der Definition benutzt. Mehrere andere Quellen beschreiben darüber hinaus einfach textlich 'technisches Fehlverhalten' (zB in [3] mit Bezug zum Telecom Standard TL9000). Schon sehr frühe Beschreibungen - siehe [4] oder [5] - benennen zB Insekten ('Bugs') als Ursache für das "Fehlverhalten der Rechner". Der Begriff 'Fehlverhalten' scheint somit für Programm- oder Softwarefehler eine sehr allgemeingültige und akzeptierte Umschreibung/Erläuterung zu sein. Das hier zu ändern, wäre eine Abkehr von etablierten Gewohnheiten - zumal detailliertere Definitionen im Kapitel 'Definitionen' näher behandelt sind.
Eine Alternative zu 'Fehlverhalten' könnte aus meiner Sicht "Abweichung von vorhandenen Vorgaben/Anforderungen oder erwarteten Ergebnissen" sein, weil dies einschließt, dass ein Fehler (im Programm!) auch vorliegen kann, wenn das Pgm noch gar nicht ausgeführt wurde.--VÖRBY (Diskussion) 12:50, 14. Jul. 2021 (CEST)
- Die unterschiedliche Sichtweise ist vermutlich auch darin begründet, dass in der Einleitung und in der Diskussion hier (auch durch mich) unterschiedliche Dinge vermischt werden. Im Abschnitt "Definition" werden die Dinge gemäß ISTQB auch gut auseineandergehalten, im Englischen durch die Unterscheidung "Error", "Defect" und "Failure" vermutlich auch. Ein Programmfehler ist sowohl der Fehler im Programm (z.B. keine Prüfung ob Körpergröße > 0) als auch der Fehlerzustand des Programmes (Körpergröße 0 wird gespeichert), als auch das Fehlverhalten des Programms (Absturz mit DivisionByZero bei Errechnung des Body-Mass-Index). Verursacht wird er durch ein Fehlverhalten des Programmierers (hätte wissen müssen, dass sämtliche Eingaben auf gültige Grenzwerte zu prüfen sind) oder des Analysten (hätte die Grenzwerte korrekt aufschreiben müssen) oder des Anwenders (hätte wissen müssen, dass das Programm noch nicht Grenzwerte prüft und somit eine korrekte Eingabe machen müssen).
- Darum kann "Fehlhandlung" oder "Fehlverhalten" nicht die korrekte Definition für Programmfehler sein, da damit weder der Fehler im Programm noch der Fehlerzustand beschrieben wird. Die Quellen beschreiben daher auch unterschiedliche Teilaspekte von Programmfehler - darum gibt teils völlig unterschiedliche Definitionen für vordergründig ein und dasselbe, aber tatsächlich unterschiedliche Dinge.
- Wir sollten uns daher mMn den Luxus erlauben, schon in der Einleitung nicht nur einen Teil der Aspekte von Programmfehler, sondern alle Aspekte von Programmfehler zu nennen. Ich würde es wie in [6] beschrieben zunächst als "Abweichung von einem gewünschten Sollzustand" subsummieren (das gilt nämlich für alle oben genannten Aspekte von Programmfehler) und dann die einzelnen Aspekte aufführen. Also Vorschlag:
- Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, bezeichnet in der Softwaretechnik eine Abweichung von einem gewünschten Sollzustand. Dies tritt auf, wenn z. B. eine bestimmte Festlegung der Spezifikation fehlerhaft ist oder falsch umgesetzt wurde, dies zunächst zu einem internen Fehlerzustand im Programm führt, der wiederum dazu führt, dass die Laufzeitumgebung fehlerhaft bzw. anders als erwartet arbeitet.
- --Sebastian.Dietrich ✉ 07:17, 15. Jul. 2021 (CEST)
- Halte ich i.W. für einen guten Vorschlag. Ich hätte aber "geforderten oder gewünschten" Sollzustand geschrieben. "Laufzeitumgebung" scheint mir ebenfalls wenig passend; darunter wird etwas anderes verstanden. Besser: "... bei der Programmausführung andere als erwartete Ergebnisse entstehen" (schließt 'fehlerhaft' ein). Plus letzten Satz der bisherigen Einleitung.
- Damit hätten wir die allgemein gebräuchliche und oft verwendete Floskel vom 'Fehlverhalten' aus dem WP-Artikel rausgenommen - aber aus einem anderen als dem eingangs diskutierten Grund. --VÖRBY (Diskussion) 09:35, 15. Jul. 2021 (CEST)
- Also: ":Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, bezeichnet in der Softwaretechnik eine Abweichung von einem geforderten oder gewünschten Sollzustand. Dies tritt auf, wenn z. B. eine bestimmte Festlegung der Spezifikation fehlerhaft ist oder falsch umgesetzt wurde, dies zunächst zu einem internen Fehlerzustand im Programm führt, der wiederum dazu führt, dass bei der Programmausführung andere als die erwarteten Ergebnisse entstehen. Weiterhin können auch Unvollständigkeit, Ungenauigkeit oder Mehrdeutigkeiten in der Spezifikation des Programms zu „Fehlern“ führen."
- Bin prinzipiell dafür, würde nur 1) statt "die erwarteten Ergebnisse" auf das Verhalten eingehen, weil das Verhalten nicht immer als Ergebnis gesehen wird. Also "... dass bei der Programmausführung ein unerwartetes Verhalten auftritt." und 2) ist der letzte Satz eigentlich schon im Satz davor enthalten bzw. könnte man schreiben "..., wenn z. B. eine bestimmte Festlegung der Spezifikation fehlerhaft, unvollständig, ungenau oder mehrdeutig ist..." --Sebastian.Dietrich ✉ 08:44, 16. Jul. 2021 (CEST)
- Servus, kann Deinen Ausführungen voll zustimmen. Vlt noch ein Link zu 'Ausführung' (Computerprogramm#Übersetzung und Ausführung).
- Zusätzliche Disk-Anmerkung: Somit entspricht der 'Programmfehler' in engerem Sinn dem 'Fehlerzustand' - der einerseits durch Fehlhandlung(en?) herbeigeführt und andererseits ggf. mehrfach (1:n) zu Fehlerwirkungen führt. Änderst Du bitte?! Grüße nach W.! --VÖRBY (Diskussion) 10:08, 16. Jul. 2021 (CEST)
- Supi - hab ich gemacht. Ich sehe die Definition breiter: Schon die fehlerhafte Spezifikation ist "eine Abweichung von einem geforderten oder gewünschten Sollzustand".
- Wien sehe ich derzeit nur selten (habe den Luxus eines Hauses am Land - in Rottenbach (Oberösterreich) - und eines Jobs, der gerade jetzt wenig physische Anwesenheit benötigt (war seit Corona erst einen Tag in physischen Meetings)). Wenn ich aber mal in Wien bin ists schon wieder ein tolles Gefühl... --Sebastian.Dietrich ✉ 19:24, 16. Jul. 2021 (CEST)
Einleitung trivial
Bearbeiten"Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, bezeichnet in der Softwaretechnik eine Abweichung von einem geforderten oder gewünschten Sollzustand."
- Jeder Fehler ist "eine Abweichung von einem geforderten oder gewünschten Sollzustand". Es ist nicht Aufgabe dieses Artikels, die allgemeine Bedeutung des Begriffs "Fehler" zu beschreiben. Was ein 'Fehler' ist, braucht man dem Leser nicht zu erklären!Wenn man eine Aussage nach langer Debatte zu sehr verwässert, dann kann sie zu einer Trivialität werden. Dann ist es nur konsequent, sie aus dem Artikel zu löschen. Trivialitäten haben in einer Enzyklopädie nichts verloren.
- "Beispiele allein ("zB") sollten keine Definition beschreiben" - Eine Einleitung braucht das Lemma nicht zu definieren, insbesondere nicht wenn direkt danach ein eigenes Kapitel "Definition" folgt.
--arilou (Diskussion) 09:10, 27. Jul. 2021 (CEST)
- Wie du feststellen kannst, war ursprünglich von 'Fehlverhalten' eines Computerprogramms die Rede. Diese Formulierung hatte Missfallen ausgelöst und wurde durch die neue ersetzt. Die Aufzählungen anschließend - mit "z.B." - beschreiben das Lemma nicht umfassend, sondern eben nur als Beispiele; insofern ist das einleitende "Abweichung ..." die passende Generalisierung, die anschließend mit einigen Beispielen präzisiert wird. Wir hatten zahlreiche Quellen eruiert und waren dabei neben "Fehlverhalten" und "Nichterfüllung einer Anforderung" vereinfachend auf "Abweichung" gestoßen und fanden diese Beschreibung als passend. Dass dabei eine nahezu identische Beschreibung wie bei "Fehler" entsteht, ist m.E. kein Mangel - sondern bezieht sich mit "in der Softwaretechnik" auf den Spezialfall von Fehler, genau wie die genannten Beispiele.
- Schließlich sollte die Einleitung beschreiben, was das Lemma IST, nicht, was es "zum Beispiel ist". Es gibt wohl schlimmere Verstöße hier in der WP.--VÖRBY (Diskussion) 15:45, 27. Jul. 2021 (CEST)
- Was ein Fehler ist, muss sehr wohl erklärt werden; schließlich sind andere Bedeutungen wie "unerwartetes Verhalten" möglich und müssen deshalb ausgeschlossen werden. -- UKoch (Diskussion) 16:16, 28. Jul. 2021 (CEST)
- Einen Leser, dem man erst noch erklären muss, was ein Fehler ist, würde ich doch besser in eine Sprachenschule für Deutsch schicken. Für deutschspachige Leser setze ich voraus, dass sie wissen, was man allgemein unter einem 'Fehler' versteht. Der (allgemeine) Begriff "Fehler" ist kein "erklärungsbedürftiger Fachbegriff". Also NEIN, was man allgemein unter "Fehler" versteht, hat in der hiesigen Einleitung nichts verloren.
- Damit bleibt als Aussage des ersten Satzes:
- Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, ist ein Begriff der Softwaretechnik.
- Wenn ihr der Meinung seid, was allgemein ein "Fehler" ist, müsse erklärt sein, dann verlinkt halt auf Fehler. Imo ist das vollkommen ausreichend.
- --arilou (Diskussion) 16:48, 28. Jul. 2021 (CEST)
- Ich weiß nicht, warum du wegen dieser einfachen Angelegenheit so einen Aufstand machst. Schließlich gibt es das Lemma - Pgm-Fehler - und dazu muss zunächst gesagt werden, WAS das ist, auch wenn dies bei "Fehler" schon so ähnlich steht - aber eben nur so ähnlich; denn die wichtigere Aussage hier ist, dass das für die Softwarerechnik, also für Computersoftware gilt. Mit "... ein Begriff der Softwaretechnik" wird in keiner Weise das Charakteristische für Pgm-Fehler beschrieben. Würde das Lemma z.B. 'Software-Anomalie' heißen, würden viele Benutzer erstmal gar nicht direkt erkennen, dass hier ein Spezialfall von 'Fehler' vorliegt. Und 'trivial' ist das Beschriebene in keinem Fall. Außerdem behandelt Wikipedia den Sachverhalt 'Generalisierung-Spezialisierung' ohnehin nicht wirklich systematisch oder transparent. --VÖRBY (Diskussion) 18:04, 28. Jul. 2021 (CEST)
- >Vorschlag 1: "... ist ein Begriff in der Softwaretechnik, mit dem für ein Computerprogramm bzw. seine Komponenten eine Abweichung zu einem geforderten oder gewünschten Sollzustand bezeichnet wird. Dies kann auftreten ..." --VÖRBY (Diskussion) 18:14, 28. Jul. 2021 (CEST)
- Das ist mMn zu eng. Ein Programmfehler betrifft nicht nur _ein_ Programm sondern u.U. ein ganzes System (an Programmen und Schnittstellen). Je nach Sichtweise gehört zu dem System auch die interne/externe Dokumentation oder auch das Handbuch. Zumindest gibts im Artikel keine Einschränkung des Begriffes auf einzelne Programme oder überhaupt das Programm. Ein Syntaxfehler auf einem Zettel Papier ist mMn genauso ein Programmfehler wie ein Fehler in einer laufenden Software. --Sebastian.Dietrich ✉ 20:14, 28. Jul. 2021 (CEST)
- 'Computerprogramm und seine Komponenten' bezieht sich auf alle Software- und Systemkomponenten, was ja in weitestem Sinn alles (auch Schnittstellen, Treiber, Param-Files etc.) 'Programm-Komponenten' sind - deshalb auch 'Programmfehler'. Mit dem "Zettel Papier'" bin ich mir nicht so sicher: Der kann höchstens die Ursache für einen PF sein, aber nur, wenn sein Inhalt in die Software eingeflossen ist. Ähnlich sehe ich das zur "Doku": Beschreibt sie (fehlerhaft) etwas, das im Programm so implementiert ist, ist sie nur das Abbild (ebenfalls die Ursache oder die Folge) eines PFs.
- Das wäre aber dann eine neue Fragestellung - die im Artikel auch zu behandeln wäre. Zur jetzigen Diskussion würde ich bei > Vorschlag 2 bleiben: "... sind Begriffe aus der Softwaretechnik, mit denen für Software- und Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden. Diese können auftreten ...". (nicht signierter Beitrag von VÖRBY (Diskussion | Beiträge) 09:48, 29. Jul. 2021 (CEST)); korrigiert: --VÖRBY (Diskussion) 09:58, 3. Aug. 2021 (CEST)
- 'Computerprogramm und seine Komponenten' ist lt. Wikipedia "kein Synonym zu Software; vielmehr ist ‚Software‘ ein IT-Sammelbegriff für Nicht-Hardware, zum Beispiel für Betriebssystem, Datenbank oder für eine komplette, für den Benutzer fertige IT-Anwendung – die Komponenten wie Grafik- und Audiodateien, Schriftarten, Hilfetexte usw. umfassen kann.". Darum ist das hier das falsche Wort - Programmfehler stecken eben nicht nur im Computerprogramm, sondern in der Software bzw. im Software-System.--Sebastian.Dietrich ✉ 18:56, 29. Jul. 2021 (CEST)
- Das ist mMn zu eng. Ein Programmfehler betrifft nicht nur _ein_ Programm sondern u.U. ein ganzes System (an Programmen und Schnittstellen). Je nach Sichtweise gehört zu dem System auch die interne/externe Dokumentation oder auch das Handbuch. Zumindest gibts im Artikel keine Einschränkung des Begriffes auf einzelne Programme oder überhaupt das Programm. Ein Syntaxfehler auf einem Zettel Papier ist mMn genauso ein Programmfehler wie ein Fehler in einer laufenden Software. --Sebastian.Dietrich ✉ 20:14, 28. Jul. 2021 (CEST)
- Ich denke, die Begriffe Programm und Software können hier nicht synonym verwendet werden. Nach meiner Meinung geht es hier um 'Programme' (und ihre Komponenten) im Sinn von 'etwas Programmiertes', letztlich Ausführbares, also eine Teilmenge von Software; auch BS, DBK, IT-Anwendung, Schriftarten, Hilfetexte ... sind 'Programme/-Komponenten. Wenn in der Einleitung auch 'Softwarefehler' als Synonym genannt wird, dann bedeutet das wohl, dass Programme im Sprachgebrauch auch oft 'Software' genannt werden - was natürlich nicht 1:1 stimmt. Wir hätten insofern zu klären, ob es um Softwarefehler oder um Programmfehler geht. Jedoch: Die wesentlichen Teile des Lemmatextes beziehen sich eindeutig nur auf ausführbare Software (~Programme).
- Nochmal zu 'trivial': Dürfte man hier die Beschreibung 'Abweichung ...' nicht verwenden, dann müsste das für alle Arten von Fehlern gelten - wie Herzfehler, Vorfahrsfehler, Blinddarm, Rechtschreibfehler ...: Alle sind eine 'Abweichung vom Normalen, Geforderten, Erwarteten'. Insofern muss es erlaubt sein, bei den Spezialformen des sehr allgemeinen Grundbegriffs 'Fehler' eine für sie zutreffende Beschreibung zu hinterlegen.--VÖRBY (Diskussion) 10:03, 30. Jul. 2021 (CEST)
- Dass Programmfehler eine Teilmenge von Softwarefehlern sind - identisch zu 'PGM<>Software' - könnte man unter 'Sonstige Fehlerbegriffe' erläutern und damit PGMF ausdrücklich (und dem Lemma-Inhalt sowie den Referenzen weitgehend entsprechend) auf 'Programme ...' eingrenzen. --VÖRBY (Diskussion) 11:57, 31. Jul. 2021 (CEST)
- > Vorschlag (3) dazu: Programmfehler vs. Softwarefehler: Soweit diese beiden Bezeichnungen nicht als Synonyme verstanden werden (was oft der Fall ist), kann – entsprechend dem Bedeutungsunterschied zwischen Computerprogramm und Software – auch für ‚Softwarefehler‘ eine breitere Definition zutreffen: Danach wären etwa auch Fehler oder Mängel in der Dokumentation Softwarefehler, unabhängig davon, ob sie auch zu fehlerhaften Programmen führten. Auch dürften Fehler in Daten (auch dieser Begriff wird je nach Definition der Software zugerechnet) kaum als Programm-, sondern, wenn überhaupt, höchstens als Softwarefehler gelten. --VÖRBY (Diskussion) 11:03, 2. Aug. 2021 (CEST)
Präzisierungen in o.g. Texten. Machen wirs jetzt so? --VÖRBY (Diskussion) 09:58, 3. Aug. 2021 (CEST); --VÖRBY (Diskussion) 15:52, 3. Aug. 2021 (CEST); kl. Korrekturen: --VÖRBY (Diskussion) 18:22, 3. Aug. 2021 (CEST)
Zur Klärung: Crapware
BearbeitenIch verstehe, dass es in der Einleitung nicht passt. Unter Siehe auch würde jedoch Crapware#Programmfehler meiner Meinung nach passen, da es sich ja um Fehler in der Software handelt, die somit als „Mist“-Software (also „Crapware“) wahrgenommen und beschrieben wird. Natürlich beschreibt Crapware nicht „den Programmfehler“ (wie im vorliegenden Artikel thematisiert), sondern die Wahrnehmung von Software mit einer unvorteilhaften Fehlerhäufigkeit (also diverse Programmfehler) durch die Öffentlichkeit.
Gibt es weitere Meinungen dazu?
‣Andreas•⚖ 22:25, 28. Aug. 2021 (CEST)
Lt Einleitungstext von Crapware handelt es sich NICHT um fehlerhafte Software. Die genannten negativen Eigenschaften (unerwünscht, schlecht geschrieben, keine brauchbare Funktionalität, einfach Mist) können bestenfalls im weitesten Sinn als Fehler bezeichnet werden, weshalb die Erwähnung bei 'Siehe auch' infrage kommen könnte. Dort aber bitte mit Erläuterung, was das konkret ist.--VÖRBY (Diskussion) 17:00, 29. Aug. 2021 (CEST)
- Ja, das ist korrekt. Es gibt zwei Bedeutungen von Crapware. Die, die sich auf Programmfehler bezieht, ist in Abschnitt Crapware#Programmfehler beschrieben. ‣Andreas•⚖ 19:01, 29. Aug. 2021 (CEST)
Krabbelvieh
BearbeitenNach dem Revert von Kleintier die Anmerkung, dass Krabbelvieh nicht das beste Wort für „callbellum“ sein kann @VÖRBY. Insekt? Wenns sein muss Krabbeltier? Mir ist das Wort am Ende eigentlich egal, aber Krabbelvieh ist unenzyklopädisch. Grüße --LukeTriton (Diskussion) 15:53, 16. Dez. 2023 (CET)
- Der ganze Satzinhalt scheint mir nicht präzise zu sein: Nach den Referenzen ist es nicht eine "scherzhafte Vorstellung", sondern die Tatsache, dass T.A. Edison einen "Bug" (lt. LEO: Insekt, Käfer Wanze ...) - ja Krabbeltier wäre besser - als Fehlerursache festgestellt hatte - und diesen (scherzhaft) als "genus callbellum" bezeichnete. --VÖRBY (Diskussion) 16:42, 16. Dez. 2023 (CET)
- Textentwurf dazu:
- Diesem Wortgebrauch liegen als älteste Belege zwei Briefe von Thomas Edison zugrunde:
- An den Präsidenten der Telegraphiegesellschaft Western Union, in dem er als Fehlerursache in einem Telefongerät ein Insekt (engl. „Bug“) identifiziert hatte, das er scherzhaft (mit Bezug auf den Erfinder des Telefons Bell) „Genus Callbellum“ nannte. >> anschließend Zitat und Übersetzung aus dem Artikel
- An Tivadar Puskás, den Erfinder der Telefonzentrale mit einer Bezugnahme auf den Ausdruck „Bug“: >> anschließend Zitat und Übersetzung aus dem Artikel
Abgrenzung Fehlerzustand und Fehlerwirkung
BearbeitenIn die Einleitung fehlt mMn. die Unterscheidung zwischen Fehlerzustand/Defekt (Englisch 'Defect', Synonyme: 'bug', 'fault') und Fehlerwirkung (Englisch 'Failure'). Diese sollte besser direkt in die Einleitung eingebunden werden, da das umgangssprachlich und selbst in Entwicklerkreisen und Testerkreisen minunter gerne miteinander vermischt wird. So kann der Artikel zur Bildung und Aufklärung beitragen.
Fehlerzustand beschreibt einen unerwünschten Zustand im Programm(code) oder System, der oft noch nicht entdeckt ist (Beispiel: ein logischer Fehler in einem Algorithmus).
Die Fehlerwirkung ist die unerwartete Auswirkung, die der Benutzer oder Tester beim Ausführen der Software oder des Systems sieht (Beispiel: das Programm stürzt ab).
Am besten auch noch Grundursache (Englisch 'Root cause') und Fehlhandlung (Englisch 'Error', Synonym 'mistake') mit erklären.
Als Softwaretest-Kursleiter musste ich das selbst ständig nachsehen, wegen der starken Verwechslungsgefahr und Vermischung der Begriffe in Branchenkreisen, und stark uneinheitlicher Terminologie.
Hat jemand Vorschläge wie man das am besten und akkuratesten formulieren und zusammenbringen könnte? Es gibt zwar im ersten Abschnitt Definitionen einen Versuch einer Übersicht, aber diese ist nicht vollständig und trotzdem unübersichtlich.
Ich fände es besser das in einem kurzen und präziseren Satz in der Einleitung zu erklären. Vor allem fehlt in der Einleitung der Bezug zur Fehlerwirkung die vom Laien am häufigsten mit dem Fehlerzustand verwechselt wird. Eventuell sollte die Artikelstruktur überarbeitet werden. Sinngemäß widersprechen sich etwa zum Beispiel im Abschnitt „Bug“ als Synonym für Programmfehler direkt unterhalb der Definitionen die zur Erläuterung verwendeten beiden Begriffe (Zitat): "Fehlfunktion oder auch Konstruktionsfehler". Fehlfunktion entspricht eher der Fehlerwirkung, Konstruktionsfehler eher dem Fehlerzustand.
"Der Fehlerzustand (fehlerhafter Code im Programm) ist von der Fehlerwirkung (das Programm stürzt ab) abzugrenzen, siehe Definition." oder ähnliches würde schon reichen, und eine Ergänzung/Überareitung der Definition. --Worstbull (Diskussion) 08:59, 12. Jan. 2024 (CET)
- Ich denke, es ist ok, in der Einleitung i.W. den 'Programmfehler' als Begriff zu beschreiben. Die Unterscheidung/Präzisierung erfolgt danach im Abschnitt "Definition"; das halte ich für ausreichend und klar genug - übrigens mit den Formulierungen aus ISTQB. Bereits in der Einleitung ist die Fehlerwirkung erwähnt: "... ein unerwartetes Verhalten oder Ergebnis eintritt". Der "Absturz" des Programms ist nur eine von vielen möglichen Fehlerwirkungen. Aus meiner Sicht muss man da nichts ändern. --VÖRBY (Diskussion) 10:45, 12. Jan. 2024 (CET)
- Ich habe es nun so eingepflegt, möglichst kurz aber auch mit dem wichtigen Zusatz, dass die Fehlerwirkung immer zur Laufzeit auftritt: https://de.wikipedia.org/w/index.php?title=Programmfehler&diff=prev&oldid=241108954 Gerne Feedback/Verbesserung.
- Den zuvor vorgeschlagenen Verweis auf die Definitionen habe ich weggelassen, das ist offensichtlich. --Worstbull (Diskussion) 00:58, 13. Jan. 2024 (CET)
- Ist jetzt redundant im Artikeltext - und es fehlt (nach ISTQB) die 'Fehlehandlung'. Nochmal: Aus meiner Sicht braucht man diesen Aspekt nicht in der Einleitung; er genügt bei den sofort nachfolgenden 'Definitionen'. --VÖRBY (Diskussion) 10:55, 13. Jan. 2024 (CET)
- Okay, das habe ich dann falsch verstanden, ich entschuldige mich. Ich habe das "es ist ok... zu beschreiben" als Zustimmung gelesen.
- Wie wäre es damit:
- "...der Programmausführung eine Fehlerwirkung, also ein unerwartetes Verhalten oder Ergebnis auftritt."
- So hätten wir nur diesen einen Begriff ergänzt, damit die klare Unterscheidung zwecks Abgrenzung in der Einleitung ist. Und den zusätzlichen Satz kann ich wieder rausnehmen. (Edit: erstmal wieder rausgenommen)
- Was genau meintest du dann mit "Ich denke, es ist ok, in der Einleitung i.W. den 'Programmfehler' als Begriff zu beschreiben."? Sollte das heißen so lassen? --Worstbull (Diskussion) 11:12, 13. Jan. 2024 (CET)
- Das sollte heißen, dass sich die Einleitung darauf beschränkt, nur den Ausdruck 'Programmfehler' als Hauptbegriff zu behandeln. Details (wie zB die 3 Teilaspekte lt. ISTQB) sollten im Kapitel 'Definitionen' bleiben und können dort auch gerne erweitert werden - bitte mit Quellenangabe. --VÖRBY (Diskussion) 16:23, 13. Jan. 2024 (CET)
- Ich verstehe, und kann das Argument Redundanz durchaus nachvollziehen. Ich würde gerne an folgender Stelle den Begriff "Fehlerwirkung" einfügen im zweiten Satz der Einleitung, zur Abgrenzung aber auch schon allein damit der Begriff erklärt ist. Denn er wird zwei Absätze später ohne Erläuterung oder Verlinkung benutzt, das könnte zu Kopfzerbrechen führen wenn man ihn nicht kennt:
- Alt:
- Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, sind Begriffe aus der Softwaretechnik, mit denen für Software-Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden. Diese können auftreten, wenn z. B. eine bestimmte Festlegung der Spezifikation fehlerhaft ist oder falsch umgesetzt wurde, und führt zunächst zu einem internen Fehlerzustand im Programm, der wiederum dazu führt, dass bei der Programmausführung ein unerwartetes Verhalten oder Ergebnis auftritt.
- Neu:
- Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, sind Begriffe aus der Softwaretechnik, mit denen für Software-Systemkomponenten Abweichungen zu einem geforderten oder gewünschten Sollzustand bezeichnet werden. Diese können auftreten, wenn z. B. eine bestimmte Festlegung der Spezifikation fehlerhaft ist oder falsch umgesetzt wurde, und führt zunächst zu einem internen Fehlerzustand im Programm, der wiederum dazu führt, dass bei der Programmausführung eine Fehlerwirkung, also ein unerwartetes Verhalten oder Ergebnis auftritt.
- Diese Variante wäre um zwei Wörter länger.
- Oder einfach nur:
- , dass bei der Programmausführung eine Fehlerwirkung auftritt.
- Der Befriff ist ja dann in den Definitionen erklärt. Das macht den Satz kürzer. --Worstbull (Diskussion) 17:53, 13. Jan. 2024 (CET)
- Vorschlag: "... fehlerhaft ist oder falsch umgesetzt wurde („Fehlhandlung“), und führt zunächst zu einem internen „Fehlerzustand“ im Programm, der wiederum bei der Programmausführung zu einem unerwarteten Verhalten oder Ergebnis führt oder führen kann („Fehlerwirkung“)."
- Ist immer noch Redundanz, aber wenn Dir das so wichtig ist? Aus meiner Sicht hätte das unter "Definitionen" gereicht. --VÖRBY (Diskussion) 10:49, 14. Jan. 2024 (CET)
- Danke für den Vorschlag! Ist eingepflegt. --Worstbull (Diskussion) 05:54, 15. Jan. 2024 (CET)
- Das sollte heißen, dass sich die Einleitung darauf beschränkt, nur den Ausdruck 'Programmfehler' als Hauptbegriff zu behandeln. Details (wie zB die 3 Teilaspekte lt. ISTQB) sollten im Kapitel 'Definitionen' bleiben und können dort auch gerne erweitert werden - bitte mit Quellenangabe. --VÖRBY (Diskussion) 16:23, 13. Jan. 2024 (CET)
- Ist jetzt redundant im Artikeltext - und es fehlt (nach ISTQB) die 'Fehlehandlung'. Nochmal: Aus meiner Sicht braucht man diesen Aspekt nicht in der Einleitung; er genügt bei den sofort nachfolgenden 'Definitionen'. --VÖRBY (Diskussion) 10:55, 13. Jan. 2024 (CET)
- Danke für die Klärung! Noch ein Vorschlag: Anführungsstriche entfernen, stattdessen evtl. kursiv setzen. -- UKoch (Diskussion) 14:48, 23. Jan. 2024 (CET)
- Die Anführungsstriche bedeuten, dass die Ausdrücke an anderer Stelle genau so definiert (und erläutert) sind.
- Könnten in den Definitionen weitere Begriffe ergänzt werden (wie Grundursache, s.o.). Wer kennt dazu verbindliche Definitionen? --VÖRBY (Diskussion) 16:08, 23. Jan. 2024 (CET)
- "Praxiswissen Softwaretest - Test Analyst und Technical Test Analyst
- Aus- und Weiterbildung zum Certified Tester - Advanced Level nach ISTQB-Standard
- By Graham Bath, Judy McKay · 2015" schreibt dazu: "Die Ursache eines Fehlerzustands. Wenn man sie behebt, dann wird das Vorkommen der Fehlerart reduziert oder eliminiert."
- https://www.google.de/books/edition/Praxiswissen_Softwaretest_Test_Analyst_u/rK32DwAAQBAJ?hl=en&gbpv=0 --Worstbull (Diskussion) 07:28, 14. Feb. 2024 (CET)
- Danke für die Klärung! Noch ein Vorschlag: Anführungsstriche entfernen, stattdessen evtl. kursiv setzen. -- UKoch (Diskussion) 14:48, 23. Jan. 2024 (CET)