Implement Manual

So far, we have manually invoked a GitHub workflow to run fake test automation, and then we executed a pre-canned (also fake) test spec. The Testspace project is being used for:

• capturing the test automation results via publishing for the workflow file
• executing a manual test
• and managing the status of both types of testing, providing an aggregated view of the health of a project

A Testspace project can be used for publishing test automation results, executing manual tests, or both.

But now, let's implement some test specs.

Basics

Test specs are maintained in the code section of a repo using markdown files (e.g. file.md). The default folder to maintain the test files is specs. This default can be changed, see manual configuration.

A quick note. The reason there is an extra sub-folder, called manual, in our repo is that we want to store the published results for manual testing and automated testing is separate locations (i.e. folders).

root
  └─ .github
  └─ specs
      └─ manual
         └─ hello.md
         └─ syntax.examples.md
         └─ use.setup.fixture.md
  └─ .testspace.yml
  ..

A test spec requires the following: Header, Suite Name, and at least one Case Name.

• Header. A test spec requires a front matter header block. This is used to uniquely identify the markdown file as a test spec. There are other unique features for front matter that will be covered later. But for now, each test spec requires the following:

   ---
   testspace:
   ---
  

• Suite Name. The suite name is defined using a # text string. This is H1 in markdown.

  # My Test
  

• Case Name. A case name is defined using a ## text string. This is H2 in markdown. There is no limit to the number of cases within a test spec.

  ## My Case1
  

Minimum requirements for a spec file below.

---
testspace:
---
# My Test
## My Case1

Of course, you can and should leverage the syntax provided by markdown. There are also additional features such as Setup and Teardown Steps, Template Steps, and Suite Fixtures. Refer here for more details.

Implement

Go ahead and create a set of test specs, each consisting of multiple cases. Check out the different syntax options that can help in communicating the test instructions:

• Lists
• Tables
• Images
• External Links

For an example of different markdown syntax take a look at this syntax examples test spec.

Once you have finished adding your own test specs, commit and push the changes:

git add .
git commit -m "1st cut at tests"
git push

Note that you can always verify a test spec first in GitHub. Testspace has been designed to match the markdown syntax rendering of GitHub.

Go to your Testspace project and click on the main space.

Run

Now that you have implemented a few new test specs let's run them.

• Select the Manual tab. A listing of all the test specs will be presented
• Create a new test Session by clicking the "New Test Session" button and select your new test specs
• Go ahead and execute each of the new tests
• Once all of the tests have been executed Complete the session

Recap

This section covered the process of implementing test specs.

• A test spec requires a header, a suite name, and at least one case name
• There are many markdown features that can be leveraged for communicating test instructions
• Any number of test specs can be executed within a test session