Hallo,
mich würde mal interessieren, wie in großen Firmen die Software getestet
und freigeben wird. Beispielweise bei Bosch, wo große Softwareprojekte
bearbeitet werden, muß ja sicherlich ein aufwendiges Freigabeprozedere
erfolgen, bevor die Software im KFZ zum Einsatz kommt.
Hat da jemand Infos darüber ?
Bei uns in der Firma (20 MA) werden nur die verschiedenen Funktionen
getestet, dann erfolgt eine Freigabe für die Serie. Die vielen
Anwendungskombinationen, die im Feld vorkommen können, werden hierbei
nicht mal näherungsweise abgedeckt. Das zeigt sich dann auch z.B. , wenn
nach 2 Jahren ein Kunde einen Anwendungsfall hat, der nicht sauber
abgefangen ist.
Hier sollen neue Methoden eingeführt werden, um die Software besser
austesten zu können.
Danke für Eure Tips !
Tja es ist wohl bei größeren Firmen so, dass es einen Analysten gibt,
der die Software auf saubere Form und lesbarkeit überprüft. Wenn nicht
gegeben, darfste dich nochmal dransetzten. Somit ist zumindest schonmal
gewährleistet, dass die Nachfolgerschaft das Projekt weiterhin betreuen
kann.
Alle möglichen Anwendungsfälle sollten in einem Fluss/Zustandsdiagramm
abgedeckt und alle Laufwege durchgetestet werden. Der Kunde verlässt
sich schliesslich darauf, dass seine Anforderungen an das
Laufzeitverhalten erfüllt werden.
Entweder jemanden einkaufen der eine Ahnung von Softwaretests hat oder
mal jemanden ordentlich darin schulen. So wie das klingt habt ihr für
eure Unternehmensgröße beängstigend wenig Ahnung von richtigem Testen.
Da gibts nicht umsonst mittlerweile komplett eigene Themenkomplexe im
Informatikstudium dafür, die nicht ohne sind und leider von viel zu
wenigen Leuten belegt werden (Das ist btw. noch erschreckender wenn man
sich die Fachinformatikerkollegen anschaut, da gibts Leute kennen
maximal Unittests, und die auch nur dem Namen nach...*argh*).
Als Einführung:
http://en.wikipedia.org/wiki/Software_Testing
und hier insbesondere
http://en.wikipedia.org/wiki/Code_coverage
zum Thema "Wie decke ich alle Kombinationen ab und muss ich das
wirklich?"...
Grüße
tester
Bosch arbeitet m.W. gem. CMMI (http://de.wikipedia.org/wiki/CMMI).
Darin geht es nicht um das Testen als solches, sondern um den
gesamten Enwicklungsprozeß - was bei euch wahrscheinlich dann auch
das Problem ist, wenn es erst beim Testen auffällt.
CMMI ist mit Sicherheit ein paar Nummern zu groß für eine
kleine Bude, aber einen Blick ist es wert, weil viele sinnvolle
Ansätze drin stecken. Leider kostest es signifikant Zeit, sich
das zu verinnerlichen.
Neben CMMI gibt es noch etliche weitere Ideologien, Entwicklung
zu betreiben mit vielen Vor- und Nachteilen (das erwähnte V-Modell,
agile SW-Entwicklung, etc.).
Der Test alleine wird aber immer zu kurz greifen. Letztlich steht
und fällt alles mit einer planvollen Vorgehensweise, was je nach
Firma sehr unterschiedlich ausfallen wird.
Aber wenn erst zum Schluß etwas herumgetestet wird, ohne daß
schon im Pflichtenheft steht, wie der Test auszusehen hat,
fehlt irgendetwas.
PS: Die meisten Modelle geben die Prozesse mehr oder weniger genau vor.
CMMI ist insofern etwas anders gelagert, als es eine Stufe höher
ansetzt und aussagt, was man beachten muß, um sich seine eigenen
Prozesse zu schaffen. Das kann dann im konkreten Fall jede andere
Philosophie mit einschließen, oder etwas ganz neues schaffen.
Hallo,
ich denke, dass auch bei Bosch nicht alle Bereiche nach CMMI und
Lehrbuch arbeiten. Auch dort wird nur mit Wasser gekocht. Meine
Erfahrung ist, dass auch in großen Unternehmen oft im Bereich des
Testens gespart wird da viele Projekte mit engen Zeitplänen hinterlegt
sind und der Nutzen des Testens noch nicht weit genug in die Köpfe
vorgedrungen ist (Stichwort, "haben wir früher doch auch noch nicht
gebraucht und da liefen die Geräte auch" ;-)). Diese Erfahrungen haben
bestimmt auch schon Boschler oder Leute von Siemens gemacht. Wenn man
sich auf Seminaren oder anderen Veranstaltungen mit diesen Leuten
unterhält bekommt man zumindest oft diesen Eindruck. Warum solls denn
auch anders sein. Dort arbeiten die gleichen Leute wie in anderen
Firmen.
Wie Klaus schon schrieb liegen die eigentlichen Ursachen meist schon am
Anfang der Entwicklung, d.h. bei den Anforderungen oder dem
Pflichtenheft. D.h. wenn nicht spezifiziert ist wie etwas funktionieren
soll kann eigentlich auch nicht getestet werden ob etwas funktioniert.
Oft ist es aber auch so, dass ein Kunde zu Beginn garnicht genau weiß
was er überhaupt möchte. Die Anforderungen kommen in meiner Firma z.B.
oft erst beim "Spielen" mit den ersten Mustern. Vorher ist nur ein
grober Funktionsrahmen gegeben der auf der Vergangenheit mit einigen
Neuerungen basiert.
Zum Testen allgemein sollte man zunächst bei den Anforderungen, bzw. der
Anforderungsanalyse anfangen. Oft ist es so, dass sich Anforderungen
auch widersprechen können. Danach sollte ein Design dokumentiert und
reviewed werden. Aus meiner Erfahrung lassen sich hier auch schon einige
Fehler vermeiden. Danach sind denke ich statische Codeanalysen mit z.B.
PCLint noch sinnvoll. Bei den Modul- oder Unit tests sollte man
versuchen dass die Tests möglichst automatisiert per Script ablaufen
können. Ist das nicht der Fall so wird meist die Software nur einmal
ausprobiert und bei Erweiterungen der Software wird aufgrund des hohen
Aufwands kein soldier Regressionstest mehr durchgeführt. D.h.
querreaktionen von Änderungen fallen erst spät auf. Nicht zu vergessen,
sind die Integrationstest, d.h. der Test des Zusammenspiels der Module.
Hier treten meines Erachtens die meisten Fehler auf. Zu guter letzt
kommen noch System und Abnahmetests. Bei allen Tests ist es sinnvoll,
dass sie von verschiedenen Personen durchgeführt werden. D.h. wenn ich
versuche meine eigene Software zu testen finde ich meistens weniger
Fehler als wenn mein Kollege das erledigt. Der Vorteil ist, dass man
hierdurch auch gleich eine Art Review durchgeführt hat.
So, genug getippt...
Gruß,Gonzo
