Qualitätssicherung ab welcher Projektgröße
-
Es muß ja keine extra Abteilung für die QS geben. Eine Abteilung kann auch zwei Aufgaben übernehmen. Nur muß man dann dieser Abteilung Zeit für QS einräumen.
Ich kann mir nicht vorstellen, das jemand eine Software entwickelt, und nicht testet? Rein instinktiv will doch jeder wissen, ob es gut ist, was da fabriziert wurde.
-
Nein. Leider geht das nicht. Schon gar nicht wenn beide Parts von derselben Abteilung uebernommen werden. DEVs und QEs muessen wie Katz und Hund sein.
-
Apollon schrieb:
Nein. Leider geht das nicht. Schon gar nicht wenn beide Parts von derselben Abteilung uebernommen werden. DEVs und QEs muessen wie Katz und Hund sein.
ACK
-
Apollon schrieb:
Nein. Leider geht das nicht. Schon gar nicht wenn beide Parts von derselben Abteilung uebernommen werden. DEVs und QEs muessen wie Katz und Hund sein.
ach was, QA muss auch jeder selbst uebernehmen. Das faengt schon beim programmierstil an. eine gesonderte QA abteilung ist dafuer da, um nicht so triviale fehler zu finden und das produkt auf herz und nieren zu pruefen. aber in erster linie ist man selbst fuer seine arbeit verantwortlich und sollte somit seine strengste QA sein.
-
Interessant, dass Du "sollte" verwendest. Und jetzt sei mal ehrlich dir selbst gegenueber: bist Du kritisch genug, was deine Arbeit angeht?
-
rapso schrieb:
ach was, QA muss auch jeder selbst uebernehmen. Das faengt schon beim programmierstil an. eine gesonderte QA abteilung ist dafuer da, um nicht so triviale fehler zu finden und das produkt auf herz und nieren zu pruefen. aber in erster linie ist man selbst fuer seine arbeit verantwortlich und sollte somit seine strengste QA sein.
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.
-
rapso schrieb:
Apollon schrieb:
Nein. Leider geht das nicht. Schon gar nicht wenn beide Parts von derselben Abteilung uebernommen werden. DEVs und QEs muessen wie Katz und Hund sein.
ach was, QA muss auch jeder selbst uebernehmen. Das faengt schon beim programmierstil an. eine gesonderte QA abteilung ist dafuer da, um nicht so triviale fehler zu finden und das produkt auf herz und nieren zu pruefen. aber in erster linie ist man selbst fuer seine arbeit verantwortlich und sollte somit seine strengste QA sein.
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. 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.
Es stimmt natürlich das QS schon im Design beginnt (-> Design for testeability) und das der Entwickler auch gewisse Basistests selber machen muß, aber wenn die QS vom entwickler gemacht ist, nun, früher nannte man das "Den Bock zum Gärtner machen".
-
Apollon schrieb:
Interessant, dass Du "sollte" verwendest. Und jetzt sei mal ehrlich dir selbst gegenueber: bist Du kritisch genug, was deine Arbeit angeht?
aber natuerlich bin ich das, wenn ich hier scheisse einchecken wuerde, dann koennte die halbe firma nicht arbeiten. Und selbst wenn ich mir 100% sicher bin das alles richtig laeuft, gibt es dann immer nen fallback, sodass man z.b. features abschalten kann und so jeder den vorherigen zustand wiederherstellen kann. wenn die QA fehler findet, dann sind das schon spezielle dinge z.b. graphikkarte xyz mit treiber 53465.345654 hat fehlende polygone oder sowas. aber selbst um sowas zu testen hab ich 4rechner untem tisch stehen.
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.
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.
... 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.
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.
-
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.
-
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.
