Microsofts Software Qualitätssicherung
In seinem Weblog äußert sich der Microsoft Entwickler Chris Pratley sehr ausführlich zu der Vorgehensweise beim Aufspüren von Fehlern in Software und erklärt unter anderem verständlich, warum Microsoft teilweise bewusst Software mit bekannten Bugs ausliefert.
Im ersten Eintrag zu diesem Thema in seinem Blog schildert er die Vorteile durch den in Windows XP integrierten Quality Feedback Agent, welcher bei Abstürzen darum bittet, Informationen diesen Absturz betreffend an Microsoft senden zu dürfen. Auf diese Weise erhalte man eine aussagekräftige Statistik und könne bei plötzlicher Häufung eines bestimmten Fehlers schnell darauf reagieren, da man zum einen überhaupt merkt, dass dieser offenbar besonders kritisch ist und man zum anderen mit oftmals hilfreichen Detail-Informationen zu diesem Absturz versorgt wird.
Die Frage, wie viele Bugs ein Produkt enthält, ist vor allem vor dessen Veröffentlichung von höchster Brisanz. Schließlich möchte man nur ungern Software ausliefern, welche bei einem hohen Anteil der Kunden Probleme verursacht. Vor der Einführung dieser halbautomatischen Qualitätskontrolle war man einzig und allein auf das Feedback von internen und externen Beta-Testern angewiesen, von welchen es bei Microsoft seinen Angaben zu Folge übrigens genauso viele gibt wie eigentliche Entwickler. Dass die so gewonnenen Informationen durch die Watson genannte Routine sinnvoll ergänzt werden können, liegt unter anderem daran, dass man die Häufigkeit sowie bestimmte Charakteristika eines Absturzes ausfindig machen kann.
Man ist somit also nicht mehr darauf angewiesen, die Stabilität eines Produktes praktisch abschätzen zu müssen, sondern kann sie in gewisser Weise messen. So hat man beim Betatest von Office XP, wo diese Technologie erstmalig zum Einsatz kam, gemerkt, dass ein einziger Bug für 27% aller Abstürze einer Anwendung verantwortlich war und konnte durch die Behebung dieses Bugs folglich die Qualität von Office XP deutlich verbessern. Zudem wurde auf diese Weise eine Fehlerquelle ausgemacht, mit der man eigentlich nur nebensächlich gerechnet hat, nämlich die an die zahlreichen Sprachen angepassten Rechtschreibprüfungen. Die niederländische und italienische Rechtschreibprüfung verursachten angeblich unglaublich hohe Zahlen an Abstürzen. Ohne Watson sei es unwahrscheinlich, dass man diese Fehler genauso schnell behoben hätte. Mit der Einführung von Office 2003 habe man Watson weiter verbessert, unter anderem erkennt es nun auch Fälle, in denen eine Anwendung nicht mehr reagiert oder ungewöhnlich lange für eine bestimmte Aktion braucht.
Zudem erklärt Chris Pradley, wie eingangs bereits erwähnt, warum man vor Veröffentlichung einer Anwendung teilweise bewusst Fehler nicht mehr behebt. Das sind solche Fehler, die eine relativ niedrige Gewichtung haben, bei denen jedoch ein hohes Potenzial besteht, dass durch sie andere Fehler eingeführt werden können. Man kann somit nicht davon ausgehen, dass ein Produkt nach dem Beheben eines Fehler besser ist als vorher, da man einen kleinen, nur wenige Anwender betreffenden, Bug durch einen größeren ausgetauscht haben könnte.
Naturally during the course of a project we fix just about every bug we find. But near the end of the project, as it gets harder to find bugs and our predicted ship date approaches, we need to make sure we can control the quality of the product in the end game. We begin a process of deciding which bugs to fix and which ones our customers can live with (because they won't notice them, mainly). Some people will read this and say "I knew it! See, Microsoft guy admits shipping buggy software!". If you conclude that, you did not understand.
Auch wenn er gegen Ende des zweiten Teils noch den zweifelhaften Versuch unternimmt, diese Technologie als Teil der Trustworthy Computing Initiative von Microsoft zu verkaufen, sind die beiden Blog-Einträge aufgrund der geschilderten Erfahrungen beim Software-Test auf jeden Fall lesenswert!
- Teil 1: Quality
- Teil 2: More on Quality