Test Plan

This document is providing a test plan for Trustpoint using the IEEE 829 standard for structuring this plan.

Introduction

The purpose of this test plan should be to test all required functions which are briefly described inside the GitHub repository. Also, there is a separation between functionality and user experience. Since the project is heavily relying on securing networks as simple as possible, the user experience should be as important as the functionality.

Summarized, this test plan is intended to ensure, through the execution and documentation of all tests, the

• functionality,

• usability,

• security and

• integration capability

of Trustpoint. This is done by specifying and implementing the above-mentioned requirements in software tests.

Test Items (Functions)

This chapter lists all needed requirements of Trustpoint, e.g. creating certificates. These requirements are only back-end requirements.

Actors

First, we define all needed actors to be as specific as needed.

Trustpoint Actors

ID	Name	Description
TPC_Web	Trustpoint Core Web Interface	The website of Trustpoint.
TP_Client	Trustpoint Client	The Trustpoint client program to be installed on clients.
Admin	Admin	The admin user of this specific Trustpoint environment.
NTEU	Non-technically experienced user	A user who is not necessarily technically experienced. This could also be an admin.
TEU	Technically experienced user	A user who does know at least a little bit about programming and PKI.

Requirements

Next, we list all requirements. Note that this list could (and will be) incomplete.

Functional Requirements

Functional Requirements

Name (Identifier)	Title	Description	Component(s)	Importance
R_001	Create, view, revoke and delete a device	TPC_Web must provide a way to create, view, revoke and delete a device.	TPC_Web, Admin	High
R_002	Usage of any zero touch onboarding protocol	Any zero touch onboarding protocol should be used, preferably the Bootstrapping Remote Secure Key Infrastructure (BRSKI) process, while connecting a new device to the network.	TP_Client	High
R_003	Certificate Lifecycle Management	Enable complete lifecycle management for certificates, including renewal and revocation.	All components	High
R_004	REST API	Provide a REST API for interacting with Trustpoint programmatically.	TPC_Web	High
R_005	Docker Container Support	Distribute Trustpoint within a fully-configured Docker container for deployment.	TPC_Web	Medium
R_006	Backup, Restore, and Update Mechanisms	Implement backup, restoration, and update features to ensure data and system resilience.	TPC_Web, Admin	High
R_007	Logging Capabilities	Provide detailed and configurable logging for system events and actions.	TPC_Web, TP_Client	High
R_008	Add, delete new Issuing CA’s	The admin should be able to add and delete new Issuing CA’s.	TPC_Web	High
R_009	High Availability	Ensure system availability using redundancy or failover mechanisms.	TPC_Web, TP_Client	High
R_010	CMP Endpoint for Onboarded Devices	Provide a CMP endpoint for device onboarding.	All components	High
R_011	EST Endpoint for Onboarded Devices	Provide an EST endpoint for device onboarding.	All components	High
R_012	Language Selection and Translation	Support multi-language UI options for global usability.	TPC_Web, TP_Client	Medium
R_013	Remote Credential Download	Enable credential downloads from a remote device using a one-time password.	TPC_Web	High
R_103	Create, view, and delete a domain	TPC_Web must provide a way to create, view, and delete a domain.	TPC_Web, Admin	High
R_104	Create, view, revoke and delete a truststore	TPC_Web must provide a way to create, view, and delete a device.	TPC_Web, Admin	High

Security Requirements

Security Requirements

Name (Identifier)	Title	Description	Component(s)	Importance
R_101	Security Level Configuration	Allow administrators to configure security levels for different Trustpoint components.	Admin, TPC_Web	Medium
R_102	Certificate Template Security	Enforce access control and secure handling for certificate templates.	TPC_Web	High

Software Risk Issues

All software testing involves risks, which are listed below in order to minimize them.

• Incomplete requirements:

  As Trustpoint is a research project, it can happen that requirements are incomplete and only become apparent in retrospect that they would have been important.

• Incomplete test coverage:

  Although we strive to keep the test coverage as high as possible, sometimes not everything can be tested. As a result, some execution paths may be left out, with the resulting problems only becoming apparent during productive operation.

• Lack of time for testing:

  It could well happen that the test plan is too long and complex, so that we run out of time with the software tests.

• Problems with the test environment:

  Not every (automated) test can be carried out on a real environment. Therefore, simulation components are likely to be used, but these will probably not represent exactly the same devices as they will look like in the production environment. An example of this would be the simulation or integration of older machines which do not provide a certificate signed by the manufacturer.

• User-friendliness:

  The testers of the program’s interface (acceptance testing) should be people with as little technical knowledge as possible, as otherwise the tests may give a false picture when tested by people from the development team.

• Problems with manual testing:

  We should thrive for automatic testing, although not every requirement can be tested automatically. That is, because the manual testing techniques are sometimes but not always the root of an error.

Features To Be Tested

This chapter lists all needed requirements of Trustpoint, e.g. creating certificates. These requirements are now front-end requirements as well as user experience. This is also the main difference between chapter Test Items (Functions) and this chapter. The table of all actors is still used though.

Features To Be Tested

Name (Identifier)	Title	Description	Component(s)	Importance
F_001	NTEU must be able to execute R_001 and R_002.	NTEU must be able to log in to the TCP_Web app and carry out the processes described in R_001 and R_002.	TPC_Web, NTEU	High

Features Not To Be Tested

There are no features present right now which we do not want to test.

Approach (Strategy)

Testing Levels

The testing will consist of Unit, System/Integration (combined), and Acceptance test levels.

Unit Testing

Unit testing will be conducted by the developers and approved by another developer. Before unit testing is considered complete and the components are passed on for further testing, developers must provide evidence of successful testing. This includes:

• A list of test cases executed

• Sample output

• Input data sets

• Documentation of identified and resolved defects

Note that this can be done automatically.

All unit test artifacts will also be shared with the test engineer for validation and record-keeping. The focus of unit testing will be on verifying the functionality of individual modules of Trustpoint.

System/Integration Testing

System/Integration testing will be carried out by the test developer and the full development team. The primary goal at this stage is to ensure that all Trustpoint modules work together seamlessly, emphasizing interoperability, data consistency, and security.

Also, testing the software under high load and in a larger system should be performed. (Scalability) (It could be the case that those tests are not feasible, because we cannot create such a broad testing environment.)

Acceptance Testing

Acceptance testing will be conducted by the end-users with assistance from the test manager or one of the developers. This phase will focus on validating the Trustpoint system’s usability, reliability, and alignment with user expectations in a production-like environment. The testing process will involve:

• Evaluating user workflows,

• trust validation,

• and secure interactions to ensure the system meets all functional requirements.

Programs will enter acceptance testing only after all critical and major defects have been resolved.

Note that we are able to test user workflows automatically at the integration test phase but there needs to be another acceptance test phase where we actually provide manual tests.

Test Tools

The testing for the Trustpoint project will utilize modern testing frameworks and tools to ensure robust and efficient validation of the application’s functionality across all levels.

Unit Testing

Unit testing for the core functionalities of Trustpoint will be implemented using pytest, a widely adopted Python testing framework. This ensures comprehensive and automated validation of the smallest testable units. Tests will be integrated into the defined GitHub pipelines to enable continuous integration and delivery (CI/CD). These pipelines will ensure that any changes to the codebase are thoroughly tested before merging, reducing the risk of regressions and enhancing development agility.

Integration/System Testing

Integration testing will leverage behave to create BDD test scenarios. This approach will allow us to define tests in plain language that are easy to understand for both technical and non-technical stakeholders. The scenarios will focus on validating the interactions between Trustpoint components, ensuring that they function cohesively as a system.

Acceptance Testing

The tool for acceptance testing has not been finalized at this stage. However, efforts are underway to evaluate suitable tools that align with the requirements of end-user testing. In the interim, manual acceptance testing will be performed in collaboration with end users to validate the system’s readiness for production.

Data Management

