Qualitätssicherung ab welcher Projektgröße
-
xindon schrieb:
Zum Beispiel grad bei grafischen Oberflächen kommen Nicht-Entwickler auf die wildesten Ideen, wie man was anklicken kann, was ich als Entwickler niemals tun würde. Deswegen würde ich mich nicht auf Entwicklung und QS in einer Person verlassen.
ja, wenn schon das design seltsame dinge zulaesst bzw faelle nicht vorsieht ist das eigentlich schlecht, schlimm ist wenn sowas erst der QA-abteilung auffaellt. sowas sollte schon ein programmierer oder lead programmierer erkennen und dem design melden. und gerade deswegen ist eben jeder wichtige QA, nicht nur die QA abteilung.
-
rapso schrieb:
skals schrieb:
Entwickler Testen ihren eigenen Code immer um zu zeigen das er funktioniert. (Gute) Tester dagegen testen den Code um zu beweisen, das er nicht geht.
und ein (Guter) entwickler versucht moeglichst alle von seinen aenderungen beeinflussten dinge zu testen, nicht nur die funktionierenden cases heraus zu picken.
Das ist unrealistisch. Es mag vielleicht bei Software von ueberschauberer Groesse funktionieren, aber wenn es um verteilte Systeme geht, die dazu auch noch in verschiedenen Umgebungen laufen muessen, dann ist es fuer den Entwickler unmoeglich "alle von seinen aenderungen beeinflussten dinge zu testen".
rapso schrieb:
Als Entwickler hast Du eine ganz andere Sichtweise auf den Code und testest auch anders. Der Tester sieht den Code dagegen aus den Augen des Anwenders und findet so meistens Fehler, die Du als Entwickler nicht mal als Fehler wahrnimmst.
Ich sag ja nicht, dass tester ueberfluessig sind, jedoch sind sie bei weitem nicht so gut im testen wie der entwickler selbst. das es sie trotzdem gibt liegt einfach daran, dass man als entwickler nicht die zeit hat den ganzen tag die software zu nutzen um dann unstimmingkeiten zu finden. dafuer gibt es tester.
Die QA ist viel mehr. QA ist eine Kontrollinstanz. Sie sorgt dafuer, dass Bugs nicht als Features durchgehen.
rapso schrieb:
... aber wenn die QS vom entwickler gemacht ist, nun, früher nannte man das "Den Bock zum Gärtner machen".
nein, die sichtweise trifft nicht zu. denn auch die QA kann nur das was man ihr beibringt, und von wem weiss sie wie die software sein soll? natuerlich von den entwicklern.
Nein. Das weiss sie vom Kunden, bzw. aus den Requirements- und Design-Dokumenten.
rapso schrieb:
Genau. "Wer ist für Qualität verantwortlich?" -- "Jeder selbst!" niemals "Die Qualitätssicherung". Die QS definiert vielleicht Abläufe an die sich die Entwickler zu halten haben und setzt die auch durch. Letztlich ist Qualität aber nichts was man von außen drüberlegen kann.
stimm ich zu. die QA sollte im optimalfall nur noch verifizieren dass alles richtig ist.Das uebernimmt wieder eine andere Abteilung. Aber optimal waere es schon, ja.
-
Apollon schrieb:
Das ist unrealistisch. Es mag vielleicht bei Software von ueberschauberer Groesse funktionieren, aber wenn es um verteilte Systeme geht, die dazu auch noch in verschiedenen Umgebungen laufen muessen, dann ist es fuer den Entwickler unmoeglich "alle von seinen aenderungen beeinflussten dinge zu testen".
das haengt wieder eher mit softwaredesign zusammen damit das ueberschaubar bleibt.
Die QA ist viel mehr. QA ist eine Kontrollinstanz. Sie sorgt dafuer, dass Bugs nicht als Features durchgehen.
ja eben, QA soll verifizieren dass das programm stimmt, nicht erst bugs suchen die ein entwickler haette finden muessen.
Nein. Das weiss sie vom Kunden, bzw. aus den Requirements- und Design-Dokumenten.
nein, die kunden wissen nicht wie software zu testen ist. sie wissen eventuell die entanforderungen, aber bugs zu tracken wird der QA von den entwicklern beigebracht.
Das uebernimmt wieder eine andere Abteilung. Aber optimal waere es schon, ja.
diese abteilung nennt sich QA
-
Jester schrieb:
Die QS definiert vielleicht Abläufe an die sich die Entwickler zu halten haben und setzt die auch durch.
Das nennt sich Qualitätsmanagement und ist was anderes als die Qualitätssicherung, die diese Prozesse ausführt.
-
rapso schrieb:
Apollon schrieb:
Das ist unrealistisch. Es mag vielleicht bei Software von ueberschauberer Groesse funktionieren, aber wenn es um verteilte Systeme geht, die dazu auch noch in verschiedenen Umgebungen laufen muessen, dann ist es fuer den Entwickler unmoeglich "alle von seinen aenderungen beeinflussten dinge zu testen".
das haengt wieder eher mit softwaredesign zusammen damit das ueberschaubar bleibt.
Na gut. Ersetzen wir Ueberschaubarkeit durch Komplexitaet.
rapso schrieb:
Die QA ist viel mehr. QA ist eine Kontrollinstanz. Sie sorgt dafuer, dass Bugs nicht als Features durchgehen.
ja eben, QA soll verifizieren dass das programm stimmt, nicht erst bugs suchen die ein entwickler haette finden muessen.
Und wieder ein "haette".
rapso schrieb:
Nein. Das weiss sie vom Kunden, bzw. aus den Requirements- und Design-Dokumenten.
nein, die kunden wissen nicht wie software zu testen ist. sie wissen eventuell die entanforderungen, aber bugs zu tracken wird der QA von den entwicklern beigebracht.
Och glaub mir, die Kunden wissen ganz genau wie Software zu testen ist.
Ich weiss ja nicht was ihr fuer eine QA habt, aber bei uns besteht sie ueberwiegend aus Dipl. Infs. Es muss uns also kein Dev beibringen wie man Bugs findet und meldet. Zumal wir ein Hauseigenes Tool zum Bugtracking einsetzten, welches die QA geschrieben hat
-
Ich denke einer der Ansatzfehler ist es zu glauben, es sei die Aufgabe der QS Programmierfehler zu finden. Das ist schlicht falsch. Der entwickler sollte selber dafür Sorge tragen das seine Routinen auch einwandtfrei funktionieren. Wenn Programmierfehler regelmässig erst in der QS auffallen, dann läuft etwas anderes schon falsch...(Im Zweifelsfall macht der Programmierer dann einfach seinen Job nicht richtig)
QS steht für Qualitätssicherung. Um etwas zu sichern muß man es messbar machen. Also ist die erste Frage woran man Qualität einer Software meßbar macht. Da es eigendlich Ziel jedes Softwarehauses sein sollte möglichst fehlerfreie Software zu produzieren kann die Anzahl der "Bugs" allein eigendlich kein ausreichendes Meßkriterum sein. Oder hat einer von Euch mal eine z.B. Autowerbung gesehen wo damit geworben wurde, daß das Auto weniger Produktionsfehler hat als ein vergleichbares Produkt der Konkurrenz? Und wenn ihr so eine Werbung sehen würdest, wäre das für euch wirklich ein Kaufargument?
Fehlerfreiheit ist also kein Qualitätskriterium, sondern eine Vorraussetzung dafür das man eine Software überhaupt verkauft. Als Kunde setze ich vorraus das ich ein funktionierendes Produkt erwerbe. Punkt. Qualität einer Software definiert sich für mich als Kunden über ganz andere Kriterien.
Wie benutzerfreundlich ist das Interface, kann ich es Intuitiv bedienen? Wie gut ist das Handbuch? Passt da Handbuch überhaupt mit den Features zusammen? Wie flüssig läuft das programm? Hat es entscheidende Features die ich brauche? Wie verhält sich das Programm bei Fehlbedienung und vor allem, sind die Meldungen bei Fehlbedienung ausreichend um den Benutzer dabei zu unterstützen diese Fehlebedienung zu erkennen?
Ich denke, da kommt noch mehr zusammen, aber das alles zusammen macht am Ende die Qualität einer Software aus.
-
esmald schrieb:
Oder hat einer von Euch mal eine z.B. Autowerbung gesehen wo damit geworben wurde, daß das Auto weniger Produktionsfehler hat als ein vergleichbares Produkt der Konkurrenz? Und wenn ihr so eine Werbung sehen würdest, wäre das für euch wirklich ein Kaufargument?
Eigentlich schon, das ist sogar üblich, das machen alle, die Testsieger in der Pannenstatistik sind. Das ist letztlich genau die Aussage "besser geplant und gebaut, daher weniger Pannen=Bugs".
-
Apollon schrieb:
rapso schrieb:
Apollon schrieb:
Das ist unrealistisch. Es mag vielleicht bei Software von ueberschauberer Groesse funktionieren, aber wenn es um verteilte Systeme geht, die dazu auch noch in verschiedenen Umgebungen laufen muessen, dann ist es fuer den Entwickler unmoeglich "alle von seinen aenderungen beeinflussten dinge zu testen".
das haengt wieder eher mit softwaredesign zusammen damit das ueberschaubar bleibt.
Na gut. Ersetzen wir Ueberschaubarkeit durch Komplexitaet.
ergaenze design explizit mit "sauberem design mit guter kapselung und durchdachten schnittstellen"
rapso schrieb:
Die QA ist viel mehr. QA ist eine Kontrollinstanz. Sie sorgt dafuer, dass Bugs nicht als Features durchgehen.
ja eben, QA soll verifizieren dass das programm stimmt, nicht erst bugs suchen die ein entwickler haette finden muessen.
Und wieder ein "haette".
jo, da waeren wir wieder bei der qualitaet des entwicklers, je schlechter der entwickler, desto besser muss die QA sein (wohl sogar ueberproportional) damit die qualitaet erhalten bleibt.
rapso schrieb:
Nein. Das weiss sie vom Kunden, bzw. aus den Requirements- und Design-Dokumenten.
nein, die kunden wissen nicht wie software zu testen ist. sie wissen eventuell die entanforderungen, aber bugs zu tracken wird der QA von den entwicklern beigebracht.
Och glaub mir, die Kunden wissen ganz genau wie Software zu testen ist.
und du glaub mir, sie haben keine ahnung wie man einen bug trackt.
-
Moderne Qualitätsmanagement-Systeme begleiten den Weg eines Produktes beginnend bei einer Kundenforderung über die Entwicklung, Herstellung, die gesamte Nutzungsdauer beim Anwender bis hin zur Entsorgung bzw. zum Recycling. Tests auf Fehlerfreiheit und Beschäftigung mit Reklamationen sind o.k., aber genau genommen nicht der optimale Ansatz. Besser ist die Fehlervermeidung von Anfang an, also Vorbeugemaßnahmen.
-
esmald schrieb:
Ich denke einer der Ansatzfehler ist es zu glauben, es sei die Aufgabe der QS Programmierfehler zu finden. Das ist schlicht falsch. Der entwickler sollte selber dafür Sorge tragen das seine Routinen auch einwandtfrei funktionieren. Wenn Programmierfehler regelmässig erst in der QS auffallen, dann läuft etwas anderes schon falsch...(Im Zweifelsfall macht der Programmierer dann einfach seinen Job nicht richtig)
ganz mein reden
QS steht für Qualitätssicherung. Um etwas zu sichern muß man es messbar machen. Also ist die erste Frage woran man Qualität einer Software meßbar macht. Da es eigendlich Ziel jedes Softwarehauses sein sollte möglichst fehlerfreie Software zu produzieren kann die Anzahl der "Bugs" allein eigendlich kein ausreichendes Meßkriterum sein.
das sieht man bei software auch etwas weicher als bei anderen dingen, oft verzichtet man auch auf irgend ein feature weil es zum release nicht fehlerfrei oder nach wunsch lief. bei z.b. PKW kannst du nicht einfach so auf nen tankdeckel verzichten weil er bei 200km/h abfliegt.
-
Für mich klingt das so, wie wenn hier Qualitätssicherung mit sorgfältigem Arbeiten verwechselt würde.
Natürlich muß jeder Entwickler selbst für maximale Qualität sorgen, u.a. durch die bekannten Mittel:
- gutes Design
- eigene Tests
- Kommunikation mit KollegenErsetzt das eine Qualitätssicherung? Auf keinen Fall.
Es ist klar, daß man den Qualitätsregelkreis möglichst kurz halten muß, d.h. was ein Entwickler bemerken kann, sollte er auch bemerken und abstellen dürfen.
Paradoxerweise kann es sein, daß selbst bei fehlerfreier Anlieferung aller Einzelteile das Gesamtteil immer noch nicht funktioniert.
Weiterhin kommt dazu noch das in diversen psychologischen Spielchen bestätigte Prinzip, daß man selbst für seine eigene Arbeit der am ungeeignetste Tester ist. Das wurde hier schon erwähnt, das liegt einfach daran, daß man selbst bei der Entwicklung (von egal was) das eigene Bild im Kopf hat, welches das real vorhandene Konstrukt überlagert. Daher ist man bei Abweichungen der Realität vom gedachten Zustand betriebsblind und extrapoliert sein Gedankenbild in die Realität. Das abzustreiten wäre naiv, da allgemein akzeptiert und seit Jahren bekannt - innerhalb der Industrie, aber auch in der Softwareentwicklung. Solche Ideen wie Pair-Programming beruhen ja gerade auf diesem Problem.
Das beste Beispiel aus dem Alltag ist für jeden nachvollziehbar die Sache mit der Rechtschreibung. Man sieht eigene Rechtschreibfehler einfach nicht. Dafür muß man die Fehlerursachen unterscheiden:
a) basierend auf Wissenslücken, wenn ich glaube, daß das Wort "Maschiene" geschrieben wird, so werde ich diesen Fehler niemals bemerken (können) - bis mich jemand von außerhalb darauf aufmerksam macht und mir diesen Fehler abtrainiert
b) basierend auf Ausführungsfehlern (aka "Tippfehlern"), man schreibt aus Versehen einen Buchstabendrehre und kann diesen nicht wahrnehmen, weil man innerlich "sieht", daß das Wort richtig da steht. Dies wird sogar stärker, wenn das Wort nicht zur eigentlichen Hauptebene des Textes gehört, sondern zu einer weniger "wichtigen" Ebene - da nimmt die Aufmerksamkeit noch mehr ab
Solche Effekte haben bereits vor vielen Jahren dazu geführt, daß man über Korrekturleser und Qualitätssicherer Texte mehrfach überprüft, um sie möglichst fehlerfrei zu machen. Extrembeispiel ist hier das Rechtschreibkorrektorat, jemand der überhaupt keine Ahnung von dem Thema hat, aber nur die Schreibung überprüft.
Solche und ähnliche Dinge sind eingeführte und erprobte Verfahren, die bei weniger komplexen Themen als Softwareentwicklung bereits notwendig sind. Es erscheint mir daher außerordentlich fragwürdig, daß Softwareentwickler ohne zusätzliche Kontrollschleife dies bewerkstelligen können - es müssen ja wahre Übermenschen sein. Ich schließe nicht aus, daß es solche Teams gibt, die völlig ohne Zusatzkontrolle absolut fehlerfrei arbeiten, aber halte das für extrem unwahrscheinlich und werde daher den normalen Entwicklungsalltag immer so planen, wie wenn ich nicht mit Übermenschen zu tun hätte ("real working processes for real people").
Zusätzlich denke ich mir, daß Entwickler viel zu teuer sind, um QS zu betreiben. QS hat etwas von Experimentalwissenschaft, man muß destruktive Fallen aufstellen und Testszenarien konstruieren, aber auch mit Kunden und Anwendern diskutieren und daraus die Fehlerbilder ableiten. Aber vom Entwickler verlangt man, daß er sich mit neuesten Softwaretechniken auskennt, APIs beherrscht, usw, und stellt dies durch teure Weiterbildungsmaßnahmen sicher. Will ich nun, daß dieser Mann 30% seiner Zeit auch noch testet, wo er dieses spezielle Wissen gar nicht einbringen kann? Dafür qualifiziere ich lieber jemand speziell für "professionelle Fehlersuche" mit eigenem Fachwissen.
Auch kann die QS-Sicherung Defizite bei einzelnen Programmierern erkennen, wenn jemand systematisch immer wieder gleiche und ähnliche Fehler verursacht, ist hier gezielt eine Schulung möglich.
Unter dem Strich spricht dies alles dafür, daß man QS mit einem Personalstamm in einer eigenen Abteilung betreibt, und versucht die Entwickler produktiv einzusetzen, was diese nicht von der Pflicht entbindet, möglichst fehlerfrei zu arbeiten.
Btw - aus diesem Grund bin ich auch nie wirklich glücklich, wenn ich gezwungen bin Softwarearbeiten an externe Einzelentwickler abzugeben. Ich frage mich da immer, wer das Zeugs eigentlich getestet hat... außer mir.
-
Marc++us schrieb:
Ersetzt das eine Qualitätssicherung? Auf keinen Fall.
kann die QS ein defizit in einem dieser punkte kompensieren? auch auf keinen fall. deswegen ist es eine "sicherung" und kein "auf fehler auflaufen".
Marc++us schrieb:
Paradoxerweise kann es sein, daß selbst bei fehlerfreier Anlieferung aller Einzelteile das Gesamtteil immer noch nicht funktioniert.
wenn das jedem bewust ist, wieso testet das nicht jeder als teil des ganzen bevor er das eincheckt? dafuer hat man hochbezahlte leute und keine coder-aeffchen, damit sie nachdenken und selbststaendig arbeiten und nicht nur stumpfe protokolle erfuellen.
und nein, das ist nicht zu aufwendig, denn wenn eine person mal nen tag sein modul vor dem einchecken testet ist es weniger verlustreich als wenn mal die halbe firma die von diesem modul abhaengt nicht arbeiten kann... verhindern kann man das nicht 100%ig, das ist klar, aber einfach nur die kleine welt des eigenen "einzelteils" zu sehen ist eine grundkompetenz eines entwicklers.
So laeuft es in allen brangen, nicht nur der softwareentwicklung. wieso soll man beim programmieren davon ausgehen "ach, wenn es schieffgeht werden sie sich schon bei mir melden", es erwartet doch auch kein PKW-tester, dass er den wagen wohl nicht starten koennen wird weil es aus sooovielen teilen besteht die alle fuer sich gut sind, aber so zusammengebaut niemand verantworten kann dass es laufen muss.Weiterhin kommt dazu noch das in diversen psychologischen Spielchen bestätigte Prinzip, daß man selbst für seine eigene Arbeit der am ungeeignetste Tester ist. Das wurde hier schon erwähnt, das liegt einfach daran, daß man selbst bei der Entwicklung (von egal was) das eigene Bild im Kopf hat, welches das real vorhandene Konstrukt überlagert. Daher ist man bei Abweichungen der Realität vom gedachten Zustand betriebsblind und extrapoliert sein Gedankenbild in die Realität. Das abzustreiten wäre naiv, da allgemein akzeptiert und seit Jahren bekannt - innerhalb der Industrie, aber auch in der Softwareentwicklung. Solche Ideen wie Pair-Programming beruhen ja gerade auf diesem Problem.
gleichzeitig waere es naiv zu behaupten dass irgendjemand besser ein modul testen koennte als der entwickler dieses "einzelteils". dazu muss man nichtmal studien anstellen. die QA kann dann natuerlich noch weitere dinge finden fuer die man eventuell blind war, aber auch das ist eine qualitaet eines entwicklers.
a) basierend auf Wissenslücken, wenn ich glaube, daß das Wort "Maschiene" geschrieben wird, so werde ich diesen Fehler niemals bemerken (können) - bis mich jemand von außerhalb darauf aufmerksam macht und mir diesen Fehler abtrainiert
gegenbeispiel: jemand muss eine wichtige presentation machen
a) er hofft dass irgendeiner seiner probleser ihn auf diesen fehler hinweist
b) er hat die proffesinalitaet eine rechtschreibpruefung schon vorher drueber laufen zu lassenb) basierend auf Ausführungsfehlern (aka "Tippfehlern"), man schreibt aus Versehen einen Buchstabendrehre und kann diesen nicht wahrnehmen, weil man innerlich "sieht", daß das Wort richtig da steht. Dies wird sogar stärker, wenn das Wort nicht zur eigentlichen Hauptebene des Textes gehört, sondern zu einer weniger "wichtigen" Ebene - da nimmt die Aufmerksamkeit noch mehr ab
deswegen kennt ein hochbezahlter entwickler diverse techniken um auch solche fehler zu minimieren, z.b. text wort fuer wort rueckwaerts lesen und so kontextlos die woerter zu identifizieren (neben rechtschreibpruefungssoftware).
Solche Effekte haben bereits vor vielen Jahren dazu geführt, daß man über Korrekturleser und Qualitätssicherer Texte mehrfach überprüft, um sie möglichst fehlerfrei zu machen. Extrembeispiel ist hier das Rechtschreibkorrektorat, jemand der überhaupt keine Ahnung von dem Thema hat, aber nur die Schreibung überprüft.
ja, die person sichert die qualitaet, sie ueberprueft ob es richtig ist. das lektrorrat ist aber nicht dafuer da, dass du einfach worter reinschreibst wenn du dir unsicher bist wie sie geschrieben werden, sondern fuer die fehler die dir entgangen sind. das impliziert dass du jeden fuer dich selbst erkennbaren fehler auch schon gefixt hast. (notfalls unter zuhilfenahme von werkzeugen wie z.b. duden)
Solche und ähnliche Dinge sind eingeführte und erprobte Verfahren, die bei weniger komplexen Themen als Softwareentwicklung bereits notwendig sind. Es erscheint mir daher außerordentlich fragwürdig, daß Softwareentwickler ohne zusätzliche Kontrollschleife dies bewerkstelligen können - es müssen ja wahre Übermenschen sein.
es geht nicht um perfekte software, denn wenn es diese gebe, dann haette schon jemand gemerkt dass die QA nicht noetig ist. es geht darum dass ohne die QA schon software gemacht wird, die man normal nutzen kann. die QA ist dann dafuer da um weitere ungereimheiten zu klaeren. wie "bei genau 212km/h gab ich so ein resonanzgeraeusch gehoert am ruckspiegel".
Zusätzlich denke ich mir, daß Entwickler viel zu teuer sind, um QS zu betreiben. QS hat etwas von Experimentalwissenschaft, man muß destruktive Fallen aufstellen und Testszenarien konstruieren, aber auch mit Kunden und Anwendern diskutieren und daraus die Fehlerbilder ableiten. Aber vom Entwickler verlangt man, daß er sich mit neuesten Softwaretechniken auskennt, APIs beherrscht, usw, und stellt dies durch teure Weiterbildungsmaßnahmen sicher. Will ich nun, daß dieser Mann 30% seiner Zeit auch noch testet, wo er dieses spezielle Wissen gar nicht einbringen kann? Dafür qualifiziere ich lieber jemand speziell für "professionelle Fehlersuche" mit eigenem Fachwissen.
das haengt von fall zu fall ab, manchmal ist der tester der bestbezahlte, weil er so hochqualifiziert sein muss, dass er das entwickelte voll ausnutzen kann. (z.b. F1 rennfahrer). manchmal ist es gleich, und manchmal, bei z.b. software oder hygiene artikeln, kostet es die firma oft nur porto.
aber da gibt es ebenfalls unterschiede, es gibt einfache "es ist abgestuerzt" tester, es gibt "wenn ich das und das mache, dann stuerzt es immer an dieser stelle ab" und es gibt "ich hab alle module nacheinanader durchgetestet, es stuerzt in xyz ab, es ist erst seit version 3425 so, vermutlich haengt es mit .. zusammen und laut changelog kann man den bug an mickeymouse assignen" und entsprechend die verguetung.Auch kann die QS-Sicherung Defizite bei einzelnen Programmierern erkennen, wenn jemand systematisch immer wieder gleiche und ähnliche Fehler verursacht, ist hier gezielt eine Schulung möglich.
genau das sollte aber nicht der fall sein, das sollte ein entwickler ebenfalls erkennen und daran arbeiten sein defizit auszumerzen.
Btw - aus diesem Grund bin ich auch nie wirklich glücklich, wenn ich gezwungen bin Softwarearbeiten an externe Einzelentwickler abzugeben. Ich frage mich da immer, wer das Zeugs eigentlich getestet hat... außer mir.
mach dir das leben einfacher und angagier eine externe testfirma. dann weisst du genau wie die qualitaet ist und musst dich nicht auf hoffnung verlassen.
-
rapso schrieb:
Btw - aus diesem Grund bin ich auch nie wirklich glücklich, wenn ich gezwungen bin Softwarearbeiten an externe Einzelentwickler abzugeben. Ich frage mich da immer, wer das Zeugs eigentlich getestet hat... außer mir.
mach dir das leben einfacher und angagier eine externe testfirma. dann weisst du genau wie die qualitaet ist und musst dich nicht auf hoffnung verlassen.
Danke, dieser Nachsatz erspart mir die Gegenargumentation zu Deinem Beitrag, da er im Widerspruch zu Deinen eigenen Aussagen steht.
Aber ansonsten wimmelt es in Deinem Beitrag von Aussagen, die im krassen Widerspruch zu der gesammelten Industriepraxis von vielen Jahrzehnten stehen - nicht nur im Bereich Software.
Nimm nur das Beispiel wichtige Präsentation - sowas lässt man immer probelesen. Das ist auch viel effektiver gearbeitet.
Das beste Beispiel ist eigentlich - das gilt sehr oft, wenn die präzise Ausführung von Dingen erforderlich ist - das Militär. Wesentliche Schritte werden hier immer von einer zweiten Person kontrolliert. Militärische Vorgehensweisen haben etwas sehr lehrreiches, da hier viele 100 Jahre Erfahrung im systematischen Vorgehen vorliegen.
Auch so Dinge wie Defizite selbst erkennen ist ja gar nicht möglich, das sollte Dir doch einleuchten: wenn Du etwas nicht kennst, wie kannst Du dann selbst entdecken, daß es Dir fehlt? Dafür benötigst Du einen externen Feedback-Geber. Externes Feedback ist schon deswegen notwendig, weil nur ein Außenstehender die vorhandene Situation ohne Emotionen analysieren kann. Jemand innerhalb der Problemwelt wird selbst zum Stakeholder des Projekts, und kann daher einige Probleme nicht mehr unabhängig erkennen. Dafür ist die Außensicht notwendig, die z.B. über Rückmeldung aus QS/QA kommen kann. Der Entwickler selbst kann das nicht leisten.
Und das hier:
gleichzeitig waere es naiv zu behaupten dass irgendjemand besser ein modul testen koennte als der entwickler dieses "einzelteils". dazu muss man nichtmal studien anstellen.
ist eine Einzelmeinung von Dir. Klar, gestehe Dir das zu, falsch und richtig ist immer schwer zu sagen, aber Dir sollte wenigstens klar sein, daß Du Dich damit gegen 99.99% aller Aussagen im Software Engineering und im Engineerung stellst, wo genau das Gegenteil als beste Maßnahme gefordert wird.
Auch das verwunderlich, wenn Dir das nicht auffällt, das liegt doch daran, daß der Entwickler einen selbstgemachten Fehler teilweise nicht erkennen kann, sonst hätte er ihn ja nicht gemacht. Wenn der Entwickler den Fehler begangen hat, dann glaubt er bei gewissen Fehlerklassen, daß dies richtig sei, und kann daher gar keine Testfälle konstruieren, die das falsifizieren, weil er dazu den richtigen Weg kennen müßte.
Wie gesagt, kann sein, daß in Eurer Firma alle so genial sind, daß jeder das selbst im Griff hat, aber das ist weder Industriepraxis noch allgemeine Vorgehensweise, und auch keine Lehrmeinung.
In der Wissenschaft arbeitet man ja auch so, daß jemand etwas entwickelt (eine Theorie), und diese veröffentlicht, und dann wird sie von Dritten geprüft. Diese wissenschaftliche Prinzip ist mehr viele 100 Jahre alt, hat also offensichtlich seinen Nutzen bewiesen. Wieso man davon freiwillig abweichen sollte, ist mir schleierhaft.
-
Marc++us schrieb:
Danke, dieser Nachsatz erspart mir die Gegenargumentation zu Deinem Beitrag, da er im Widerspruch zu Deinen eigenen Aussagen steht.
ja, deine voidaussage ist sehr fundiert.
Aber ansonsten wimmelt es in Deinem Beitrag von Aussagen, die im krassen Widerspruch zu der gesammelten Industriepraxis von vielen Jahrzehnten stehen - nicht nur im Bereich Software.
so ging es mir bei deinem beitrag auch.
Nimm nur das Beispiel wichtige Präsentation - sowas lässt man immer probelesen. Das ist auch viel effektiver gearbeitet.
ja, nachdem man alle fehler beseitigt hat die man selbst beseitigen kann, wie ich schon sagte.
Das beste Beispiel ist eigentlich - das gilt sehr oft, wenn die präzise Ausführung von Dingen erforderlich ist - das Militär. Wesentliche Schritte werden hier immer von einer zweiten Person kontrolliert.
militaer ist mit einer hierarchy aufgebaut bei der jeder seine verantwortung traegt und kein schiff hat 2 capitaene, zwei erste offiziere usw. militaer ist das gegenteil von qualitaet, da muss man befehle ausfuehren obwohl man sieht dass sie falsch sind, nur selten wird diese regel gebrochen und das muss sein in einem system bei dem das schlimmste waere wenn es gelaemt waere durch uneinigkeit in der entscheidungsfindung.
Auch so Dinge wie Defizite selbst erkennen ist ja gar nicht möglich, das sollte Dir doch einleuchten: wenn Du etwas nicht kennst, wie kannst Du dann selbst entdecken, daß es Dir fehlt? Dafür benötigst Du einen externen Feedback-Geber.
was ist komplett aus dem zusammenhang gerissen, hat dir TGGC nachhilfe gegeben?
du sagst: QA kann sich auf fehler von individuen einstellen und so effektiver arbeiten
ich sage: wenn ein individuum wiederholt den selben fehler bereinigen muss, waere es eine gute qualitaet wenn er diesen fehler abstellen wuerde, statt dass man die QA darauf optimiert auf diesen fehler vorranging zu pruefen und es der person mitzuteilen.Externes Feedback ist schon deswegen notwendig, weil nur ein Außenstehender die vorhandene Situation ohne Emotionen analysieren kann. Jemand innerhalb der Problemwelt wird selbst zum Stakeholder des Projekts, und kann daher einige Probleme nicht mehr unabhängig erkennen. Dafür ist die Außensicht notwendig, die z.B. über Rückmeldung aus QS/QA kommen kann. Der Entwickler selbst kann das nicht leisten.
das haengt vom entwickler ab und da kann man nicht alles ueber einen kamm scheeren. manchen ist die qualitaet wichtiger als seine befangenheit dem projekt gegenueber, weil er weiss das auch die qualitaet ueber das projekt entscheiden, manche sind dann noch penibler als jede QA.
andere wiederrum leben nach dem motto "die QA wird sich schon melden wenn es nicht laeuft" und checken bewust unsichere changes ein.gleichzeitig waere es naiv zu behaupten dass irgendjemand besser ein modul testen koennte als der entwickler dieses "einzelteils". dazu muss man nichtmal studien anstellen.
ist eine Einzelmeinung von Dir. Klar, gestehe Dir das zu, falsch und richtig ist immer schwer zu sagen, aber Dir sollte wenigstens klar sein, daß Du Dich damit gegen 99.99% aller Aussagen im Software Engineering und im Engineerung stellst, wo genau das Gegenteil als beste Maßnahme gefordert wird.
nein, das interpretierst du nur so. worauf du dich beziehst ist lediglich dass menschen eine andere prespektive fehlt wenn sie ein produkt entwickeln und ein unabhaengiger tester mit seiner perspektive vielleicht ganz andere fehler findet.
aber das aendert nichts daran dass der modul-maintainer, weil er sich am besten damit auskennt, auch am besten sein modul testen kann. er weiss die zusammenhaenge am besten, er weiss auch die tragweite seiner arbeit am besten und kann deswegen am besten testen, denn in den meisten faellen testen die QA-tester nur nach den ihnen gegebenen moeglichkeiten die vom entwickler bereitgestellt werden muessen, ansonsten ist das produkt eine blackbox und fuer tester oft auf simpelster ebene nicht bewertbar, ob es den anforderungen genueg. ala "blinkge das licht rot auf []ja/[]nein" -> tester: "hmm war mehr so orange, ach ich kreuz mal ja an"
und auch dazu gibt es studien ohne ende.
Du musst dir das als hierarchy der qualitaet von QA vorstellen
1.entwickler
2.tester
3.automatisches/unittesting
und auch am ende dieser "qualitaets-chain" gibt es noch fehler, nur sind diese dann gering. und jede stufe dieser QA hat weniger beizutragen beim testen, aber immer noch etwas.
deswegen gibt es auch etwas wie pairprogramming, wie du schon darauf verwiesen hast. weil zwei entwickler sehr sehr effektiv arbeiten koennen, viel effektiver als ein entwickler und eine QA abteilung dahinter.Auch das verwunderlich, wenn Dir das nicht auffällt, das liegt doch daran, daß der Entwickler einen selbstgemachten Fehler teilweise nicht erkennen kann, sonst hätte er ihn ja nicht gemacht. Wenn der Entwickler den Fehler begangen hat, dann glaubt er bei gewissen Fehlerklassen, daß dies richtig sei, und kann daher gar keine Testfälle konstruieren, die das falsifizieren, weil er dazu den richtigen Weg kennen müßte.
und wenn der entwickler (sei es der der implementiert oder der der das design macht) die testfaelle nicht spezifizieren kann, dann wird es einem "lektrorats buero ohne ahnung weil total unabhaeangige sichtiweise" auch nicht gelingen diesen testfall selbst herauszufiden.
Wie gesagt, kann sein, daß in Eurer Firma alle so genial sind, daß jeder das selbst im Griff hat, aber das ist weder Industriepraxis noch allgemeine Vorgehensweise, und auch keine Lehrmeinung.
das haengt natuerlich sehr von firma zu firma ab. ich kenne manche firmen bei denen es nach deiner vorstellung laeuft. das cyclen die versionen immer zwischen QA und entwicklern. die bug-datenbanken sind rotz voll mit bugs und jeder entwickler jammert nur dass er keine seit hat soviel zu testen weil er unmengen zu tun hat und er muss es ja auch nicht, weil man doch noch die QA weiter aufstocken wird... und der impact jedes bugs beeinflusst immer mehr leute und ich weiss garnicht wie die in soetwas arbeiten koennen. diese "fire&forget" mentalitaet setzt sich bei denn fest.. "es laeuft, ich checks ein, mal sehen ob jemand meckert"... und so fuehlt sich kaum jemand verantwortlich fuer sein tun, denn "fehler passieren" und wenn 8h um sind, geht man nachhause.
ich hab das glueck in einer moderneren firma zu arbeiten in der bewust das gegenteil verlangt wird, leute die dessen nicht faehig sind, werden hier auch nicht eingestellt. man will ganz bewust responsibility von den leuten fuer ihre arbeit. keine listen und jeder hat bugs die er abarbeiten kann. kein "hier, das hat sich geaendert, koennt ihr ja mal testen ob es laeuft"-mails an die QA.
Wenn man was andert, muss es laufen, falls es doch fehler gibt ist das prioritaet 1 und man supported die person die deswegen probleme hat bis es so ist wie es sein muss. Falls man doch mit stumpfarbeit ueberfordert ist, wird die QA in die pflicht genommen die bereitgestellte version auf die aenderungen hin zu testen (stumpftests) und erst wenn die ihr freizeichen gibt checkt man das ein.
(damit sag ich nicht, dass es keine bug-db gibt, natuerlich gibt es das dahinter noch, aber es ist kein teil des entwicklungs-cycles, sonder nur noch assurance dass das ziel erreicht wurde).In der Wissenschaft arbeitet man ja auch so, daß jemand etwas entwickelt (eine Theorie), und diese veröffentlicht, und dann wird sie von Dritten geprüft. Diese wissenschaftliche Prinzip ist mehr viele 100 Jahre alt, hat also offensichtlich seinen Nutzen bewiesen. Wieso man davon freiwillig abweichen sollte, ist mir schleierhaft.
aber auch bei der wissenschaft veroeffentlich niemand eine theorie sofern er im geringsten zeichen sieht fuer ihre falschheit. erst wenn er selbst davon ueberzeugt ist, ansonsten wuerden sich die leute sehr peinlich machen, weil die moeglichkeit besteht dass am naechsten tag jemand diese theorie widerlegt und der wissenschaftler als "lamer" abgestempelt ist.
und genau diese verantwortlichkeit wird von modernen firmen fuer die eigene arbeit erwartet.
-
Es geht auch ganz anders:
http://www.cleansoft.com/cleansoft_mgrguide.html#SoftwareCleanroom