Microsoft Windows Updates – Wie das Testing funktioniert, warum Daten gesendet werden

Erscheint ein neues Programm oder ein neues Update, hagelt es meist gleich irgendwelche Kritik, dass Microsoft seine Anwender als Tester missbrauchen würde und bei den Mitbewerbern – hier ist dann meist Apple gemeint bei den PCs bzw. Android bei den Smartphones – die Systeme doch viel fehlerfreier bis ganz fehlerfrei laufen würden. Mithin, dass die doch einen viel besseren Job machten als Microsoft! Und dass Microsoft auf Kosten der Kunden seinen Job nur halb macht.

Das ist nur vordergründig richtig, eigentlich ist es sogar komplett falsch.

Wenn man mal unter die Oberfläche schaut, dann sieht man sehr schnell, dass Microsoft einen hervorragenden Job leistet. Doch der Reihe nach.

Es ist ja beileibe nicht so, dass hier die Programmierer einsam und mit sich selbst genug in ihrem Kämmerchen sitzen und fröhlich drauflos programmieren, bei weitem nicht. Da gibt es schon im Vorfeld besprochene, bestimmte Features, die von den einzelnen, verschiedenen Teams erarbeitet werden. Mal ist das eine Team schneller, mal das andere, je nachdem wie aufwendig ein Feature ist. Ist ein Feature fertig, wird es intern gegengetestet. Da die einstellbaren Optionen von Windows schon jetzt mehrere Zig-Tausende Möglichkeiten umfassen, sind natürlich die möglichen Kombinationen daraus uferlos. Deshalb werden auch Testprogramme benutzt.

Warum Testprogramme?

Beispiel: Ein Miniprogramm mit nur 10 Optionen. Das ergibt 10! = 3.628.800 Möglichkeiten, wie diese Optionen benutzt werden können. (Anmerkung: ! spricht sich Fakultät und berechnet die Anzahl aller Kombinationen. Bei drei Optionen haben wir z.B. 1+2+3, 1+3+2, 2+1+3, 2+3+1, 3+1+2, 3+2+1, also sechs Möglichkeiten. Das berechnet sich auch 3 x 2 x 1 = 6, bei vier wäre das 4 x 3 x 2 x 1 = 24 usw.)

Bei beispielsweise nur (!) 64 möglichen Checkboxen in einem Programm gibt es theoretisch 64! ≈ 1,27·10 hoch 89 verschiedene Kombinationen. Wer an die Geschichte mit dem nur (!) verdoppelten Reiskorn pro Feld denkt, weiß, dass die Summe ganz schnell astronomisch wird. Dagegen ist eine simple Parabel ein flacher Berghang.

Die von den meisten Taschenrechnern höchste berechenbare Zahl ist 69!, die größte darstellbare Zahl 170! ≈ etwa 7,3 x 10 hoch 306 (siehe Wikipedia).

Wie groß wäre dann die folgende Zahl?  1.000.000.000! – Ich kann es mir nicht vorstellen…

Wollte man also alle tausende Millionen mal Milliarden Kombinationen, die ein normales Windows bietet, komplett austesten, so bräuchten auch die schnellsten Rechner dafür mehrere hundert Jahre. Und damit sind noch nicht einmal alle unterschiedlichen Treiber und Hardwareplattformen mit einbezogen (das ist keine Vermutung, das ist Fakt). Heutzutage gibt es spezielle Testprogramme, die deshalb bestimmte – häufig vorkommende – Optionen gegeneinander bzw. gegen neue austesten können. Sicherlich werden dann auch die Hersteller mit einbezogen, indem sie Leihstellungen zur Verfügung stellen oder sogar selbst testen.

Hardware – Wer schreibt die Treiber?

Hat die neue Version die Hürde Testprogramm geschafft, dann geht sie ins Testlabor. Dort stehen hunderte verschiedene Referenzgeräte der verschiedenen Hersteller. Und hier kann man sehr schnell den Unterschied zwischen Apple und Microsoft erkennen: iOS bzw. MacOS muss auf nur WENIGEN, Windows auf sehr verschiedenen VIELEN Systemen laufen. (Allein die Anzahl der Chip-Sätze ist unter iOS/MacOS sehr übersichtlich, bei Windows-PCs dagegen gibt es für jede CPU-Generation viele unterschiedliche Chip-Sätze von verschiedenen Herstellern.)  Selbst Android läuft nur auf im Verhältnis sehr wenigen Referenzmodellen, wobei die Hersteller teilweise eigene Erweiterungen hinzufügen oder vorhandene ersetzen. Diese modifizierten Version können dann natürlich nur noch vom Hersteller gepatcht werden.