Data for testing will primarily be sourced from production-like datasets to simulate real-world scenarios effectively. Where necessary, synthetic data will be generated or modified using Python-based utilities to ensure test completeness. Under no circumstances will changes be made directly to actual production data during testing activities.

Item Pass/Fail Criteria

The test process for the Trustpoint project will be considered complete once the following criteria have been met:

1. Core Functionalities Validation:

   • All critical and major defects identified during unit, integration, and system testing must be resolved.

   • The core functionalities of Trustpoint, such as certificate issuance, renewal, revocation, and domain validation, must operate reliably without workarounds.

2. Integration Testing Success:

   • The PKI components must demonstrate seamless interaction, with no critical or major integration issues.

   • Simulated high-volume certificate management scenarios should execute without performance degradation or system crashes.

3. Acceptance Testing Completion:

   • The platform must pass acceptance testing by end users, ensuring it meets their operational requirements.

   • All critical and major defects discovered during this phase must be corrected, verified, and closed.

4. Data Integrity Verification:

   • Test data generated during the system/integration and acceptance phases must validate correctly against expected outcomes, ensuring the platform’s reliability and accuracy in managing certificates.

   • Production-like scenarios must confirm data consistency across all Trustpoint modules.

5. PKI Compliance Validation:

   • Trustpoint’s processes must comply with PKI standards and security protocols.

   • Certificate data exchanges and storage must adhere to security best practices.

6. Deployment Readiness:

   • The system must pass GitHub pipeline tests, including automated unit and integration tests executed through pytest and behave, with 100% of critical tests passing.

   • The staging environment must match the production setup, with successful parallel runs simulating live scenarios for a predefined period (e.g., two weeks).

Once these criteria are satisfied, Trustpoint will be considered ready for live deployment. Following this, any additional configurations, user onboarding, or domain activations will occur incrementally as per readiness and validation.

Suspension Criteria And Resumption Requirements

Suspension Criteria And Resumption Requirements

Title	Suspension	Resumption
Unavailability of CA or Domain Validation Services	Testing will be paused if the certificate authority (CA) or domain validation services are unavailable, as these are critical for validating PKI-related functionalities.	Testing will resume once the CA or validation services are operational, and any interrupted test cases will be re-executed to ensure completeness.
Critical Defect Identified in Core Functionality	If a critical defect in core features (e.g., certificate issuance, revocation, or renewal) is identified during testing, further testing will be suspended until the issue is resolved.	Testing will resume once the defect is fixed and verified in the development environment.
Test Environment Instability	Testing will pause if the staging or testing environment becomes unstable or misconfigured, as this could lead to unreliable results.	Testing will resume after the environment is restored to a stable and functional state, and necessary validations have been performed.
Unavailability of Required Test Data	If critical test data (e.g., domain configurations, certificate requests) is unavailable or incomplete, testing will be suspended for the affected areas.	Testing will resume once sufficient test data has been prepared and verified.
Staffing or Resource Constraints	If key personnel (e.g., test managers or developers) or resources (e.g., access to tools or infrastructure) are unavailable, testing may be delayed for impacted areas.	Testing will resume once adequate staffing and resources are available to continue the process effectively.

Test Deliverables

The following consolidated deliverable will be provided at the conclusion of the Trustpoint testing process:

Comprehensive Test Report:

This single document will include the following components:

1. Unit Test Results:

   • Summary of pytest executions, including test case descriptions, pass/fail status, and defect details.

   • Logs and outputs from automated tests executed through GitHub pipelines.

2. Integration Test Results:

   • Results from BDD tests using the behave framework.

   • Detailed logs of test scenarios, their outcomes, and any identified issues.

3. Defect and Incident Reports:

   • A summary of defects encountered during testing phases, their resolution status, and associated incident logs.

4. Acceptance Testing Summary:

   • Results of acceptance tests, including user feedback and final approval status.

   • Any open issues and their planned resolutions (if applicable).

5. Coverage Metrics:

   • Test coverage statistics to demonstrate the completeness of testing efforts.

Remaining Test Tasks

Remaining Test Tasks

Task	Assigned To	Status
Collect and finalize testing requirements (e.g., PKI workflows, certificate lifecycle scenarios).	TM, PM, Client	In Progress
Define and finalize acceptance criteria for Trustpoint’s features.	TM, PM, Client	Pending
Configure and validate the test environments (development and staging).	TM, Dev	In Progress
Develop unit tests using pytest for core functionalities (e.g., certificate issuance, renewal, and revocation).	Dev	In Progress
Develop integration tests using behave for end-to-end workflows.	TM, Dev	Pending
Execute system/integration tests in the staging environment.	TM, Dev	Not Started
Document results from unit, integration, and acceptance tests for inclusion in the comprehensive test report.	TM	Not Started
Conduct acceptance testing with end users (e.g., system administrators, security teams).	TM, Client	Not Started
Resolve defects identified during testing and retest as needed.	Dev	Ongoing
Finalize and deliver the comprehensive test report (including test results and coverage).	TM	Not Started

Environmental Needs

The following elements are required to support the testing effort at all levels within the Trustpoint project:

1. Access to Development and Staging Environments:

   • A dedicated development environment for initial testing, debugging, and iterative fixes.

   • A staging environment that mirrors the production setup for system, integration, and acceptance testing.

2. Certificate Authority (CA) Setup:

   • Access to a functional CA system to validate PKI-related features such as certificate issuance, renewal, and revocation.

3. GitHub CI/CD Pipeline Configuration:

   • An operational GitHub pipeline to automate testing and deployment workflows. This pipeline will execute unit and integration tests using pytest and behave frameworks.

4. Database Access:

   • Availability of a testing database populated with production-like data to simulate realistic scenarios.

   • A clear separation between testing and production data to ensure no overlap or accidental data modification.

5. Secure Networking Configuration:

   • A secure network environment for testing interactions between Trustpoint components, including domain validation and security protocol testing.

6. Access to Backup/Recovery Processes:

   • Access to nightly backup and recovery tools for safeguarding test environment data.

7. Testing Tools:

   • Functional installations of pytest and behave for automated testing.

   • Additional tools may be added as acceptance testing needs evolve.

This streamlined setup ensures an effective and efficient testing process while minimizing redundancy and complexity.

Staffing And Training Needs

1. Staffing Requirements

   • At least one dedicated tester should be assigned for the integration and acceptance testing phases to ensure thorough and independent validation.

   • In the absence of a dedicated tester, the test manager will assume this role with support from the development team.

   • Developers will assist in test case creation and debugging during the unit testing and integration testing phases.

2. Training Needs

   • Developers and Testers:

     • Familiarity with Trustpoint’s core functionality, including certificate issuance, renewal, revocation, and domain validation workflows.

     • Training on pytest for unit testing and behave for integration testing, including understanding the GitHub pipeline integration.

   • End Users:

     • Training on navigating Trustpoint’s user interfaces, configuring domains, and interpreting system-generated reports.

Responsibilities

Responsibilities

Responsibility	TM	PM	Dev	Test Team	Client
Acceptance Test Documentation & Execution	X	X		X	X
System/Integration Test Documentation & Execution	X	X	X	X
Unit Test Documentation & Execution	X		X
System Design Reviews	X	X	X	X	X
Detailed Design Reviews	X	X	X	X
Test Procedures and Rules	X	X	X	X
Change Control and Regression Testing	X	X	X	X
Certificate Lifecycle Scenarios Review	X	X	X		X

Schedule

The following schedule outlines the remaining testing activities. These activities are aligned with the project’s current progress and emphasize completing testing efficiently and effectively. Specific dates and durations should be detailed in the project timeline managed by the project manager in collaboration with development and test leads.

Testing Schedule Table

