Qualitätssicherung bei Linden Lab

From Second Life Wiki

Haben Sie sich auch schon immer gefragt, wie Fehler in Second Life hinter den Kulissen behandelt werden? Als Antwort auf eine Frage von Ricky Lucero gab Kelly Linden Auskunft(en) über unsere Qualitätssicherungs-Methodik.:

---

Wir haben tatsächlich eine Qualitätssicherungs-Abteilung.

Unser Vorgehen ist ungefähr wie folgt:

• Die Projektleitung erstellt eine Verzweigung (Branch) aus der Hauptentwicklungslinie (Trunk) eines neuen Projekts.
• Entwickler, die an diesem Projekt arbeiten, geben Ihren neuen Code in diesen Branch ein.
• Entwickler schreiben Testpläne für den Code, den sie geschrieben haben.
• Wenn das Projekt „beendet“ ist, werden die Testpläne und der Branch/die Revision an die Qualitätssicherung (QS) weitergeleitet.
• QS testet den Branch
  • testet nach Testplänen der Entwickler
  • testet laut verwandten Testplänen
  • führt einen Probelauf (Smoke test) durch
  • meldet der Projektleitung gefundene Programmfehler (Bugs)
• Entwickler beheben die Fehler und schicken den korrigierten Code zurück an QS, die erneut testet und prüft
• Der Branch wird wieder in den Trunk eingefügt
• Der Trunk geht zum Testen zur QS und Fehler werden wieder den Entwicklern gemeldet (zu diesem Zeitpunkt befinden sich viele Projekte in der Entwicklung)
• Entwickler beheben die Fehler und schicken den korrigierten Code zurück an QS, die erneut testet und prüft
• Eine „Beta“-Version wird veröffentlicht (entweder ein Viewer wie der Focus Beta oder für das gesamte Grid)
• Einwohner und QS melden den Entwicklern Fehler. Die Entwickler beheben diese und die QS prüft erneut.
• Die neue Version wird für das Hauptgrid veröffentlicht.

Dies ist eine einfache und etwas idealisierte Darstellung der Vorgänge. Manchmal erfordern Fehlerbehebungen in Notfällen eine Verkürzung der oben genannten Schritte (wie z.B. öffentliche Beta). Es kann auch mehr Branching und Merging des vorhandenen Codes erforderlich sein. Das ist abhängig von der Größe des Projekts und der Entwicklung im Trunk.

Zusammenfassend kann man sagen, dass wir mit einem sehr komplexen System zu tun haben. Viel Hardware und unterschiedliche Software ist notwendig und alles muss zusammenarbeiten, ganz zu schweigen, von all den Einzelschritten innerhalb eines Prozesses. Diese Systeme werden außerdem von vielen Leute auf viele unterschiedliche Arten verwendet. Manchmal erkennen wir einfach nicht, daß Dinge inworld auf eine bestimmte Art getan werden, bis wir es kaputt gemacht haben.

Sind wir gut dabei, Fehler zu minimieren? Nein, nicht wirklich. Wir haben jedoch eine QS-Abteilung und der oben beschriebene Prozeß unterliegt einer permanenten Überprüfung und Veränderung. Ich glaube, wir haben uns im Vergleich zu früher schon verbessert. Wir widmen jetzt auch einen großen Teil der Entwicklungsarbeit der Fehlerbehebung, was das Absichern gegen zukünftige Skalierungsprobleme und Ähnliches, sowie das Ersetzen von Kernsystemen, die unter heutzutage falsch erscheinenden Annahmen entwickelt wurden, mit einschließt. Für den Benutzer sind diese oft nicht sichtbar, es sein den sie gehen „kaputt“ oder wir handeln nicht schnell genug.

Ich unterziehe meine Entwicklungsarbeit selbst ausgiebigen Tests, bevor ich meine Arbeit an die QS weitergebe. Es macht keinen Sinn einfach Code zu schreiben, diesen dann zu kompilieren und weiterzugeben. Ich teste meinen Code, damit ich weiß, er macht tatsächlich das, für was ich ihn geschrieben habe. Erst dann schicke ich ihn an QS weiter. Unser Entwicklungsteam ist größer als unser QS-Team und eine andere Vorgehensweise macht, meiner Meinung nach, wenig Sinn. Dies ist auch eine Fähigkeit, die Teil der Jobbeschreibung unserer Entwickler ist.

---

Auf die Bitte näher auf die Behebung von Fehlern durch Entwickler einzugehen, fügte Kelly hinzu:

---

Wie ich bereits sagte, war dieses eine vereinfachte Beschreibung. Fehlermeldungen von Einwohnern gehen nicht direkt an die Entwickler. Sie werden zuerst von der QS gelesen und reproduziert und dann von den Entwicklern behoben .

Es gibt unterschiedliche Definitionen und verschiedene Ebenen von „kritisch“, noch dazu kommen die Veränderungen „hinter den Kulissen“, die oft sehr viel kritischer sind, als es ihre verborgene Natur erahnen lässt. Es gibt immer eine große Anzahl von Themen, die Priorität erhalten, und mit einem begrenzten Entwicklungs-Team bedeutet das, dass einige Themen immer wieder ans Ende der Liste rutschen, auch wenn wir uns bemühen, dies zu verhindern. Bitte sehen Sie das nicht als Einladung, „Was ist mit Fehler X”-Postings zu senden. Bitte senden sie Bug-Reports (Fehlermeldungen) dann, wenn die Fehler auftreten.

---

Hierzu gibt es eine Seite mit Bekannten Problemen (nur auf Englisch verfügbar).