Diskussion:Review (Softwaretest)

Links

Der Link "Code Review Checklist" führt auf die Startseite einer Beratungsfirma. Das erscheint mir unangemessen, ich plädiere dafür den Link zu streichen.

Grüße, Matt (nicht signierter Beitrag von 193.254.175.108 (Diskussion | Beiträge) 18:13, 6. Jul 2009 (CEST))

Eine solche "Code Review Checklist" hilft doch sehr dabei, sich mit dem Thema auseinander zu setzen. Ich habe den Link der auf die Startseite führt korrigiert, nun erscheint die korrekte Seite. Das Links auf kommerzielle Seiten, wie in diesem Fall eine Beratungsfirma, unangemessen sind, kann ich auch verstehen. Vielleicht ist der Link, der nun auf die inhaltlich korrekte Seite zeigt, doch hilfreicher als die Startseite.

Grüsse - gunggel--Gunggel 11:14, 21. Jul. 2009 (CEST)

Standards

Die definierten Reviews sind nicht nach IEEE 1028. Statt dessen beziehen sich die 4 definierten Reviews (informelles Review, Walkthrough, Peer-Review, Inspection) auf den ISTQB-Standard.

IEEE1028 definiert die formalen Reviews, d.h. die letzten 3 oben genannten, sowie 2 weitere (Audit, Management Review). Die beiden weiteren Reviews sind für das Testen von Dokumenten allerdings nicht besonders wertvoll und daher nicht in den ISTQB-Standard aufgenommen.

Ferner fehlt mir an dem Artikel die Historie des Standards, d.h. zumindest den Vermerk, dass es sich um IEEE1028-1997 handelt.

             Das ist so nicht ganz korrekt, die Reviewtypen in IEEE 1028-1997 sind Management Review, Technical Review, Inspections, Walk-Through und Audit. Das heißt die "zwei weiteren" sind nicht Management Review und Audit, sonder Management Review und Technical Review  Grüße,   Matt (nicht signierter Beitrag von 193.254.175.108 (Diskussion | Beiträge) 14:10, 7. Jul 2009 (CEST)) 

hseebauer

Die Übersetzung des Begriffes "technical review" aus dem Englischen nach "technisches Review" im Deutschen ist problematisch. Im Englischen bezeichnet "technical" so etwas wie zu Deutsch "fachlich, handwerklich" oder auch "formal". Im Deutschen hat sich für "technical Review" der Begriff "fachliches Review" durchgesetzt, der auch eher den Kern der Methode trifft, da hier Fachleute inhaltlich am Dokument arbeiten.

Aussprache

Sollte man eigentlich auf die englische Wortherkunft explizit hinweisen? Und in diesem Zusammenhang auf die Aussprache? Bei der bin ich mir nämlich nicht ganz sicher: Man hört oft "Räwiu" (ich kann leider kein phonetisch), meiner Meinung nach müßte es aber eigentlich "Riwiu" heißen. Gilt es als eingedeutscht, oder nicht? stmnt 15:35, 28. Mai 2008 (CEST)

Geschlecht (grammatisch)

Wie heißt es denn nun richtig? Die Review, das Review oder der Review? Im Artikel wird männlich (was ich ausschließen würde) mit sächlich gemischt (was der gängigen Übersetzung englischer Begriffe ins Deutsche entspricht). Die weibliche Form fand ich im Duden (online).

Doppelte Interwiki-Verlinkung

Warum ist der deutsche Artikel auf zwei englische verlinkt (links)?

http://en.wikipedia.org/wiki/Code_review http://en.wikipedia.org/wiki/Software_review

Wunschdenken vs. Realität

Im Artikel steht: "Für unerfahrene Entwickler bietet der Codereview durch einen erfahrenen Programmierer eine gute Möglichkeit, sich schnell und praxisorientiert weiterzubilden." Dies setzt allerdings voraus, dass ein Entwickler dessen Code reviewt wird, tatsächlich sich als (eher) "unerfahren" betrachtet und daher auch die Bereitschaft zeigt, von einem "erfahrenen" Programmierer auch lernen zu wollen.

