Softwareprojekte & Bugmanagement & Tests
-
erstmal danke für eure zeit.
hmhm, an unit tests habe ich auch schon gedacht. im optimalen fall habe ich von vornherein unit-tests, wie von rüdiger erläutert. das wirft weitere fragen auf:
1. hat jemand erfahrung mit der nachträglichen implementierung von unit-tests? ist das praktikabel?
2. wie wird dieses vorgehen von kundenseite angenommen? habt ihr erfahrung mit kunden, die ähnlich wie bei mir in die testunterlagen reinschauen müssen?
3. auch der vorschlag von cmatt und matthias, nach jedem fix dafür einen unit test zu schreiben gefällt mir. aber kann man damit alles abdecken? in einigen fällen geht ja nichts über manuelles testen. man kommt hier meiner meinung nach nicht immer drumherum, oder?grüsse,
.alx
-
1. Es ist aufwendig aber im Gegenzug werdet ihr dabei Fehler und Ungereimtheiten finden, die euch vielleicht schon immer Probleme gemacht haben.
2. Ich glaube kein Kunde wird lauthals protestieren wenn die Software bevor er sie bekommt ausgiebig getest wird.
Man wird dem Kunden auch nicht die Ergebnisse der Testreihen vorlegen sondern eher ein Vergleich zwischen vorher->nachher. Genau das interessiert und dadurch kann man z.B. auch belegen dass sich das Verhalten nicht negativ verändert hat...
3. Warum muß man immer gleich versuchen ALLES abdecken? Es ist doch schon eine große Arbeitserleichterung wenn die Grundfunktionalitäten getestet werden, die man von Hand gar nicht mehr macht, weil es einfach zu viel Zeit kostet.
Wenn die Grundfunktionalität stabil arbeitet hat man schon sehr viel gewonnen.
Die komplexeren Sachen und Sonderfälle würde ich automatisiert testen wenn sie erfahrungsgemäß/potentiel Seiteneffekten zum Opferfallen oder man beim manuellen Testen nicht gleich sieht was schief läuft.
-
Test driven developement in der rein-form kannst nur machen wenn kein Kunde da steht der rumplärrt "ich das aber jetzt haben, jetzt, jetzt, jetzt!! bääähhh", oder du nicht nur kronisch überlastete Entickler hast. Es gibt leider wenige Firmen die einen der beiden Punkte erfüllen, will heissen und der Praxis ist das "erst test schrieben dann implemtien" so gur wie nicht umsetztbar.
Zu deinen Punkten
-
Ja, ist es. Es dauert etwas bis nam den Entwickler verlickert hat, das sie daruch schneller werden und das nicht nur zuätzlicher aufwand ist. Bsp sehr häufiges problem bei uns: es braucht ne mange Zeit bis man überhaupt dort ist wo es was zum verifizieren gibt. Z.b. beim finalisieren einer DVD gibts nen fehler. Um dort anzugelangen musst jetzt aber erst mal ne DVD brennen, was einige Zeit kostet. Schaffst du es dem Entwickler nur einziges mal davon zu überzeugen, das er nen unit test für genau die methode schreiben soll anstatt x mal 10min. zu warten bis der debugger dort ist wo er sein soll macht der beim nächsten mal automtisch da es einfach bequemert ist. Weiß nicht wie es bei eucht ist aber bei uns hab die erfahrung gemacht das Entwickler generell der Meinung sind: "Testen? Das macht doch die QA, wozu soll ich das auch machen?". Das muß man abstellen und zwar sehr schnell.
-
Haben wir nicht. Kann ich dir also nicht sagen. Aber ich denke hier gillt: je mehr der kunde an test ergenissen sieht, deszo zufriedener wir er sein. Auch wenn das nur ne ist mit "foo1()... passed, foo2()... passed" ist und er damit ncith wirklich was anfagen kann
-
Nein kann man nicht. Du brauchst immer ne "Endabnahme" von nem echten tester, aber der soll ich auf sachen konzentrieren das sich nicht automatisiern lässt.
Bei uns gillt folgendes: komplexe funktionen bekommen nen unti-test vor der imeplentierung (unti tests für get/set methoden zu schreiben ist IMHO sinnlos). Was als komplex einzustuft wird kann der entwickler selbst entscheiden, anders rum will ich aber bei nem bug wegen fehlenden test dann auch nicht höheren "ja aber die funktion ist mega-kompliziert da kann schon mal was schief gehen".
Für bugfixes, deren test sich automatisieren lässt, gibts nen unit test (gibt auch ausnamhen bei irgend welche mini-fixes, wo der fix 5min. dauert, das unit test schreiben aber 50).
-
-
CMatt schrieb:
Test driven developement in der rein-form kannst nur machen wenn kein Kunde da steht der rumplärrt "ich das aber jetzt haben, jetzt, jetzt, jetzt!! bääähhh", oder du nicht nur kronisch überlastete Entickler hast. Es gibt leider wenige Firmen die einen der beiden Punkte erfüllen, will heissen und der Praxis ist das "erst test schrieben dann implemtien" so gur wie nicht umsetztbar.
Quatsch! - Als ich früher in meinen Büro alleine entwickelt habe, mit zehn Kunden gleichzeitig am Hals, war es dennoch keine Schwierigkeiten Unit-Tests von Anfang an zu etablieren. War eine Sache von 1-2 min. Die Testvektoren hatte ich als XML File i.d.R. schon auf der Stange in meiner Reposity - GUI-Eingabe-Tests, Persistence-Abort Tests etc. Ohne ist nur leichter den Kopf in den Sand zu stecken, das ist alles. Das liegt nicht am Kunden - das liegt an der Hinter-dem-Mond-Klitsche für die Du arbeitest und Deiner fehlenden Erfahrung ...
Wenn ich heute ein Assessment für einen Softwarezulieferer durchführe und ich finde in deren Töpfen keine Unit-Tests oder Akzeptanstests, rattern die glatt durch das Assessment. Und wenn mein Sponsor im Nachassessment immer noch keine Unit-tests etc. findet, wird die Zusammenarbeit mit dieser Firma beendet!
Für den Nahkampf kann ich nur Frank Westphal empfehlen
:http://www.frankwestphal.de/TestgetriebeneEntwicklungmitJUnitundFIT.html
-
Prof84 schrieb:
CMatt schrieb:
Test driven developement in der rein-form kannst nur machen wenn kein Kunde da steht der rumplärrt "ich das aber jetzt haben, jetzt, jetzt, jetzt!! bääähhh", oder du nicht nur kronisch überlastete Entickler hast. Es gibt leider wenige Firmen die einen der beiden Punkte erfüllen, will heissen und der Praxis ist das "erst test schrieben dann implemtien" so gur wie nicht umsetztbar.
Quatsch! - Als ich früher in meinen Büro alleine entwickelt habe, mit zehn Kunden gleichzeitig am Hals, war es dennoch keine Schwierigkeiten Unit-Tests von Anfang an zu etablieren. War eine Sache von 1-2 min. Die Testvektoren hatte ich als XML File i.d.R. schon auf der Stange in meiner Reposity - GUI-Eingabe-Tests, Persistence-Abort Tests etc. Ohne ist nur leichter den Kopf in den Sand zu stecken, das ist alles. Das liegt nicht am Kunden - das liegt an der Hinter-dem-Mond-Klitsche für die Du arbeitest und Deiner fehlenden Erfahrung ...
Das geht, wenn die Kunden (oder der/die Chef/s) genau wissen was sie wollen. Wenn dann ein Programm plötzlich wieder einiges anders machen soll, dann kannst du wieder die hälfte der Tests vergessen. Kommt natürlich darauf an wie schwerwiegend die Änderungen sind.
-
KennerDerKunden schrieb:
Das geht, wenn die Kunden (oder der/die Chef/s) genau wissen was sie wollen. Wenn dann ein Programm plötzlich wieder einiges anders machen soll, dann kannst du wieder die hälfte der Tests vergessen. Kommt natürlich darauf an wie schwerwiegend die Änderungen sind.
Das ist aber ein Problem, das nichts mit Testen zu tunen hat, sondern mit Projekt-, Änderungs- und Anforderungsmanagement, sowie dem System Engineering.
Und normalerweiser bucht man mich, um solchen Chef's, die nicht wissen was Sie wollen, den Kopf zu schruppen ...
-
Prof84 schrieb:
Quatsch! - Als ich früher in meinen Büro alleine entwickelt habe, mit zehn Kunden gleichzeitig am Hals, war es dennoch keine Schwierigkeiten Unit-Tests von Anfang an zu etablieren. War eine Sache von 1-2 min.
Das allein sagt mir das du keinen Ahnung hast wovon ich vorhin gesprochen habe.
Wenn bei dir das unit test schreiben in 1-2 minuten pro projekt dauert, schön für dich bei uns bei uns nicht. Projkte für 10 Kunden gleichzeit die eine 1-mann Entwicklungsabteilung bewätigen kann stehen in keiner relation zu unseren. Dei 1-2min. bei test driven developement sind kompletter schwachsin. Mach da mal ne 1h pro tag draus wenn sich die Anforderungen nicht ständig andere um diese 'vorlagen' verwenden kann. Bei nem team von 20 entwicklern machen dann 2 1/2 nichs mehr anderes als das => das geht einfach nicht die wir eigentlich 30 entwickler brauchen würden um die arbeit zu bewältigen, nicht 17,5. Bei uns gibts ganz klare aussagen von Kundenseite: wir wollen das als erstes, mir egal ob da noch bugs drinnen sind, könnt ja ein update nachschieben, aber wir brauchen das vor es xy hat". Ob irgend ne buchhaltungssoftware 2 wochen später kommt interessiert doch keine sau. Es gibt etwas geschrei, wie immer, das was, da abreiten nicht 4 andere Firmen zur selben Zeit an genau dem selben feature. Wenn wir zu spät sind geht das ganz einfach "was woll ihr denn noch hier? von cyberding haben wir das vor 2 tagen bekommen, bye!". Das kannst du dir nicht oft leisten wenn du nicht fulltime unit tests für harz4 schreiben willst.Also hier zu behaupten jeder kann das machen und wer das nicht mach steckt nur den kopf in den sand ist absolut realitätsfremd oder stammt von einerm der bisher nur in Firmen war bei dem der konkurz/zeitdruck sehr viel gerinner ist und nicht der gewinner, der als erstes beim kunden anruft und sag 'hab es'.
-
Prof84 schrieb:
KennerDerKunden schrieb:
Das geht, wenn die Kunden (oder der/die Chef/s) genau wissen was sie wollen. Wenn dann ein Programm plötzlich wieder einiges anders machen soll, dann kannst du wieder die hälfte der Tests vergessen. Kommt natürlich darauf an wie schwerwiegend die Änderungen sind.
Das ist aber ein Problem, das nichts mit Testen zu tunen hat, sondern mit Projekt-, Änderungs- und Anforderungsmanagement, sowie dem System Engineering.
Und normalerweiser bucht man mich, um solchen Chef's, die nicht wissen was Sie wollen, den Kopf zu schruppen ...
Das hat in dem Moment was mit dem testen zu tun sobald die resourcen kanpp sind, die deatlines stehen und x andere schneller sein wollen als du. Projekt-, Änderungs- und Anforderungsmanagement spuckt keine Entwickler aus und mach auch keine 25h tage. Wenn du zu spät bist kann du die test, sammt der software drum rum, in die tonne treten, will keiner mehr.
-
Sorry, wenn ich jetzt so Dumm fragen muss, aber was genau ist den ein Unit Test und wie sieht dieser in der Praxis aus ?
-
Was habt ihr den für Projekt bzw. Kunden die alles gleich 5 mal entwickeln lassen? Der schnellste gewinnt dann? Was ist den das für ne verbuggte Software?
Normalerweise beschleunigen Unit Tests eigentlich die Entwicklung, weil man dann weiß, dass ein Modul funktioniert und man nicht irgenwo Fehler suchen muss, weil man keine Ahnung hat was geht. Auch das Debuggen geht in Test viel einfacher als im kompletten Projekt.
-
unit_test? schrieb:
Sorry, wenn ich jetzt so Dumm fragen muss, aber was genau ist den ein Unit Test und wie sieht dieser in der Praxis aus ?
-
@CMatt
naja, nur weil sich die Anforderungen an ein Programm ändern, sind doch nicht alle Unit-Tests hin oder erwartet dein Chef auf einmal, das wahr = falsch ist und falsch = wahr?Im Zweifelsfall ist es wohl leichter ein Unit-Test neu oder umzuschreiben, als ein Unit-Test erst Wochen oder Monate nach der Entwicklung einer Unit zu programmieren.
unit_test? schrieb:
Sorry, wenn ich jetzt so Dumm fragen muss, aber was genau ist den ein Unit Test und wie sieht dieser in der Praxis aus ?
-
rüdiger schrieb:
@CMatt
naja, nur weil sich die Anforderungen an ein Programm ändern, sind doch nicht alle Unit-Tests hin oder erwartet dein Chef auf einmal, das wahr = falsch ist und falsch = wahr?Hab ich das gesagt? Mit Anforderungen meine ich hier, das solche vordefintieen werzeuge einem sehr helfen (haben wir ja auch) aber es auch sehr viele test cases gibt die nicht einfach nur zusammengeklick werden können, sonder wo man echten code tippen muss / siche überlegen muß was der test üerhaupt machen muß um die funktion möglist vollständig zu testen. Da reichen dann die 1-2min. nicht mehr.
Was ich versuche euch klar zu machen ist, das unit test erst mal bremsen. Auf das ganze projekt gesehe machen sie schneller das fixen schneller geht / gar nicht erst gemacht werden, gar keine Frage, aber die zeitpanne von kick-off bis zur ersten beta wir nun mal länger und wenns zu viel länger dauert als bei Firma x zieh auch das besser qualität argument nicht mehr, denn nehmen die Firma x.Versteht mich jetzt nicth falsch, ich bin großer beführworter von jeder art von automatisierten test, aber solche aussagen wie "Quatsch, das könnt ihr auch, hab ich doch selbst schon gemacht, ihr woll nur nicht" ohne überhaupt nen blassen schimmer zu haben nach welche vorgaben wir arbeiten, geht mir tierisch auf den sac* (das kann doch nur von nem consultant kommen
)
Das geht einfach nicht bei allen. Dann besser abgespeckte unti tests (war schon schwer genug das durch zu bekommen) und nen job, als pures test driven development und bald keinen job mehr.Was habt ihr den für Projekt bzw. Kunden die alles gleich 5 mal entwickeln lassen? Der schnellste gewinnt dann?
Die lassen nicht entwickeln. Die sitzten einfach und sagen "unser HD-DVD laufwerk ist fertig, brauchen nen player asap, wollen das ding ja auf den mark werfen bevor y uns die wenigen kunden wegschnappt".