Activity	Responsibility	Duration/Timeline	Details
Review Requirements Document	Test Team, Dev, PM	1 Week	Review requirements to ensure complete understanding and alignment of test objectives.
Finalize and Review Requirements	TM, PM, Test Team	1 Week	Develop and review the requirements needed for writing the acceptance tests.
Review System Design Document	Test Team, Dev	3 Days	Enhance understanding of the system structure and refine test objectives.
Conduct Unit Tests	Dev	Ongoing until code completion	Verify individual methods/functions as they are completed; results reviewed by the development lead.
System/Integration Testing	Test Team, Dev	2 Weeks	Validate module interactions, data flow, and PKI processes in a staging environment.
Acceptance Testing	Test Team, End Users, PM	2 Weeks	Perform final user-driven testing to ensure Trustpoint meets functional and usability expectations.

Planning Risks And Contingencies

Planning Risks And Contingencies

Risk	Description	Contingency Plan
Limited Staff Availability for Testing	Key stakeholders or end users may have limited availability during acceptance testing.	Schedule testing in advance; assign a test team representative if stakeholders are unavailable.
Incomplete or Changing Requirements	Requirements may evolve or be incomplete, leading to rework or missed test cases.	Conduct iterative reviews; adopt agile testing practices to adapt dynamically to changes.
Test Environment Instability	The staging or test environment may become misconfigured or unavailable, causing delays.	Maintain backup environments; use configuration checklists to ensure reliable setups.
Delays in Defect Resolution	Defects may take longer to resolve, impacting subsequent testing phases.	Prioritize critical defects; allocate additional resources for prompt resolution.
Dependence on External Systems	External PKI components (e.g., Certificate Authorities) may be unavailable during testing.	Use mock services or simulators; coordinate with service providers to ensure availability.
Inadequate Test Data	Insufficient or unrealistic test data may result in incomplete testing or missed edge cases.	Generate synthetic data using Python utilities; use anonymized production-like datasets for validation.

Approvals

Test Cases

Since we are using the BDD principle for system and integration testing, we decided on specifying the tests directly inside the Cucumber feature files. This has the advantage of removing the need to keep two or more documents updated at the same time. Also, Gherkin is a well organized language such that the test ideas and steps are possible to read - even for people without a background in software engineering. That being said, we state the feature files in the following and provide a brief description on the test ideas.

Functional Requirements

R_001

This testcase is related to requirement R_001.

Test Idea

To test the requirement of creating, viewing, editing, and deleting devices using the TPC_Web interface, the focus will be on validating the complete lifecycle of device management through the web platform.

The test would start with an admin user creating a new device through the web interface. This process involves navigating to the appropriate page, filling out the required fields (e.g., name, serial number and domain), and submitting the form. Once the device is created, the test would verify that it appears in the list of devices and that all details are accurately displayed on its details page.

Finally, the test would validate the deletion process, where the admin removes the device through the web interface. Once deleted, the system should ensure that the device is no longer accessible or visible in any lists or details pages. Additional negative tests could confirm appropriate handling when attempting to access or manipulate a non-existent or already-deleted device.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_001_Manage_devices_via_TPC_Web
@allure.label.package:R_001_Manage_devices_via_TPC_Web
Feature: Manage devices via TPC_Web
  As an admin user
  I want to create, view, edit, and delete devices
  So that I can manage trusted devices effectively through the web interface.

  Background:
    Given the admin user is logged into TPC_Web
    And the issuing ca with unique name "test_CA" with pkcs12 file exist
    And a domain trustpoint_test with issuing ca "test_CA" exist

  Scenario Outline: Add a new device without domain credential onboarding
    When the admin navigates to the "create onboarding device" page
    And the admin fills in the device details with <name>, <serial_number> and domain "trustpoint_test"
    And the admin clicks on "Create Device"
    Then the system should display a confirmation page
    And the new device with <name>, <serial_number> and domain name "trustpoint_test" should appear in the device list

    Examples:
      | name            | serial_number |
      | Suction-Pads    | GC538K0DG7MW  |
      | Vacuum-Ejectors | 90OI4GL6RMNO  |

  Scenario Outline: Delete an existing device
    Given the device <name> with <serial_number> exists
    When the admin navigates to the "device list" page
    And the admin deletes the device with the name <name>
    Then the system should display a confirmation message stating "Successfully deleted"
    And the device <name> should no longer appear in the device list

    Examples:
      | name            | serial_number |
      | Suction-Pads    | GC538K0DG7MW  |
      | Vacuum-Ejectors | 90OI4GL6RMNO  |

  Scenario: Handle non-existent devices
    When the admin attempts to view the details of a non-existent device "NonExistentID"
    Then the system should display an error message

R_002

This testcase is related to requirement R_002.

Test Idea

Warning

There is no test idea present. This will change in the future!

Feature File

Warning

There is also no feature file present! This will also change as soon as a test idea is provided.

R_003

This testcase is related to requirement R_003.

Test Idea

To test the complete lifecycle management of certificates, the focus will be on ensuring that admin users can successfully perform actions such as renewing and revoking certificates via the TPC_Web interface.

The test begins by identifying an existing certificate. Using TPC_Web, the admin initiates the renewal process, and the system updates the expiration date. Similarly, the admin navigates to the certificate management page and initiates a revocation process. The system should confirm the action and reflect the certificate’s updated status as revoked.

Edge cases include attempting to renew or revoke non-existent certificates or performing actions on certificates in invalid states (e.g., already revoked certificates). The system should handle these scenarios gracefully, with appropriate error messages or restrictions.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_003_Certificate_lifecycle_management_via_TPC_Web
@allure.label.package:R_003_Certificate_lifecycle_management_via_TPC_Web
Feature: Certificate lifecycle management via TPC_Web
  As an admin user
  I want to manage certificates across their lifecycle
  So that I can ensure their validity and revoke them when necessary.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Successfully renew a certificate
    Given the certificate <certificate_id> exists and is close to expiration
    When the admin navigates to the certificate management page for <certificate_id>
    And the admin initiates the certificate renewal process
    Then the system should display a confirmation message
    And the certificate <certificate_id> should have an updated expiration date

    Examples:
      | certificate_id |
      | CERT1234       |
      | CERT5678       |

  Scenario Outline: Successfully revoke a certificate
    Given the certificate <certificate_id> exists and is active
    When the admin navigates to the certificate management page for <certificate_id>
    And the admin initiates the certificate revocation process
    Then the system should display a confirmation message
    And the certificate <certificate_id> should have a status of "revoked"

    Examples:
      | certificate_id |
      | CERT9101       |
      | CERT1121       |

  Scenario: Attempt to renew a non-existent certificate
    When the admin attempts to <renew> a non-existent certificate "NONEXISTENT"
    Then the system should display an error message stating "Certificate not found"

  Scenario: Attempt to revoke a non-existent certificate
    When the admin attempts to <revoke> a non-existent certificate "NONEXISTENT"
    Then the system should display an error message stating "Certificate not found"

  Scenario Outline: Attempt to renew a revoked certificate
    Given the certificate <certificate_id> exists and is revoked
    When the admin attempts to renew the certificate <certificate_id>
    Then the system should display an error message stating "Certificate renewal not allowed for revoked certificates"

    Examples:
      | certificate_id |
      | CERT3131       |
      | CERT4151       |

  Scenario Outline: Attempt to revoke an already revoked certificate
    Given the certificate <certificate_id> exists and is revoked
    When the admin attempts to revoke the certificate <certificate_id>
    Then the system should display an error message stating "Certificate is already revoked"

    Examples:
      | certificate_id |
      | CERT6161       |
      | CERT7171       |

R_004

This testcase is related to requirement R_004.

Test Idea

To test the REST API for interacting with Trustpoint programmatically, we focus on verifying CRUD operations (Create, Read, Update, Delete) and additional actions like querying and filtering. We begin by validating that authorized API clients can authenticate successfully and perform each operation on digital identities. This includes creating a new identity, retrieving its details, updating its attributes, and deleting it. Each API response should include appropriate status codes and payloads.

