Hallo Thorsten, -------- Original-Nachricht -------- > Von: Thorsten Ziehm <[email protected]>
> > Die Präsentation hat mehrere Teile. Einmal dass was sich hinter > Qualitätssicherung für Software verbirgt (mit Links zu Wiki-Seiten) > und welche Aufgaben die QA-Projekt leistet. Du hast Recht, dass > vielleicht nicht genau beschrieben ist, wie das QA-Projekt Einfluss > auf die Qualität des Produktes nehmen kann. Leider kann keine Präsentation alles beinhalten, was zu einem konkreten Thema gehört. Deshalb ist es schwer zu beurteilen, ob nicht aufgezeigte Punkte einfach keinen Platz mehr hatten oder ob Sie generell in der Betrachtung fehlen. Was mir in der Präsentation fehlt ist der Bereich von Qualitätssicherung "außerhalb" des Testens. Dieser existiert - die genannten Links und Beschreibungen der Präsentation haben aber einen sehr starken Fokus auf "Testing". Zwei Links, die nicht in der Präsentation enthalten ist: http://en.wikipedia.org/wiki/Software_quality_assurance http://satc.gsfc.nasa.gov/assure/agbsec3.txt Hier liegt der Fokus der QA nicht (allein) auf dem Produkt, sondern auf dem Prozess. Wenn es also Probleme im Release Engineering, bei der Abstimmung mit Entwicklern, internen Dokumentationen ... gibt, wäre die QA durchaus gefragt, das zu bemerken und zu eskalieren. Einige dieser Aufgaben werden auch jetzt schon von der QA innerhalb OOo wahrgenommen. Wie gesagt - es ist nicht leicht festzustellen, ob das einfach keinen Platz in der Präsentation hatte. > > > Das ist eigentlich schade, da QA mehr bedeuted, als > > "Software testen" und Mitarbeit bei Featureimplementierung. > > Software testing ist Teil von Quality Assurance. Quality Assurance > bedeutet aber nicht, Behebung von Fehlern! Korrekt. Der (aus meiner Sicht) nächste logische Schritt, nach dem Feststellen von Fehlern ist aber die Organisation der Fehlerkorrektur. Bezieht man QA nur auf das Produkt, liegt das außerhalb der Zusständigkeit des QA-Teams, denn es ist klar in der Zuständigkeit der Entwickler. Bezieht man QA aber auf den Prozess, ist diese Koordination klar der Verantwortung der QA - denn wenn es kein definiertes Bindeglied zwischen "fehler Gefunden" und "so wird er korrigiert" gibt, ist der Prozess defekt. Aus Sicht des Projektes gibt es dieses Bindeglied im Moment eher nicht. Es funktioniert an vielen Stellen trotzdem, da sich QAler und Entwickler kennen - das kann man aber nicht Prozess nennen. ... > > Nochmals in anderen Worten. > Die Qualitätssicherung deckt Fehler aus und priorisiert sie. Sie > ist nicht dafür zuständig die Fehler zu beheben. Dies ist nicht > nur bei uns so, sondern in allen Bereichen wo es eine Qualitätssicherung > gibt. > > Das was dem QA-Projekt am Ende fehlt ist, die Macht zu sagen, ein > Produkt nicht freizugeben. Nein, ich glaube nicht, dass uns diese Macht fehlt (bzw. dass wir *genau* diese benötigen). Wenn wir einmal bei Release-Freigabe angelangt sind, ist es eh zu spät. Was fehlt ist die bessere Koordination mit den Entwicklern, wie Fehler effizient korrigiert werden können. Gruß, André PS.: Achso - es ist ja immer recht offensichtlich, dass eine Fehlerkorrektur Aufwand bedeuted. Evtl. sollte man mal untersuchen, was uns offene Fehler an Aufwand kosten. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
