Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.06.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>>> Mit "zu Ende" ist wahrscheinlich ein eindeutig abgrenzbares
>>> Ergebnis mit Erreichen einer definierten Zielgr��e gemeint.
>> Ich hatte das bereits vor l�ngerem f�r mich - kann jeder f�r sich
>> and ers sehen - definiert: "zu Ende" hei�t, da� ich keine Bugs mehr
>> sehe und es so l�uft, wie ich mir das vorstelle.
> Klar das benennt Dein Vorgehen auf einen konkreten Zweig bezogen.
Wir arbeiten derzeit ja nur an einem einzigen Zweig.
> und nicht mehr das Grundprinzip.
Das ist IMO schon ein Grundprinzip.
> Wie gesagt, es bestehen da durchaus noch M�glichkeiten,
> experimentellen Source abzulegen, daf�r gibts ja das /Trial.
Absolut.
Aber der hinter der von mir geposteten Dokumentation stehende Code ist
kein experimenteller Code wie es z.B. mal der Code zum Stichwort
"Overlay im XMS" eine Weile war (und deshalb auch im Trial lag).
Sondern vom Zeitpunkt der Fertigstellung an voll funktionsf�higer und
anwendertauglicher Code, der nur derzeit eben noch unvollst�ndig und
l�ckenhaft ist.
Wenn man damit jetzt experimentieren w�rde, w�rde man nat�rlich jede
Menge Bugs feststellen, was aber nichts bringt, da mir die durch die
L�cken vorhandenen Bugs sowieso bereits wohlbekannt sind.
Diese bekannten L�cken will ich erst schlie�en, dann darf sich
meinetwegen jeder dar�ber hermachen.
>>> Ansonst ist alles relativ, selbst die Forderung "getestet" kann man
>>> nicht wirklich gew�hrleisten.
>> Einspruch - kann man selbstverst�ndlich, wenn man das will.
>> Der UUZ hat Testszenarien durchlaufen, die schon l�cherlich abartig
>> und v�llig unrealistisch - gleichwohl RFC-konform und theoretisch
>> denkbar - sind. Und die *haben* Bugs zutage gef�rdert...
> Trotzdem sind noch Bugs aufgetreten.
Na logisch, und es werden vermutlich auch zuk�nftig immer noch durch
alten Code verursachte und seit jeher im UUZ existierende Bugs auftreten
und gemeldet werden - es sind zwar gro�e Teile des UUZ neugeschrieben
worden, aber doch nicht alles. Und ich teste nat�rlich prim�r die von
mir neugeschriebenen und ver�nderten Routinen, aber doch nicht jede
bereits seit Urzeiten bestehende und bisher nicht beanstandete Routine -
weil das schon vom Aufwand her gar nicht geht.
Die Bugs, die aufgetreten sind und gemeldet wurden, waren jedenfalls
Altlasten (letztes Beispiel falscher LEN:-Header bei UTF-8-Nachrichten,
die gar nicht in UTF-8 vorliegen). An in der Praxis aufgetretene Bugs
in den neuen Routinen, die von jemand anderem als von mir selbst bemerkt
und gemeldet wurden, kann ich mich nicht erinnern.
Aber auch das kann nat�rlich trotzdem jederzeit passieren. Nur ist das
durch das intensive Testen wesentlich unwahrscheinlicher geworden.
>> Davon bringt mich gerade nach den bisherigen Erfahrungen keiner ab:
>> Der beste Tester ist immer noch der Entwickler selbst (unterstellt,
>> er befa�t sich gedanklich auch damit, was sein Code unter welchen
>> Bedingungen zu leisten hat und er hat ein Interesse daran, nicht nur
>> quick&dirty-m��ig zu Werke zu gehen).
> Selbstverst�ndlich hat ein Entwickler zu testen, sonst macht er sich
> zum Gesp�tt.
Da werden ja durchaus auch andere Positionen vertreten, deshalb wollte
ich das nochmal klarstellen.
Und gar nicht so selten braucht man auch gar nicht zu testen, um den Bug
zu sehen, sondern es reicht das Lesen des Codes. Wenn Stringadditionen
vollf�hrt werden oder mit 'insert' gearbeitet wird, kann ich mir auch so
schon ausrechnen, da� Zeichen ab Pos. 253 verlorengehen m�ssen.
Und das ist genau das, was ein Nur-Tester ohne Kenntnis und Verst�ndnis
des Codes gar nicht oder nur per Zufall herausfinden wird. Deshalb kann
und darf man sich auf das Prinzip des Testens durch Nur-Tester oder gar
User nicht verlassen.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