Error handling should also be tested, such as attempting operations with invalid data, unauthorized access, or on non-existent resources. Edge cases, such as rate limits or concurrent requests, should be addressed to confirm robustness.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_004_REST_API_interaction_with_Trustpoint
@allure.label.package:R_004_REST_API_interaction_with_Trustpoint
Feature: REST API interaction with Trustpoint
  As an API client
  I want to use the REST API to interact with Trustpoint
  So that I can programmatically manage digital identities.

  Background:
    Given an API client is authenticated

  Scenario Outline: Successfully create a new identity
    When the API client sends a POST request to "/api/identities" with the following payload:
      | name   | identifier   |
      | <name> | <identifier> |
    Then the API response should have a status code of 201
    And the response payload should include the created identity with:
      | name   | identifier   |
      | <name> | <identifier> |

    Examples:
      | name        | identifier |
      | Alice Smith | alice123   |
      | Bob Johnson | bob567     |

  Scenario Outline: Retrieve an existing identity
    Given the identity <identifier> exists
    When the API client sends a GET request to "/api/identities/<identifier>"
    Then the API response should have a status code of 200
    And the response payload should include the identity with:
      | identifier   | name   |
      | <identifier> | <name> |

    Examples:
      | identifier | name        |
      | alice123   | Alice Smith |
      | bob567     | Bob Johnson |

  Scenario Outline: Update an existing identity
    Given the identity <identifier> exists
    When the API client sends a PUT request to "/api/identities/<identifier>" with the following payload:
      | name       |
      | <new_name> |
    Then the API response should have a status code of 200
    And the response payload should include the updated identity with:
      | identifier   | name       |
      | <identifier> | <new_name> |

    Examples:
      | identifier | new_name     |
      | alice123   | Alice Cooper |
      | bob567     | Robert Jones |

  Scenario Outline: Delete an identity
    Given the identity <identifier> exists
    When the API client sends a DELETE request to "/api/identities/<identifier>"
    Then the API response should have a status code of 204
    And the identity <identifier> should no longer exist

    Examples:
      | identifier |
      | alice123   |
      | bob567     |

  Scenario: Attempt to access the API without authentication
    When the API client sends a GET request to "/api/identities" without authentication
    Then the API response should have a status code of 401
    And the response payload should include an error message stating "Unauthorized"

  Scenario Outline: Attempt to retrieve a non-existent identity
    When the API client sends a GET request to "/api/identities/<identifier>"
    Then the API response should have a status code of 404
    And the response payload should include an error message stating "Identity not found"

    Examples:
      | identifier |
      | unknown123 |
      | invalid567 |

R_005

This testcase is related to requirement R_005.

Test Idea

This requirement states that we want to distribute Trustpoint in a fully-configured Docker container. The idea for testing would be to build the container, run it on a production system and then check all other requirements manually or build a test suite and check the requirements automatically.

For now, we have the idea of using our docker_compose_r_005 to build and start the trustpoint container as well as the postgres container. After this, we check if the startpage is visible and returns a 200 code. This test is executed inside a GitHub actions pipeline.

Docker Compose File

services:
  trustpoint:
    build:
      context: .
      dockerfile: docker/trustpoint/Dockerfile
    image: trustpointproject/trustpoint:latest
    container_name: trustpoint
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - postgres
    environment:
      POSTGRES_DB: "trustpoint_db"
      DATABASE_USER: "admin"
      DATABASE_PASSWORD: "testing321"
      DATABASE_HOST: "postgres"
      DATABASE_PORT: "5432"

  postgres:
    build:
      context: .
      dockerfile: docker/db/Dockerfile
    image: trustpointproject/postgres:latest
    container_name: postgres
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: "admin"
      POSTGRES_PASSWORD: "testing321"
      POSTGRES_DB: "trustpoint_db"

volumes:
  postgres_data:

GitHub Actions File

name: Docker Compose Test

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Checkout code
        uses: actions/checkout@v6

      # Step: Run Docker Compose to start services.
      # Uses the hoverkraft-tech/compose-action to manage Docker Compose commands.
      # "compose-file": path to the docker-compose file.
      # "up-flags":
      #   --build : forces a rebuild of the images.
      #   --wait  : waits for the services to be up and running.
      - name: Run Docker compose
        uses: hoverkraft-tech/compose-action@v2.4.3
        with:
          compose-file: "./docker-compose.yml"
          up-flags: "--build --wait"

      # Step: Test the Home Page with curl.
      # A loop attempts to fetch the HTTP response code from the running service.
      # The -L flag tells curl to follow redirects.
      # The -s flag makes curl run silently.
      # The -o option saves the full response body into response.txt.
      # The -w option writes out the HTTP status code.
      - name: Test Home Page with curl (self-signed HTTPS)
        run: |
          echo "Checking health of the HTTPS endpoint with self-signed cert..."

          URL="https://127.0.0.1/"

          for i in {1..20}; do
            http_response=$(curl -k -L -s -o response.txt -w "%{http_code}" "$URL") || true

            if [ "$http_response" = "200" ]; then
              echo "✅ Success on attempt $i"
              break
            else
              echo "⏳ Attempt $i failed with HTTP code $http_response, retrying..."
              sleep 3
            fi
          done

          echo "Server returned: $http_response" >> "$GITHUB_STEP_SUMMARY"

          if [ "$http_response" != "200" ]; then
            echo "❌ Healthcheck failed." >> "$GITHUB_STEP_SUMMARY"
            echo "Response body:" >> "$GITHUB_STEP_SUMMARY"
            cat response.txt >> "$GITHUB_STEP_SUMMARY"
            exit 1
          else
            echo "✅ Healthcheck passed." >> "$GITHUB_STEP_SUMMARY"
            echo "Response body:" >> "$GITHUB_STEP_SUMMARY"
            cat response.txt >> "$GITHUB_STEP_SUMMARY"
          fi

R_006

This testcase is related to requirement R_006.

Test Idea

To verify the implementation of backup, restoration, and update mechanisms for ensuring system resilience:

1. Backup Verification:

   • An admin initiates a system backup via the TPC_Web interface.

   • The system confirms that the backup process completes successfully.

   • The backup file is retrievable and valid.

2. Restore Verification:

   • An admin uploads a valid backup file through the TPC_Web interface.

   • The system restores the data and confirms the restoration is successful.

   • Restored data is consistent with the backup file contents.

3. System Update Verification:

   • An admin triggers a system update via the TPC_Web interface.

   • The system downloads and applies the update.

   • Post-update, the system verifies the integrity and functionality of the application.

Edge cases include:

• Handling a corrupt backup file during restoration.

• Attempting to perform operations with insufficient admin privileges.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_006_Backup_Restore_Update
@allure.label.package:R_006_Backup_Restore_Update
Feature: Backup, Restore, and Update Mechanisms
  Ensure system resilience through robust backup, restoration, and update features.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Verifying the backup mechanism
    When the admin initiates a system backup
    Then the system confirms the backup process completes successfully
    And the backup file <backup_file> is retrievable and valid

    Examples:
      | backup_file     |
      | backup_20250128 |

  Scenario Outline: Verifying the restoration mechanism
    When the admin uploads a backup file <backup_file>
    Then the system restores the data successfully
    And the restored data is consistent with the backup file contents

    Examples:
      | backup_file     |
      | backup_20250128 |

  Scenario: Verifying the system update mechanism
    When the admin triggers a system update
    Then the system downloads and applies the update
    And the system verifies the integrity and functionality post-update

R_007

This testcase is related to requirement R_007.

Test Idea

To verify that the system provides detailed and configurable logging for system events and actions, we will test the following scenarios:

1. Logging of User Actions

   • The admin performs actions such as creating, updating, and deleting identities.

   • The system logs these actions with relevant details (timestamp, user ID, action type, and outcome).

2. Log Retrieval & Filtering

   • The admin retrieves system logs via the TPC_Web interface.

   • Logs can be filtered by time range, user, or event type.

3. Log Configuration Management

   • The admin modifies the logging configuration to change verbosity levels.

   • The system applies the new logging settings and updates log output accordingly.

