Diskussion:Programmfehler

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Programmfehler“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit oder --~~~~.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 720 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Fehler pro Zeilen Quellcode

Ich sehe keinen Sinn darin, die Stabilität an der Anzahl Fehler pro Zeilen Quellcode zu definieren, und noch weniger darin, einen fixen Schwellwert anzugeben. Dass Zeilenanzahl generell eine wenig aussagekräftige Softwaremetrik ist, hat sich in der Branche längst herumgesprochen, und die Stabilität kann auch nicht sinnvollerweise durch die Fehleranzahl definiert werden, da ein Fehler ganz unterschiedliche Auswirkungen auf die Stabilität haben kann. Da ausserdem keine Quelle angegeben ist, lösche ich den Satz einfach mal raus. --Zumbo (Diskussion) 09:44, 12. Mär. 2020 (CET)

Ich gebe dir grundsätzlich Recht: Vor allem auch deshalb, weil die Aussage ohne Bezug auf eine Programmiersprache getätigt wird. Trotzdem denke ich, dass in eine Messgröße für Fehlerdichte in irgendeiner Weise die Größe des Programms einfließen muss; denn es ist ein Unterschied, ob z.B. "2 Fehler" in einem 100 Statement-Programm (Modul?) oder in einem mit 5000 Statements existieren. Zusätzlich: Diese Größe muss unterstellen, dass es sich um "bisher gefundene Fehler" (was auch immer der Zeitbezug ist) handeln kann. Weiterhin müsste man nur echte Anweisungen (keine Kommentare etc.) als Grundlage heranziehen. Vielleicht kann man die Quelle finden - die dann Konkreteres belegen sollte. --VÖRBY (Diskussion) 11:02, 12. Mär. 2020 (CET)

Der Abschnitt Fehlerquotient#Fehlerdichte in der Informatik geht näher auf diese Metrike ein und enthält auch zahlreiche Quellenangaben. Ich denke, man sollte auf diesen Artikel per 'Hauptartikel'-Link verweisen - oder auf eine der dortigen Referenzen. --VÖRBY (Diskussion) 16:41, 12. Mär. 2020 (CET)

In [1] wird u.a. die Messgröße 'lines of Code' behandelt und diskutiert. Sie sei "im praktischen Einsatz meist ungenau" und "nur ein grobes Maß für die ,,Menge`` an Software". Ihre Definition werde "eventuell durch das Weglassen von leeren Zeilen und Kommentarzeilen, eventuell auch Deklarationszeilen modifiziert". Sie sei "nur für den gleichen Programmierer im gleichen Problembereich und mit der gleichen Programmiersprache direkt vergleichbar". Das sollte man in 'Fehlerquotient' nachtragen, bei Programmfehler auch die Aussage, dass alternativ "Function Points" als Bezugsgröße für die Fehleranzahl verwendet wird. --VÖRBY (Diskussion) 17:08, 12. Mär. 2020 (CET)

Es geht um den Satz: "Programme mit einer Fehlerdichte von weniger als 0,5 Fehlern pro 1000 Zeilen Quelltext gelten als stabile Programme."

In Fehlerquotient#Fehlerdichte in der Informatik steht dazu was inkl. jeder Menge Belege. Sollte mMn hier auch eingebaut bleiben. Hab größtenteils ich dort belegt (d.h. ich hab auch Zugriff auf die Literatur) und auch teilweise geschrieben.

Zu den von euch geäußerten Kritikpunkten:

• Ja Zeilenanzahl ist keine perfekte Metrik, ist aber die Metrik zu der es mit Abstand am meisten Untersuchungen gibt. Es gibt jede Menge Untersuchungen an teils zig tausenden Projekten hinsichtlich Zeilenanzahl. Einige Dinge korrelieren eindeutig mit Zeilenanzahl, einige Dinge nicht.
• Mit Stabilität (in der Literatur steht wirklich "stable") kann vieles gemeint sein - in der Literatur wird hinsichtlich Fehlerrate Software in stabil, reifend, labil, fehleranfällig und unbrauchbar unterschieden. Gebe @Zumbo: aber recht, "stabil" kann was ganz was anderes auch bedeuten und sollte erklärt werden.
• Ja die Metrik ist unabhängig von Programmiersprachen. Liegt vermutlich an den 10 bis 50 Codezeilen je Mitarbeiter und Tag (siehe Lines of Code.
• Da es um 0,5 Fehler pro 1000 Zeilen geht, ist der Unterschied 100 vs. 5000 Statements damit eh implizit
• Es geht nicht um "bisher gefundene Fehler", sondern insgesamt um Fehler, die (noch) in der Software sind.
• Grundlage für die Berechnung ist immer (source) lines of code (d.h. ohne Kommentarzeilen oder Leerzeilen) --> sollte wie VÖRBY schreibt auch dort nachgetragen werden...

--Sebastian.Dietrich ✉ 17:15, 12. Mär. 2020 (CET)

Der Kritik in [2] gibts sicher noch einiges hinzuzufügen: generierter Code, Bezahlung nach Lines of Code, ... verfälscht das alles. Aber klar, wenn ich will, kann ich jede Metrik bewusst verfälschen. Für "Menge an Fachlichkeit" ist LOC auch keine geeignete Metrik, sehr wohl aber für "Größe der Software" und eben indirekt "Anzahl Fehler in der Software"... --Sebastian.Dietrich ✉ 17:19, 12. Mär. 2020 (CET)

Ich würde HIER im Artikel die bisherige Aussage allgemeiner ausdrücken (~"Je nach Art und Zweck der Software gelten unterschiedliche Fehleranzahlen, z.B. 0,5 pro 1000 LOC, als angemessen"), die Details aber (an einer zentralen Stelle) in Fehlerquotient belassen. Alternativ könne man die Details HIER einstellen und DORT nur verweisen; an beiden Stellen dasselbe wäre wohl Redundanz. --VÖRBY (Diskussion) 17:52, 12. Mär. 2020 (CET)

Textvorschlag: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie wird als Prozentwert in der Software noch vorhandener Fehleranzahlen im Verhältnis zur Gesamtanzahl der Programmzeilen ausgedrückt. Je nach Art und Zweck der Software gelten unterschiedliche Prozentsätze als Obergrenze anzustreben, z. B. 0,5% für kritische Anwendungen (etwa Militär, Krankenhaus). Alternativ nennt man die Fehleranzahl je Function Point. Weitere Details hierzu siehe Hauptartikel Fehlerqoutient.

Bitte QS, dann Aufnahme in den Artikel. Rest in Fehlerquotient einarbeiten? --VÖRBY (Diskussion) 18:46, 12. Mär. 2020 (CET)

+1 aber mit folgenden Kritikpunkten:

• Das Wort "Fehlerdichte" ist in der IT gängiger als "Fehlerquotient" (da es eben kein quotient ist - siehe nächster Punkt)
• Sie ist kein Prozentwert sondern pro KLOC (also z.B. "0,5 Fehler pro KLOC")
• Man muss die Einheit immer dazuschreiben "Fehler pro KLOC" oder "Fehler pro FPoint"
• Man kann auch die Fehlerdichte vor dem Test beschreiben - "noch vorhanden" stimmt also nicht immer.
• Der Satz mit der Alternative je Functionpoint ist unnötig, da drüber ohnedies "bzw. je Functionpoint" steht
• Lines of Code sollte genauso wie Function Point verlinkt werden und wenn schon englisch dabei idealerweise gleich die exaktere Bezeichnung SLOC nehmen und vielleicht gleich den Begriff KLOC reinbringen. Quellcode klingt mMn auch mehr nach SLOC als nach LOC

darum

Textvorschlag 2: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Quellcode (Kilo Source Lines of Code oder KLOC) bzw. je Function Point. Je nach Art und Zweck der Software gelten unterschiedliche Zahlen als Obergrenze anzustreben, z. B. 0,5 pro KLOC für kritische Anwendungen (etwa Militär, Krankenhaus). Weitere Details hierzu siehe Hauptartikel Fehlerqoutient.

Kürzere Alternative, da der Satz ja in der Einleitung steht:

Textvorschlag 3: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Code (Kilo Source Lines of Code) bzw. je Function Point.

--Sebastian.Dietrich ✉ 06:22, 13. Mär. 2020 (CET)

TV3 erscheint mir als guter Vorschlag. Ich würde auf jeden Fall noch auf den Hauptartikel verweisen wollen - und dort die oben diskutierten Zusätze mit der neuen Quelle ergänzen.

Man könnte dort auch noch anmerken, dass diese Messgröße irgendwie immer fiktiv bzw. nur ein Hoffnungs-/Zielwert ist, der erst nachträglich verifiziert/bewiesen werden kann - zB wenn man (wieder mal) Fehler gefunden hat. Sowohl als Zielwert als auch als ermittelte Größe gehört deshalb wohl zur Definition, dass die FD ab einem bestimmten Zeitpunkt gemeint ist; Fehlermengen zu Beginn des Testens sind anders zu sehen als im Produktionsbetrieb (etwa seit Abnahmetest; ist das implizit die 'gängige' Definition?).

Machst Du? Danke. --VÖRBY (Diskussion) 10:42, 13. Mär. 2020 (CET)

Gerne - ich versteh aber deinen ersten Satz "TV3..." nicht. Was meinst du mit verweisen (Link auf Hauptartikel macht mMn keinen Sinn, da es erst ab Fehlerdichte um Programmfehler geht)? Ich vermute du meinst Einbau der oben diskutierten Zusätze mit der neuen Quelle - das kann ich gerne machen.

@Fiktiv - ja. Man kanns zwar mit recht großer Bandbreite schätzen, aber richtig verifizieren kann mans nur mit formaler Spezifikation/Verifikation (auch wenn die Software schon ewig im Einsatz ist, hat sie u.U. noch Fehler)

@bestimmter Zeitpunkt - jein. Die Fehlerdichte ändert sich natürlich mit der Zeit, aber die dort genannten Zahlen beziehen sich immer auf die Fehlerdichte zum Zeitpunkt der Produktivsetzung. Das ("Zeitpunkt der Produktivsetzung") kann ich aber ergänzen und ich könnte auch noch Zahlen zur üblichen Fehlerdichte vor dem Test liefern... --Sebastian.Dietrich ✉ 20:23, 13. Mär. 2020 (CET)

Hallo, TV3 ist dein Textvorschlag3. Weil in 'Fehlerquotient' (#Informatik, dorthin sollte auch der Link zeigen) derzeit die meisten und wichtigsten Details behandelt sind, ist das der eigentliche 'Hauptartikel'. Oder wir drehen das um und nehmen das meiste der dortigen Aussagen hier bei Programmfehler auf - und verweisen aus ..Quotient nach Programmfehler. Aber auch in Programmfehler wären die Texte zu Dichte nur ein Nebenaspekt; insofern könnten wir die bisherige Textverteilung auf 2 Artikel auch so lassen. Egal wie: Die zahlreichen Detailaspekte von 'FD' sollten m.E. an einer Stelle stehen, in anderen Artikeln nur kurze Zusammenfassung(en) und Link auf den Hauptartikel(#Abschnitt). --VÖRBY (Diskussion) 09:28, 14. Mär. 2020 (CET)

Sebastian, danke für die Ergänzung. Der Link auf 'Fehlerdichte' ist ausreichend, ein zusätzlicher HA-Verweis deshalb überflüssig. ERLEDIGT!? Servus!--VÖRBY (Diskussion) 18:34, 14. Mär. 2020 (CET)

Ja mMn. mMn sollte der Hauptartikel weiterhin dort bleiben, weil dort spezifischer.

Mit dem Einbau der Kritik in [3] habe ich aber meine Schwierigkeiten, da sie 1) besser zu Lines of Code als zu Fehlerdichte passt (Fehlerdichte ist ja nur eine der Metriken, die auf LOC basiert) und 2) als Kritik nicht so geeignet ist, da sie unter 1.5.4 und 1.5.5. eigentlich beschreibt wie gut sie hier passen und 3) es meines Wissens nach überhaupt keine Metriken gibt, die exakt was aussagen, LOC somit nicht schlechter ist als alles andere... --Sebastian.Dietrich ✉ 20:02, 14. Mär. 2020 (CET)

