Branch Workflow

When a project is created for manual testing, it is connected to a GitHub repository. Each space under the project maps to a corresponding branch in the repository. Spaces are automatically created and deleted based on the repository activity. When a space is created it is set in a release or sandbox mode.

• Release spaces are for test execution
• Sandbox spaces are for test development

A repo's default branch (i.e. main) is always a release space. All other branches are sandbox spaces unless explicitly configured. The example configuration below sets all branches with the string release_ in its name as a release space:

.testspace.yml

manual:

release:
  - "*release_*"  # i.e. "release_56" branch used for test execution

There are two branch flows recommended when testing using Testspace:

• Main flow
• Release flow

Main flow

The Main flow is based on the GitHub flow. The default branch, typically set as main, is used for testing all releases, with branches created from the default branch used for working on new test development.

github.com/org/repo/branches
  └─ main
  └─ testdev/abc_tests
  └─ testdev/xyz_tests
   ..

Releases

The Main flow is based on continuously testing using the default branch (i.e. single release space).

tip

Update the branch description to reflect the name of the release being tested.

When a release has been completed/deployed it is recommended to tag the repo and pin the results adding a link to the commit id representing the repo being tested.

It is common to follow the same release naming of the repo being tested.

Hotfix

If a hotfix patch is required to be tested a release branch can be used. The following is an example of leveraging a tag.

$ git checkout -b release_42.4.1 tags/v42.4
..
$ git push origin release_42.4.1

Note that the release branch will require configuring:

.testspace.yml

manual:

release:
  - "release_42.*"

Release flow

The Release flow is loosely based on the Gitflow, where a release branch represents the testing for a specific release of the system under test. This flow is especially useful when multiple releases are required to be maintained at the same time.

tip

The Release flow is used when multiple releases are required to be tested and maintained.

A common practice is to name the branch based on the system under test release name.

github.com/org/repo/branches
  └─ main
  └─ release_abc
  └─ release_def
   ..
  └─ testdev/new_tests_for_abc
   ..

To support the Release flow the non-default branches requires configuring:

.testspace.yml

manual:

release:
  - "release_*"

Carry Results

When branching, if the base branch has test results, the results will be copied as a new baseline for the space corresponding to the newly created branch. The baseline suites will be carried forward on subsequent test sessions.

To assure proper baseline of test results, create your new branch from the appropriate base branch with results. For example:

git checkout release_abc
git checkout -b release_def
..
git push origin release_def

The new branch (i.e. release_def) will reference the current release_abc results as it's baseline. In the next session, all tests not executed will be carried from the baseline, the release_abc test results at the time of branching.

Reset Results

A space's results can be reset, removing all history of previous test sessions, including metrics. To start with a clean slate use the hamburger menu of the space and select Reset:

tip

To avoid carrying a base branch's previous status use the Reset option.

Test Development

Following the same process for code development, a branch - Sandbox space - should be used to isolate new test development without affecting other branches in the repository. Using a pull request enables others to discuss and review potential changes, follow-up with additional commits, all before your changes are merged into the base branch.

info

Sandbox spaces do not persist spec runs.