Somit ist das in der Theorie schön - in der Praxis stoßen Code-Reviews aufgrund der meist vorherrschenden "Ich bin eh besser!"-Denke auf keine große Resonanz und führen sogar zu Konflikten, die dann wieder völlig Kontraproduktiv sind. (nicht signierter Beitrag von 80.146.185.162 (Diskussion | Beiträge) 10:11, 23. Apr. 2010 (CEST))

Belege für Aussagen in diesem Artikel

"Untersuchungen haben gezeigt, dass mit Reviews 85% der Fehler bei einem Aufwand von 25% gefunden werden können."

Gibt es hierfür Belege? Welche Untersuchungen? Interne Untersuchungen? Wie war die Projekt-Struktur? Wie fand die allgemeine/sonstige Kommunikation in dem Projekt statt?

Auch hier sieht die Realität eher anders aus. Dank moderner Test-Tools und IDE's mit z.b. automatischem Review, kommt bereits zunehmend qualitativ hochwertiger Code raus. Was dazu führt, dass sich Code-Reviews hauptsächlich auf Fachlichkeiten beziehen - Eine Diskussion, die eher in der Requirement-Analyse oder in der Design-Phase stattfinden sollte, statt NACH dem Entwickeln. Das führt wiederum dazu, dass auch von einem ERFAHRENEN Entwickler während des Code-Reviews keine inhaltlichen (semantischen) Fehler gefunden werden. (nicht signierter Beitrag von 80.146.185.162 (Diskussion | Beiträge) 10:11, 23. Apr. 2010 (CEST))

IEEE 610

Hier wird auf IEEE 610 bezug genommen (Formalste Reviewtechnik mit einem dokumentierten Vorgehen nach IEEE 610, IEEE 1028.) Das verstehen ich nicht, da ich nur IEEE610.12 "IEEE Standard Glossary of Software Engineering Terminology" kenne, das hat wohl nichts mit Review zu tun. Wenn das nicht kontreter wird sollte man IEEE610 entfernen. -- UlrichAAB [?] 13:50, 4. Jun. 2010 (CEST)

Einleitung

Hallo Alexander, du hast den nachfolgenden Text eingestellt (von mir geringfügig abgeändert). „Diesen Bereichen zugeordnet sind technische Dokumente wie etwa Readmes, Installationsanweisungen oder Bedienungsanleitungen, aber auch Programme oder Skripte, die für eine Installation gebraucht werden sowie Dokumente mit Informationen und Anweisungen an andere, ähnlich qualifizierte Entwickler um diese zu befähigen den Übersetzungsvorgang der Quellen zu einem späteren Zeitpunkt erfolgreich zu reproduzieren, etwa für ein Bug-Fixing oder eine Weiter-Entwicklung.“
Ich finde, daraus wird nicht klar, was mit 'bei gestellt' (jetzt 'zugeordnet') gemeint ist. Da der Artikel im Kontext 'Softwaretest' steht, sollten solche Dokumente eigentlich dazu dienen, den Code zu überprüfen, vielleicht auch die Dokumente selbst. So wie der Text jetzt aussieht, hat er nicht viel mit 'Testen' zu tun.
Grüße von --VÖRBY 13:21, 9. Jul. 2011 (CEST)

Komposition der unterschiedlichen Reviews

Müsste es nicht nach den Regeln für zusammengesetzte Wörter z.B. "Codereview" anstatt "Code-Review" heißen?DerMh (Diskussion) 15:52, 18. Okt. 2017 (CEST)

Der Bindestrich im zusammengesetzten Wort ist zwar stilistisch unschön, in der Sache aber ist "Codereview" äquivalent zu "Code-Review". Allerdings sind weder "Codereview" noch "Code-Review" laut google gebräuchlich, und im Bereich IT werden englische Fachbegriffe nur selten der Zusammenschreibung zuliebe eingedeutscht. Scrum Master statt Scrummaster, Software Engineer statt Softwareengineer; die englische Schreibweise bleibt bestehen.

Editwar um "Belege fehlen"

@UweJae: und @Schotterebene: - stellen wir mal den Editwar ein und diskutieren hier. --Sebastian.Dietrich  ✉  17:18, 13. Jun. 2021 (CEST)

