Diskussion:Softwaretest

Zum Archiv

Wie wird ein Archiv angelegt?

Verifikation

Tests zur teilweisen Verifikation? Es gibt meiner Meinung nach keine teilweise Verifikation, nur unterschiedliche Arten derselbigen. Tests unterscheiden sich fundamental von der Verifikation. Sie erbringen eben keinen Nachweis der Korrektheit. Daher finde ich die Aussage am Anfang des Artikels sehr problematisch.--guwac

Verifikation soll den Nachweis der Übereinstimmung eines Software-Produkts mit seiner Spezifikation zeigen. Korrektheit im Sinne von Fehlerfreiheit existiert letztendlich nur bei trivialen Programmen. Auch ist die Gleichsetzung von Verifikation und Validation falsch. "Verifikation: Wird ein korrektes Produkt entwickelt? Valdiation: Wird das richtige Produkt entwickelt?"--Taschenrechner 17:02, 27. Apr 2005 (CEST)

vermisste Testarten

Ich vermisse noch Modulgruppentest und Shakedowntest. Eine Auflistung aller existierenden Testarten wäre super. (nicht signierter Beitrag von 81.200.198.20 (Diskussion) 14:38, 12. Mär. 2014 (CET))

Beim Softwaretest ist man sehr kreativ mit den Bezeichnungen. Modulgruppentest könnten woanders Integrationstest und Shakedowntest könnten woanders Smoketest genannt werden. Solange nicht bekannt ist was, womit und zu welchem Zweck getestet wird, ist alles Spekulation.--Avron (Diskussion) 15:32, 12. Mär. 2014 (CET)

Unter Weblinks gibt es ein Glossar, in dem auch viele Testarten enthalten sind. Ich stimme Avron zu: Es gibt hier unendlich viel Kreativität; wichtig ist aber der Kontext, in dem eine bestimmte Testart steht.

PS: Disk-Beiträge sollten chronologisch eingeordnet werden. --VÖRBY (Diskussion) 17:44, 12. Mär. 2014 (CET)

Was mich hierzu wundert ist, bzgl. der Teststufen, der alleinige Verweis auf das V-Modell. Dieses ist doch nicht das einzigste Entwicklungsmodell, welches in der Softwareentwicklung verwendet wird. Kommen nicht noch automatisch mehrere Testarten ins Spiel, wenn man sich nicht allein auf das V-Modell stützt? (nicht signierter Beitrag von 84.21.34.168 (Diskussion) 15:05, 22. Apr. 2015 (CEST))

Auch beim Testen wird man ein bestimmtes 'Vorgehen' (Reihenfolge) haben - und das sind die Teststufen, egal woran sie sich orientieren. Eine Möglichkeit davon ist das Vorgehen(smodell) (ein beliebiges) bei der Entwicklung. Insofern könnte/sollte man den expliziten Verweis auf DAS V-Modell neutralisieren und allgemeingültiger fassen. Wäre es das? Danke für den Hinweis. --VÖRBY (Diskussion) 17:12, 22. Apr. 2015 (CEST)

Fuzztest

Wo wäre denn hier Fuzztest einzuordnen? Neuer Artikel?

Damit ist wohl Fuzzing gemeint.-- Avron 19:05, 1. Aug. 2008 (CEST)

Klassifikation nach Ablauf, Umfang - Unsortiertes Sammelsurium von Testbegriffen

Unter dem Abschnitt "Klassifikation nach Ablauf, Umfang" werden wahllos Begriffe aufgeführt die in keiner Art und Weise sortiert sind und teilweise auch falsch erklärt sind.

• Installationstests wird mit der Definition des Konfigurationstests erklärt.
• Destruktionstests sollen das korrekte (ein definiertes) Verhalten bei unnormalem Gebrauch sicherstellen Tests können kein Verhalten sicherstellen sondern nur nachweisen.
• Unterschied Lasttest und Performancetest??
• Unterschied zwischen Abnahme- und Akzeptanztest??

--DJ 18:40, 31. Dez. 2006 (CET) Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)

Wer macht was?

Der Software-Test kann verschiedene Ausprägungen haben: So gibt es den Code and Unit-Test (Komponententest), der vom Entwickler durchgeführt wird und bei dem das Programm auf Syntax- und Logikfehler überprüft wird. Beim Integrationstest testet die Softwareproduktion in einer Testumgebung die Einbindung der Software in die bereits vorhandene Softwarearchitektur.

• Die Überprüfung auf Syntaxfehler findet bei der statischen Code-Analyse statt. Das hat nichts mit Unit-Test zu tun.
• Die Softwareproduktion testet nur den Produktionsprozess der Software. Sie hat mit Integrationstest nicht zu tun.
• Eine Software kann nicht in eine Softwarearchitektur eingebunden werden. Die SW-Architektur beschreibt die grundlegenden Elemente und die Struktur eines Softwaresystems.

