4.0.2 Fortschritt und Erklärung des Qualitätssicherungsprozesses
Es gab bereits einige Verzögerung bzgl. der Veröffentlichung von vB 4.0.2 und wir dachten daher, dass eine Erklärung für unsere Kunden notwendig wird. Release-Termine sind eigentlich immer darauf eine Schätzung und wir geben unser Bestens, um basierend auf Informationen und Ressourcen, die wir zum Zeitpunkt der Nennung eines Termins haben, einen Termin zu nennen, wann wir mit den aktuellen Fixes fertig sind.Dennoch sind ständige Verbesserungen etwas, wonach wir streben und daraus resultierend, haben wir uns überlegt, wie wir das Ganze weiter verbessern können. Selbst der beste Prozess wird uns harte Entscheidungen fällen lassen, die einen Kompromiss aus Termineinhaltung und Produkt-Zielen sind. Wir denken, dass es diesmal richtig ist, auf Qualität zu setzen, statt uns an einen künstlichen Zeitplan zu klammern. Wir entschuldigen uns für die Unannehmlichkeiten, die daraus entstehen, aber wir glauben, dass es am Ende viel besser sein wird und die Zeit damit sinnvoller eingesetzt wurde.
Der Prozess, dem wir für ein Bugfix-Release folgen, ist die schlimmsten Bugs zu priorisieren. Dann implementiert das Entwicklerteam eine Reihe von Fixen für die kritischsten der Fehler. Danach teilen wir den Quellcode auf, um ihn zu testen und zu stabilisieren (deshalb gibts bereits Bugs, die in 4.0.3 behoben sind, obwohl 4.0.2 nicht einmal veröffentlicht ist). An diesem Punkt werden nur die aller kritischsten Fehler in ein mögliches Release aufgenommen - diese sind meist die wichtigsten für den Kunden -, um Fehler durch Konflikte zu beheben, oder um vorherige Fixes zu korrigieren, die noch nicht korrekt funktionierten. Wenn eine Build stabilisiert wurde, bekommt die Qualitätssicherung (QA) sie, um sie zu testen und Probleme zu melden.
Und warum noch eine Verspätung für 4.0.2? Am Anfang gingen wir von einer Schätzung der Fixes aus, die wir ursprünglich der QA gaben - mehr behobene Fehler heißt mehr testen. Wir haben zudem recht spät eine Reihe von Fehler gefunden, die wir noch mit 4.0.2 beheben wollten, größtenteils diese um die RTL-Probleme (Rechts-nach-Links-Schreibweise) und Probleme mit dem Internet Explorer. Wir wussten, dass dies eine Verzögerung verursachen würde, doch wir entschieden im besten Interesse unserer Kunden, diese Fehler zu beheben, anstatt sie in ein späteres Release zu schieben.
Als wir uns in diese Fehler einarbeiteten, fanden wir recht schnell heraus, dass manche von ihnen eine grundlegende Änderung verlangen, wie RTL im IE6 und IE7 dargestellt werden muss. Dadurch wurde es nötig, durch fast alle CSS-Codes im System zu gehen, um die Stellen zu finden, die verbessert werden müssen. Der Ärger mit den Änderungen wie diesen ist, dass sie schwer einzuschätzen sind, wie lang sie dauern. Zudem braucht es viel mehr Testläufe, als bei eng abgegrenzten Fixes. Nicht zuletzt fanden wir aber, dass diese Geschichte zu beheben ein großer Vorteil für eine Großzahl unserer Kunden ist, was auch das Risiko den Termin nicht halten zu können, rechtfertigt. Also schritten wir fort mit dem Beheben der Fehler. Dadurch wurde unser Zeitplan jedoch unberechenbar und wir mussten unsere VÖ-Daten ein paar mal neu berechnen.
Wir hoffen, dass Sie dies verstehen und schätzen Ihre Geduld, während wir das neue Release zu dem besten machen, was wir können - bevor wir es veröffentlichen.
Kevin