@UweJae: Du hast mit [1] und Anmerkung "Zum aktuellen Zeitpunkt handelt es sich um eine einseitige Darstellung der Vorteile von Reviews." an mehreren Stellen (auch welche mit Belegen) das "Belege fehlen" Papperl eingebracht. Es ist jetzt nicht ersichtlich, was du eigentlich meinst. Fehlen Belege oder handelt es sich deiner Meinung nach an den Stellen um eine einseitige Darstellung der Vorteile von Reviews?

Darum hab ichs mit Kommentar "Wenn der Artikel wie lt. deinem Kommentar einseitig ist, dann bring die andere Seite ein und stopf ihn nicht mit Papperln voll" rückgängig gemacht.

Du hast das wieder rückgängig gemacht (= WP:Editwar) mit der Anmerkung "Lieber Sebastian, das geht so nicht. Das Anmerken von fehlenden Belegen kann auch erfolgen ohne selbst andere Belege zu kennen.)". Das verwirrt jetzt noch mehr. 1) wo hast du diese Info her oder ist das deine Interpretation der Regeln der WP? 2) Was meinst du mit "andere Belege" - denkst du etwa die Aufgabe der Autoren sei es für von dir behauptete andere Infos Belege suchen zu müssen?

Das wurde wiederum von Schotterebene mit dem Kommentar "Revert - keine Verbesserung" revertiert, was du promt wieder durch eine Zusammenfassung des Papperls für den gesamten Artikel rückgängig gemacht hast. Das Papperl ist hier auf jeden Fall falsch. Der Artikel hat zwei Belege, wenn dir das zu wenig ist, dann kannst weitere bringen. Wennst denkst dass es andere Sichten und Belege dazu gibt, dann kannst dich auf die Suche nach den Belegen machen. Diese Arbeit wird dir niemand abnehmen. Aber Papperln setzen, ist auf jeden Fall der falsche Weg. --Sebastian.Dietrich  ✉  17:32, 13. Jun. 2021 (CEST)

+1 Dieses Baustein-Fallenlassen hier sehe ich in diesem kollaborativen Projekt auch kritisch und eher als Störung. Dahinter steht die Haltung "Ich zeige mit spitzem Finger auf ein Problem - für eine Mitarbeit an einer Lösung bin ich mir aber zu fein" - insbesondere, wenn es von jemand kommt, dessen Beiträge hier überschaubar sind. Diese Bausteine verschandeln oft über Jahre den Artikel, weil die ursprünglichen Autoren längst inaktiv sind. Ich nehme den Baustein jetzt wieder raus und kündigte eine Vandalismusmeldung im Fall einer Wiedereinsetzung an. Grüße, --Schotterebene (Diskussion) 17:58, 13. Jun. 2021 (CEST)

@Sebastian.Dietrich Hallo Sebastian, danke für die Erstellung dieser Diskussion. Die Markierung mit 'Belege fehlen' hatte ich eingefügt, weil an einzelnen Abschnitten die Belege fehlen (meine subjektive Ansicht). Die Abschnitte Erfolgsfaktoren und Reviewprozess sollten mit Nachweisen belegt werden. Die angegebene Quelle für die Statistiken ist ein Vortrag Capers Jones, Chief Scientist Emeritus: Software Quality in 2002: A Survey of the State of the Art. (pdf; 234 kB) Software Productivity Research an Artemis company, 23. Juli 2002, S. 56, abgerufen am 15. Oktober 2013 (englisch) in dem keine Quelle der Statistiken angegeben ist. Der Autor des Vortrags ist sicherlich vertrauenswürdig und sehr kompetent. Aber der Artikel Review (Softwaretest) würde an Qualität gewinnen, wenn Belege ergänzt würden. Leider kenne ich selbst keine geeigneten Quellen, da ich mich noch nicht tiefergehend mit der Theorie Rund um Reviews beschäftigt habe. Schotterebene hatte zurecht angemerkt, dass das Zurücksetzen keine Verbesserung enthält. Daher habe ich die Markierung Belege fehlen Zusammengefasst und zu Beginn des Artikels angegeben. Der Hinweistext zu Belege fehlen enthält ja auch den Hinweis, dass im ganzen Artikel Belege fehlen könnten. Daher ist das sicher hinreichend. Wenn allerdings zwei Reviewer (@Sebastian.Dietrich, @Schotterebene) der Meinung sind, dass die angegebenen Quellen den Hinweis auf fehlende Belge nicht rechtfertigen, dann akzeptiere ich das. (nicht signierter Beitrag von UweJae (Diskussion | Beiträge) 18:49, 13. Jun. 2021 (CEST))

