Skip to main content

Testspace Board

Testspace has no built-in management functionality, but rather relies on integration with GitHub Boards. This aligns project management with the development process.

Testspace relies on integration with GitHub Boards.

When a Testspace board is created in GitHub, there are two built-in automations controlled by Testspace:

  • Issues generated from test execution are automatically added to the board
  • Cycles are automatically added to the board, along with state and status updates

Everything else is controlled by the board's automation settings.


A board is enabled using the .testspace.yml configuration file. The board name is required to be Testpace.

To create a GitHub Project Board for Testspace, use the following steps.

  • In Github, create a new project named Testspace
  • From the project template choose one of the three supported templates:
    • Basic kanban
    • Automated kanban (Recommended)
    • Automated kanban with reviews

A board is enabled using the .testspace.yml configuration file. The board name is required to be Testpace.

Once the board is created, Testspace will automatically add any existing Cycles to the board, along with their status.


Issues that are pushed during a session are automatically added to the board in the "To do" column.


To do#

When a cycle is created and has no status, the issue is positioned in the "To do" column.

In progress#

Once a cycle contains status, the issue is moved to the "In progress" column, enveloped in a board note, with reference to the issue, and status is maintained consistent with the cycle listings status.

Board Note


Once a cycle is completed (i.e. the defining GitHub issue is closed), the cycle is moved into the "Done" column.


The following are general tips on using a GitHub project board with a Testspace project. The Testspace Board can be used as the main vehicle to manage and communicate all of the testing activities.

  • Identify test case issues that require triage
  • Exempt issues to be addressed at a later date
  • Capture test requirements for new test development
  • Define release testing stages with cycles
  • Define milestones to associate issues and cycles
  • Make observations concerning usability, features, etc.


The first item to decide on is what type of template to use when creating the Project board. The Automated kanban is our recommended choice, enabling the built-in trigger to automatically move issues and pull requests.

Project Board

We recommend the Automated kanban Project board template.


One of the benefits of the Testspace board is managing the triage of issues generated from test cases. As part of the triage process, label(s) should be assigned to an issue. Leveraging some of the standard types of labels is recommended: bug, invalid, etc. If a bug label is added to the issue we recommend also adding a second label, such as assigned, when the bug is being worked on by the development team.

Another labeling scheme recommended is to use an exempt label when an issue is not going to be addressed for a period of time (i.e. a different "release" in the future). In conjunction with the exempt label, it is recommended to exempt the failing test case in Testspace and add a link to the issue in the triage form.

Use Testspace exemptions and an issue label, such as exempt, together.


When capturing test requirements with an external system such as Jira or GitHub issues, we recommend to reference them within the test spec description section:

# My Suite
Refs: [#5](/../../issues/5)
Suite description text

For GitHub issues, we also recommend using a unique label such as test reqs. A test reqs issue can also be added to the Board, tracked, and associated with a pull request for review. It can also be useful to add the pull request to the Testspace board for tracking. Note, that Testspace keeps track of pull requests within the Project Insights.

When implementing new tests follow the recommended test development branching policy.


A Testspace board provides built-in status of cycles and auto-generated issues from test case execution. Some other techniques that can be considered that provide additional visibility and status:

  • Leverage milestones for assigned issues and defined cycles.
  • Add an Observation column to the board used to capture usability/questions/etc. that can facilitate a communication thread contained in issue (i.e. label it observation).
  • Create a Note and add badges to it for overall status tracking.
  • Add badges to the Testspace board description field.


When completing a Release the following steps are recommended:

  • Tag the source repo and pin the results.
  • Close all Cycle issues associated with the release. They will automatically move to the Done column.
  • Use the Board Archive all cards feature to remove and save the history of all issues in the Done column.
  • Create new Cycle issues for the next release. Note, the same name can be used again, including the metadata.