Teststrategien, -tools, etc.
-
Hallo,
für Ein-Mensch-Projekte liegt die Minimalantwort doch auf der Hand: Unit-Tests. Kein Code ohne (Unit-)Test. Für ein Softwareprojekt insgesamt natürlich viel zu wenig, da nur auf kleinster Ebene getestet wird, für jeden einzelnen Programmierer aber ungemein wichtig. Der nächste Schritt für ein kleines Projekt wären imo Acceptance-Tests (FitNesse, Avignon...).Manuelle Tests werden zwar noch häufig durchgeführt aber es nicht gerade state of the art.
Was nicht automatisch läuft und beliebig reproduzierbar ist, ist kein Test sondern "ausprobieren"
-
nach jeder änderung an funktionalität ein kurzer, genormter, check im programm vom entwickler. wenn nötig baut der entwickler unit tests (nach ermessen, unit tests sind nicht immer sinnvoll) und liefert sie der QS. die QS testet nach plan. für neue programmversionen werden vorab von der QS teststrategien entwickelt.
denk mal so ähnlich wirds bei verdammt vielen softwareentwicklern ablaufen.
Manuelle Tests werden zwar noch häufig durchgeführt aber es nicht gerade state of the art.
automatisierte tests sind super, wenn es darum geht, bestimmte vorgänge auf konsistentes verhalten zu überprüfen. wenn ich z.b. einen konverter schreibe, dann kann ich konvertierte daten gegen testdaten vergleichen.
aber "usability" lässt sich schwer automatisiert testen. nach meiner erfahrung treten (weil es eben unit tests gibt) in basisfunktionalität sehr selten fehler auf. aber sobald eine software "bedient" wird und nicht vollständig automatisch abläuft (stichwort: benutzeroberfläche) braucht man manuelle tests. die sind immer noch state of the art und verbrauchen (leider) die meiste zeit.
-
Unittest sind ganz nützlich, wenn man Bugs fixt, neue sachen hinzufügt oder was refactort. dann kannman einfach den test nochml laufen lassen und schauen ob die alte funktionalität noch geht. würde ich sogar mehr in größeren projekten sehen, da dort auch andere leute in fremdem code rumbasteln.
kommt wahrscheinlich auch auf projekt an, was man testen kann. bei viel ui sind manuelle test gut, auch von usern die keine ahnung von der ui haben. bei ner echtzeitsteuerung die alle daten über sensoren bekommt kann man sicher viel mehr automatisieren.
meien erfahrung: keine testabteilung, zuwenig unittests, manuelle tests von programmieren und usern.
-
user tests würd ich keinen daumen nach unten verpassen. die sind zwar nicht sonderlich gut geeignet, um kernprobleme zu finden, aber die finden zuverlässig unlogisches oder undurchsichtiges verhalten. wird nur viel zu selten berücksichtigt. wenn ein user sagt, dass die anwendung scheisse ist, dann ist sie scheisse. so einfach ist das
-
das
war nur für die user tests die ich erlebt hat, weil dort so verbuggte software rausgegeben wurde, dass es eigentlich garnichts gebratch hat. die bugs hätte man als programmierer schon finden können.
-
Wir machen Unit-Tests, die die erste Testinstanz sind. Nach einem Build und Deploy testen dann unsere Kollegen, die nicht direkt mitprogrammieren, das ganze. Naja, und danach müssen die echten User herhalten.
Aber eine richtige Testabteilung die nur dafür abgestellt ist, haben wir nicht. Die Unittests schreibt jeder Entwickler selber. Manchmal machen wir auch Codereview-Runden... aber seltener.
-
Hallo
Besser als Fehlerfinden ist Fehlervermeidung.
Da die Anzahl möglicher unerwünschter Interaktionen und Seiteneffekte mit dem Quadrat der Anzahl der Komponenten steigt, heißt das vor allem: Programme so einfach wie möglich halten:
"Einfachheit ist der unvermeidliche Preis der Zuverlässigkeit." (C.A.R. Hoare)
Gruß
-
kleine Bemerkung schrieb:
Da die Anzahl möglicher unerwünschter Interaktionen und Seiteneffekte mit dem Quadrat der Anzahl der Komponenten steigt, heißt das vor allem: Programme so einfach wie möglich halten:
"Einfachheit ist der unvermeidliche Preis der Zuverlässigkeit." (C.A.R. Hoare)
Wenn der Kunde was will, dann sollte es auch rein, sonst nimmt er von wo anders.
-
und genau das ist dann der punkt, wenn sich "einfache programme" rächen. dann wird nämlich an allen ecken und enden irgendwas rangetackert, um funktionalität zu unterstützen, die niemals vorgesehen war.
komplexe programme sind schon ok, denn programme so zu gestalten, dass sie modular und erweiterbar sind, macht sie alles andere als einfach. aber wenn das konzept stimmt, dann sind sie trotzdem robust und die anzahl der fehler steigt nicht quadratisch sondern schlicht linear.
-
Hallo
andere Bemerkung schrieb:
Wenn der Kunde was will, dann sollte es auch rein, sonst nimmt er von wo anders.
Klar. Das widerspricht dem Gebot der Einfachheit nicht,
denn man kann ja feinkörnig modularisieren und damit einfache (und damit einfach wartbare) Teilsysteme schaffen und diese dann zu einem größeren System zusammensetzen.Eine der Grundideen von *n*x war einmal, eine Vielzahl kleine Tools zu schaffen, die jedes nur eine bestimmte Aufgabe erfüllen, diese aber dann möglichst fehlerfrei und gut.
Na gut, wird heute nicht mehr so eng gesehen, > 50 Options bei ls ...Gruß
-
thordk schrieb:
aber "usability" lässt sich schwer automatisiert testen. nach meiner erfahrung treten (weil es eben unit tests gibt) in basisfunktionalität sehr selten fehler auf. aber sobald eine software "bedient" wird und nicht vollständig automatisch abläuft (stichwort: benutzeroberfläche) braucht man manuelle tests. die sind immer noch state of the art und verbrauchen (leider) die meiste zeit.
Es gibt auch fuer GUIs Regressionstest-Tools. Z.B. Silk. Dieses Tool wird bei uns eingesetzt und funktioniert erstaunlich gut.
Aber zum eigentlichem Thema: Ja. bei uns wird wirklich getestet. Es werden Testhandbuecher, Testplaene und Testfaelle geschrieben und alles wird protokolliert. Die Ergebnisse der Tests werden geloggt und in einer Datenbank aufbewahrt. Ebenso Bugreports. Es ist auch unverzichtbar. Das Untenehmen in dem ich arbeite hat wirklich grosse nahmhafte Kunden und da sind Audits nicht unueblich. Dabei interessiert es die Kunden auch, wie die Qualitaet ihrer Software gesichert wird. Es ist daher denkbar unguenstig, wenn man in solchen Faellen nichts vorzuweisen hat.
Auf der anderen Seite aber wird bei weitem nicht alles das getestet, was getestet werden sollte. Es ist schlicht unmoeglich. Softwaretesting ist extrem zeitintensiv. Dann halten sich auch noch die Entwickler nicht an die Deadlines und liefern erst eine Woche vor Codefreeze erste lauffaehige Versionen oder veraendern Software noch lange nach dem Freeze. Das macht wiederrum bereits bestehende Tests unbrauchbar, sodass diese angepasst werden muessen. Und natuerlich - wie fast immer und ueberall - ist die Abteilung unterbesetzt. Ich bin seit Mitte Februar als Werkstudent dort taetig und betreue bereits jetzt 6 Projekte. Vollzeit Beschaeftigte betreuen weit mehr und haben auch dem entsprechende Ueberstundenkonten. Releasetermine sind aber fix. Somit ist klar, dass teilweise noch voellig ungetestete Software beim Kunden landet.