Ich hatte die o.a. Ergänzungen weniger als Kritik empfunden denn als Präzisierung der Definition und Erweiterung um wesentliche Aspekte.

Ob sie besser zu LOC oder zu Fehlerdichte passen? Bisher sind die Details im wesentlichen bei FD beschrieben, was wohl auch ok ist. Insofern sollte man auch in FD ergänzen, um so ein vollständiges Bild zu bekommen.

Nochmal zu 'Zeitpunkt': Die Messgröße ist solange ein hypothetischer Erwartungswert, bis die Fehleranzahl bekannt ist - und das gilt dann immer für einen zurückliegenden Zeitraum, zB n Fehler seit Produktionssetzung (das wärend also erkannte!). --VÖRBY (Diskussion) 09:24, 15. Mär. 2020 (CET)

Eigentlich beschreibts nicht die erkannten Fehler, sondern alle. D.h. bleibt de facto für größere Programme immer hypothetisch, weil in der Praxis nie alle Fehler auftauchen. --Sebastian.Dietrich ✉ 19:25, 15. Mär. 2020 (CET)

Die Bestätigung ist also immer nur nachträglich möglich (Zielgröße=X > Realität=Y). Ich habe die m.E. für den Hauptartikel relevanten Elemente/Kriterien (in meinen Disk-Beiträgen) fett markiert, z.K. Machs gut, trotz Virus!--VÖRBY (Diskussion) 09:13, 16. Mär. 2020 (CET)

