The Test Team Handbook/5 - Test board organization

From EncyclopAtys

< The Test Team Handbook
Revision as of 14:30, 25 December 2020 by Moniq (talk | contribs) (Board users: column names update)
Jump to: navigation, search
de:The Test Team Handbook
en:The Test Team Handbook
es:The Test Team Handbook
fr:The Test Team Handbook
ru:The Test Team Handbook
 
UnderConstruction.png
Translation to review
Don't blame the contributors, but come and help them 😎

Reference text ( Maintained text, used as reference ) :
Notes: (Moniq, 2020-12-25)

Test board organization scheme
Test board organization scheme
Test board process diagram
Test board process diagram

This document describes details how tasks on the Test team board are organized.

Theory

The board divides whole process into seven steps, with progress from left to right. Odd columns are meant for management and Non-Testers in the team. Every other column involves testing and is meant for Testers.

Every task starts in either Blocked for Yubo, Blocked for Gingo or Blocked for Atys column. It determines on which server the testing is initially placed. If the task progress (pass all server testing) it moves to right to next server or to end its lifetime as completed in the Done column.

The task remains "on server" and undertake one or more Test rounds/sessions until the all known or newly discovered issues are solved. The board organization use five main settings to indicate task details to all team members no matter of the current role.

  • column on the board - how is overall task progress
  • task position in column - priority within the current column
  • task colour - general state indication: new (yellow), ok (green), troubles (orange), WIP (grey)
  • tag stickers - various additional symptoms of the task
  • deadline - the latest date by which the task must be analyzed



Test Team board elements description


Board task elements

Board users

The work in the Test team is based on team members roles. Based on your current role you have chosen, you pay attention to different parts of the board and operate on different task base. The team itself consists of different type of Ryzom team members, pure testers who look for a running test, translators who work on strings, wiki project members who document changes, marketing team members who wants news for public, event team members who prepare games or scenes and developers who maintain the code. All of them can be, basically, divided into two groups.

  • Testing, members who look for opened testing and its details
  • Management members who manage tasks between testing

Team members accept (use) different roles while working in the Test team. Your first step should be to tell yourself, what would you like to do with the board now. Based on that, you pay attention to different task details and different parts (columns) of the board:

  • For Testing:
    • Testing on Yubo (2nd)
    • Testing on Gingo (4th)
    • Testing on Atys (6th)
  • For Management:
    • Waiting for Yubo (1st)
    • Waiting for Gingo (3rd)
    • Waiting for Atys (5th)
    • Done (7th)

After you open a desired task, based on your role you pay attention to different task details.

  • For Testing, usually testers or translators performing a testing, look for latest Testing PAD. You will find there all details related to current running test.
  • For Management, use task description/comments to provide task details, external links to add all related documents and sub-tasks to review and manage opened task issues.

Some more about work in the Test team by various roles is described in Test Team roles article.

Columns (task progress)

The theory is that a new testing task travels during its lifetime from left to right when progress and right to left when troublesome. After each testing round or session it is decided if the task is ready to progress (move right on the board) or if there is more work on it (move left on the board).

Waiting for Yubo

This column contains new or actually closed tasks that will continue with testing on the Yubo server. It is a place where:

  • Yubo task management should be done here (yellow or orange colour)
  • developers can create new tasks for the Testing team with target on Yubo server
  • translators can review translation issues found during testing (low priority due early stage)
  • where all tests with issues return after testing on Yubo is closed

Before such task can continue for new testing on Yubo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

Testing on Yubo

This column contains all opened tests on the Yubo server. It is a place where:

  • active testers from the Test team should look (green and orange colours)
  • all currently opened tests on Yubo server are placed
  • non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

Waiting for Gingo

This column contains new or actually closed tasks that will continue with testing on the Gingo server. It is a place where

  • Gingo task management should be done here (yellow or orange colour)
  • developers can create new tasks for the Testing team with target on Gingo server
  • translators can review translation issues found during testing
  • where all tests with issues return after testing on Gingo is closed
  • where all successful tests on Yubo server come (yellow colour)

Before such task can continue for new testing on Gingo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

Testing on Gingo

This column contains all opened tests on the Gingo or Atys BETA server. It is a place where:

  • active testers from the Test team should look (green and orange colours)
  • all currently opened tests on Gingo or Atys BETA servers are placed
  • non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

Waiting for Atys

This column contains new or actually closed tasks that will continue with testing on the Atys server. It is a place where

  • non-testers should do a management of tasks that belong to Atys (yellow or orange colour)
  • developers can create new tasks for the Testing team with target on Atys server
  • translators can review translation issues found during testing
  • where all tests with issues return after testing on Atys is closed
  • where all successful tests on Gingo server come

Before such task can continue for new testing on Atys, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

Testing on Atys

This column contains all opened tests on the Atys server. It is a place where:

  • active testers from the Test team should look (green and orange colours)
  • all currently opened tests on Atys server are placed
  • all currently opened tests on beta Atys server are placed
  • non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

Done

This is a column where every task come at the end of its lifetime. Once the parent task is adjusted, testing task can be closed.

Colours (task state)

Test Team board task opened for testing
Test Team board task opened for testing
Test Team board task with known issues
Test Team board task with known issues
Test Team board task ready to be processed
Test Team board task ready to be processed
Test Team board task being adjusted by a coordinator
Test Team board task being adjusted by a coordinator

Each task can have one of various colours. This setting represents its state:

  • Green marks tasks that are running ok, mainly opened tests and tasks in Done column
    • Colour for: Testing
  • Orange marks troublesome tasks, running tests with confirmed issues or closed tests with any issues preventing progress
    • Colour for: Testing, Management
  • Yellow marks new tasks in column, needs to be processed
    • Colour for: Management
  • Grey is a colour for tasks someone is currently doing management on
    • Colour for: Management

Position (task priority in current column)

Position of a task in each column tells you how important is a work on it. Higher position inside a column means higher task priority. Please ignore the task Priority settings. It belongs to team managers to set their priority. Optionally you can choose initial priority when the task arrives to new column to tell your priority guess, based on task progress, number and seriousness of issues, overall project priority...

Tag stickers (task symptoms)

Each task can have one or more stickers (tags) placed on. It represents main current task "symptoms".

Colour scheme

Tag stickers have coloured background to help you get oriented.

  • Orange is for (confirmed) issues to solve
  • Pink is for (confirmed) issues on Atys
  • Purple is for (confirmed) translation issues
  • Yellow is for questions
  • Green is for running test

Commonly used tags

The list is dynamic so you can create any sticker you wish, however it is useful to have some standard list of those everyone should understand.

  • ⏳ patch (orange): this task requires a server patch before it can progress or be (re)tested
  • Bugs reported (orange): represents tasks that have any unsolved confirmed issues
  • Bugs reported on Atys (pink): represents tasks that have any unsolved confirmed issues
  • Translation issue (purple): represents tasks that have any unsolved translation issues
  • Test in progress (green): represents that a task testing is in progress
  • Quick (green): represents those tasks that have undemanding testing, it should not consume more than 30 minutes of your time
  • Clarify first (yellow): test details or some aspects of testing/change are not clear and needs to be clarified first before testing can continue
  • Dev: XYZ (no colour): represents a developer who to ask for details or discuss issues

Deadline (task deadline in current column)

Applies to open tests only, otherwise ignore. The date and time represents when the test (round) will be closed on server. It is needed to have at least basic testing done completed due the date. Deadlines are important in case you need to prepare the change for upcoming patch or if some specific features will be activated for limited time (running events, bigger tests...).