Testcase Creation

Test cases are created based on the user stories created as part of the requirements. A test case follows a specified structure based on the plain-text language Gherkin. These test cases are created as GitLab issues in order to manage the execution of user acceptance tests there. A more detailed description of the creation process follows in the next three sections.

Derivation

A user-oriented approach was chosen to define the functional requirements of the CIVITAS/CORE platform. User journeys were therefore created from which the functional requirements were derived. This same approach was also chosen for the creation of the test cases.

A user journey covers a software feature at a higher level. This user journey itself consists of several user stories that break down the software feature into smaller functions. The test cases are derived from these user stories. A test case can be derived from one user story, from several together, or from an entire user journey.

info

A test case should always include enough user stories to cover a natural function to be performed by the user. The function should therefore not be too small or too extensive, but should cover exactly one software function to be performed.

Structure

To define a test case, it must follow a specific structure and therefore a specific syntax. This syntax is based on the plain-text language Gherkin. Gherkin offers the possibility to formulate test cases in spoken language while still following a specific structure through the use of keywords.

Example

A test case always starts with the keyword Feature, followed by a short description. Next, an initial context can be defined using the indented keyword Given, followed by the keyword when, which adds an event or action. Finally, the expected result is defined after the keyword Then.

Feature: Successful User Login

  Scenario: Valid Login
    Given valid login credentials of a user
    When User credentials are entered
    Then User successfully logged in

info

In addition to the keywords mentioned in the example, there are other keywords and thus other ways to specify a test case.

A detailed description of the syntax can be found under the Gherkin tab.

Documentation Testing

Each test case describes one or more functions of the application. These functions should also be documented for users. For this reason, in addition to the functionalities, the test case should also specify that the included functions are documented in detail.

Since this is a prerequisite for every scenario, the Gherkin keyword Background is used for this requirement as follows:

Feature: Successful User Login

  Background: All functions performed in the scenarios are documented in detail for users.

  Scenario: Valid Login
    ...

To make it easier for the tester to verify this requirement, the link to the function documentation is included before the test case definition in gherkin.

Documentation: [User and admin guide](https://docs.core.civitasconnect.digital/docs_v2/User-and-admin-guide/intro)

```gherkin

Feature: Successful User Login

...

```

GitLab

The GitLab repository Test Management is used to manage the test cases.

To create a test case there, click on the New Item button under the Issues tab to add a new issue. In the dialog box that appears, select the Test-case template from the Description dropdown menu. A template with Gherkin keywords will then appear in the description to facilitate the creation of the test case.

Test-case Template

Title

<!--
Use as Title: Test case: <short-title>
-->

The template begins with a comment specifying how the title of the issue should look. It begins with the prefix Test case. After a colon, the short title of the test case is added at the end.

Gherkin Test Case

Feature: <name of the feature>
  <description of the feature>
  Documentation: hhtpsfas;//

  Background:
    Given <initial context that's given for all scenarios>
    And <...>

  Scenario: <description of a scenario>
    Given <context for this scenarios>
    When <action to perform in this scenario>
    Then <expected result of executed action>

The title is followed by a template for the test case to be defined in Gherkin. The template serves only as a minimal example and must be adapted to the test case.

Docs

<!--
Gherkine reference:
https://docs.core.civitasconnect.digital/docs_v2/Development/Development%20Process/Process_Manual_Testing/Gherkin
-->

Since the template for the test case to be defined in Gherkin is minimal, the link to the Gherkin documentation is also stored in the template as a comment. This helps to define a more comprehensive test case.

Labels

/label ~uat::test-case

Finally, the labels that are assigned by creation are defined in the template.

Linking User Story

In addition to specifying the test case using Gherkin syntax, the user stories from which the test case was derived must also be linked. This can be done by opening the issue after it has been created and adding the user stories under Linked items.

Test-case Guidelines

Description

The description should meet the following requirements:

• The description consists of 2–3 sentences
• The description begins with the role and what I want to do with it (e.g. As a data steward, I want...)

Background

The background context of each test case should include at least the following information:

Information	Example sentence	count	required
Login-Status	I am logged in	1	✓
Group membership and Role	I am in a group with the role "XY"	1	✓
Permission	I have (not) the permission to ...	-	-
Location	I am on the ... page and see ...	1	-
Documentation	All functions performed in the scenarios are documented in detail for users.	1	✓

Scenario

Given

The scenario context of each test case should include at least the following information:

Information	Example sentence	count	required
Permission	I have (not) the permission to ...	*	*
Location	I am on the ... page and see ...	1	*

warning

When considering a given context, one should always consider the opposite. For example, if you are testing what happens when you have certain permissions, you should also test what happens when you do not have them.

When (Level of Detail)

The "When" section should describe the individual steps the tester is supposed to perform. Each action or click should be described without specifying the exact location on the user interface where the step is to be performed.

warning

In this section, you should also always consider actions that do not follow the correct procedure. For example, in the case of an input field, you should also consider incorrect entries.

Then

The "Then" section should describe the expected result. It should explain:

• what changes on the user interface
• what has been saved
• what additional actions have been triggered as a result
• which action should not be possible to perform