Beispielvideo

Datei:Wikipedia-Reiter-Bug02 OHNE TON.webm Ich fand das von PantheraLeo eingebaute Beispielvideo sehr gut. Natürlich gibt es Millionen verschiedene Beispiele von Bugs, das Video zeigt aber ein Beispiel direkt aus der Wikipedia und etwas, was auf den ersten Blick den Artikelinhalt veranschaulicht. Daher möchte ich die Pauschalbegründung für den Revert, "ein Bsp von zig-Tausend - hier irrelevant", zurückweisen. --Wikiolo (D) 16:17, 31. Mai 2020 (CEST)

Der Artikel hier behandelt Programmfehler in ihrer Gesamtheit, siehe z.B. Abschnitt 'Arten von Programmfehlern'. Es werden u.a. die Ursachen beschrieben oder worin der Fehler konkret besteht - was das Video nicht zeigt. Es ist lediglich eine Erscheinungsform eines evtl. Fehlers. Der Ausdruck 'grafischer Fehler' kommt im Artikel auch nicht vor; was ist das? Das Video gleich in der Einleitung zu positionieren, entspricht auch nicht der Bedeutung des Artikels. Beispiele für konkrete Fehler zeigt (und beschreibt!!!) die Liste von Programmfehlerbeispielen.--VÖRBY (Diskussion) 17:13, 31. Mai 2020 (CEST)

Das Video soll ein Beispiel geben, wie sich ein Programmfehler auswirken kann und kann daher als Beispiel für ein Programmfehler in seiner Gesamtheit verwendet werden. Es ist auch nicht der Sinn einer eingearbeiteten Datei, ein gesamtes Thema darzustellen; das muss aus dem Artikel selbst hervorgehen. Gerne kann die Videobeschreibung angepasst werden, z.B. Auswirkungsbeispiel eines Programmfehlers. --Wikiolo (D) 18:08, 31. Mai 2020 (CEST)

Eine Grafik oder ein Video bei der Einleitung sollte nicht ein spezielles Thema oder nur einen Teilaspekt zeigen.

Wenn "Einleitung", dann muss es auch (möglichst belegt!) echt typisch sein, oder tatsächlich (so ziemlich) alle Aspekte zeigen.

Ansonsten bitte an die geeignete Artikelstelle, oder eben ganz raus.

--arilou (Diskussion) 14:54, 13. Nov. 2020 (CET)

Habe das Video mal verschoben und in 'Laufzeitfehler' eingestellt; das ist es wohl. Da aber dort wirklich nur "ein Beispiel von Milliarden" gezeigt wird, und dazu ohne konkreten Bezug zu Artikelinhalten, könnte man das m.E. auch löschen.--VÖRBY (Diskussion) 18:14, 13. Nov. 2020 (CET)

Fehler in der Einleitung / zu Fehlverhalten

In 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 [4]. 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 [5] 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 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 [6] mit Bezug zum Telecom Standard TL9000). Schon sehr frühe Beschreibungen - siehe [7] oder [8] - 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 [9] 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

"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."

1. 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.
2. "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)

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

Widerspruch zu Text v Crapware; nach Klärung ggf. bei 'Siehe auch' einstellen: gehört nicht in die Def;

Ich 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)