User Tools


Testspace has two distinct types of Projects to support differences in testing focus – Unit, Integration, and System – and their associated workflows.

A Project's type cannot be changed.

There are two types of Testspace Projects:

  1. Connected - Each project is connected to a single Git repository. Each Space under the Project is connected to a single branch in the repository. Spaces are automatically created with each new branch and are hidden when the branch is deleted. See the Services section under Account topic for more information.
  2. Standalone - not using Git services1). Spaces are manually created on the Spaces tab under each Standalone project.

Standalone Projects

Standalone Projects and their Spaces – as the name suggests – stand alone, unconnected from GitHub and Bitbucket services, and can be used for all types of unit, integration and system level testing. Results can be pushed manually on the console or from any type of automation system including CI. Standalone projects are only available with Standard Testspace organizations.

Connected Projects

By connecting to GitHub and Bitbucket services, Projects connect to repositories, with Spaces automatically created for each new branch. Results for each git push are collected and analyzed for the life of the branch. Indicators and trends detail the history of the branch’s health – regression rates, test and coverage growth, code churn, and more – indispensable data when reviewing pull requests prior to merging. All metrics for all branches, maintained after deletion, are used to calculate the Workflow Efficiency and Test Effectiveness indicators for the Project’s connected repository. Connected Projects work with all standard CI services, such as Travis, Circle CI, Shippable, and AppVeyor.

New Project

Note: Creating a new Project or editing the properties of an existing Project requires Administrator or Owner privileges.

To create a new project click the New Project button at the top right of the page.2)

New button

New Connected Project

To create a project based on a repo requires Connected Services to allow access to the repositories.

Once the account owner has connected with one or more Git repo organizations3), selecting the New Project button will bring up the following dialog.

 Repos Listing

Select one of the available repositories and click OK. All currently connected repositories will be grayed out and unselectable.

Or select STANDALONE at the bottom of the dialog to create a new standalone project

New Standalone Project

When creating a Standalone project, the Edit Project dialog is used to enter all user-definable settings for the new project (see Project Settings below).

Project Settings

Option Description
Name Name of the project
  • The setting is Read-only for Connected Projects and is derived from the connected repository (<org-name>:<repo-name>)
  • Names are not case-sensitive
  • The name must be unique among Projects under the current Organization
  • The name may not contain the following characters / & # ?
Tip: Avoid names with spaces. They require quoting if specified on the command line.
Description Textual description of the project. The description text supports a subset of Markdown.
Public Access
  • Public projects are visible to the public, while private repositories are only accessible to Users in your organization.
  • The setting is Read-only for Connected Projects, and is controlled by the access setting for the Git connected repository Public|Private.
Users A selection of Users that have access to the project with their current email notification settings.

Project Access

Within the Parent Organization

Users with Owner or Admin permission can access any Project in the organization. Other users must have explicit permission to access a Project (and its member Spaces).

If you are an ordinary user and don't have access to every Project in your Organization, the Projects tab on the Organization Page will display the Request Access button.

Clicking the button brings up a dialog which allows you to request access to any Project you're not on. Once the dialog's SUBMIT button is clicked, a request email is sent to all Admins. An Admin can then grant access by editing the individual Project properties, or by editing the requester's user properties.

From Outside the Parent Organization

By default, Projects (and their child Spaces) are private, meaning that they not visible or accessible to users who are not members of the parent Organization.

A Project's Public attribute can be set when creating new a Project or editing its properties to make the Project visible to other users. The following table summarizes the access rules for different classes of users.

User Class Private Project Public Project
Anonymous ✘ Not Visible
✘ Not Accessible
✔ Visible
• Read-Only
Member of another Testspace Organizationn ✘ Not visible
✘ Not accessible
✔ Visible
✔ Copyable (to the Organization where user is a member)
Member of this Testspace Organization ✔ Visible
✔ Editable, Copyable (with sufficient user privilege)
✔ Visible
✔ Editable, Copyable (with sufficient user privilege)
Note: Member Spaces inherit the access properties of their parent Project.


1) Paid plans only
2) This button will only appear if the user has the required privilege.
3) Includes GitHub User Accounts and Organizations, and Bitbucket Teams

Page Tools