Being a Test Team Coordinator - Revision history

Leda at 06:05, 27 May 2023

2023-05-27T06:05:27Z

Moniq: /* All issues are resolved */ extended

2020-12-25T17:31:52Z

‎All issues are resolved: extended

Moniq: /* All issues are resolved */ typos

2020-12-25T17:26:15Z

‎All issues are resolved: typos

Moniq: /* Principles */ +principle, order adjusted

2020-12-25T17:22:43Z

‎Principles: +principle, order adjusted

Moniq: /* Principles */ order changed

2020-12-25T17:08:31Z

‎Principles: order changed

Moniq: /* Never trust others */ rewritten, extended

2020-12-25T17:04:32Z

‎Never trust others: rewritten, extended

Moniq: /* Relate an issue importance to players not to other issues */ one point rewritten

2020-12-25T16:53:56Z

‎Relate an issue importance to players not to other issues: one point rewritten

Moniq: /* Relate an issue importance to players not to other issues */ +bold

2020-12-25T16:47:11Z

‎Relate an issue importance to players not to other issues: +bold

Moniq: /* Relate an issue importance to players not to other issues */ -typo

2020-12-25T16:45:48Z

‎Relate an issue importance to players not to other issues: -typo

Moniq: /* Testing leadership */ 2 paragraphs

2020-12-25T16:44:09Z

‎Testing leadership: 2 paragraphs

← Older revision		Revision as of 06:05, 27 May 2023
Line 1:		Line 1:
−	{{WIP}}	+	{{WIP}}<noinclude>{{Trad\|DE=Koordinator eines Testteams sein\|EN=Being a Test Team Coordinator\|palette=team\|H=1}}</noinclude>
	A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.		A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

@@ Line 47: / Line 47: @@
 * 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.
 ===Make suggestions not decisions===

@@ Line 45: / Line 45: @@
 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 tasks 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 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 is 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.
+* 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.
 ===Make suggestions not decisions===

@@ Line 41: / Line 41: @@
 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.
 ===Make suggestions not decisions===
@@ Line 73: / Line 79: @@
 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.
-===All issues are resolved===
+===Work never ends===
-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.
+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.
-* 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 tasks 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.
+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.
-* Issues that is 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.

@@ Line 35: / Line 35: @@
 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.
-===All issues are resolved===
+===It is up to you===
-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.
+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.
-* 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 tasks 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.
+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.
-* Issues that is 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.
-===Relate an issue importance to players not to other issues===
+===Relate importance to players not to other issues===
 We are basically using three type of issues, <font style="color: red;">red</font> for really serious issues, <font style="color: orange;">orange</font> for minor issues and <font style="color: blue;">blue</font> 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.
@@ Line 52: / Line 60: @@
 * '''Wrong instructions in Journal''' - you must to consider if you need to <font style="color: blue;">clarify</font> 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 <font style="color: orange;">minor issue</font> or something serious that will break game experience and is a <font style="color: red;">red issue</font>?
 * '''No image with event instructions for neutrals''' - this might be serious <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issue</font> that will be probably solved when the missing dialog is fixed
 ===Never progress tasks by default===
@@ Line 72: / Line 73: @@
 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.
-===Make suggestions not decisions===
+===All issues are resolved===
-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.
+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.
-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.
+* 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 tasks 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 is 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.

@@ Line 50: / Line 50: @@
 * '''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 <font style="color: orange;">orange minor issue</font> 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 <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issues</font> unless it causes other troubles like when a player will not get important information for example. Then consider to make them <font style="color: red;">red issue</font>
-* '''Wrong instructions in Journal''' - you consider if you need need to <font style="color: blue;">clarify</font> first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for <font style="color: orange;">minor issue</font> or something misleading to be a serious <font style="color: red;">red issue</font>.
+* '''Wrong instructions in Journal''' - you must to consider if you need to <font style="color: blue;">clarify</font> 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 <font style="color: orange;">minor issue</font> or something serious that will break game experience and is a <font style="color: red;">red issue</font>?
 * '''No image with event instructions for neutrals''' - this might be serious <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issue</font> that will be probably solved when the missing dialog is fixed

@@ Line 47: / Line 47: @@
 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 <font style="color: blue;">clarify the issue</font> first. If still an exploit, it will be <font style="color: red;">red issue</font>.
+* '''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 <font style="color: blue;">clarify the issue</font> first. If still an exploit, it will be <font style="color: red;">red issue</font>.
-* 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 <font style="color: orange;">orange minor issue</font> 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 <font style="color: red;">red issue</font> 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.
+* '''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 <font style="color: orange;">orange minor issue</font> 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 <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issues</font> unless it causes other troubles like when a player will not get important information for example. Then consider to make them <font style="color: red;">red issue</font>
+* '''Various missing translations''' - missing translations are usually only <font style="color: orange;">orange minor issues</font> unless it causes other troubles like when a player will not get important information for example. Then consider to make them <font style="color: red;">red issue</font>
-* Wrong instructions in Journal - you consider if you need need to <font style="color: blue;">clarify</font> first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for <font style="color: orange;">minor issue</font> or something misleading to be a serious <font style="color: red;">red issue</font>.
+* '''Wrong instructions in Journal''' - you consider if you need need to <font style="color: blue;">clarify</font> first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for <font style="color: orange;">minor issue</font> or something misleading to be a serious <font style="color: red;">red issue</font>.
-* No image with event instructions for neutrals - this might be serious <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issue</font> that will be probably solved when the missing dialog is fixed
+* '''No image with event instructions for neutrals''' - this might be serious <font style="color: red;">red issue</font> 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 <font style="color: orange;">orange minor issue</font> that will be probably solved when the missing dialog is fixed
 ===Never trust others===

@@ Line 42: / Line 42: @@
 ===Relate an issue importance to players not to other issues===
-We are basically using three type of issues, <font style="color: red;">red</font> for really serious issues, <font style="color: orange;">orange</font> for minor issues and <font style="color: blue;">blue</font> 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 to other issues. Following example will explain it a little better.
+We are basically using three type of issues, <font style="color: red;">red</font> for really serious issues, <font style="color: orange;">orange</font> for minor issues and <font style="color: blue;">blue</font> 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.

@@ Line 15: / Line 15: @@
 ===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.
+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.
 ===Requesting other teams===