Diskussion:Review (Softwaretest)

message: 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)
thread_title:  Links 

message: 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)
thread_title:  Standards 

message: 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)
thread_title:  Aussprache 

message: 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)
thread_title:  Wunschdenken vs. Realität 

message: "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)
thread_title:  Belege für Aussagen in diesem Artikel 

message: 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)
thread_title:  IEEE 610 

message: 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)
thread_title:  Einleitung 

message: 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)
thread_title:  Komposition der unterschiedlichen Reviews