Koordinator eines Testteams sein - Versionsgeschichte

Leda am 27. Mai 2023 um 07:56 Uhr

2023-05-27T07:56:26Z

Leda am 27. Mai 2023 um 07:55 Uhr

2023-05-27T07:55:31Z

Leda: /* Die Arbeit endet nie */

2023-05-27T07:55:15Z

‎Die Arbeit endet nie

Leda: /* Principles */

2023-05-27T07:54:08Z

‎Principles

Änderungen zeigen

Leda: /* Requesting other teams */

2023-05-27T07:22:11Z

‎Requesting other teams

Leda: /* Testing leadership */

2023-05-27T07:17:33Z

‎Testing leadership

Leda: /* Neue Aufgabe erstellen */

2023-05-27T07:12:53Z

‎Neue Aufgabe erstellen

Leda: /* New task creation */

2023-05-27T07:12:18Z

‎New task creation

Leda: Die Seite wurde neu angelegt: „{{WIP}}{{Trad|DE=Koordinator eines Testteams sein|EN=Being a Test Team Coordinator|palette=team|H=1}} Ein Teamkoordinator ist eine Perso…“

2023-05-27T06:09:10Z

Die Seite wurde neu angelegt: „{{WIP}}<noinclude>{{Trad|DE=Koordinator eines Testteams sein|EN=Being a Test Team Coordinator|palette=team|H=1}}</noinclude> Ein Teamkoordinator ist eine Perso…“

Neue Seite

{{WIP}}<noinclude>{{Trad|DE=Koordinator eines Testteams sein|EN=Being a Test Team Coordinator|palette=team|H=1}}</noinclude>
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|Beweis]] für Testzwecke erstellt.

== 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.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor issues in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that are not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.
To properly close an issue on the Test team side you need to mark the issue as done on the board as well as in the latest PAD and also mark the PAD record with date, time and details about how the issue was resolved. Fixed and confirmed, transformed, splitted or moved to other issues or other tasks, resolved as not being an issue, simply your summary over the specific issue.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

===Relate importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Work never ends===
Even after a task has landed in the Done column, the work is not over. The Test team should know the most about new game changes and you should try to track all issues players have experienced. Do not hesitate to go and test the issue yourself on Gingo and, with respect to players, on Atys.

While the task is still on the Test team board, do not hesitate to move it back and rise new issues to solve. In case the task is already completed, consider contacting the original developer, opening new task on Bugs board or request new testing so the Test team knows current situation on Atys.

In case any task related issue is reported on the Ryzom forum, give your feedback to the player and provide the task number where the issue was added so the player can ask about specific task in the future and we will be able to find the issue and details about its solution.

← Nächstältere Version		Version vom 27. Mai 2023, 07:55 Uhr
Zeile 1:		Zeile 1:
−	~~{{WIP}}~~<noinclude>{{Trad\|DE=Koordinator eines Testteams sein\|EN=Being a Test Team Coordinator\|palette=team\|H=1}}</noinclude>	+	<noinclude>{{Trad\|DE=Koordinator eines Testteams sein\|EN=Being a Test Team Coordinator\|palette=team\|H=1}}</noinclude>
	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.		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.

← Nächstältere Version		Version vom 27. Mai 2023, 07:55 Uhr
Zeile 86:		Zeile 86:

	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.		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.
		+
		+	<noinclude>
		+	[[Kategorie:Test-Team]]
		+	</noinclude>

@@ Zeile 19: / Zeile 19: @@
 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.
-===Requesting other teams===
+=== Anfragen an andere Teams ===
-[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
+[[File:Test board scheme.png|thumb|alt=Schema für die Organisation der Test-Boards|Schema für die Organisation der Test-Boards]]
-It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.
+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.
-====Task with issues====
+==== Aufgabe mit Problemen ====
-In case there are any issues, there are three options how to resolve them:
+Falls es Probleme gibt, gibt es drei Möglichkeiten, sie zu lösen:
-* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
+* 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.
-* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
+* Das Problem ist bestätigt und kann während der Testphase behoben werden - leite das Problem zur Lösung an das entsprechende Team weiter
-* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime
+* 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
-====Tasks without issues====
+==== Aufgaben ohne Probleme ====
-Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.
+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.
 ==Principles==

@@ Zeile 13: / Zeile 13: @@
 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.
-===Testing leadership===
+=== Tests anleiten ===
-[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
+[[File:Tteam task open.png|thumb|alt=Aufgabe des Testteams zum Testen geöffnet|Aufgabe des Testteams zum Testen geöffnet]]
-To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.
+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.
-Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.
+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.
 ===Requesting other teams===

@@ Zeile 9: / Zeile 9: @@
 === Neue Aufgabe erstellen ===
 [[File:Tteam task new.png|thumb|alt=Test Team Board-Aufgabe bereit zur Bearbeitung|Test Team Board-Aufgabe bereit zur Bearbeitung]]
-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 einen neuen Test anfordert]] lesen, der diesen Prozess von der anderen Seite beschreibt.
+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.

@@ Zeile 2: / Zeile 2: @@
 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|Beweis]] für Testzwecke erstellt.
+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 [[Das Test-Team-Handbuch/Beweise schaffen|Beweis]] für Testzwecke erstellt.
 == Theorie ==

@@ Zeile 7: / Zeile 7: @@
 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.
-===New task creation===
+=== Neue Aufgabe erstellen ===
-[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
+[[File:Tteam task new.png|thumb|alt=Test Team Board-Aufgabe bereit zur Bearbeitung|Test Team Board-Aufgabe bereit zur Bearbeitung]]
-This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.
+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 einen neuen Test anfordert]] lesen, der diesen Prozess von der anderen Seite beschreibt.
-You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.
+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.
 ===Testing leadership===