Qualitätssicherung ab welcher Projektgröße
-
Dann kann ich wohl davon ausgehen, dass in unserer Firma was fehlt.
-
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.
