Aus EnzyklopAtys
Leda (Diskussion | Beiträge) (→Requesting other teams) |
Leda (Diskussion | Beiträge) (→Principles) |
||
| Zeile 32: | Zeile 32: | ||
Die Aufgaben, bei denen keine Probleme bekannt sind, können weiter bearbeitet oder geschlossen werden. Benachrichtige den Aufgabenentwickler, den Teammanager, das Marketingteam, die Übersetzer und/oder die Enzyklopädisten zum richtigen Zeitpunkt, damit sie ihre Arbeit machen können - die Änderung auf den nächsten Server verschieben, die Übersetzung abschließen, die Dokumentation für das Wiki schreiben, die Änderung ankündigen, Patch Notes schreiben... was auch immer ihre Arbeit ist. | Die Aufgaben, bei denen keine Probleme bekannt sind, können weiter bearbeitet oder geschlossen werden. Benachrichtige den Aufgabenentwickler, den Teammanager, das Marketingteam, die Übersetzer und/oder die Enzyklopädisten zum richtigen Zeitpunkt, damit sie ihre Arbeit machen können - die Änderung auf den nächsten Server verschieben, die Übersetzung abschließen, die Dokumentation für das Wiki schreiben, die Änderung ankündigen, Patch Notes schreiben... was auch immer ihre Arbeit ist. | ||
| − | == | + | == Prinzipien == |
| − | + | Bei der Arbeit eines Koordinators geht es nicht darum, eine bestimmte Anzahl von Aufgaben richtig zu erledigen oder eine bestimmte Anzahl von Aufgabenkommentaren zu schreiben. Gestalte deine Arbeit so, daß sie zu den aktuellen Aufgaben passt, aber beachte bitte diese Grundsätze. Jeder einzelne von ihnen hat seine Daseinsberechtigung und wird Dir helfen, deine Arbeit besser zu machen. | |
| − | === | + | === Es liegt an Dir === |
| − | + | Die Entscheidung, als Koordinator zu handeln, liegt bei Dir und in deiner Verantwortung. Meistens kann jeder ein Problem als gelöst markieren, manchmal aus Versehen, und Du wirst auch schöne Geschichten über eine glückliche Zukunft hören. Es funktioniert, wir haben es geschafft, es ist gelöst. Aber Du bist es, der einen Test durchführt, also solltest Du dich vergewissern, daß der Testgegenstand tatsächlich vorhanden ist und auf dem Zielserver läuft und daß es möglich ist, den Test überhaupt zu starten. | |
| − | + | Sie sind derjenige, der bestätigen muß, daß eine Fehlerbehebung tatsächlich auf den Spieleserver übertragen wurde. Durch eigene Tests oder durch die Eröffnung neuer Tests für Tester. Du bist es, der alle von den Testern gemeldeten Probleme erneut testet und sie den Entwicklern bestätigt. Natürlich mußt Du nicht alles selbst machen, sondern kannst auch andere Tester um Hilfe bitten. Aber es liegt in Deiner Verantwortung, welche Anweisungen Du den Testern gibst und ob sie in der Lage sind zu testen. | |
| − | + | Es liegt an Dir, keine Probleme zu akzeptieren, die eigentlich keine sind, und den Entwicklern, Übersetzern und Loristen alle Problemaspekte zu erklären. Es ist Deine Aufgabe, alle Probleme ordnungsgemäß zu schließen und sicherzustellen, daß alle Probleme gelöst oder in das Bugs Board verschoben wurden. Es ist Deine Aufgabe, andere verwandte Teams und Projekte über bestehende Probleme aus deren Bereichen oder über den Fortschritt einer Aufgabe zu informieren. | |
| − | === | + | === Alle Probleme sind behoben === |
| − | + | Stelle sicher, daß Du alle Probleme, die während der Laufzeit einer Aufgabe entdeckt wurden, verfolgst und daß alle Probleme ordnungsgemäß gelöst werden, bevor die Aufgabe abgeschlossen wird. | |
| − | * | + | * Probleme, die geklärt werden können, müssen vor dem Ende des Tests geklärt werden, da dies zu weiteren Problemen führen kann, die sich aus einem solchen Problem ergeben. |
| − | * | + | * Probleme, die im Rahmen der Testaufgabe gelöst werden können, müssen behoben, erneut getestet und die Lösung bestätigt werden, bevor die Aufgabe fortgesetzt werden kann. Die einzige Ausnahme sind kleinere Probleme beim Wechsel von einem Server zum anderen, die sich auf noch nicht vollständig fertiggestellte Funktionen beziehen. Solche Probleme können offen bleiben, müssen aber am Ende der Laufzeit der Aufgabe ordnungsgemäß behoben werden. |
| − | * | + | * Probleme, die nicht innerhalb der Aufgabe behoben werden können, in der Regel Fehler im Zusammenhang mit einer Systemfunktion, auf der die Änderung basiert, müssen in die Fehlertafel aufgenommen und dann innerhalb der Testaufgabe geschlossen werden. |
| − | + | Um ein Problem auf Seiten des Test-Teams ordnungsgemäß zu schließen, müssen Sie das Problem sowohl auf dem Board als auch im letzten PAD als erledigt markieren und den PAD-Datensatz mit Datum, Uhrzeit und Details zur Lösung des Problems kennzeichnen. Behoben und bestätigt, umgewandelt, aufgeteilt oder auf andere Probleme oder andere Aufgaben verschoben, als kein Problem gelöst, einfach Ihre Zusammenfassung über das spezifische Problem. | |
| − | === | + | === Vorschläge, nicht Entscheidungen === |
| − | + | Alle Rückmeldungen und Vorschläge der Tester sind sehr willkommen, aber denke immer daran, daß Tester nicht diejenigen sind, die Entscheidungen treffen. Dies obliegt den Entwicklern, Managern, Spieldesignern und Lorexperten, je nach Problemstellung. Eure Aufgabe ist es, andere Teams vor möglichen Problemen, Inkonsistenzen oder Regressionen zu warnen oder bessere Lösungen vorzuschlagen, aber nicht zu entscheiden, wie eine Lösung implementiert wird (falls sie wirklich ein Problem behebt), wie Regeln festgelegt werden oder ob eine Information (lore) gültig ist. | |
| − | + | Wenn Du Aufgabenstellungen verwaltest, rechne immer damit, daß eine Änderung von unerfahrenen Spielern mit unterschiedlichen Bedürfnissen und Ideen genutzt werden kann. Versuche, alle als neutral zu betrachten und versuche, gemeinsame Spielprinzipien in einem Feature zu finden und stelle sicher, daß es ausgewogen und fair für alle Spieler ist. Denke über die Auswirkungen auf das aktuelle Spiel nach, denn Entwickler oder Manager, die sich auf die Aufgabe konzentrieren, sehen es vielleicht nicht in Relation. Tester sind diejenigen, die eine Funktion als erste erleben und nutzen. | |
| − | + | Es liegt auch nicht an den Testern oder Koordinatoren zu entscheiden, ob etwas ein Fehler ist oder nicht und ob er behoben wird oder nicht. Andererseits mußt Du jedes Problem, das einer der Tester aufwirft, sorgfältig prüfen und entscheiden, ob Du das Problem an jemanden weitergibst, der eine Entscheidung treffen kann, oder ob es bereits behandelt oder behoben wurde. | |
| − | === | + | ===Wichtigkeit auf Spieler beziehen, nicht auf andere Probleme=== |
| − | + | Wir verwenden grundsätzlich drei Arten von Problemen, <font style="color: red;">rot</font> für wirklich ernste Probleme, <font style="color: orange;">orange</font> für kleinere Probleme und <font style="color: blue;">blau</font> für alle anderen wie Klärungen. Ob ein Testleiter ein Problem mit rot, orange oder blau markiert, bleibt ihm überlassen, aber die Wichtigkeit sollte sich danach richten, wie sich das Problem auf das Spielgeschehen auswirkt und nicht nach anderen Problemen. Das folgende Beispiel soll dies etwas besser erklären. | |
| − | + | Die Tester haben beim Testen der Aufgabe #123 mehrere Probleme entdeckt. Es ist möglich, zwei Dinge zu kombinieren, um Spielmechanismen auszunutzen, es fehlt ein NSC-Dialog, verschiedene fehlende Übersetzungen, falsche Anweisungen im Journal und kein Bild mit Ereignisanweisungen für neutrale Charaktere wird angezeigt. | |
| − | + | Aus dem oben Gelesenen geht hervor, dass wir 5 Probleme für die fiktive Aufgabe #123 haben werden: | |
| − | * | + | * "Kombiniere Gegenstände, um sie zu nutzen" - das sieht vielleicht schwerwiegend aus, aber überlege dir die Umstände, die es erlauben, es zu benutzen, überlege dir Variationen mit anderen Gegenständen. Überlege dir, was du eventuell tun musst <font style="color: blue;">kläre den Sachverhalt</font> zuerst. Falls es sich immer noch um einen Exploit handelt, wird es ein <font style="color: red;">rotes Problem</font>. |
| − | * | + | * "Fehlender NSC-Dialog" - hier wird es etwas schwieriger, weil wir berücksichtigen müssen, wie sehr es das Spiel beeinflusst. Wenn der Dialog nur "Danke, tschüss" sagt, ist es ein <font style="color: orange;">oranges kleines Problem</font> und wird wahrscheinlich nicht schwer zu lösen sein. Andererseits, wenn dieser spezielle Dialog eine Kette unterbricht, die Mission unmöglich oder schwer zu erfüllen macht, dann wird es ein <font style="color: red;">roter Fehler</font> und die Tatsache, dass der obige Exploit vielleicht viel wichtiger aussieht, spielt keine Rolle. Beide haben aus Sicht des Gameplays die gleiche Bedeutung, da sie das Spielerlebnis oder die Balance stark beeinflussen. |
| − | * ''' | + | * '''Verschiedene fehlende Übersetzungen''' - fehlende Übersetzungen sind normalerweise nur <font style="color: orange;">orange kleine Probleme</font> es sei denn, es verursacht andere Probleme, z. B. wenn ein Spieler wichtige Informationen nicht erhält. Dann solltest Du in Erwägung ziehen, sie zu <font style="color: red;">roten Prolemen</font> zu machen. |
| − | * ''' | + | * '''Falsche Anweisungen im Journal''' - Du musst dir überlegen, ob du zuerst Informationen zur <font style="color: blue;">Klärung</font> brauchst, was in der Anleitung stehen soll und was die Absicht des Schöpfers ist. Falls die Anweisungen wirklich falsch sind, bedenke, wie ernst das Problem ist, nur ein kleiner Tippfehler für ein <font style="color: orange;">kleines Problem</font> oder etwas Schwerwiegendes, das die Spielerfahrung beeinträchtigt und ein <font style="color: red;">rotes Problem</font> ist? |
| − | * ''' | + | * '''Kein Bild mit Ereignisanweisungen für Neutrale''' - dies könnte ein ernsthaftes <font style="color: red;">rotes Problem</font> sein, wenn es sich um ein häufiges Problem handelt, das auf etwas sehr Falsches hindeutet und die Tatsache, daß es nicht so wichtig ist, wie der Exploit, keine Rolle spielt. Andererseits, wenn der fehlende NPC-Dialog oben darauf hinweisen sollte, daß diese Funktion nicht-neutrale Attribute erfordert, ist es nur ein <font style="color: orange;">oranges kleines Problem</font>, das wahrscheinlich gelöst sein wird, wenn der fehlende Dialog behoben ist. |
| − | === | + | === Niemals Aufgaben standardisiert vorantreiben === |
| − | + | Wenn du Aufgaben auf dem Test-Team-Board verwaltest, werden sie nie standardisiert fortgesetzt. Die erste Spalte, in der die Aufgabe nach Abschluss eines Tests erscheint, ist zurück auf Warten. Die Tests müssen zuerst ausgewertet werden und die Aufgabe kann nur dann fortgesetzt werden, wenn keine bekannten Probleme dies verhindern. | |
| − | + | Um eine Aufgabe von Yubo nach Gingo weiterzuleiten, gibt es kein Problem mit Übersetzungsproblemen, da wahrscheinlich nicht alles vor dem Testen auf Yubo gemacht wurde und die Übersetzer an den Strings arbeiten werden, wenn es endgültig ist. | |
| − | + | Andererseits, wenn eine Aufgabe von Gingo zu Atys übergeht, darf es keine bekannten Probleme geben, außer solchen, die nicht zu schwerwiegend sind und nicht innerhalb des Tests gelöst werden können. Solche Probleme werden am Ende in die Fehlertabelle aufgenommen. | |
| − | === | + | === Behalte Deine Aufgaben im Auge === |
| − | + | Wenn Du dich entschlossen hast, eine Aufgabe zu leiten und als Testleiter einen Test durchzuführen, solltest Du nicht nur den Test ordnungsgemäß vorbereiten und seine Ergebnisse am Ende überprüfen, sondern auch alle paar Tage den aktuellen PAD überprüfen, um Fragen der Tester zu beantworten und den Fortschritt zu sehen. Markiere alle Teile des Berichts eines Testers, die Du bewertet hast, und gebe ihm Kommentare. Alle Änderungen und Aktualisierungen des PAD sollten in Deinem eigenen Bericht dokumentiert und mit Datum und Uhrzeit versehen werden. | |
| − | + | Wenn das PAD zu lang wird, ist das ein Zeichen dafür, daß die getestete Funktion von einem Entwickler bearbeitet werden muß, um Details zu klären oder den Test neu zu starten. Schließe den Test und überprüfe die Situation selbst. Bespreche die Situation mit den Entwicklern, Übersetzern oder Loristen, um zu klären, was möglich ist. Überprüfe die Änderungen selbst, erstelle ein neues PAD mit nur aktuellen Problemen und schließe alle Probleme im alten PAD ordnungsgemäß. Beginne neue Tests. Wenn die Entwickler etwas versprochen haben, vergewissere dich, daß sie wirklich alle Änderungen durchgeführt haben und verfolge den Fortschritt. | |
| − | === | + | === Die Arbeit endet nie === |
| − | + | Selbst wenn eine Aufgabe in der Spalte "Erledigt" gelandet ist, ist die Arbeit noch nicht vorbei. Das Testteam sollte am besten über neue Spieländerungen Bescheid wissen, und Du solltest versuchen, alle Probleme zu verfolgen, die bei den Spielern aufgetreten sind. Zögere nicht, das Problem selbst auf Gingo und, mit Rücksicht auf die Spieler, auf Atys zu testen. | |
| − | + | Solange die Aufgabe noch auf dem Test-Team-Board steht, zögere nicht, sie zurück zu verschieben und neue Probleme zu lösen. Falls die Aufgabe bereits abgeschlossen ist, solltest Du dich mit dem ursprünglichen Entwickler in Verbindung setzen, eine neue Aufgabe im Bugs-Board eröffnen oder einen neuen Test anfordern, damit das Testteam die aktuelle Situation auf Atys kennt. | |
| − | + | Falls ein Problem im Zusammenhang mit einer Aufgabe im Ryzom-Forum gemeldet wird, gebe dem Spieler Dein Feedback und gebe die Nummer der Aufgabe an, zu der das Problem hinzugefügt wurde, damit der Spieler in Zukunft nach einer bestimmten Aufgabe fragen kann und wir in der Lage sind, das Problem und die Details zu seiner Lösung zu finden. | |
Version vom 27. Mai 2023, 09:54 Uhr
!!!! WIP !!!! Die letzte Bearbeitung war von Leda am 27.05.2023.
Ein Teamkoordinator ist eine Person, die bereit ist, die Arbeit anderer zu koordinieren und all die langweilige Bürokratie des Testteams zu verwalten. Dies erfordert eine Menge zusätzlicher Zeit, Geduld und Verantwortung. Tester werden faul sein, Entwickler werden lügen, das Marketing wird Versprechungen machen und andere Teams werden keine Zeit für Ihre Probleme haben. Die Arbeit muss jedoch irgendwie erledigt werden. Wenn Du der Meinung bist, daß Du dem Team auf diese Weise helfen kannst, wird dir dieser Artikel einige Grundsätze näher bringen, wie Deine Arbeit aussehen sollte.
Es wird erwartet, daß Du den Prozess verstehst, wie Aufgaben im [Team] Testboard verwaltet werden und Du verstehst warum. Deine Mitgliedschaft in anderen Ryzom-Teams und -Projekten kann sehr hilfreich sein, insbesondere die Mitgliedschaft im Bugs-Projekt, die es Dir erlaubt, auch verwandte Aufgaben im Bugs-Board zu verwalten. Du solltest auch damit vertraut sein, wie man einen Beweis für Testzwecke erstellt.
Inhaltsverzeichnis
Theorie
Im Falle des Testteams ist die Arbeit des gesamten Teams eng mit den Aufgaben des Teamboards verbunden. Das Team wird aufgefordert, einen Test auf einem Zielserver durchzuführen, erledigt die Aufgabe und kümmert sich um alle entdeckten Probleme. Es gibt drei Hauptaufgaben, die zu einer Koordination gehören und den gesamten Testprozess miteinander verbinden, allerdings ist es nicht möglich, dir genaue Punkte zu geben, die du tun musst. Jede Aufgabe ist anders, so dass du innerhalb der Prozessprinzipien kreativ sein solltest.
Neue Aufgabe erstellen
Dies ist der Beginn aller Aufgaben. Einer der Teamkoordinatoren muß eine neue Aufgabe erstellen und eine erste Dokumentation für einen Test vorbereiten. Das bedeutet, daß Du eine neue Aufgabe in der Wartespalte des Zielservers erstellst und alle Anfragedetails beschreibst, z.B. was getestet werden soll, unter welchen Umständen, Hintergrundinformationen und ähnliches. All die Informationen, die für den zukünftigen Testleiter notwendig sind, um die Angelegenheit der Änderung vollständig zu verstehen. Diese Aufgabe wird sehr oft von Entwicklern erledigt, um einen Test anzufordern. Du kannst dazu auch den Artikel Wie man neue Tests anfordert lesen, der diesen Prozess von der anderen Seite beschreibt.
Du solltest dich vergewissern, daß alle Aspekte der Änderung (des Tests) geklärt sind und daß es keine Zweifel an allgemeinen Fragen gibt, z. B. wie hoch eine Ereignisbelohnung sein sollte oder wie lange die Abkühlung einer Mission dauern sollte. Denke daran, daß der zukünftige Testleiter so viel wie möglich wissen muß, um valide Tests für die Tester vorzubereiten.
Tests anleiten
Die Leitung einer Test-Aufgabe ist die häufigste Aufgabe, die ein Koordinator übernehmen kann. Du wählst aus den neuen (gelben) Aufgaben, die auf dem Board warten, diejenige aus, um die Du dich kümmern willst. Überprüfe die Änderungen an der Aufgabe auf dem Zielserver, um sicherzustellen, daß sie läuft, erstelle ein Test-PAD mit allen erforderlichen Anweisungen und führe selbst zumindest einen kurzen Test durch. Stelle sicher, daß Du alle notwendigen Anweisungen für die Tester bereitstellen. Denke daran, daß die Tester vielleicht nur Freiwillige sind, die helfen wollen, aber keine Erfahrung haben.
Sobald der Test abgeschlossen ist oder wenn es nicht möglich ist, mit dem Testen fortzufahren, ist es deine Aufgabe, den Test auszuwerten, alle bekannten Probleme zu verfolgen und die anderen Teams über die Ergebnisse zu informieren. Du entscheidest, ob eine Aufgabe fortgesetzt werden kann oder ob sie zurückgegeben wird.
Anfragen an andere Teams
Es kommt nur selten vor, dass ein Test ohne Probleme endet, und selbst wenn dies der Fall ist, musst du die Aufgabe noch zu Ende führen.
Aufgabe mit Problemen
Falls es Probleme gibt, gibt es drei Möglichkeiten, sie zu lösen:
- Problem ist bestätigt, aber eigentlich kein Problem - kläre alle Details mit den entsprechenden Teams und Entwicklern und schließe es, wenn es wie vorgesehen funktioniert.
- Das Problem ist bestätigt und kann während der Testphase behoben werden - leite das Problem zur Lösung an das entsprechende Team weiter
- Das Problem ist bestätigt und kann während der Testphase nicht behoben werden - füge das Problem am Ende der Lebensdauer der Aufgabe in die Fehlertafel ein
Aufgaben ohne Probleme
Die Aufgaben, bei denen keine Probleme bekannt sind, können weiter bearbeitet oder geschlossen werden. Benachrichtige den Aufgabenentwickler, den Teammanager, das Marketingteam, die Übersetzer und/oder die Enzyklopädisten zum richtigen Zeitpunkt, damit sie ihre Arbeit machen können - die Änderung auf den nächsten Server verschieben, die Übersetzung abschließen, die Dokumentation für das Wiki schreiben, die Änderung ankündigen, Patch Notes schreiben... was auch immer ihre Arbeit ist.
Prinzipien
Bei der Arbeit eines Koordinators geht es nicht darum, eine bestimmte Anzahl von Aufgaben richtig zu erledigen oder eine bestimmte Anzahl von Aufgabenkommentaren zu schreiben. Gestalte deine Arbeit so, daß sie zu den aktuellen Aufgaben passt, aber beachte bitte diese Grundsätze. Jeder einzelne von ihnen hat seine Daseinsberechtigung und wird Dir helfen, deine Arbeit besser zu machen.
Es liegt an Dir
Die Entscheidung, als Koordinator zu handeln, liegt bei Dir und in deiner Verantwortung. Meistens kann jeder ein Problem als gelöst markieren, manchmal aus Versehen, und Du wirst auch schöne Geschichten über eine glückliche Zukunft hören. Es funktioniert, wir haben es geschafft, es ist gelöst. Aber Du bist es, der einen Test durchführt, also solltest Du dich vergewissern, daß der Testgegenstand tatsächlich vorhanden ist und auf dem Zielserver läuft und daß es möglich ist, den Test überhaupt zu starten.
Sie sind derjenige, der bestätigen muß, daß eine Fehlerbehebung tatsächlich auf den Spieleserver übertragen wurde. Durch eigene Tests oder durch die Eröffnung neuer Tests für Tester. Du bist es, der alle von den Testern gemeldeten Probleme erneut testet und sie den Entwicklern bestätigt. Natürlich mußt Du nicht alles selbst machen, sondern kannst auch andere Tester um Hilfe bitten. Aber es liegt in Deiner Verantwortung, welche Anweisungen Du den Testern gibst und ob sie in der Lage sind zu testen.
Es liegt an Dir, keine Probleme zu akzeptieren, die eigentlich keine sind, und den Entwicklern, Übersetzern und Loristen alle Problemaspekte zu erklären. Es ist Deine Aufgabe, alle Probleme ordnungsgemäß zu schließen und sicherzustellen, daß alle Probleme gelöst oder in das Bugs Board verschoben wurden. Es ist Deine Aufgabe, andere verwandte Teams und Projekte über bestehende Probleme aus deren Bereichen oder über den Fortschritt einer Aufgabe zu informieren.
Alle Probleme sind behoben
Stelle sicher, daß Du alle Probleme, die während der Laufzeit einer Aufgabe entdeckt wurden, verfolgst und daß alle Probleme ordnungsgemäß gelöst werden, bevor die Aufgabe abgeschlossen wird.
- Probleme, die geklärt werden können, müssen vor dem Ende des Tests geklärt werden, da dies zu weiteren Problemen führen kann, die sich aus einem solchen Problem ergeben.
- Probleme, die im Rahmen der Testaufgabe gelöst werden können, müssen behoben, erneut getestet und die Lösung bestätigt werden, bevor die Aufgabe fortgesetzt werden kann. Die einzige Ausnahme sind kleinere Probleme beim Wechsel von einem Server zum anderen, die sich auf noch nicht vollständig fertiggestellte Funktionen beziehen. Solche Probleme können offen bleiben, müssen aber am Ende der Laufzeit der Aufgabe ordnungsgemäß behoben werden.
- Probleme, die nicht innerhalb der Aufgabe behoben werden können, in der Regel Fehler im Zusammenhang mit einer Systemfunktion, auf der die Änderung basiert, müssen in die Fehlertafel aufgenommen und dann innerhalb der Testaufgabe geschlossen werden.
Um ein Problem auf Seiten des Test-Teams ordnungsgemäß zu schließen, müssen Sie das Problem sowohl auf dem Board als auch im letzten PAD als erledigt markieren und den PAD-Datensatz mit Datum, Uhrzeit und Details zur Lösung des Problems kennzeichnen. Behoben und bestätigt, umgewandelt, aufgeteilt oder auf andere Probleme oder andere Aufgaben verschoben, als kein Problem gelöst, einfach Ihre Zusammenfassung über das spezifische Problem.
Vorschläge, nicht Entscheidungen
Alle Rückmeldungen und Vorschläge der Tester sind sehr willkommen, aber denke immer daran, daß Tester nicht diejenigen sind, die Entscheidungen treffen. Dies obliegt den Entwicklern, Managern, Spieldesignern und Lorexperten, je nach Problemstellung. Eure Aufgabe ist es, andere Teams vor möglichen Problemen, Inkonsistenzen oder Regressionen zu warnen oder bessere Lösungen vorzuschlagen, aber nicht zu entscheiden, wie eine Lösung implementiert wird (falls sie wirklich ein Problem behebt), wie Regeln festgelegt werden oder ob eine Information (lore) gültig ist.
Wenn Du Aufgabenstellungen verwaltest, rechne immer damit, daß eine Änderung von unerfahrenen Spielern mit unterschiedlichen Bedürfnissen und Ideen genutzt werden kann. Versuche, alle als neutral zu betrachten und versuche, gemeinsame Spielprinzipien in einem Feature zu finden und stelle sicher, daß es ausgewogen und fair für alle Spieler ist. Denke über die Auswirkungen auf das aktuelle Spiel nach, denn Entwickler oder Manager, die sich auf die Aufgabe konzentrieren, sehen es vielleicht nicht in Relation. Tester sind diejenigen, die eine Funktion als erste erleben und nutzen.
Es liegt auch nicht an den Testern oder Koordinatoren zu entscheiden, ob etwas ein Fehler ist oder nicht und ob er behoben wird oder nicht. Andererseits mußt Du jedes Problem, das einer der Tester aufwirft, sorgfältig prüfen und entscheiden, ob Du das Problem an jemanden weitergibst, der eine Entscheidung treffen kann, oder ob es bereits behandelt oder behoben wurde.
Wichtigkeit auf Spieler beziehen, nicht auf andere Probleme
Wir verwenden grundsätzlich drei Arten von Problemen, rot für wirklich ernste Probleme, orange für kleinere Probleme und blau für alle anderen wie Klärungen. Ob ein Testleiter ein Problem mit rot, orange oder blau markiert, bleibt ihm überlassen, aber die Wichtigkeit sollte sich danach richten, wie sich das Problem auf das Spielgeschehen auswirkt und nicht nach anderen Problemen. Das folgende Beispiel soll dies etwas besser erklären.
Die Tester haben beim Testen der Aufgabe #123 mehrere Probleme entdeckt. Es ist möglich, zwei Dinge zu kombinieren, um Spielmechanismen auszunutzen, es fehlt ein NSC-Dialog, verschiedene fehlende Übersetzungen, falsche Anweisungen im Journal und kein Bild mit Ereignisanweisungen für neutrale Charaktere wird angezeigt.
Aus dem oben Gelesenen geht hervor, dass wir 5 Probleme für die fiktive Aufgabe #123 haben werden:
- "Kombiniere Gegenstände, um sie zu nutzen" - das sieht vielleicht schwerwiegend aus, aber überlege dir die Umstände, die es erlauben, es zu benutzen, überlege dir Variationen mit anderen Gegenständen. Überlege dir, was du eventuell tun musst kläre den Sachverhalt zuerst. Falls es sich immer noch um einen Exploit handelt, wird es ein rotes Problem.
- "Fehlender NSC-Dialog" - hier wird es etwas schwieriger, weil wir berücksichtigen müssen, wie sehr es das Spiel beeinflusst. Wenn der Dialog nur "Danke, tschüss" sagt, ist es ein oranges kleines Problem und wird wahrscheinlich nicht schwer zu lösen sein. Andererseits, wenn dieser spezielle Dialog eine Kette unterbricht, die Mission unmöglich oder schwer zu erfüllen macht, dann wird es ein roter Fehler und die Tatsache, dass der obige Exploit vielleicht viel wichtiger aussieht, spielt keine Rolle. Beide haben aus Sicht des Gameplays die gleiche Bedeutung, da sie das Spielerlebnis oder die Balance stark beeinflussen.
- Verschiedene fehlende Übersetzungen - fehlende Übersetzungen sind normalerweise nur orange kleine Probleme es sei denn, es verursacht andere Probleme, z. B. wenn ein Spieler wichtige Informationen nicht erhält. Dann solltest Du in Erwägung ziehen, sie zu roten Prolemen zu machen.
- Falsche Anweisungen im Journal - Du musst dir überlegen, ob du zuerst Informationen zur Klärung brauchst, was in der Anleitung stehen soll und was die Absicht des Schöpfers ist. Falls die Anweisungen wirklich falsch sind, bedenke, wie ernst das Problem ist, nur ein kleiner Tippfehler für ein kleines Problem oder etwas Schwerwiegendes, das die Spielerfahrung beeinträchtigt und ein rotes Problem ist?
- Kein Bild mit Ereignisanweisungen für Neutrale - dies könnte ein ernsthaftes rotes Problem sein, wenn es sich um ein häufiges Problem handelt, das auf etwas sehr Falsches hindeutet und die Tatsache, daß es nicht so wichtig ist, wie der Exploit, keine Rolle spielt. Andererseits, wenn der fehlende NPC-Dialog oben darauf hinweisen sollte, daß diese Funktion nicht-neutrale Attribute erfordert, ist es nur ein oranges kleines Problem, das wahrscheinlich gelöst sein wird, wenn der fehlende Dialog behoben ist.
Niemals Aufgaben standardisiert vorantreiben
Wenn du Aufgaben auf dem Test-Team-Board verwaltest, werden sie nie standardisiert fortgesetzt. Die erste Spalte, in der die Aufgabe nach Abschluss eines Tests erscheint, ist zurück auf Warten. Die Tests müssen zuerst ausgewertet werden und die Aufgabe kann nur dann fortgesetzt werden, wenn keine bekannten Probleme dies verhindern.
Um eine Aufgabe von Yubo nach Gingo weiterzuleiten, gibt es kein Problem mit Übersetzungsproblemen, da wahrscheinlich nicht alles vor dem Testen auf Yubo gemacht wurde und die Übersetzer an den Strings arbeiten werden, wenn es endgültig ist.
Andererseits, wenn eine Aufgabe von Gingo zu Atys übergeht, darf es keine bekannten Probleme geben, außer solchen, die nicht zu schwerwiegend sind und nicht innerhalb des Tests gelöst werden können. Solche Probleme werden am Ende in die Fehlertabelle aufgenommen.
Behalte Deine Aufgaben im Auge
Wenn Du dich entschlossen hast, eine Aufgabe zu leiten und als Testleiter einen Test durchzuführen, solltest Du nicht nur den Test ordnungsgemäß vorbereiten und seine Ergebnisse am Ende überprüfen, sondern auch alle paar Tage den aktuellen PAD überprüfen, um Fragen der Tester zu beantworten und den Fortschritt zu sehen. Markiere alle Teile des Berichts eines Testers, die Du bewertet hast, und gebe ihm Kommentare. Alle Änderungen und Aktualisierungen des PAD sollten in Deinem eigenen Bericht dokumentiert und mit Datum und Uhrzeit versehen werden.
Wenn das PAD zu lang wird, ist das ein Zeichen dafür, daß die getestete Funktion von einem Entwickler bearbeitet werden muß, um Details zu klären oder den Test neu zu starten. Schließe den Test und überprüfe die Situation selbst. Bespreche die Situation mit den Entwicklern, Übersetzern oder Loristen, um zu klären, was möglich ist. Überprüfe die Änderungen selbst, erstelle ein neues PAD mit nur aktuellen Problemen und schließe alle Probleme im alten PAD ordnungsgemäß. Beginne neue Tests. Wenn die Entwickler etwas versprochen haben, vergewissere dich, daß sie wirklich alle Änderungen durchgeführt haben und verfolge den Fortschritt.
Die Arbeit endet nie
Selbst wenn eine Aufgabe in der Spalte "Erledigt" gelandet ist, ist die Arbeit noch nicht vorbei. Das Testteam sollte am besten über neue Spieländerungen Bescheid wissen, und Du solltest versuchen, alle Probleme zu verfolgen, die bei den Spielern aufgetreten sind. Zögere nicht, das Problem selbst auf Gingo und, mit Rücksicht auf die Spieler, auf Atys zu testen.
Solange die Aufgabe noch auf dem Test-Team-Board steht, zögere nicht, sie zurück zu verschieben und neue Probleme zu lösen. Falls die Aufgabe bereits abgeschlossen ist, solltest Du dich mit dem ursprünglichen Entwickler in Verbindung setzen, eine neue Aufgabe im Bugs-Board eröffnen oder einen neuen Test anfordern, damit das Testteam die aktuelle Situation auf Atys kennt.
Falls ein Problem im Zusammenhang mit einer Aufgabe im Ryzom-Forum gemeldet wird, gebe dem Spieler Dein Feedback und gebe die Nummer der Aufgabe an, zu der das Problem hinzugefügt wurde, damit der Spieler in Zukunft nach einer bestimmten Aufgabe fragen kann und wir in der Lage sind, das Problem und die Details zu seiner Lösung zu finden.