@Schotterebene Dein Kommentar hier ist einfach nur provozierend. Du kennst die Beweggruende, warum ich diesen Artikel markiert habe, nicht. Dein Kommentar "Ich zeige mit spitzem Finger auf ein Problem - für eine Mitarbeit an einer Lösung bin ich mir aber zu fein" stimmt nicht. Mir ist einfach nur das Fehlen von Quellen aufgefallen, als ich den Artikel gelesen habe. Der Hinweis "insbesondere, wenn es von jemand kommt, dessen Beiträge hier überschaubar sind." motiviert richtig sich hier mehr einzubringen. Der Hinweis das Belege fehlen halte ich (aus meiner subjektiven Sicht) nicht für verschandeln. Vor Allem ist ein Hinweis auf fehlende Belege ist nichts, warum sich irgendjemand in seiner Persönlichkeit verletzt angegriffen fühlen sollte. Zudem möchte ich dich bitten eine Vandalismusmeldung zu machen sofern ich mich hier falsch verhalten haben sollte. (nicht signierter Beitrag von UweJae (Diskussion | Beiträge) 19:07, 13. Jun. 2021 (CEST))

Prinzipiell ists irrelevant, welcher Meinung ich oder Schotterebene sind. Für das Einfügen des Papperls gibts Regeln (die mit 100ten Autoren abgestimmt sind) - hier findest du sie: Wikipedia:Belege#Fehlende_Belege. Dort steht "In gravierenden Fällen [...] Einfügen der Vorlage [...]" Um so einen gravierenden Fall handelt es sich bei diesem Thema hier sicher nicht. Hier würde folgendes passen: "Auf der Diskussionsseite sollte man erklären, welche Aussagen belegt werden müssten. Noch besser ist es, selbst nach Belegen zu suchen und sie dann zu ergänzen." - das ist ja jetzt erfolgt.

Ja bei Erfolgsfaktoren und Reviewprozess gibt es keine Belege, das ist sicher verbesserungswürdig. Vielleicht hilft dir ja [2] oder [3] oder dasselbe auf Englisch weiter.

Bei den Statistiken ist der Vortrag vom Capers Jones sicher gut genug. Die Quelle für seine Statistiken nennt er gleich auf der 2ten Seite des Vortrags ("SOURCES OF SPR’S QUALITY DATA") - und auch ohne das genannt zu haben wäre die Reputation des Autors schon genug um den Vortrag als für die WP würdige Quelle anzuerkennen. Klar wärs toll hier noch mehr zu haben. Steve McConnels Code Complete hat lt. https://www.agilesparks.com/blog/peer-code-review-benefits-and-statistics/ was dazu - werds mal einfügen. Über Google findet man sicher noch mehr.

@UweJae: - wenn dir also bei irgendeiner Seite in der WP Stellen auffallen, die nicht bzw. nicht gut genug belegt sind (davon gibts leider Millionen von Stellen - aber weit weniger als in anderen WP-Sprachen oder etwa in anderen Enzyklopädien), dann setz das Papperl nur in gravierenden Fällen (z.B. vermutete Falschaussagen auf Artikeln zu Themen in der Presse). Ansonsten ignoriers einfach (weil es ja für jeden Leser klar ersichtlich ist, dass da keine Quellen vorhanden sind), oder - besser - schlag mal in Google nach, ob sich nicht mit 1min. Aufwand gute Quellen finden lassen, die man mit 5min. Aufwand in den Artikel einbauen kann. --Sebastian.Dietrich  ✉  09:02, 14. Jun. 2021 (CEST)