Aus EnzyklopAtys
(Die Seite wurde neu angelegt: „<noinclude>{{Trad|DE=Das Test-Team-Handbuch/6 - Tipps für den Testbericht|EN=The Test Team Handbook/6 - Testing report tips|H=1}}</noinclude> This document is…“) |
K |
||
| Zeile 1: | Zeile 1: | ||
<noinclude>{{Trad|DE=Das Test-Team-Handbuch/6 - Tipps für den Testbericht|EN=The Test Team Handbook/6 - Testing report tips|H=1}}</noinclude> | <noinclude>{{Trad|DE=Das Test-Team-Handbuch/6 - Tipps für den Testbericht|EN=The Test Team Handbook/6 - Testing report tips|H=1}}</noinclude> | ||
| − | + | Dieses Dokument ist eine Sammlung von Tipps, die für jeden Testbericht sehr wichtig sind. Jedes Thema ist wichtig und hat einen Grund. Es ist nicht möglich, ein Dokument zu schreiben, das Ihnen beibringt, ein guter Tester zu sein, oder das alle Situationen abdeckt, die auftreten können. Dies sind einige hervorgehobene wichtige Punkte, aber Ihr persönlicher Einsatz und Wille ist der zweite und nicht weniger wichtige Teil Ihrer Arbeit. | |
| − | = | + | = Bericht zum letzten PAD = |
| − | + | Als Tester sollten Sie alle Ihre Berichte in das neueste [[Dateiformate#Die_.pad.27s|Test-PAD]] einfügen, das sich auf eine Aufgabe bezieht, an der Sie gerade arbeiten. Falls die Aufgabe mehr als einen PAD-Link enthält, verwenden Sie immer den neuesten. Es gibt ein [https://cloud.ryzom.com/f/36218 selbsterklärendes PAD-Beispiel] sowie ein [https://cloud.ryzom.com/f/36039 PAD mit grundlegender Hilfe] zur PAD-Organisation. Die tatsächliche Form der einzelnen Test-PADs ist vollständig dem aktuellen Testleiter (einem Koordinator, der den aktuellen Test verwaltet) überlassen, jedoch werden alle PADs ähnlich sein, da ähnliche Informationen erfasst werden müssen. | |
| − | + | Für den Fall, dass die Aufgabe kein PAD hat, der Test aber offen ist (was sehr selten vorkommt), können Sie Ihren Bericht direkt in den Aufgabenkommentaren verfassen. | |
| − | = | + | = Details zur Testumgebung bereitstellen = |
| − | + | Dies ist die wichtigste und wesentlichste Information, die Sie angeben. Ihr aktueller Zeichenname, der zu Testzwecken verwendet wird, ist nicht so wichtig und könnte nur nützlich sein, wenn ein Entwickler Datenbankdetails in Bezug auf ihn überprüfen muss. Es ist viel wichtiger, uns dies mitzuteilen: | |
| − | * '''Tester name''' - | + | * '''Tester name''' - den Namen, den Sie im Testteam verwenden. Möglicherweise geht aus Ihrem Bericht nicht alles klar hervor und ein Koordinator muß mit Ihnen über Einzelheiten sprechen. |
| − | * '''Platform''' - | + | * '''Platform''' - Name und Version Ihres Betriebssystems, einschließlich der Information, ob es sich um 32 oder 64 Bit handelt. Einige Probleme können aus verschiedenen Gründen plattformspezifisch sein. |
| − | * '''Language''' - | + | * '''Language''' - Ihre Ryzom-Client-Locales, die Sie während Ihrer Tests verwendet haben. Einige Probleme können aus verschiedenen Gründen sprachspezifisch sein. |
| − | + | Es gibt auch einige spezifische Informationen, die für einen bestimmten Test benötigt werden (z.B. die Auflösung des Bildschirms). All diese Informationen werden normalerweise gespeichert im <font style="color: green;">'''Testers'''</font>-Abschnitt des PADs. Falls Sie verschiedene Kombinationen verwenden, denken Sie daran, alle aufzulisten und anzugeben, ob ein entdecktes Problem für alle oder nur für einige dieser Kombinationen gilt. | |
| − | = | + | = Anweisungen sorgfältig lesen = |
| − | + | Jeder Test-PAD enthält normalerweise einen Abschnitt mit einer allgemeinen <font style="color: green;">'''Beschreibung'''</font>. Sie finden dort einige Details über die Änderung, die Sie testen, und optional Details über bekannte Probleme, behobene Probleme, mögliche Belohnungen, allgemeine Mechanismen der Änderung oder Debug-/Tester-Tools für Ihre Tests. | |
| − | + | Ein weiterer sehr wichtiger Abschnitt ist <font style="color: green;">'''Anweisungen'''</font>, wo Sie genauere Informationen darüber finden, welche Figur Sie für den Test vorbereiten müssen, gegebenenfalls mit Tipps, wie Sie das tun können, und in der Regel eine Liste der Dinge, die wir testen müssen. Ihre Arbeit sollte jedoch nicht hier enden. | |
| − | = | + | = Geben Sie Datum und Uhrzeit Ihrer Prüfung an = |
| − | + | Alle Ihre Berichte, Fragen und Rückmeldungen gehen an die <font style="color: green;">'''Reports'''</font>-Abteilung. Beginnen Sie einen neuen Bericht immer mit Datum und Uhrzeit, zu der die Prüfung durchgeführt wurde, einschließlich der Zeitzone. Dies ist aus mehreren Gründen wichtig: | |
| − | * | + | * Aktiv entwickelte Dinge können sich im Laufe der Zeit ändern und wir müssen wissen, ob Ihr Bericht vor oder nach einer bestimmten Änderung erstellt wurde. |
| − | * Server | + | * Es kann sein, daß der Server zum Zeitpunkt Ihres Berichts technische Schwierigkeiten hat und daß einige der entdeckten Probleme nicht direkt mit der Aufgabe zusammenhängen. |
| − | = | + | = Fragen Sie, wenn Sie sich verlaufen haben = |
| − | + | Keiner weiß alles. Falls Sie die Materie einer Änderung nicht verstehen, die Funktionsweise nicht klar ist oder Sie ein Verhalten entdeckt haben, das nicht durch die PAD-Anweisungen abgedeckt ist, fragen Sie danach. Jede Aufgabe hat einen Entwickler, der im PAD und auch als Sticker auf der Aufgabe erwähnt wird. Jeder geöffnete Test hat auch einen Testleiter, einen Koordinator, der sich um den aktuellen Test kümmert. Fragen Sie sie nach Details. Wir arbeiten alle daran, Ryzom besser zu machen, also sollten Sie nicht zögern, auch direkt im [https://chat.ryzom.com/group/t-test #t-test]-Kanal zu fragen. | |
| − | = | + | = Alles berichten = |
| − | + | Ja, Sie sollten alle Themen in den Anweisungen wiedergeben, aber es ist auch wichtig, daß Sie alle möglichen damit zusammenhängenden Details angeben können. Ihr Bericht sollte beschreiben, was und wie Sie den Test durchgeführt haben und alle damit verbundenen Umstände. Beschreiben Sie Ihre Tätigkeit, vor allem, wenn Sie ein Problem entdecken. Legen Sie Ihrem Bericht Screenshots bei oder nehmen Sie ein Video auf, das die gesamte Situation festhält. Lesen Sie den Artikel [[Das Test-Team-Handbuch/Beweise schaffen|Beweise schaffen]], um zu erfahren, wie man das macht. | |
| − | + | Ihr Bericht sollte auch teilweise ein Feedback für den Entwickler oder den Testleiter sein und zögern Sie nicht, bessere Lösungen für bestimmte Situationen vorzuschlagen. Denken Sie aus der Sicht der Spieler: | |
| − | * | + | * Überlegen Sie, was die Spieler mit dem Feature erleben werden. |
| − | * | + | * Überlegen Sie, welche Probleme sie haben könnten, wenn sie die Funktion allein oder in Kombination mit anderen Spielmechaniken verwenden. |
| − | * | + | * Denken Sie daran, daß die Spieler Einschränkungen haben könnten (Sprachbarrieren, Farbenblindheit, Behinderungen...) |
| − | * | + | * Bedenken Sie, daß die Spieler vielleicht nicht so erfahren sind wie Sie |
| − | = | + | = Behalten Sie Ihre Arbeit im Auge = |
| − | + | Ihre Arbeit endet nicht mit einem schönen, glänzenden Bericht voller Bilder. Kommen Sie in ein paar Tagen wieder und überprüfen Sie, ob Ihr Bericht überprüft wurde und alle Probleme in der <font style="color: green;">'''Issues'''</font>-Sektion sind. Fragen Sie die Koordinatoren und Entwickler nach dem Fortschritt. Wiederholen Sie Ihre Fragen, falls Sie keine Antwort erhalten haben, entweder im PAD oder im Chat. | |
| − | + | Seien Sie nicht zu faul, eine neue Figur vorzubereiten und Ihre Tests zu wiederholen. Innerhalb eines Berichts (einer Testsitzung) sollten Sie entdeckte Probleme untersuchen und vollständig beschreiben, aber auch nach einem Fortschritt. Kommen Sie zurück und testen Sie alles erneut, erstellen Sie einen neuen Bericht, der die letzten Änderungen widerspiegelt. Bestätigen Sie von anderen entdeckte Probleme, bestätigen Sie Problembehebungen. Sie verfügen über die nötige Intelligenz, Erfahrung und Kreativität. Deshalb brauchen wir Sie. Ansonsten könnte eine Maschine Ihre Arbeit erledigen. | |
| − | = | + | = Testserver aufbrechen, aber auf Atys diskret sein= |
| − | + | Wenn Sie auf Yubo oder Gingo testen, suchen Sie immer nach Möglichkeiten, wie Sie etwas kaputt machen oder ausnutzen können. Zögern Sie nicht, es zu tun. Besser brechen Sie einen Test-Server, als daß es später die Spieler mit Atys tun. Und seien Sie nicht so naiv zu glauben, daß die Spieler es nicht versuchen werden. Spielen Sie dumm, suchen Sie nach Wegen, wie man Dinge auf unerwartete Weise nutzen kann. Kombinieren Sie Dinge, auch wenn es sinnlos erscheint. Beschädigen Sie die Konfigurationsdatei der Funktionen. Mißbrauchen Sie die Benutzeroberfläche. Wird nach einer Zahl gefragt? Geben Sie eine Zeichenkette ein. Erwartet es, daß Sie auf einen Link oder eine Schaltfläche klicken? Laden Sie das Fenster einige Male neu. Zerstören Sie es. ... | |
| − | + | Völlig anders ist die Situation beim Testen auf Atys. Testen Sie, aber denken Sie immer an die normalen Spieler, die gekommen sind, um das Spiel zu genießen. Falls Sie den Verdacht haben, daß etwas andere beeinträchtigen könnte... | |
| − | * | + | * Machen Sie zuerst einen ähnlichen Test auf Gingo |
| − | * | + | * Konsultieren Sie als nächstes die Entwickler. |
| − | + | Sie sollten immer unauffällig sein und auf jeden Fall die folgenden Dinge vermeiden: | |
| − | * | + | * Keine Details für die Öffentlichkeit spoilern, die Spieler sollen Spaß haben und Dinge selbst entdecken |
| − | * | + | * Belästigen Sie andere Spieler nicht, lassen Sie sie die Spielfunktionen genießen und besetzen Sie z.B. nicht den Platz/das Spiel |
| − | * | + | * Verwenden Sie Exploits nicht aus anderen Gründen als zum erneuten Testen (oder Sie werden gebannt) |
<noinclude> | <noinclude> | ||
Aktuelle Version vom 22. März 2022, 11:36 Uhr
Dieses Dokument ist eine Sammlung von Tipps, die für jeden Testbericht sehr wichtig sind. Jedes Thema ist wichtig und hat einen Grund. Es ist nicht möglich, ein Dokument zu schreiben, das Ihnen beibringt, ein guter Tester zu sein, oder das alle Situationen abdeckt, die auftreten können. Dies sind einige hervorgehobene wichtige Punkte, aber Ihr persönlicher Einsatz und Wille ist der zweite und nicht weniger wichtige Teil Ihrer Arbeit.
Inhaltsverzeichnis
Bericht zum letzten PAD
Als Tester sollten Sie alle Ihre Berichte in das neueste Test-PAD einfügen, das sich auf eine Aufgabe bezieht, an der Sie gerade arbeiten. Falls die Aufgabe mehr als einen PAD-Link enthält, verwenden Sie immer den neuesten. Es gibt ein selbsterklärendes PAD-Beispiel sowie ein PAD mit grundlegender Hilfe zur PAD-Organisation. Die tatsächliche Form der einzelnen Test-PADs ist vollständig dem aktuellen Testleiter (einem Koordinator, der den aktuellen Test verwaltet) überlassen, jedoch werden alle PADs ähnlich sein, da ähnliche Informationen erfasst werden müssen.
Für den Fall, dass die Aufgabe kein PAD hat, der Test aber offen ist (was sehr selten vorkommt), können Sie Ihren Bericht direkt in den Aufgabenkommentaren verfassen.
Details zur Testumgebung bereitstellen
Dies ist die wichtigste und wesentlichste Information, die Sie angeben. Ihr aktueller Zeichenname, der zu Testzwecken verwendet wird, ist nicht so wichtig und könnte nur nützlich sein, wenn ein Entwickler Datenbankdetails in Bezug auf ihn überprüfen muss. Es ist viel wichtiger, uns dies mitzuteilen:
- Tester name - den Namen, den Sie im Testteam verwenden. Möglicherweise geht aus Ihrem Bericht nicht alles klar hervor und ein Koordinator muß mit Ihnen über Einzelheiten sprechen.
- Platform - Name und Version Ihres Betriebssystems, einschließlich der Information, ob es sich um 32 oder 64 Bit handelt. Einige Probleme können aus verschiedenen Gründen plattformspezifisch sein.
- Language - Ihre Ryzom-Client-Locales, die Sie während Ihrer Tests verwendet haben. Einige Probleme können aus verschiedenen Gründen sprachspezifisch sein.
Es gibt auch einige spezifische Informationen, die für einen bestimmten Test benötigt werden (z.B. die Auflösung des Bildschirms). All diese Informationen werden normalerweise gespeichert im Testers-Abschnitt des PADs. Falls Sie verschiedene Kombinationen verwenden, denken Sie daran, alle aufzulisten und anzugeben, ob ein entdecktes Problem für alle oder nur für einige dieser Kombinationen gilt.
Anweisungen sorgfältig lesen
Jeder Test-PAD enthält normalerweise einen Abschnitt mit einer allgemeinen Beschreibung. Sie finden dort einige Details über die Änderung, die Sie testen, und optional Details über bekannte Probleme, behobene Probleme, mögliche Belohnungen, allgemeine Mechanismen der Änderung oder Debug-/Tester-Tools für Ihre Tests.
Ein weiterer sehr wichtiger Abschnitt ist Anweisungen, wo Sie genauere Informationen darüber finden, welche Figur Sie für den Test vorbereiten müssen, gegebenenfalls mit Tipps, wie Sie das tun können, und in der Regel eine Liste der Dinge, die wir testen müssen. Ihre Arbeit sollte jedoch nicht hier enden.
Geben Sie Datum und Uhrzeit Ihrer Prüfung an
Alle Ihre Berichte, Fragen und Rückmeldungen gehen an die Reports-Abteilung. Beginnen Sie einen neuen Bericht immer mit Datum und Uhrzeit, zu der die Prüfung durchgeführt wurde, einschließlich der Zeitzone. Dies ist aus mehreren Gründen wichtig:
- Aktiv entwickelte Dinge können sich im Laufe der Zeit ändern und wir müssen wissen, ob Ihr Bericht vor oder nach einer bestimmten Änderung erstellt wurde.
- Es kann sein, daß der Server zum Zeitpunkt Ihres Berichts technische Schwierigkeiten hat und daß einige der entdeckten Probleme nicht direkt mit der Aufgabe zusammenhängen.
Fragen Sie, wenn Sie sich verlaufen haben
Keiner weiß alles. Falls Sie die Materie einer Änderung nicht verstehen, die Funktionsweise nicht klar ist oder Sie ein Verhalten entdeckt haben, das nicht durch die PAD-Anweisungen abgedeckt ist, fragen Sie danach. Jede Aufgabe hat einen Entwickler, der im PAD und auch als Sticker auf der Aufgabe erwähnt wird. Jeder geöffnete Test hat auch einen Testleiter, einen Koordinator, der sich um den aktuellen Test kümmert. Fragen Sie sie nach Details. Wir arbeiten alle daran, Ryzom besser zu machen, also sollten Sie nicht zögern, auch direkt im #t-test-Kanal zu fragen.
Alles berichten
Ja, Sie sollten alle Themen in den Anweisungen wiedergeben, aber es ist auch wichtig, daß Sie alle möglichen damit zusammenhängenden Details angeben können. Ihr Bericht sollte beschreiben, was und wie Sie den Test durchgeführt haben und alle damit verbundenen Umstände. Beschreiben Sie Ihre Tätigkeit, vor allem, wenn Sie ein Problem entdecken. Legen Sie Ihrem Bericht Screenshots bei oder nehmen Sie ein Video auf, das die gesamte Situation festhält. Lesen Sie den Artikel Beweise schaffen, um zu erfahren, wie man das macht.
Ihr Bericht sollte auch teilweise ein Feedback für den Entwickler oder den Testleiter sein und zögern Sie nicht, bessere Lösungen für bestimmte Situationen vorzuschlagen. Denken Sie aus der Sicht der Spieler:
- Überlegen Sie, was die Spieler mit dem Feature erleben werden.
- Überlegen Sie, welche Probleme sie haben könnten, wenn sie die Funktion allein oder in Kombination mit anderen Spielmechaniken verwenden.
- Denken Sie daran, daß die Spieler Einschränkungen haben könnten (Sprachbarrieren, Farbenblindheit, Behinderungen...)
- Bedenken Sie, daß die Spieler vielleicht nicht so erfahren sind wie Sie
Behalten Sie Ihre Arbeit im Auge
Ihre Arbeit endet nicht mit einem schönen, glänzenden Bericht voller Bilder. Kommen Sie in ein paar Tagen wieder und überprüfen Sie, ob Ihr Bericht überprüft wurde und alle Probleme in der Issues-Sektion sind. Fragen Sie die Koordinatoren und Entwickler nach dem Fortschritt. Wiederholen Sie Ihre Fragen, falls Sie keine Antwort erhalten haben, entweder im PAD oder im Chat.
Seien Sie nicht zu faul, eine neue Figur vorzubereiten und Ihre Tests zu wiederholen. Innerhalb eines Berichts (einer Testsitzung) sollten Sie entdeckte Probleme untersuchen und vollständig beschreiben, aber auch nach einem Fortschritt. Kommen Sie zurück und testen Sie alles erneut, erstellen Sie einen neuen Bericht, der die letzten Änderungen widerspiegelt. Bestätigen Sie von anderen entdeckte Probleme, bestätigen Sie Problembehebungen. Sie verfügen über die nötige Intelligenz, Erfahrung und Kreativität. Deshalb brauchen wir Sie. Ansonsten könnte eine Maschine Ihre Arbeit erledigen.
Testserver aufbrechen, aber auf Atys diskret sein
Wenn Sie auf Yubo oder Gingo testen, suchen Sie immer nach Möglichkeiten, wie Sie etwas kaputt machen oder ausnutzen können. Zögern Sie nicht, es zu tun. Besser brechen Sie einen Test-Server, als daß es später die Spieler mit Atys tun. Und seien Sie nicht so naiv zu glauben, daß die Spieler es nicht versuchen werden. Spielen Sie dumm, suchen Sie nach Wegen, wie man Dinge auf unerwartete Weise nutzen kann. Kombinieren Sie Dinge, auch wenn es sinnlos erscheint. Beschädigen Sie die Konfigurationsdatei der Funktionen. Mißbrauchen Sie die Benutzeroberfläche. Wird nach einer Zahl gefragt? Geben Sie eine Zeichenkette ein. Erwartet es, daß Sie auf einen Link oder eine Schaltfläche klicken? Laden Sie das Fenster einige Male neu. Zerstören Sie es. ...
Völlig anders ist die Situation beim Testen auf Atys. Testen Sie, aber denken Sie immer an die normalen Spieler, die gekommen sind, um das Spiel zu genießen. Falls Sie den Verdacht haben, daß etwas andere beeinträchtigen könnte...
- Machen Sie zuerst einen ähnlichen Test auf Gingo
- Konsultieren Sie als nächstes die Entwickler.
Sie sollten immer unauffällig sein und auf jeden Fall die folgenden Dinge vermeiden:
- Keine Details für die Öffentlichkeit spoilern, die Spieler sollen Spaß haben und Dinge selbst entdecken
- Belästigen Sie andere Spieler nicht, lassen Sie sie die Spielfunktionen genießen und besetzen Sie z.B. nicht den Platz/das Spiel
- Verwenden Sie Exploits nicht aus anderen Gründen als zum erneuten Testen (oder Sie werden gebannt)