4. Log Storage & Integrity

   • Logs are stored persistently and are not lost between system restarts.

   • Unauthorized users cannot modify or delete logs.

Edge cases:

• Verifying how the system handles an excessive number of log entries.

• Testing logging behavior when storage space is low.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_007_Logging_capabilities
@allure.label.package:R_007_Logging_capabilities
Feature: Logging Capabilities
  The system must provide detailed and configurable logging for system events and actions.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Logging user actions
    When the admin performs an action <action>
    Then the system logs the action <action> with relevant details

    Examples:
      | action |
      | create |
      | update |
      | delete |

  Scenario Outline: Retrieving and filtering logs
    When the admin retrieves logs for the time range <time_range>
    Then the system displays logs within the <time_range>
    And logs can be filtered by <filter_criteria>

    Examples:
      | time_range    | filter_criteria |
      | last 24 hours | user            |
      | last 7 days   | event type      |

  Scenario Outline: Configuring logging settings
    When the admin modifies logging configuration to <log_level>
    Then the system applies the new logging configuration
    And logs reflect the new verbosity level <log_level>

    Examples:
      | log_level |
      | DEBUG     |
      | INFO      |
      | WARNING   |

  Scenario: Ensuring log storage and integrity
    When the system restarts
    Then previous logs are still accessible
    And unauthorized users cannot delete or modify logs

R_008

This testcase is related to requirement R_008.

Test Idea

To verify that the admin is allowed to add or delete new Issuing CA’s, there are the following steps needed.

• Admin is logged in

• Admin navigates to the page “pki-issuing ca’s”

• Admin can click on “add new issuing ca”

• Admin is able to either upload a pkcs12 file or upload separate key and certificate file

• The system should display the newly added Issuing CA

Feature File

@allure.label.epic:Features
@allure.label.suite:R_008_Issuing_CA_Management
@allure.label.package:R_008_Issuing_CA_Management
Feature: Add and delete new Issuing CAs
  The system must provide a way to add and delete new issuing CAs.

  Background:
    Given the admin user is logged into TPC_Web
    And the admin is on the "pki/issuing-cas" webpage

  Scenario: Add a new issuing CA by uploading a valid PKCS12 file
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From PKCS#12 File"
    Then the system should display a form page where a file can be uploaded
    When the admin uploads a valid PKCS12 issuing CA file
    And the admin clicks the "Add new issuing CA" button to add "test_CA"
    Then the system should display a confirmation message stating "Successfully added Issuing CA"
    Then the issuing CA "test_CA" "appears" in the list of available CAs


  Scenario: Add a new issuing CA by uploading a broken PKCS12 file
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From PKCS#12 File"
    Then the system should display a form page where a file can be uploaded
    When the admin uploads a broken PKCS12 issuing CA file
    And the admin clicks the "Add new issuing CA" button to add "test_CA"
    Then the response payload should include an error message stating "Failed to parse"
    And the issuing CA "test_CA" "does not appear" in the list of available CAs


  Scenario: Add a new issuing CA by uploading a duplicated PKCS12 file
    Given the issuing ca with unique name "test_CA" with pkcs12 file exist
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From PKCS#12 File"
    Then the system should display a form page where a file can be uploaded
    When the admin uploads a duplicated PKCS12 issuing CA file
    And the admin clicks the "Add new issuing CA" button to add "test_CA_duplicate"
    Then the response payload should include an error message stating "UNIQUE constraint failed"
    And the issuing CA "test_CA" "appears" in the list of available CAs


  Scenario Outline: Add a new issuing CA by uploading valid key and certificate files
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From Separate Key and Certificate Files"
    Then the system should display a form page where a file can be uploaded
    When the key file of type <key_type> is "valid"
    And the certificate file of type <cert_type> is "valid"
    And the certificate file is "a CA certificate"
    And the certificate chain of type <cert_chain> is "valid"
    And the admin clicks the "Add new issuing CA" button to add "test_CA"
    Then the system should display a confirmation message stating "Successfully added Issuing CA"
    Then the issuing CA "test_CA" "appears" in the list of available CAs

    Examples:
      | key_type | cert_type | cert_chain |
      | .key     | .cer      | .pem       |
      | .key     | .der      | .pem       |
      | .key     | .pem      | .pem       |
      | .pem     | .cer      | .pem       |
      | .pem     | .der      | .pem       |
      | .pem     | .pem      | .pem       |


  Scenario: Add a new issuing CA by uploading end entity certificates
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From Separate Key and Certificate Files"
    Then the system should display a form page where a file can be uploaded
    When the key file of type "_ee.pem" is "valid"
    And the certificate file of type "_ee.pem" is "valid"
    And the certificate file is "an end entity certificate"
    And the certificate chain of type ".pem" is "valid"
    And the admin clicks the "Add new issuing CA" button to add "test_CA"
    Then the response payload should include an error message stating "The provided certificate is not a CA certificate."
    And the issuing CA "test_CA" "does not appear" in the list of available CAs


  Scenario: Add a new issuing CA by uploading valid key and certificate files - Mismatched key and cert file
    When the admin clicks on "Add new Issuing CA"
    Then the system should display multiple options to add a new issuing CA
    When the admin clicks on "Import From Separate Key and Certificate Files"
    Then the system should display a form page where a file can be uploaded
    When the key file of type ".pem" is "valid"
    And the certificate file of type ".pem" is "valid"
    When the key and the certificate file are not matching
    And the admin clicks the "Add new issuing CA" button to add "test_CA"
    Then the response payload should include an error message stating "The provided private key does not match the Issuing CA certificate."
    And the issuing CA "test_CA" "does not appear" in the list of available CAs

  # Scenario: Add a new issuing CA by uploading valid key and certificate files but mismatching chain
  #   When the admin clicks on "Add new Issuing CA"
  #   Then the system should display multiple options to add a new issuing CA
  #   When the admin clicks on "Import From Separate Key and Certificate Files"
  #   Then the system should display a form page where a file can be uploaded
  #   When the key file of type ".pem" is "valid"
  #   And the certificate file of type ".pem" is "valid"
  #   And the certificate file is "a CA certificate"
  #   And the certificate chain of type ".pem" is "valid"
  #   And the certificate chain does not contain the issuer of the certificate file
  #   And the admin clicks the "Add new issuing CA" button to add "test_CA"
  #   Then the system should display an error message
  #   And the issuing CA "test_CA" "does not appear" in the list of available CAs

  Scenario: Delete an issuing CA
    Given the issuing ca with unique name "test_CA" with pkcs12 file exist
    And the issuing CA with the unique name "test_CA" has no associated certificates
    And the issuing CA with the unique name "test_CA" has no associated domains
    When the admin select the issuing CA with the unique name "test_CA"
    And the admin clicks on Delete Selected
    Then the system should display a confirmation dialog page
    When the admin clicks on "Delete selected Issuing CAs"
    Then the system should display a confirmation message stating "Successfully deleted"
    Then the issuing CA "test_CA" "does not appear" in the list of available CAs

R_009

This testcase is related to requirement R_009.

Test Idea

There is no High Availability Concept for Trustpoint yet, so that the test needs to be redesigned after we decided on which concept top use. For now, the test assumes a multi-server setup.

To verify that the system ensures high availability through redundancy and failover mechanisms, we will test the following scenarios:

1. Failover Mechanism Activation

   • Simulate a primary server failure.

   • Verify that the system seamlessly switches to a secondary server.

   • Ensure no data loss or service interruption.

2. Load Balancing Under High Traffic

   • Simulate multiple concurrent users accessing the system.

   • Verify that traffic is distributed across multiple nodes.

   • Ensure response times remain within acceptable limits.

3. Recovery After a Server Crash

   • Simulate a server crash and restart.

   • Ensure the system restores its previous state without manual intervention.

   • Verify that logs and transactions remain intact.

4. Database Replication Consistency

   • Ensure that database replication maintains consistency across multiple nodes.

   • Test whether changes made on one node propagate to others correctly.

Edge cases:

• Sudden simultaneous failure of multiple components.

• Failover switching back to the primary server after recovery.

• Performance degradation during failover.

Feature File

Nonexistent.

R_010

This testcase is related to requirement R_010.

Test Idea

To verify that the system provides a CMP endpoint for onboarding devices, we will test the following scenarios:

1. Device Registration and Certificate Enrollment

   • A new device initiates a CMP request to the endpoint.

   • The system processes the request and issues a certificate.

   • The device successfully receives and stores the issued certificate.

2. Certificate Renewal for an Onboarded Device

   • An onboarded device requests certificate renewal.

   • The system validates the request and issues a new certificate.

   • The device replaces its old certificate with the new one.

3. Handling Unauthorized Requests

   • A device with invalid credentials tries to access the CMP endpoint.

   • The system rejects the request with an appropriate error response.

4. Certificate Revocation for a Compromised Device

   • An admin requests certificate revocation for a specific device.

   • The system revokes the certificate and updates the revocation list.

   • The revoked device is unable to authenticate using its certificate.

5. High Load Handling

   • Simulate multiple devices requesting certificate issuance simultaneously.

   • Verify that the system handles high traffic without performance degradation.

Edge cases:

• Expired certificates being used for renewal.

• Partial network outages during certificate issuance.

• Unexpected payloads being sent to the CMP endpoint.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_010_CMP_Endpoint
@allure.label.package:R_010_CMP_Endpoint
Feature: CMP Endpoint for Onboarded Devices
  The system must provide a CMP endpoint to securely onboard devices.

  Background:
    Given the CMP endpoint is available

  Scenario: A device successfully requests a certificate
    Given a new device with identifier "Device123"
    When the device sends a CMP request for a new certificate
    Then the system should issue a new certificate for "Device123"
    And the device should store the issued certificate

  Scenario: An onboarded device renews its certificate
    Given an onboarded device with identifier "Device456" and an active certificate
    When the device sends a CMP request for certificate renewal
    Then the system should issue a new certificate for "Device456"
    And the device should replace its old certificate with the new one

  Scenario: Unauthorized device attempts to access the CMP endpoint
    Given a device with invalid credentials
    When the device sends a CMP request
    Then the system should reject the request with an "Unauthorized" error

  Scenario: Admin revokes a device certificate
    Given a registered device with identifier "Device789" and a valid certificate
    When an admin revokes the certificate for "Device789"
    Then the system should update the revocation list
    And "Device789" should no longer authenticate using its certificate

  Scenario Outline: High load certificate issuance
    Given <num_devices> devices are requesting certificates simultaneously via CMP
    When the CMP endpoint processes the requests
    Then all certificates should be issued within <max_response_time> milliseconds

    Examples:
      | num_devices | max_response_time |
      | 100         | 500               |
      | 1000        | 1000              |

R_011

This testcase is related to requirement R_011. Note that EST and CMP could be tested the same way. This is still w.i.p.

Test Idea

To verify that the system provides an EST endpoint for onboarding devices, we will test the following scenarios:

1. Device Registration and Certificate Enrollment

   • A new device initiates an EST request to the endpoint.

   • The system processes the request and issues a certificate.

   • The device successfully receives and stores the issued certificate.

2. Certificate Renewal for an Onboarded Device

   • An onboarded device requests certificate renewal using EST.

   • The system validates the request and issues a new certificate.

   • The device replaces its old certificate with the new one.

3. Handling Unauthorized Requests

   • A device with invalid credentials tries to access the EST endpoint.

   • The system rejects the request with an appropriate error response.

4. Certificate Revocation for a Compromised Device

   • An admin requests certificate revocation for a specific device.

   • The system revokes the certificate and updates the revocation list.

   • The revoked device is unable to authenticate using its certificate.

5. High Load Handling

   • Simulate multiple devices requesting certificate issuance simultaneously via EST.

   • Verify that the system handles high traffic without performance degradation.

Edge cases:

• Expired certificates being used for renewal.

• Partial network outages during certificate issuance.

• Unexpected payloads being sent to the EST endpoint.

Feature File

@allure.label.owner:Aircoookie
@allure.label.epic:Features
@allure.label.suite:R_011_EST_Endpoint_for_Onboarded_Devices
@allure.label.package:R_011_EST_Endpoint_for_Onboarded_Devices
Feature: R_011 EST Endpoint for Onboarded Devices
  The system must provide an EST endpoint to securely onboard devices.

  Background:
    Given the EST endpoint is available

  Scenario Outline: Credential enrollment with a client certificate
    Given a new device with serial number "<serial_number>"
    And the IDevID Truststore and serial number registration pattern is configured in Trustpoint
    When the device sends an EST simpleenroll request for a new <credential_type> credential using its <client_cert_type> cert
    Then the request should <outcome>
    And if successful issue a new <credential_type> credential for "<serial_number>"
    And if failed the error message should be "<error_message>"

    Examples:
      | serial_number | client_cert_type | credential_type  | outcome | error_message |
      | Device123     | idevid           | domaincredential | succeed | -             |
      | Device234     | domaincredential | tlsserver        | succeed | -             |
      | Device345     | idevid           | tlsserver        | fail    | (any)         |
      | Device456     | tlsserver        | tlsserver        | fail    | must be DOMAIN_CREDENTIAL |
      | Device567     | idevid           | tlsserver        | fail    | must be DOMAIN_CREDENTIAL |
      | Device678     | tlsserver        | domaincredential | fail    | (any)         |

  Scenario: A device requests a second domain credential with its IDevID
    Given an onboarded device with serial number "Device123" and an issued valid domain credential
    When the device sends a EST request for a new domain credential using its IDevID
    Then the system should reject the request
    And if failed the error message should be "Device already onboarded"

  Scenario: A device successfully requests an application credential with username and password
    Given a new device with serial number "Device234"
    And the device is added to Trustpoint and the password is known to the device
    When the device sends a EST request for a new certificate
    Then the system should issue a new certificate for "Device234"
    And the device should store the issued certificate

  Scenario: An onboarded device renews its certificate
    Given an onboarded device with identifier "Device456" and an active certificate
    When the device sends a EST simplereenroll request for certificate renewal
    Then the system should issue a new certificate for "Device456"
    And the device should replace its old certificate with the new one

  Scenario: A device attempts to renew a different certificate
    Given an onboarded device with identifier "Device567" and an active certificate
    When the device sends a EST simplereenroll request where the CSR signer is different from the TLS client certificate
    Then the system should reject the request

  Scenario: A device attempts to renew an expired certificate
    Given an onboarded device with identifier "Device567" and an active certificate
    And the certificate has expired
    When the device sends a EST simplereenroll request for certificate renewal
    Then the system should reject the request

  Scenario: A device attempts to renew a revoked certificate
    Given an onboarded device with identifier "Device567" and an active certificate
    And an admin revokes the certificate for "Device567"
    When the device sends a EST simplereenroll request for certificate renewal
    Then the system should reject the request

  Scenario: Unauthorized device attempts to access the EST endpoint
    Given a device with invalid credentials
    When the device sends a EST request
    Then the system should reject the request with an "Unauthorized" error

  Scenario: Admin revokes a device certificate
    Given a registered device with identifier "Device789" and a valid certificate
    When an admin revokes the certificate for "Device789"
    Then the system should update the revocation list
    And "Device789" should no longer authenticate using its certificate

  Scenario Outline: High load certificate issuance
    Given <num_devices> devices are requesting certificates simultaneously via EST
    When the EST endpoint processes the requests
    Then all certificates should be issued within <max_response_time> milliseconds

    Examples:
      | num_devices | max_response_time |
      | 100        | 500               |
      | 1000       | 1000              |

R_012

This testcase is related to requirement R_012.

Test Idea

To verify that the system provides multi-language UI options, we will test the following scenarios:

1. Default Language Selection

   • A new user accesses the system.

   • The system detects the browser’s language settings and applies the appropriate default language.

   • If no supported language is detected, the system defaults to English.