Zurück zu Windows: Die Hardwarehersteller bekommen auch die Testversion, um bei Bedarf ihre Treiber anpassen zu können – was übrigens nicht alle Hersteller tun bzw. zeitnah tun. Denn für die Treiber ist ausschließlich der Hersteller zuständig. Allerdings programmiert auch hier Microsoft für diverse Geräte eine Grundversion, den Standardtreiber. Viele kennen vielleicht noch den VGA-Standardtreiber? Viele Treiber der Hersteller mussten früher von Hand nachinstalliert werden. Dies hat Microsoft bei Windows 10 wesentlich verbessert, indem hier wesentlich mehr Treiber über Windows Update zur Verfügung stehen und automatisch mitinstalliert oder nachgezogen werden. Das wurde auch für die Fingerprintreader gemacht, denn die Anmeldung damit funktioniert seit Windows 10 astrein und pfeilschnell. Was unter anderem daran liegt, dass die benötigte Software mit Windows Hello bereits vorhanden ist und die von den Herstellern entwickelten oder lizensierten Programme nicht mehr benötigt werden.

Abstürze und defekte Hardware

Aber auch beim Testen der Hardware verbergen sich Tücken: Die Hardware kann defekt sein. Dazu eine Anekdote: Eines der „besten Testprogramme“ seiner Zeit auf defekten Speicher war damals (etwa 1993) Word für Windows 2.0. In den meisten Fällen war der RAM-Speicher defekt, wenn Word mittendrin, meist beim Seitenumbruch oder dem Erstellen eines Inhaltsverzeichnisses, abstürzte… Mit nur ein wenig Vorstellungskraft kann man sich vielleicht die Kunden von damals vorstellen, die alle steif und fest behaupteten und auch recht laut der Ansicht waren, dass Word oder je nach persönlicher Vorliebe wahlweise auch Windows oder Microsoft schuld am Absturz sei (bis man auf den defekten Speicher hinwies…).

Heute passiert dies so nicht mehr, da Windows Hardware-Zugriffe abfängt und Windows die Speicherverwaltung anders handhabt. Die Benutzer dagegen haben ihre prinzipiellen Ansichten aber nicht geändert – stürzt Windows ab, ist es immer noch die Software. Dass auch mal die Hardware schuld sein kann (beim Lumia deuten z.B. manche Aussagen zu Abstürzen auf einen defekten Akku hin) ist eher nicht im Bewusstsein der meisten zu finden.

Übrigens: Viele Apple-User kennen das auch, dass ihr OS abstürzt – es friert dann ein. Würde Apple den Aufwand an Bugtesting betreiben, den Microsoft betreibt, dann müsste eigentlich ein nahezu fehlerfreies Betriebssystem möglich sein – aber davon ist auch Apple weit entfernt.

Hat die neue Version auch das Testlabor überstanden, dann geht die Version an eigene Mitarbeiter, die diese Testversion selbst wiederum einige Zeit aktiv nutzen. Und auch da hat Microsoft vermutlich unterschiedlich große Gruppen, die Zugriff auf die verschiedenen Versionen haben.

Ab und an wird eine Update-Version sozusagen „eingefroren“ und mit einem – wenn man so will – neuen „Namen“ veröffentlicht. Dieser „Name“ ist das, was man auf dem PC unter Windows-Version findet: z.B. 1703, 1607, 1511, 1507. Auf dem PC kann die komplette Build-Version auf dem Command-Prompt mit „ver“ angezeigt werden.

Ein Ring, sie zu knechten…?

Hat es neuer Code bis an diesen Punkt geschafft, so muss nun, wohl oder übel, der Sprung ins kalte Wasser erfolgen, respektive ins Insider-Programm, die Version gelangt in den Fast Ring. Dann wird das Feedback ausgewertet, wieder programmiert, Bugs gefixt und es kommt eine neue Fixversion. Das erfolgt dann einige Male hintereinander, wobei am Anfang natürlich die sichtbaren Änderungen am größten sind und gegen Ende hin gegen Null gehen. Ab und an, wenn man der Ansicht ist, dass die aktuelle Version bugfrei genug ist für den nächsten Ring, geht sie dann in den Slow Ring und dann in den Release Preview Ring.

Teilweise – und ohne Ankündigung! –  werden auch die Ringe nochmal in A- und B-Gruppen aufgeteilt, die unterschiedliche Varianten eines Features testen. Die Rückmeldungen zu den Varianten sind enorm wichtig, denn sie bestimmen die weitere Richtung der Entwicklung. Deshalb gibt es auch keine Ankündigung dazu, um nicht irgendwelche Erwartungshaltungen bzw. davon beeinflusstes Feedback zu provozieren. Wer in welcher Gruppe landet, ist unter anderem auch davon abhängig, wie viel und wie gut er bislang Feedback gegeben hat.  Von diesen erwartet man sich nämlich besonders fundiertes Feedback um evtl. Versionen, bei denen mehr Bugs erwartet werden, besser fixen zu können. Und/oder es unterscheidet sich anhand der Hardwareplattform, wer welche Version erhält.

Sind alle neuen Features einsortiert, gibt es eine neue Update-Version, die – natürlich – auch wieder komplett durch die Ringe läuft, mit steigenden Fixversionen, bevor sie dann den Stempel RTM (Ready/Release to Manufacturing)  bzw. RTW (Ready/Release to Web) – erhält, also „produziert“ bzw. verteilt werden darf.

