Hallo,

mich würde interessieren wie ihr das in eure Firma mit Qualitätssicherung haltet. In manchen Firmen ist Qualitätssicherung ja das Auffinden von Fehlern die beim Kunden aufgetreten sind und dann daraufhin erst ausgemerzt werden. So wird es z.Z. bei uns gemacht. Leider wird da aber der Kunde mit schlechter Software bestraft und zum Betatester degradiert.
In letzter Zeit hatten wir häufiger das Problem das unausgereifte Software zum Kunden oder in die Produktionsstrasse geraten ist. Wir Programmierer hatten natürlich mit besten Wissen und Gewissen gehandelt. Dennoch haben Fehler in der Programmierung zu erheblichen Verlusten geführt.
Also was macht ihr um Qualität zu garantieren? Mindestens 24h Stresstestverfahren? Betatester einstellen? Checkliste abarbeiten? Muß natürlich alles noch bezahlbar bleiben.

lemming

Hi Lemming,

ich erstelle für meinen AG eine Auftragsverwaltung. Da wir das Teil deshalb auch selbst einsetzen, habe ich einen wunderbaren "Beta"test. Zudem habe ich 3 weitere Büros, bei denen ich die Software ebenfalls vorab einsetzen lasse, wenn die bei uns einige Wochen ohne Probleme gelaufen ist. Allerdings ist auch das mehr als unbefriedigend, da immer noch zu viele Fehler durchrutschen.

Ich habe versucht unsere Azubis als Betatester einzusetzen, war aber auch nicht besonders erfolgreich.

Da ich für das nächste Release die Applikation überarbeite und umbauen werde, will ich versuchen mit Bubelen oder DUnit einen automatischen Softwaretest einzubauen um wenigstens den größten Teil der Appl durch automatische Tests abzudecken.

Grüße
Lemmy

Man kann auch sehr viel selbst testen. Es ist nicht schwer. Nur machen muß man es.

Als erstes sollte man eine Checkliste erstellen mit möglichen Fehler-Punkten. Als simples Beispiel wäre her die Tabulator-Reihenfolge. Da die Elemente nach und nach auf dem Formular plaziert werden, stimmt oft die Reihenfolge nicht. Solche Punkte also auf eine Liste setzten und nach Beendigung der Programmierarbeiten testen. Das hört sich erst einmal sehr simpel an, man glaubt aber nicht wie schnell solch Punkte übersehen werden. Und welche Punkte sind das? So einfach ist das nicht. Es gib zwar Fehler-Punkte die für alle Programmierer gelten, aber auch Punkte die nur für einen Bereich gelten, z.B. Datenbanken. Am besten sollten sich alle in der Firma zusammen setzten und alle Fehler sufschreiben die vorkommen können. Am besten über den Zeitraum von zwei bis drei Wochen paar mal zusammen setzen. Manche Punkte fallen einem erst nach paar Tagen ein. Diese Liste gilt dann für alle Arbeiten der Firma, nicht nur den einen Auftrag.

So findet man schon 2/3 aller Fehler, ohne überhaupt mit den Beatatests angefangen zu haben.

Ein zweiter wichtige Punkt ist der Beta-Zeitpunkt. Bist zu diesem Datum kann der Kunde noch seine Wünsche äußern, danach nicht mehr. Das muß man ihm klar machen und den Zeitpunkt muß man auch dem Kunden mitteilen. Er kann nicht bis Ultimo mit seinen Wünschen ankommen. Irgendwann ist Schluß. Ist der Beta-Zeitpunkt ereicht, dann wird die Software nur noch geprüft. Es wird nicht mehr programmiert, sondern nur noch nach Fehlern gesucht. Das können auch die Programmierer auch selbst machen.

Ist die Fehlersuche der Programmierer vorbei, sollte das Programm theoretisch ohne Fehler sein.

Jetzt kommen die Firmentests. Hier kommen Programmiererkollegen drann, die an dem Programmierung nicht beteidigt waren und keine Ahnung haben wie das Programm funktioniert. Die fangen jetzt wild auf dem Programm rumzuklicken, bzw. machen Sachen die der Programmierer nie machen würde, z.B. zuerst Button B drücken und dann erst Button A. Schon stellt sich heraus, daß es bei dieser Reihenfolge eine Fehlermeldung gibt. Zuletzt kann man das Programm von Personen die absolut keine Ahnung haben was die da machen, also keine Programmierer.

Was noch wichtig ist: die Tests sollten schriftlich festgehalten werden. Nicht einfach über den Tisch rufen was man gefunden hat, sondern alle Fehler notiern; mit Uhrzeit, wann der Fehler aufgetreten ist und was die Folge war.

Erst dann sollte man das Programm an den Kunden weitergeben, jedoch mit dem Hinweis, daß es sich immer noch um eine Beta-Version handelt. Eine Betaversion, die man zwar Tests unterzogen hat und die wahrscheinlich keine Fehler mehr enthällt, aber immer noch nicht im Produktionsprozes eingesetzt werden sollte, sondern erst von Mitarbeitern getestet werden. Und wenn man denen seine Betaberichte vorlegt, dann sehen sie, daß man bereits viel getestet hat. Falls Fehler noch gefunden werden, dann weiß der Kunde, daß es eher eine Außname ist.