--DJ 19:41, 31. Dez. 2006 (CET) Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)

Fehler beim Kapitel Planung

Sollte der Verwies vom Nebeneffekt nicht besser so umgeschrieben werden, dass er auch in die richtige Richtung Wirkung (Informatik) weist?

überarbeiten / Überarbeitungsbaustein gesetzt

Der Artikel ist ziemlich zusammengewurstelt und bedarf einer gründlichen Überarbeitung. Die Diskusionsseite übrigens auch. --Avron 16:34, 10. Jan. 2008 (CET)

Das finde ich auch. Ein systematischer Überblick der Vorgänge und Arten des Testens findet sich z.B. in "Objektorientierte Softwaretechnik" und Brügge und Dutoit. Ich hab leider grad keine Zeit, den Artikel gründlich zu überarbeiten, außerdem bin ich kein Experte im Software Engineering und im Testen. Daher habe ich einen Überarbeitungsbaustein gesetzt.--Thomaserl 20:53, 28. Feb. 2009 (CET)

Ich habe den Artikel schon mal überarbeitet. Bitte genau nennen was überarbeitungswürdig ist, aber keine "prophylaktischen" Bausteine reinsetzen.--Avron 08:37, 2. Mär. 2009 (CET)

"Der Softwaretest ist eine analytische, dynamische Maßnahme zur Qualitätssicherung von Software, d. h. der Softwarequalität." Der Satz ergibt ja keinen Sinn, würde ja heißen: "..., dynamische Maßnahme zur Qualitätssicherung der Softwarequalität." weiß nicht ob das korrektes Deutsch ist aber es horcht sich auf jeden Fall grottig an :(

Hier wird schön durchgemischt deutsch, englisch ohne Rücksicht auf Verluste da sollte zumindest etwas Linie rein. die Fragestellung ist nicht trivial, denn die Übersetzungen sind nicht 1:1 (z.B. Testplan ... ) --193.158.17.135 08:57, 14. Mai 2008 (CEST)

Was ist denn "testgetrieben"? test-driven bedeutet immer noch testgesteuert auch wenn alle Welt den Driver mit Treiber übersetzt.

Literatur

Das gepostete Buch von Graham Bath e.a. ist das Standard-Lehrbuch für den SW-Test in englischer Sprache - es ist vom Feinsten, sonst mache ich mir nich die Mühe, in die Wikipedia zu schreiben.

Wer das von der Literaturliste löscht ("Hubertl") ist wohl nicht ganz am modernsten Stand oder mit der Materie nicht so richtig vertraut - dafür sollte eine Wikipedia ja gut sein, um neue Informationen zugänglich zu machen.

Das Thallerbuch ist jedenfalls ziemlich veraltet und bietet nur wenig sinnvolle Information.

Wenn in diesem Artikel das Sneed / Seidl / Baumgartnerbuch gestattet ist, was ich begrüße, weil ich dort erwähnt werde, dann sollte dieses Buch auch in diesem Artikel vorkommen:

Hier noch einmal der Titel:

• Graham Bath, Judy McKay: The Software Test Engineer´s Handbook. rockynook Computing, ISBN 1-933952-24-5

Definition von Test vs Prüfung

"Ein Softwaretest ist ein Test während der Softwareentwicklung, um die Funktionalität einer Software an den Anforderungen und ihre Qualität zu messen, und Softwarefehler zu ermitteln."

Die Ermittlung von Fehlern ist sicherlich der wichtigste Grund zum Testen. Der andere Grund ist der Qualitätsnachweis einer Software (Stichwort: Abnahmetest).

Die Definition von "Test" schließt zudem hier die statschen Prüfungen (Reviews, Statische Prüfung) ein. Die gehören definitiv nicht zum Test. Die gegebene Definition widerspricht auch der ANSI-Definition, the process of operating a system or component ..., nach der ein Test zwingend die Ausführung des Testgegenstands erfordert.

-- Heinrich Seebauer 13:30, 23. Apr. 2009 (CEST)

Je nach Quelle wird 'Test' (Testen') unterschiedlich definiert: Eine engere Auslegung versteht darunter nur die Prüfungen 'am fertigen Objekt' durch 'Ausführung', meint also nur das dynamische Testen. Nach erweiterten Definitionen (siehe auch Spillner) gehört jede Art von 'Prüfen' zum 'Testen'; der Unterschied zwischen konkreter Ausführung eines Testobjekts und andersartigen 'Prüfungen' gilt dabei als nicht begriffsbestimmend.
Praxisorientierte Feststellung: Wenn eine ganze Gruppe von Prüfhandlungen 'statische Tests' genannt wird, dann sollten die wohl auch zum 'Testen' gehören.--VÖRBY 12:51, 21. Dez. 2010 (CET)

Testgetriebene Entwicklung

Der Satz "Bei der testgetriebenen Entwicklung werden die Tests im Zuge der Softwareentwicklung im Idealfall nach jeder Änderung ausgeführt" müsste genauer heißen: "Bei der testgetriebenen Entwicklung werden die Tests im Zuge der Softwareentwicklung im Idealfall vor und nach jeder Änderung ausgeführt".

Qelle: Testgetriebene_Entwicklung (nicht signierter Beitrag von Phayn (Diskussion | Beiträge) 23:31, 18. Feb. 2010 (CET))

Usability und Benutzer-Tests sollten erwähnt werden

Dass der Begriff Usability nirgends auftaucht, ist leider symptomatisch. Neben formalen Testverfahren sind Benutzer-Tests notwendig, um herauszufinden, ob die Software überhaupt das leistet, was der Anwender von ihr möchte, und ob er mit der Software zurechtkommt. Dafür müsste man aber mit echten Menschen reden, was viele Softwareentwickler ungern tun ;-) -- Nichtich 11:02, 5. Okt. 2010 (CEST)

Steht unter Nicht-funktionale Tests. Wie so oft wird zwar eine gute Gebrauchstauglichkeit gefordert, aber selten konkretisiert. So kann ein Test der Gebrauchstauglichkeit nur subjektiv ablaufen. Um eine Software zu erstellen die das leistet was der Benutzer möchte, braucht man vor allem ein gutes Anforderugnsmanagement. --Avron 14:46, 5. Okt. 2010 (CEST)

Weblink Glossar Testbegriffe

Hallo, ich hatte mich beim Eintrag des Weblinks beim Glossar bewusst für die Seite von imbus entschieden, weil das Glossar vom ISTQB absolut nicht convenient ist. Das pdf liest doch so kein Mensch. Das Glossar von imbus gibt es Deutsch/Englisch, ich kann filtern, es hat interaktive Links, übersichtliche Reiter und kann noch als pdf ausgedruckt werden. Es ist außerdem umfassender als das ISTQB Glossar. Der Vorstand Tilo Linz von imbus ist gleichzeitig Vorsitzender des German Testing Boards und hat an dem ISTQB Glossar mitgearbeitet (siehe Verzeichnis im ISTQB Glossar). Deshalb sollte das imbus Glossar aus meiner Sicht zumindest als Alternative angeboten werden.--LaZeck (Diskussion) 21:43, 1. Jun. 2012 (CEST)

Also so schwer ist das nicht, in einem PDF-Glossar die Begriffe zu suchen. Das Ganze riecht nach Werbung – Du hast rein gar keine berufliche Verbindung zu imbus? Honi soit qui mal y pense. --Mussklprozz (Diskussion) 23:54, 1. Jun. 2012 (CEST)

LaZeck, auch ich empfand und empfinde diesen Link in erster Linie als 'Werbung', was deine beiden letzten Sätze ja auch beweisen. Was du da schreibst, kann ja wohl keine Begründung sein. Offizielle Dokumente sind in WP besser als solche Verweise. Schließlich gibt es viele Unternehmen, die im ISTQB-Board aktiv mitarbeiten. Evtl. könnte man ja bei ISTQB ein Verzeichnis anerkannter 'Träger' einstellen(*), aber hier im Artikel hat das keinen Platz. Das zweimalige Revertieren muss genügen!!--VÖRBY (Diskussion) 09:08, 2. Jun. 2012 (CEST)

(*) Eine solche Mitgliederliste ist bereits in ISTQB Certified Tester über den dortigen Weblink 'German Testing Board e.V.' (dort: 'Mitglieder') aufrufbar. Ein Möglichkeit zur Verbesserung der WP-Enzyklopädie im Thema 'Testen' könnte darin bestehen (das wäre ein Vorschlag von mir an ISTQB_Members), für 'ISTQB' einen eigenen Artikel zu schreiben; bisher ist 'ISTQB' in Wikipedia nur eine Weiterleitungsseite auf 'ISTQB Certified Tester'. --VÖRBY (Diskussion) 09:19, 3. Jun. 2012 (CEST)

QM oder QS?

Im Artikel ist mehrmals die Rede davon, dass Testen Teil des Qualitätsmanagements sei. Da ist wohl eher Qualitätssicherung gemeint. -84.131.210.65

Im weiteren Sinn wird das hier als Synonym gesehen. Aber: QM als übergeordneter Begriff gilt als die gültige Zuordnung, die 'konstruktiven' Maßnahmen etwa ließen sich nur schwer unter 'Qu-Sicherung' einordnen. Wie bei 'Qualität' gibt es auch zu 'Testen' unterschiedlich breite Definitionen, siehe Definition. 'Testen' bedeutet i.w.S. mehr als nur 'Prüfen'. QM kann man also m.E. so stehen lassen. --VÖRBY (Diskussion) 08:53, 3. Mär. 2013 (CET)

Softwaretest vs Test

Von diesem, eine einzelne Testmaßnahme bezeichnenden Begriff ist die gleich lautende Bezeichnung Test (auch Testen) zu unterscheiden, ...

Diese Unterscheidung scheint mir sehr gewagt, da Software im Kompositum einfach das Bestimmungswort ist, um den Test vom Hardwaretest oder Test im Allgemeinen zu unterscheiden. Auch innerhalb des Artikels wird häufig nur Test verwendet, ohne dass auf die genannte Unterscheidung Rücksicht genommen wird. --Siehe-auch-Löscher (Diskussion) 09:48, 18. Jun. 2013 (CEST)

Guten Morgen! Diese umfassendere Definition wird u.v.a. bei Spillner verwendet (siehe Softwaretest#Definitionen, man könnte die Ref auch dort nochmal einstellen. Darüber hinaus merke ich an, dass der ganze Artikel i.W. auf die ganze Disziplin abstellt, nur in Einzelfällen auf den 'einzelnen Test'. Aus diesem Grund hatte ich diesen Hinweis in der Einleitung eingestellt. Im Text kann die konkrete Bedeutung (einzeln oder Disziplin) meist aus dem Zusammenhang erkannt werden. Mit dem Plural 'Tests' ist eigentlich immer eine Menge von Einzelfällen gemeint. 'Testen' dagegen meint die Disziplin. 'Softwaretest' und 'Softwaretesten' wären also zwei verschiedene Begriffe. Für beides wird aber überwiegend 'Softwaretest' benutzt. Und diese Situation findet sich in Lexika und besd auch auch der WP sehr, sehr häufig. Wie man dieses Problem hier lösen könnte, weiß ich auch nicht, m.E. dient diesem Zweck genau der Hinweis in der Einleitung, der Leser wird a von b beim Lesen unterscheiden können. Grüße von --VÖRBY (Diskussion) 10:22, 18. Jun. 2013 (CEST)

Sprachlich kann ich nachvollziehen, dass beim Testen mehrere Tests durchgeführt werden. --Siehe-auch-Löscher (Diskussion) 10:57, 18. Jun. 2013 (CEST)

Nachtrag: 'Software' im Lemma zeigt auf eine spezielle Disziplin von Testen (weniger Test) hin. Testen und Test sind einfach Verb und Substantiv, dein/unser Problem hat also mit 'Software' nichts zu tun!. Was wovon abgeleitet ist, ist mir sprachlich nicht bekannt. Solche Begriffspaare finden sich aber häufig in der WP; wenn ich mich recht erinnere, gibt es sogar in der WP:Hilfe irgendwo eine Aussage dazu - nur eines von beiden zu verwenden. Weiterhin ist es sogar beim Begriff 'Test' als Einzelfall schwierig, ihn abzugrenzen: Wo beginnt und wo endet er? Was gehört (zB an Vorbereitung) dazu? Zählt auch z.B. statistisches Nachbereiten (Teststatistik) zum (einzelnen) Test? 'Testen' ist auch mehr als einfach die Mehrzahl, sondern inhaltlich ist viel mehr darunter zu verstehen; auch wenn es nur 'SW-Test' haißt; siehe Artikel.

Übrigens definiert auch der englische Artikel das Lemma i.S. der gesamten Disziplin, er heißt allerdings 'software testing' und behandelt die engere (und eigentlich unbedeutende, meist nur im Plural auftretende) Definition nicht. In Deutsch 'Softwaretesten' zu sagen wäre allerdings ungewöhnlich.

Will heißen: Neben dem Hinweis auf die beiden Bedeutungen braucht es i.W. keine Unterscheidung. Andernfalls müsste man wohl eine große Anzahl anderer Artikel sinngemäß ebenfalls splitten. --VÖRBY (Diskussion) 11:10, 18. Jun. 2013 (CEST)

ergänzt um en:WP: --VÖRBY (Diskussion) 20:27, 18. Jun. 2013 (CEST)

Anwendungsmonitoring

Bisher werden (nicht nur in diesem Artikel) die Bereiche Softwaretest (zB mit Jenkins) und Systemüberwachung (zB mit Nagios) getrennt dargestellt. In der Praxis gibt es jedoch eine große Überlappung dieser beiden Bereiche.

Leider gibt es zum Wort "Anwendungsmonitoring" noch keinen Wikipediaeintrag.

Dieser Hinweis also nur als Anregung ... Gruß, Thomas (nicht signierter Beitrag von 194.113.71.71 (Diskussion) 09:29, 7. Okt. 2013 (CEST))

Große Überlappung sehe ich nicht. Ein Tool für Systemüberwachung kann sowohl für produktive Überwachung wie auch z. b. bei einem Lasttest mit Testdatenvolumen verwendet werden. --Avron (Diskussion) 20:20, 7. Okt. 2013 (CEST)

Ich sehe da auch nur geringe Zusammenhänge: Natürlich kann man Programme auch beim Softwaretest (zB mit Monitoringmitteln) überwachen. Das wäre dann aber einfach nur eine von vielen Möglichkeiten zum Einsatz von Werkzeugen beim Testen. Ich haben diesen Link im Artikel nachgetragen.--VÖRBY (Diskussion) 16:56, 14. Okt. 2013 (CEST)

Smoketest werden bewusst NICHT nach Zufallsprinzip ausgeführt

Smoketest ist kein zufälliger Test (In Zufallsreihenfolge und Zufallstestfällen), sondern eher kurzer Test. Siehe auch "http://www.softwaretest-umfrage.de/CT_Glossar_DE_EN_V21_sortiert.htm#SmokeTest" aus ISTQB©/GTB Standardglossar der Testbegriffe (nicht signierter Beitrag von 80.226.24.5 (Diskussion) 17:52, 19. Dez. 2013 (CET))

Hallo, Bezeichnungen für Testarten gibt es ja viele - und viele davon meinen ähnliche Sachverhalte. In deiner Quelle wird m.E. ein 'Vorbereitungstest' beschrieben - in der wesentliche Funktionen 'schnell mal' getestet werden. Die im WP-Artikel beschriebene Erklärung für 'Smoke' scheint mir da schon logischer, denn es geht ums 'Abrauchen', während es bei Vorbereitungstests sicher auch um die Korrektheit geht. Insofern wäre deine Quelle nicht präzise. Aber zugegebenermaßen liegt hier eine Ähnlichkeit vor - was aber bei anderen Testartbezeichnungen auch so ist. Vorschlag zur Güte: Bei Smoketest die Aussage 'Zufall' rausnehmen, aber den (wichtigen!) Unterschied zu Vorbereitungstest bestehen lassen. Grüße von --VÖRBY (Diskussion) 18:50, 19. Dez. 2013 (CET)

Hallo zurück ja einverstanden, Zufall ist schon draußen, danke :-) Über alle anderen Begrifflichkeiten lässt sich sowieso trefflich diskutieren, insofern halte ich mich an den am weitest verbreiteten ISTQB - Standard, der auch von den meisten SW-Firmen als Qualifizierung angeboten/ vorausgesetzt wird, wenn man im Softwaretest tätig ist. Auch die WP- Seite "Smoke Testing" erklärt den Begriff kurz und gut. Viele Testarten bzw die Begrifflichkeiten überschneiden sich, d. h. ein mehrmals (in mind. 2 SW-Versionen) ausgeführter Test ist schon ein regressiver Test. Und Smoketest ist ein Vorbereitungstest etc. pp. (nicht signierter Beitrag von 80.226.24.5 (Diskussion) 19:48, 26. Dez. 2013 (CET))

Genauso sehe ich das auch - bezüglich der Überschneidungen von Testartbegriffen. Ja, ein Smoke-Test KANN auch ein Vorbereitungstest sein und umgekehrt, aber es sind eben keine Synonyme (Absturz, Rauch). Wer auch immer diesen Begriff definiert: Mit 'rauchen' sollte er schon irgend etwas zu tun haben - was in der de.WP ja auch der Fall ist. Gruß von --VÖRBY (Diskussion) 11:19, 27. Dez. 2013 (CET)

Testartenklassifikation überarbeiten

Aktuell wurde der Abschnitt 'Klassifikation nach Testumfang' eingefügt - nachdem er vorher bei 'Modultest' eingefügt und hier ([1]) wieder gelöscht worden war; siehe dazu auch die Diskussion. Mit den darin enthaltenen Texten entsteht Redundanz und z.T. Widerspruch zu schon vorhandenen Kapiteln. Ich schlage vor, das ganze Kapitel 'Klassifikation für Testarten' zu überarbeiten und dabei darauf zu achten, dass jede Überschrift eine klare, disjunkte Klassifik-Klasse benennt, in der dann verschiedene Testarten beschrieben sind. Der Abschnitt '.. nach dem Testkriterium' wäre dabei wohl aufzulösen, weil dabei unterschiedlichste Dinge gemeint sind. Dieses Klass-Schema könnte/sollte zunächst in der Diskussion erörtert werden; ich würde das zunächst vorbereiten. --VÖRBY (Diskussion) 11:32, 14. Mär. 2017 (CET); Links ergänzt: --VÖRBY (Diskussion) 13:18, 23. Mär. 2017 (CET)

Ohne Feedback. Dann würde ich mir das mal vornehmen. Zunächst altes Kapitel gelöscht: --VÖRBY (Diskussion) 11:32, 16. Mär. 2017 (CET)

Gelöschtes Kapitel 'Klassifikation nach Testumfang'

Ein Modultest oder Unittest (englisch:

unit test

) testet ausschließlich eine kleinst-mögliche testbare Funktionalität, d. h. ein Modul (

Unit

). Ein Komponententest (englisch:

component test

) testet einen Teilaspekts des zu testenden Systems unter ausschließlicher Verwendung interner Code-Schnittstellen. Der Teilaspekt wird durch Testobjekte von nicht zu testenden Komponenten isoliert. Ein Komponententest testet hierbei lediglich die zu einer Komponente (in vielen Programmiersprachen irreführend als

module

bezeichnet) oder Klasse zusammengefassten Objekte. Will 'Komponente' oder 'Modul' nach einer bestimmten Sicht (Programmiersprache) definieren. Hier im Testartikel ist das kontraproduktiv. Im Artikel bereits behandelt. Ein Integrationstest (englisch:

integration test

) testet die Kommunikationspfade und Interaktionen zwischen mehreren Komponenten eines Systems. Im Artikel bereits behandelt. Ein Schnittstellentest (englisch:

contract test

) testet, ob eine Schnittstelle einen, durch einen Kontrakt definierten, Standard einhält. eine Schnittstelle ist nur ein 'Ort', keine Funktion. Im Artikel bereits behandelt. Ein Ende-zu-Ende-Test (englisch:

end-to-end test

) testet, ob das Gesamtsystem (z. B. von der Benutzerschnittstelle bis zur Datenbank) ein definiertes Verhalten erfüllt. Ein Systemtest (englisch:

system test

) testet, ob eine Menge von Softwaresystemem in einer Testumgebung korrekt miteinander arbeitet. Die Testumgebung muss hierbei möglichst der Produktionsumgebung entsprechen. Schon im Artikel; aber anders definiert Ein Verhaltenstest (

behaviour test

) testet die Anwendung aus der Sicht des Nutzers oder Klientanwendung. Man unterscheidet zwischen:

• Ein Featuretest (englisch:
  feature test
  ) testet eine einzelne, vom Benutzer ausführbare, Funktion.
• Ein Fähigkeitstest (englisch:
  capability test
  ) testet, ob eine vom Benutzer auszuführende Tätigkeit, durch das Ausführen einer Serie von Features, erfüllt werden kann.
• Ein Akzeptanztest (englisch:
  acceptance test
  ) testet, ob die Software eine in der Anforderung definierte Funktionalität oder Eigenschaft erfüllt. Gilt für alle Tests, hat mit Akzeptanz nichts zu tun.

Die im Behavior Driven Development eingesetzte Sprache Gherkin weist hierbei eine abweichende Bezeichnung auf: nicht relevant, zu detailliert

Bezeichnungen in Gherkin

Testart	Bezeichnung
Feature	(When) Step
Fähigkeit	Szenario
Akzeptanzkriterium	Feature

<references>

Neue Struktur des Hauptkapitels

Derzeit Workversion, die ggf. diskutiert werden kann. Wenn diese 'steht', können die dazugehörenden Testarten in der jeweiligen Überschrift einsortiert werden. Reihenfolge ggf. neu ordnen. Im Wesentlichen ist also zu tun:

• Zuordnen der oben in #Klassifikation nach Testumfang beschriebenen Testarten in die u.a. Klassifikationsklassen
• Testarten aus 'Klassifikation nach dem Testkriterium' (ist nichtssagend) ebenfalls aufteilen in andere Klassen.
• Dabei jeweils ggf. neue Klassen erkennen und benennen sowie Testarten zuordnenn

• Nach der Prüftechnik: kann mit Unterkapiteln vorlfg bleiben wie er ist
• Aus ISO-Qualitätsmerkmalen abgeleitete Testarten - kann bleiben
• Zum Testen ausgewählte methodische Ansätze - kann bleiben
• Aus der Art (und dem Umfang) des Testobjekts - ggf. zwei getrennte Unterkapitel?
• Zeitpunkt der Testdurchführung - kann bleiben
• nach der Testintensität - kann bleiben
• Informationsstand über die zu testenden Komponenten
• wer die Tests ausführt oder spezifiziert - wie bisher
• nach der Art der Softwaremaßnahme - wie bisher
• ... ggf. weitere?

Während der Überarbeitung wurde die Struktur z.T. anders gegliedert. Siehe Neufassung. --VÖRBY (Diskussion) 12:39, 21. Mär. 2017 (CET)

Notizen aus der Kapitel-Überarbeitung

Kapitel angelegt: --VÖRBY (Diskussion) 11:32, 16. Mär. 2017 (CET)
Vorbereitung der Struktur: --VÖRBY (Diskussion) 12:37, 16. Mär. 2017 (CET)

Ich habe die Üerarbeitung in dieser Workdatei vorgenommen. Will sie noch überprüfen und dann das Kapitel im Artikel ersetzen. --VÖRBY (Diskussion) 20:02, 20. Mär. 2017 (CET)

Überarbeitung wie in der Einleitung zu #Neue Struktur des Hauptkapitels beschrieben abgeschlossen. Inhalte aus dem gelöschten Kapitel (s.o.) wurden zum Teil übernommen, andernfalls wurden Anmerkungen (in small) direkt im Disk-Text ergänzt. --VÖRBY (Diskussion) 12:39, 21. Mär. 2017 (CET)

In Kürze Übernahme in den Artikel; oder gibt es noch Feedback? --VÖRBY (Diskussion) 15:37, 22. Mär. 2017 (CET)

Übernahme in den Artikel: --VÖRBY (Diskussion) 10:42, 24. Mär. 2017 (CET)

Seitenzahl für Quelle zum Phasenmodell

Hallo,

kennt jemand die Seitenzahlen aus dem Buch, auf die sich im Abschnitt "Testprozess / Testphasen" der Text und die Abbildung zum Phasenmodell nach Pol, Koomen und Spillner bezieht? Folgende Wikipedia-Quelle enthält keine Angabe zur Seitenzahl und ich konnte es auf Anhieb nicht im Buch finden: https://de.wikipedia.org/wiki/Softwaretest#cite_note-PKS-1. Vielen Dank!

Vielen Dank --Sumpfbefreier (Diskussion) 16:35, 5. Apr. 2018 (CEST)

Hallo, ich hatte die Aussagen aus dem genannten Buch verwendet. Leider ist dieses nicht mehr in meinem Besitz, es wurde m.W. später auch neu aufgelegt, vielleicht mehrfach oder auch unter anderem Titel. Bei Gelegenheit möchte ich nochmal recherchieren und den Text ggf. aktualisieren. --VÖRBY (Diskussion) 10:55, 6. Apr. 2018 (CEST)

Das Buch hat lt. IHV 544 Seiten, Kap. 8.1 beschreibt den Testprozess. --VÖRBY (Diskussion) 12:55, 6. Apr. 2018 (CEST)

"Softwareentwicklung vs. Industrie"

Ohne Referenz oder Belege steht am Anfang des Beitrags:

"Und: „Beim Testen in der Softwareentwicklung wird i. d. R. eine mehr oder minder große Fehleranzahl als 'normal' unterstellt oder akzeptiert. Hier herrscht ein erheblicher Unterschied zur Industrie: Dort werden im Prozessabschnitt 'Qualitätskontrolle' oft nur noch in Extremsituationen Fehler erwartet.“"

• Definiere "normal"...
• Definiere "mehr oder minder große Fehleranzahl"...

Qualitätskontrolle ist auch kein Prozessabschnitt per se sondern eine kontinuierliche Aktivität. Hier wird "Industrie" mit "Softwareentwicklung" verglichen. Das ist Äpfel mit Birnen. Qualität in der Softwareentwicklung ist dann noch zusätzlich eine eigene Situation, siehe hierzu auch https://de.wikipedia.org/wiki/Softwarequalität oder Normen wie ISO 25010.

Der Text sollte vereinfacht werden und auf den Punkt gebracht werden. Es gibt zig Publikationen in IET, IEEE, ACM, Wiley, ScienceDirect, Springer, etc. die Inhalte zu Software Quality Assurance, SW Testing, SW Quality und der "Fehleranzahl" haben. Man könnte dann auch auf https://de.wikipedia.org/wiki/Programmfehler verweisen, dort "Fehlerfreiheit" oder auch https://de.wikipedia.org/wiki/Release_early,_release_often Oder man nähert sich dem Thema mehr philosophisch: https://medium.com/@akifev/is-there-such-a-thing-as-bug-free-software-8215fe19053c oder https://softwareengineering.stackexchange.com/questions/239210/theoretically-bug-free-programs

Zusätzlich könnte man noch auf den Führung/Management zu sprechen kommen, z.B. hier https://saucelabs.com/blog/7-reasons-your-testing-strategy-hasnt-reduced-your-bug-count

Oder bei Sicherheit "Industrie" auf z.B. https://de.wikipedia.org/wiki/Liste_von_Programmfehlerbeispielen

Fazit ich würde den Satz ganz streichen. Was soll damit genau ausgesagt werden? Extremsituationen müssen in Projekten definiert werden (Risikomanagement), z.B. in Real-Time und dann müsste man von Sicherheit (Safety) sprechen bzw. erwähnen. --LS (Diskussion) 11:42, 1. Sep. 2020 (CEST)

Es ist nicht gut formuliert; es ist damit wohl gemeint dass es im Allgemeinen akzeptiert wird, dass eine Software Fehler hat, welche wenn sie gefunden werden, in einer neuen Version gefixt werden. Im Gegensatz dazu kann Hardware nicht so einfach gefixt werden; wenn bei einem Top der Henkel nach dem ersten Kochen abfällt, dann ist es halt Schrott. Wobei die Akzeptanz der Fehler bei Software mit der Kritikalität der Anwendung zusammenhängt. So wird akzeptiert dass ein Textverarbeitungsprogramm einen Fehler hat und abstürzt. Bei einer Software im Flugzeug wäre das hingegen tödlich.--Avron (Diskussion) 11:58, 1. Sep. 2020 (CEST)

Die oben kritisierte Aussage ist belegt, sie ist ein Zitat von "Pol, Koomen, Spillner (Quelle PKS)".--VÖRBY (Diskussion) 12:07, 1. Sep. 2020 (CEST)

Teststufe vs Testzyklus

"Die Einordnung der Teststufen (auch Testzyklen genannt)". Das wäre mir neu. Ein Testzyklus kann aus meiner Sicht die Tests aller Stufen enthalten. Ein Testzyklus ist lt. ISTQB "Eine Testprozess-Instanz für eine bestimmte Version eines Testobjekts." --2001:16B8:2AD9:7C00:38C3:CD18:D1FE:3468 09:54, 25. Mär. 2021 (CET)

"... bestimmte Version eines Testobjekts" - das entspricht also der Bedeutung von 'Teststufe', synonym 'Testzyklus'. Dass zwischen Instanz und Typ häufig nicht unterschieden wird, ist bei Prozessen oft zu beobachten; siehe auch Geschäftsprozess.--VÖRBY (Diskussion) 10:23, 25. Mär. 2021 (CET)

Nach meiner Auffassung ist eine "Version" (z.B.) ein Inkrement bei einer inkrementellen SW Entwicklung. Dieses Inkrement durchläuft normalerweise beim Test alle Teststufen. In einem älteren Glossar vom ISTQB (2014) ist der Testzyklus wie folgt definiert: "Durchführung des Testprozesses für ein einzelnes bestimmtes Release des Testobjekts.". --2001:16B8:2AD9:7C00:38C3:CD18:D1FE:3468 10:44, 25. Mär. 2021 (CET)

Die Definitionen gelten nicht für eine bestimmte Vorgehensweise (zB die inkrementelle). Selbst dort werden wohl niemals 'alle Teststufen' durchlaufen, sondern nur die, die für das jeweilige Release in der Testprozess-Definition vorgesehen sind. Die ISTQB-Definition bezieht sich auf ein solches ('bestimmtes') Release - gültig für alle Testobjekte und gilt damit als Synonym für Teststufe.--VÖRBY (Diskussion) 11:42, 25. Mär. 2021 (CET)

Selbstverständnlich werden in größeren Projekten alle Teststufen durchlaufen. Ich nenne jetzt noch einen Literaturvweis: "Die beim Test nachgewiesenen Fehlerwirkungen müssen je nach Fehlerklasse beseitigt werden und ein erneuter Test wird notwendig. Oft entstehen auch Zyklen, wenn beim Test von Änderungen weitere Fehlerwirkungen entdeckt werden, die es zu beseitigen und dann erneut zu testen gilt. Es ist unrealistisch, keine solchen Korrekturzyklen einzuplanen, da dann davon ausgegangen wird, dass keine Fehlerwirkungen im Test nachgewiesen werden, die zu beheben und in einem weiteren ->Testzyklus zu testen sind." A.Spillner - Basiswissen Softwaretest Seite S. 32. Auch im Glossar dieses Buches (S. 267) werden die beiden Begriffe klar unterschieden. Mir ist es prinzipiell egal, ob das in dem Artikel so falsch bleibt. Aber zumindest habe ich darauf hingewiesen. (nicht signierter Beitrag von 2001:16B8:2AD9:7C00:9929:E838:A020:110B (Diskussion) 12:31, 25. Mär. 2021 (CET))

Ja, i.d.R. werden 'alle Teststufen (Mehrzahl) durchlaufen. Eine einzelne davon testet gem. Definition im Testprozess den Reifegrad der Testobjekte. Das schließt natürlich auch Testwiederholungen (nochmal Auszuführendes = Zyklus) für einzelne Testobjekte ein - um die Ziele der Teststufe zu erreichen. Die dabei erforderlichen Tätigkeiten kann man allgemeinsprachlich auch Zyklus nennen (Duden: Folge zusammengehöriger Vorgänge). Das wäre dann aber eine andere Bedeutung, und etwas anderes als das Synonym von 'Teststufe'. Die Definitionen von ISTQB, siehe {https://www.german-testing-board.info/wp-content/uploads/2016/08/CT_Glossar_DE_EN_V23.pdf}, beschreiben mit Testzyklus wohl eher diese abweichende Bedeutung. Ich denke aber, man sollte im Artikeltext erwähnen, dass Zyklus und Stufe nur zum Teil synonym verwendet werden - und dass mit 'Testzyklus' (allgemeiner) auch die im Testprozess vorgesehene Tätigkeitenfolge für ein einzelnes Testobjekt innerhalb einer bestimmten Teststufe (= Release), bei Fehler ggf. mehrfach auszuführen, gemeint sein kann. Danke für den Hinweis. --VÖRBY (Diskussion) 13:40, 25. Mär. 2021 (CET)