2. Manual Language Selection

   • A user manually selects a different language from the UI settings.

   • The system updates all UI elements to reflect the chosen language.

   • The language setting persists across sessions.

3. Language Persistence

   • A user selects a language and logs out.

   • Upon re-login, the system retains the user’s language preference.

4. UI Translation Accuracy

   • Verify that key UI elements (menus, buttons, notifications) are translated correctly for each supported language.

   • Ensure that dynamic text (e.g., form labels, user-generated content) remains unaffected.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_012_Multi_language_support
@allure.label.package:R_012_Multi_language_support
Feature: Language Selection and Translation
  The system should support multi-language UI options for global usability.

  Background:
    Given the system supports the following languages:
      | language |
      | English  |
      | German   |

  Scenario Outline: Default language selection based on browser settings
    Given a new user accesses the system with browser language <language>
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |

  Scenario Outline: User manually selects a different language
    Given the admin user is logged into TPC_Web
    When the user selects <language> from the language settings
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |

  Scenario Outline: Language setting persists after logout
    Given the admin user is logged into TPC_Web
    When the user selects <language> from the language settings
    and the user logs out and logs back in
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |

  Scenario Outline: Verify UI elements are translated correctly
    Given the admin user is logged into TPC_Web
    When the user selects <language> from the language settings
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |

R_013

This testcase is related to requirement R_013.

Test Idea

The Remote Credential Download feature allows users to download an issued application credential from a remote device using a one-time password (OTP). The test covers the following scenarios:

1. Admin Generates One-Time Password

   • An admin successfully generates a one-time password (OTP) for a specific issued credential.

   • The OTP is displayed in the “Download on Device Browser” view.

   • The OTP should be valid for a limited time.

2. User Enters OTP Correctly

   • The user visits the “/devices/browser” endpoint.

   • They enter a valid OTP.

   • The system grants access to a page where the user can select the format for the credential download.

3. User Enters OTP Incorrectly

   • The user visits the “/devices/browser” endpoint.

   • They enter an invalid OTP.

   • The system displays a warning message indicating the OTP is incorrect.

   • The user is not granted access to download the credential.

4. User Downloads Credential

   • The user is on the credential download page.

   • The download token is still valid (not expired).

   • The user enters a password to encrypt the private key.

   • The user selects a file format.

   • The credential is successfully downloaded in the selected format.

Feature File

@allure.label.owner:Aircoookie
@allure.label.epic:Features
@allure.label.suite:R_013_Remote_Credential_Download
@allure.label.package:R_013_Remote_Credential_Download
@fixture.r013.setup
Feature: R_013 Remote Credential Download
  The system must allow users to securely download an issued credential
  from a remote device without requiring user authentication.
  Instead, a one-time password (OTP) should be used to authorize the download.

  Background:
    Given the TPC_Web application is running

  @critical
  Scenario: Admin creates one time password
    Given an issued credential is successfully issued
    And the admin user is logged into TPC_Web
    When the admin visits the associated "Download on Device browser" view
    Then a one-time password is displayed which can be used to download the credential from a remote device

  @normal
  Scenario: User enters one time password correctly
    Given a correct one-time password
    When the user visits the "/devices/browser" endpoint and enters the OTP
    Then they will receive a page to select the format for the credential download

  @minor
  Scenario: User enters one time password incorrectly
    Given an incorrect one-time password
    When the user visits the "/devices/browser" endpoint and enters the OTP
    Then they will receive a warning saying the OTP is incorrect

  @critical
  Scenario: User downloads credential on remote device browser
    Given the user is on the credential download page
    And the download token is not yet expired
    When the user enters a password to encrypt the credential private key
    And selects a file format
    Then the credential will be downloaded to their browser in the requested format

Security Requirements

R_101

This testcase is related to requirement R_101.

Test Idea

To verify that administrators can configure security levels for different Trustpoint components, we will test the following scenarios:

1. Set Security Level for a Component

   • The admin selects a Trustpoint component.

   • The admin sets the security level to “High”.

   • The system successfully applies and saves the security level.

2. Modify an Existing Security Level

   • The admin updates the security level of a component from “Medium” to “High”.

   • The system correctly applies and reflects the change.

3. Invalid Security Level Input is Rejected

   • The admin attempts to set an invalid security level.

   • The system rejects the input and displays an error.

4. Security Level Persists After System Restart

   • The admin configures a security level for a component.

   • The system is restarted.

   • The security level remains correctly applied.

5. Security Level Affects System Behavior

   • A component with a high-security level enforces stricter access control.

   • A component with a low-security level has more lenient settings.

   • The system behaves accordingly.

6. Security Configuration is Logged

   • Every change to security levels is logged.

   • The log contains details such as timestamp, admin ID, and old/new security levels.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_101_Security_Configuration
@allure.label.package:R_101_Security_Configuration
Feature: Security Level Configuration
  Administrators can configure security levels for different Trustpoint components.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Admin sets security level for a component
    Given the Trustpoint component <component> is selected
    When the admin sets the security level to <security_level>
    Then the system should apply the security level <security_level>
    And the system should log the security level change with details

    Examples:
      | component    | security_level |
      | TP_Client_01 | High           |
      | TP_Client_02 | Medium         |
      | TP_Client_03 | Low            |

  Scenario: Admin modifies an existing security level
    Given the Trustpoint component "TP_Client_01" has security level "Medium"
    When the admin sets the security level to "High"
    Then the system should apply the security level "High"
    And the system should log the security level change with details

  Scenario: Invalid security level input is rejected
    Given the Trustpoint component "TP_Client_01" is selected
    When the admin sets the security level to "UltraSecure"
    Then the system should reject the input with error "Invalid security level"

  Scenario: Security level persists after system restart
    Given the Trustpoint component "TP_Client_01" has security level "High"
    When the system is restarted
    Then the Trustpoint component "TP_Client_01" should still have security level "High"

  Scenario: Security level affects system behavior
    Given the Trustpoint component "TPC_Web" has security level "High"
    When an unauthorized user attempts access
    Then access should be denied

  Scenario: Security configuration changes are logged
    Given the Trustpoint component "TP_Client_01" is selected
    When the admin sets the security level to "High"
    Then the system should log the security level change with details

R_102

This testcase is related to requirement R_102.

Test Idea

To verify that certificate template security is enforced properly, we will test the following scenarios:

1. Only Authorized Users Can Access Certificate Templates

   • A user with admin privileges accesses the certificate templates.

   • A regular user attempts to access certificate templates but is denied.

2. Secure Handling of Certificate Templates

   • A certificate template is created with restricted access.

   • The system prevents unauthorized modifications.

   • The system encrypts stored templates.

3. Modification of Certificate Templates

   • An admin updates a certificate template.

   • Unauthorized users attempt modifications but are denied.

4. Deletion Restrictions

   • Only authorized users can delete certificate templates.

   • Unauthorized users receive an error when attempting deletion.

5. Logging of Access and Modifications

   • The system logs every access and modification of certificate templates.

6. Secure Export of Certificate Templates

   • The system ensures that exported templates are encrypted.

   • Unauthorized export attempts are blocked.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_102_Certificate_Template_Security
@allure.label.package:R_102_Certificate_Template_Security
Feature: Certificate Template Security
  Enforce access control and secure handling for certificate templates.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Authorized user accesses certificate templates
    Given the user has role <role>
    When the user attempts to access certificate templates
    Then access should be <access_outcome>

    Examples:
      | role  | access_outcome |
      | Admin | granted        |
      | User  | denied         |

  Scenario Outline: Unauthorized user attempts to modify a certificate template
    Given the user has role <role>
    And a certificate template named <template_name> exists
    When the user attempts to modify the certificate template
    Then modification should be <modification_outcome>

    Examples:
      | role  | template_name   | modification_outcome |
      | Admin | Secure_Template | allowed              |
      | User  | Secure_Template | denied               |

  Scenario: Secure handling of certificate templates
    Given a certificate template named "Sensitive_Template" exists
    When an unauthorized user attempts to access it
    Then access should be denied
    And the attempt should be logged

  Scenario: Unauthorized deletion attempt
    Given a certificate template named "HighSecurity_Template" exists
    When a non-admin user attempts to delete it
    Then the deletion should be rejected
    And an error message "Permission denied" should be shown

  Scenario: Secure export of certificate templates
    Given a certificate template named "Exportable_Template" exists
    When an admin exports the template
    Then the exported template should be encrypted

  Scenario: Unauthorized export attempt
    Given a certificate template named "Exportable_Template" exists
    When a non-admin user attempts to export the template
    Then export should be denied
    And the attempt should be logged