Mit dieser Art von Tests hatte ich immer gute Erfahrungen. Ob es andere Firmen auch so machen, weiß ich nicht.

Übrigens, was noch sehr wichtig ist, daß ist die Dukumentation des Programms. Das kann man durchaus auch im Programm machen. Wichtig dabei ist der Kopf jeder Funktion. Auch wenn es Mehrarbeit ist, so sollte bei jeder Prozedur der Zweck, die Parameter und die Rückgabewerte beschrieben werden. Ist für spätere Fehlersuche nicht unwichtig.

Was aber ganz wichtig ist, daß sind die schriftlichen Regeln nach denen man testet. Wenn es keine Checklisten gibt oder keine Regeln die eingehalten werden, dann ist jeder gefundene Fehler ein Zufallstreffer. Der Unterschied zwischen einem Qualitäts Management und Test die man ausführt ist der, das man beim QM nach festgeschriebenen Regeln testest. Man kann dem Kunden immer vorweisen was man gemacht hat. Wenn man wild testet, dann kann es auch vorkommen, daß man alle Fehler findet, aber man kann nicht nachvolziehen was man wann mal getestet hat. Ohne schriftlichen Ablaufplann hat man kein QM in der Firma.

Qualitätssicherung im Betrieb? ... wer bezahlte das den noch gleich... *g
Im allgemeinen halten Praktikanten oder Auzubis dafür her. Wie gesagt, die meisten Dinge kann man bereits im Vorfelde abfangen. Ich notiere mir bei der Entwicklung stellen an denen Eingaben getätigt werden und mache ne kurzes 1 Min-Brainstorming, was alles falsch laufen könnte. Ist das Programm fertig, arbeite ich diese Liste ab und Falscheingaben zu vermeiden (Keine reelen Zahlenzulassen, keine negativen, Stimmen die längen etc.). Danach setze ich die Auzubis darauf an, sie sollen einmal alles ausprobieren, also am besten alle möglichen Aktionen einmal durchzutesten. So schafft man es meist recht gut, dass die gängigen "Trampelpfade", die der Nutzer geht relativ festgetreten sind und keine bösen Überraschungen mehr erwartet. Sofern vorhanden und eine weitere bessere Person zur Verfügung steht, gehe ich mit dieser (Also ein Entwickler und ein unbeteiligter) die Software durch um eventuelle Manipulationsschwachstellen auszunutzen. Also keine zufälligen, sondern gezielt böswillige. Gerade wenn das ganze im Webbereich eingsetzt wird ist es erstaunlich, was man dort alles noch zu Tage fördert, aber auch in Applikationen, bei gezielter falsch Eingabe...
Bei einer Lagerverwaltung oder sowas wird dann noch einmal ein Simulation durchgeführt in dem ich die Auzubis dran setze und den Schrank einpflegen lasse. Der Testlauf sollte dann eigentlich fehlerfrei verlaufen. Meist sinds eher Oberflächenfehler, die dann noch zum tragen kommen. Bei Software, die viel mit Berechungen arbeitet, gibts auch meistens noch Test mit zufällig generierten Startwerten und einer Kontrolle am Ende, ob auch alles wie erwartet verarbeitet wird. (Zyankalie bereithalten, fast plötzlich bei 100 Durchläufen irgendwo ein Wert falsch ist... ==> viele Überstunden)
Und gerade bei wichtigen projekten lohnt es sich auch das Personal noch ein wenig zu Schulen in Bezug auf "Was mache ich, wenn ein Fehler auftritt. Was sollte ich notieren, was sollte ich machen, was nicht? Welche Fehler sind unwichtig, welche fatal?" ... nicht das die auf die Idee kommen bei einem nicht gespeicherten Kommentar den Server neuzustarten...

Danke fuer eure Anregungen. Ich habe jetzt ein System in meiner Firma ausgearbeitet das glaube ich so nicht schlecht sein wird. Zunaechst werden wir jede Woche eine Entwicklerkonferenz abhalten. Darin werden die Fortschritte in den einzelnen Projekten erlaeutert und dann ueber moegliche Fehlerquellen diskutiert. Das was dabei raus kommt, kommt auf eine Checkliste. Die bekommt der Programmierer und arbeitet diese ab.
Zudem bekommen nach der Konferenz alle Beteiligten die neuste Version des Programmes zum testen. Jeder investiert im Laufe der Woche eine halbe bis ganze Stunde darin um neue Fehler zu finden. Ich erhoffe mir dadurch Fehler aufzudecken die der Programmiereer auf seinen Testpfaden nicht ausprobiert hat.
Wird ein Fehler gefunden fuellt man ein Formular in Outlook aus und schickt es an den Programmierer. In diesem Formular steht uhrzeit, Versionsnummer, Projektname, Fehler und Reproduktionsbeschreibung. Alle Formulare die der Entwickler erhaelt kann er selber in seinem Outlook verwalten und nach und nach abarbeiten.

Ich melde mich in ein, zwei Monaten nochmal und gebe bescheid in wie weit es sich verbessert hat.

lemming