Running Tests

The Manual tab lists a space's specs. A spec can be executed simply by clicking on it and hitting the START button.

tip

To quickly run a single spec just click on it and hit START.

Executing a spec outside a formally defined session is called ad hoc execution.

Run Spec

A spec is selected to execute ad hoc or within a predefined session. Opening a spec shows its test cases on the left; each is given a status individually while running.

Start

Press START to begin. A case defaults to Untested. The following table lists the available case statuses:

STATUS	description
Passed	Working as expected
Failed	Not working as expected
Not Applicable	Marked as NA in the case
Blocked	Not able to execute the test case
Untested	No testing as of yet

STATUS is a row of clickable icons rather than a dropdown — clicking one selects it:

Each case has its own comments form — supporting markdown, drag-and-drop images, and in-place issue references (#123, see Issues) — plus a toggle for that case's previous execution history. The timer starts on START.

Keyboard Support

Both the live execution dialog and the read-only preview (opened from the Specs listing without an active session) support keyboard navigation — focus starts on the current case automatically, no click needed first.

• Case list: Up/Down move one case at a time; Home/End jump to the first/last case; Page Up/Page Down jump by a page (however many cases are currently visible). Doesn't wrap at the ends.
• STATUS picker (while running): Left/Right move between Passed/Failed/Not Applicable/Blocked/Untested and wrap at the ends — moving already selects it, same as a click. Enter/Space select whichever option currently has focus.
• START/STOP: reachable by Tab, activate with Enter/Space like any button.

:::tip A spec with an automated `before`/`after` fixture has extra execution behavior — see [Automated Fixtures](automated-fixtures#execution). :::

Checklist Steps

A case with checklist steps shows each step as an individually checkable box while you're actively testing that case. Checking a box is scoped to this one run — it doesn't change the underlying spec, and different testers running the same spec each get their own independent checklist state.

note

Checking off steps interactively is currently available for Standalone specs. A Connected spec's checklist steps still render, but aren't yet individually checkable during execution.

Stop

Selecting STOP with untested cases remaining prompts for confirmation:

Left checked (default), untested cases carry forward their previous status.

Session

A test session defines a set of specs and describes the purpose of the testing activity, such as validating a new set of functionality. There are no limits to the number of test sessions that can coexist.

New

The specs listing is used to select specs for a new session. The Select spec options:

• All used for choosing all specs
• None used for de-selecting all specs
• Only failing selects specs that have 1 or more failing cases
• Never ran selects specs that have not been executed

Once the specs have been selected, click New Test Session. In the dialog:

• Add a Name for the session, or use the default (i.e. Sequence_n)
• Enable or disable Exploratory (Connected only — see Session Observations)
• Add an optional Description (e.g. "testing feature ABC")
• Select SUBMIT

When a session is created it is tagged as open, until explicitly completed. There is no limit on the number of concurrent open sessions. Click a session to highlight it and see its status.

Complete

A session can be completed at any time, independent of what specs have been executed. Click the solid blue checkmark, or open the row's options menu and select Complete.

• Completing a Test Session removes the active session from the Manual tab.
• Once a session has been completed no additional updates can be made.

note

If no Specs have been executed and the session is completed, the results record will be ignored (same behavior as deleting the session).

Folders

Specs can be organized into folders — see Spaces for Connected, or Creating & Editing Specs for Standalone. Testspace automatically recognizes the folders and presents them as tabs in the listing, alongside an Overall status covering everything. The results tab maintains status per folder the same way.

Assignee

Using the specs listing, a user can be pre-assigned for the execution of a spec, which will then be used as the default on all subsequent created sessions.

Clicking a spec's Assignee cell opens a dropdown of available users. A user can also self-assign, and overwrite an existing assignment when running a spec.

Spec Changes

When a spec with existing status has its content changed since that status was recorded, a special orange warning icon will be displayed, indicating newer changes.

The run dialog also indicates the change.

By clicking on View latest instructions..., the most recent updated content will be presented.

For existing open sessions, there will be no updates or indications of changes, however, any newly created sessions will automatically pick up the changes.

Testspace tries to gracefully handle content changes and preserve execution history and failure tracking. However, renaming a test case (i.e. changing the markdown <H2> heading that denotes it) can not be handled and will result in loss of history.

Issues

Test cases can be associated with issues from your project's configured Issues provider — GitHub, Jira, GitLab, Bitbucket, and generic tracker references are all supported, though which one applies and how it's chosen differs by project type; see Issue Providers for the full picture. There are two ways - push new issues or reference existing issues.

note

Manual test-case issues use the exact same provider as automated test result issues — whatever's configured for the project, not something set separately for Manual.

Push New Issue

If the configured Issues provider supports creating issues, one can be auto-generated within the test case execution — on a failing test case, the Push new issue checkbox defaults to selected. A project on the reference-only generic provider won't show this checkbox at all — see Issue Providers for what each provider supports.

The auto-generated Issue will insert the status in the title [Failed], along with the spec name and test case name. Comments from the test case will be added to the issue automatically as well.

The Issue is generated on the spec run STOP event, and automatically added to the ISSUES form for future reference.

info

Not every provider can create issues — generic is reference-only. See Issue Providers for the full comparison, including what Testspace does (and doesn't) sync back from the external issue.

tip

Auto-generated issues can carry a Label, set per Project — for Connected, .testspace.yml's issues.label (defaults to testspace); for Standalone, a field on the Project's Edit dialog next to Issues provider (blank by default, shown only for providers that support labels). Not every provider supports labels, and pre-existence requirements differ by provider — for GitHub, the label must already exist in the target repo, or it's silently skipped, not created; Jira has no such requirement, and adds a new label value automatically. See Issue Providers for the full comparison.

Reference Existing Issue

If you want to reference an existing issue in a test case, you can list it in the ISSUES form — this works for any provider. For GitHub specifically, you can also just mention it in the comments form inside any message, formatted as a #-prefixed issue number, e.g. #123.

Results

A test session suite's status, when completed, are aggregated together with all other previous sessions and reflected in the Space Results. A Space always represents the most up to date status for each suite.

Aggregation

A Space presentation of results is aggregated by default — the status for all suites, based on their most recent completed session.

When a session completes, the status for the suites it executed is aggregated with the non-executed suites from previous results, so suites that weren't executed this time are carried forward. A carried-forward suite's report shows which session it's carrying from in its Summary section, e.g. Session: [5] Sequence_5 ("Open" cycle).

When non-current sessions (older sessions) are completed the status of any carried forward suites will be updated in newer completed sessions as appropriate.

Session

Results can be viewed both from an Aggregated view or a Session view, via an Aggregate | Session selector in the top-right corner of the page. Session view presents only the suites executed for that session.

Issues Metric

When Issues are pushed and/or referenced during a test session, they are automatically captured in an Issues metric once the session is completed. The metric's report lists every referenced issue's title, status, and which cases reference it, with a summary line (e.g. 2 open, 0 closed / References: 2 cases).

The metric also includes a graph tracking open vs. closed issue counts over time:

There is a badge that contains the number of open issues at the time of publishing.

Exploratory

Exploratory testing is a test flow that provides additional test coverage and usability assessment, using a non-scripted testing approach.

info

Exploratory testing is non-scripted, no-constrained observational-based testing.

There are two variants of exploratory supported by Testspace:

• Spec based observations
• Session based observations

Both types support pushing issues to your project's configured Issues provider.

Spec Observations

When running a spec additional observational content can be added. To add observational comments click on Observations, located at the bottom left of the spec dialog. The ISSUES associated with observations is defaulted to Do not report.

Session Observations

info

Session Observations is currently Connected only — the Exploratory checkbox isn't available when creating a session for a Standalone project.

Session observations are created by selecting the Exploratory checkbox in the creation dialog. Once the Session is created a built-in Exploratory session spec will be provided.

The Exploratory is a generated spec used to capture observations by one or more testers for the session.

The Exploratory session can be executed by multiple users. All of the observations will be automatically added to an Issue in the project's configured Issues provider, named after the session.