Und dass auch selbst diese Version nie 100% fehlerfrei sein ist, sollte jetzt auch klar sein.

Treiber und Hardwareanpassungen

Wenn von den Hardwareherstellern bis zu diesem Zeitpunkt neue Treiber zur Verfügung stehen, dann werden die auch entsprechend von Microsoft eingebunden bzw. nachgeladen, z.B. wenn ein System neu aufgesetzt wird. Fehlt der Treiber allerdings, dann kann es durchaus passieren, dass ein neu aufgesetztes altes System mit einem alten Treiber nur beschränkt funktioniert. Wie dann vorzugehen ist, erklärt Euch dieser Artikel.

Ist allerdings für eine Hardware unbedingt ein neuer Treiber zum Betrieb der neuen Softwareversion notwendig und der Hersteller kann oder will diesen nicht liefern, so kann dies natürlich erhebliche unangenehme Folgen für den Benutzer haben: Im schlimmsten Fall heißt es nach dem Update: Operation gelungen, Patient tot. Heute nimmt Microsoft diese PCs, sofern bekannt, vom Updateprozess aus oder kann – wenigstens – das Update wieder folgenlos zurückrollen. Ein großer Fortschritt gegenüber früher! (Mein 5 Jahre alter Laptop wartet z.B. immer noch auf das Creators Update.)

Die 80-20-Regel (Pareto-Prinzip)

Das Prinzip besagt in unserem Fall, dass der Aufwand zum Finden aller Bugs am Anfang sehr klein ist und zum Ende hin enorm anwächst. Oder anders ausgedrückt: Zum Finden von 80% der Bugs braucht man 20% der Zeit, und für 20% der Bugs benötigt man 80% der Zeit.

Dieses Prinzip lässt sich auch auf andere Verhältnisse anwenden, z.B. nutzen ca. 80% aller User nur 20% des Funktionsumfangs eines Programms und umgekehrt. Mit der verwendeten Hardware ist es ähnlich: 80% der User benutzen 20% der auf dem Markt verfügbaren Hardwarevarianten. Oder: 80% der User finden 20% der Bugs, die anderen 20% „Poweruser“ haben recht große Chancen, einen Bug der restlichen 80% zu finden. Und diese 20% der Poweruser mit den 80% Hardwarevarianten versucht Microsoft mit seinem Insider-Programm zu animieren, beim Bugtesting mitzumachen. Denn ohne die geht es einfach nicht.

Und wenn man sich mal die Entwicklungszeit anschaut: Zum einfachen Schreiben der Features werden ca. 20% der Zeit gebraucht, die restliche Zeit bis zum Release wird mit dem Finden und Fixen der Bugs verbracht. Wer schon einmal ein wenig programmiert hat, der wird mir zustimmen. Beim Pareto-Prinzip muss übrigens nicht immer das Verhältnis 80-20 richtig sein, es kann auch mal 70-30, 90-10 oder ähnlich sein.

Und warum müssen dann immer noch Nutzungsdaten an Microsoft gesendet werden?

Das liegt an drei Gründen: Erstens werden auch mit dem Insider-Programm nicht alle Bugs gefunden. Die letzten fehlenden Prozent sind so selten, dass sie erst bei einer riesigen Menge an Nutzern überhaupt sichtbar werden.

Und zweitens erfährt Microsoft dadurch auch, wie User ihren Computer benutzen, wie sie bei Fehlermeldungen und Fehlern reagieren. Gerade das hilft enorm, um die Fehlermeldungen so anzupassen bzw. sogar im Hintergrund abzufangen, dass der User besser darauf reagieren kann, mit den vorhandenen Bordmitteln den Fehler selbst beheben kann bzw. im besten Fall sogar gar nichts mehr davon merkt.

Und der dritte Grund ist eigentlich der wichtigste: Windows muss den Benutzern gefallen, sie müssen gerne und gut damit arbeiten können.

Tipps für ein konstruktives Feedback

1. Bleibe höflich.
2. Schreibe es so, dass es auch jemand nachvollziehen kann, der keine Ahnung von der Materie hat.
3. Führen bestimmte Schritte zu dem Ergebnis, beschreibe diese Schritte.
4. Füge, wenn irgend möglich, Bilder (Screenshots oder eigene Veranschaulichungen) oder Aufzeichnungen hinzu.
5. Versuche, das Feedback möglichst genau den richtigen Kategorien zuzuordnen.

Ein gutes Feedback muss es dem Supportmitarbeiter ermöglichen, das Problem einwandfrei nachzustellen. Aufzeichnungen sind dabei sehr wichtig. Praktisch unerlässlich sind sie, wenn es um Hardware bzw. Gerätetreiber (z.B. Bluetooth, Datenverbindung und WLAN) geht. Aufzeichnungen sollten dabei so kurz wie irgend möglich sein.

Wie seht Ihr das nun – was haltet Ihr jetzt vom Insider-Programm? Findet Ihr es in Ordnung, dass es das Insider-Programm überhaupt gibt? In welchen Ringen seid Ihr und wie haltet Ihr das mit dem Feedback?