So far, in this tutorial we have
- manually invoked a GitHub workflow to publish pre-canned results
- implemented and executed new test specs from scratch
- learned how to generate and manage GitHub issues in conjunction with a Project Board
- formally defined a test session consisting of a set of specs for testing a build
- leveraged Exploratory Testing for non-scripted verification
- used variables and includes when implementing test specs
This section of the tutorial will focus on creating a branch when developing new test specs.
Let's again implement some new test specs, but this time use a
The first step is to create a branch. Let's call it
git checkout -b dev/newtests
Note that the GitHub UI can also be used to create a branch.
Using the same process as the previous section, go ahead and create a couple of test specs, each consisting of multiple cases.
Once complete commit and push the changes:
git add . git commit -m "new spec" git push origin dev/newtests
Now go to your Testspace project. You should see a new space called:
Once you create your first session the previous results will be automatically carried to the new branch.
- A "non" default branch will have its space sandbox attribute automatically enabled. Once a pull request is opened, the sandbox setting will be disabled.
- To disable branch(es) from automatic sandbox enabling refer to release configuration.
It is often a good practice to evaluate (pre-run) the newly developed test specs. The completion of the test session containing the new specs is often not required. This step is really for vetting the new tests before generating a pull request.
Because the test specs use plain text, it is easier for non-testers to participate in reviews. Testspace leverages the power of GitHub's Pull Request feature to facilitate peer review.
Testspace leverages GitHub's Pull Request to facilitate peer review of test specs.
Create a pull request for the
dev/newtests branch - into
main. Once a pull request is open, Testspace reflects this state along with the name of the pull request (i.e.
It is often a good practice to include a link to the active test session in the pull request, allowing reviewers to see the full rendered test instructions.
Once the pull request is
approved, the branch can be merged into the default branch and deleted. The corresponding space of the deleted branch will be automatically removed in a day or two.
Testspace supports the widely accepted development flow using branching and pull requests, in support of Manual Tests as Code.
New test development should be done using a separate/isolated branching process, thus following good development practices