R_103

This testcase is related to requirement R_103.

Test Idea

To test the requirement of creating, viewing, editing, and deleting Domain using the TPC_Web interface, the focus will be on validating the complete lifecycle of domain management through the web platform.

The test would start with an admin user creating a new domain through the web interface. This process involves navigating to the appropriate page, filling out the required fields (e.g., name, issuing ca), and submitting the form. Once the domain is created, the test would verify that it appears in the list of domains and that all details are accurately displayed on its details page.

Finally, the test would validate the deletion process, where the admin removes the domain through the web interface. Once deleted, the system should ensure that the domain is no longer accessible or visible in any lists or details pages. Additional negative tests could confirm appropriate handling when attempting to access or manipulate a non-existent or already-deleted domain.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_103_Domain_Management
@allure.label.package:R_103_Domain_Management
Feature: Manage domains via TPC_Web
  As an admin user
  I want to create, view, edit, and delete domains
  So that I can manage domains effectively through the web interface.

  Background:
    Given the admin user is logged into TPC_Web
    And the issuing ca with unique name "test_CA" with pkcs12 file exist

  Scenario Outline: Add a new domain
    When the admin navigates to the "Add new Domain" page
    And the admin fills in the domain details with <name> and issuing CA "test_CA"
    And the admin clicks on "Add new Domain"
    Then the system should display a confirmation message stating "Successfully created domain"
    And the new domain with <name> and issuing CA "test_CA" should appear in the domain list

    Examples:
      | name    |
      | arburg  |
      | homag   |

  Scenario Outline: Delete an existing domain
    Given a domain <name> with issuing ca "test_CA" exist
    When the admin navigates to the "domain list" page
    And the admin deletes the domain with the name <name>
    Then the system should display a confirmation message stating "Successfully deleted"
    And the domain <name> should no longer appear in the domain list

    Examples:
      | name    |
      | arburg  |
      | homag   |

  Scenario: Handle non-existent domains
    When the admin attempts to view the details of a non-existent domain "NonExistentID"
    Then the system should display an error message

R_104

This testcase is related to requirement R_104.

Test Idea

To test the requirement of creating, viewing, editing, and deleting Trust-Store using the TPC_Web interface, the focus will be on validating the complete lifecycle of truststore management through the web platform.

The test would start with an admin user creating a new truststore through the web interface. This process involves navigating to the appropriate page, filling out the required fields (e.g., name, issuing ca), and submitting the form. Once the truststore is created, the test would verify that it appears in the list of truststores and that all details are accurately displayed on its details page.

Finally, the test would validate the deletion process, where the admin removes the truststore through the web interface. Once deleted, the system should ensure that the truststore is no longer accessible or visible in any lists or details pages. Additional negative tests could confirm appropriate handling when attempting to access or manipulate a non-existent or already-deleted truststore.

Feature File

@allure.label.epic:Features
@allure.label.suite:R_104_Truststore_Management
@allure.label.package:R_104_Truststore_Management
Feature: Manage truststores via TPC_Web
  As an admin user
  I want to create, view, edit, and delete truststores
  So that I can manage truststores effectively through the web interface.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Add a new truststore
    When the admin navigates to the "Add new Truststore" page
    And the admin fills in the truststore details with <name>, <intended_usage> and <file_type>
    And the admin clicks on "Add new Truststore"
    Then the system should display a confirmation message stating "Successfully created the Truststore"
    And the new truststore with <name> and <intended_usage> should appear in the truststore list
    Examples:
      | name         | intended_usage | file_type |
      | truststore_1 | IDevID         | .pem      |
      | truststore_2 | TLS            | .pem      |
      | truststore_3 | Generic        | .pem      |
      | truststore_4 | IDevID         | .pkcs7    |
      | truststore_5 | TLS            | .pkcs7    |
      | truststore_6 | Generic        | .pkcs7    |

  Scenario Outline: Delete an existing truststore
    Given a truststore <name> with <intended_usage> exist
    When the admin navigates to the "truststore list" page
    And the admin deletes the truststore with the name <name>
    Then the system should display a confirmation message stating "Successfully deleted"
    And the truststore <name> should no longer appear in the truststore list

    Examples:
      | name         | intended_usage |
      | truststore_1 | IDevID         |
      | truststore_2 | TLS            |
      | truststore_3 | Generic        |

  Scenario: Handle non-existent truststores
    When the admin attempts to view the details of a non-existent truststore "NonExistentID"
    Then the system should display an error message

Feature Requirements

F_001

This testcase is related to requirement F_001.

Test Idea

To verify that an NTEU (Non-Technical Experienced User) can successfully execute R_001 and R_002 in TPC_Web, we will test the following scenarios:

1. NTEU Logs into the System

   • A valid NTEU logs into the system successfully.

   • An invalid NTEU login attempt fails.

2. Identity Management (R_001)

   • NTEU creates a digital identity.

   • NTEU views an existing digital identity.

   • NTEU edits an existing digital identity.

   • NTEU deletes a digital identity.

3. Zero-Touch Onboarding (R_002)

   • NTEU initiates device onboarding.

   • The system automatically uses a zero-touch onboarding protocol.

   • The onboarding process completes successfully.

4. UI Accessibility and User Experience

   • The UI provides clear instructions and feedback.

   • Error messages are understandable for an NTEU.

   • The onboarding and identity management workflows are intuitive.

Feature File

@allure.label.epic:Features
@allure.label.suite:F_001_NTEU_Identity_Management_and_Zero-Touch_Onboarding
@allure.label.package:F_001_NTEU_Identity_Management_and_Zero-Touch_Onboarding
Feature: NTEU Identity Management and Zero-Touch Onboarding
  NTEU must be able to log in to the TPC_Web app and perform identity management (R_001) and zero-touch onboarding (R_002).

  Background:
    Given the TPC_Web application is running

  Scenario Outline: NTEU logs into the system
    Given the user is an NTEU with username <username> and password <password>
    When the user attempts to log in
    Then login should be <login_outcome>

    Examples:
      | username     | password   | login_outcome |
      | valid_user   | correct_pw | successful    |
      | invalid_user | wrong_pw   | failed        |

  Scenario: NTEU creates a digital identity
    Given the NTEU is logged in
    When the NTEU navigates to the identity creation page
    And the NTEU enters valid identity details
    And submits the form
    Then the identity should be successfully created

  Scenario: NTEU views an existing digital identity
    Given the NTEU is logged in
    When the NTEU navigates to the identity list
    And selects an identity
    Then the identity details should be displayed

  Scenario: NTEU edits a digital identity
    Given the NTEU is logged in
    And a digital identity exists
    When the NTEU edits the identity details
    And submits the form
    Then the identity should be updated successfully

  Scenario: NTEU deletes a digital identity
    Given the NTEU is logged in
    And a digital identity exists
    When the NTEU deletes the identity
    Then the identity should be removed

  Scenario: NTEU initiates device onboarding using a zero-touch protocol
    Given the NTEU is logged in
    When the NTEU starts the device onboarding process
    Then the system should automatically use a zero-touch onboarding protocol
    And the onboarding process should complete successfully

  Scenario: UI provides clear feedback to the NTEU
    Given the NTEU is on any action page
    When the NTEU enters invalid information
    Then the system should display a clear error message
    And provide guidance for correction