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, edit and delete an identity	TPC_Web must provide a way to create, view, edit and delete a digital identity.	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	Auto-Generated Issuing CAs	Automatically generate Issuing Certificate Authorities based on configuration.	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

Security Requirements

Security Requirements

Name (Identifier)	Title	Description	Component(s)	Importance
R_101	Devices are only allowed to communicate with valid certificates	Machines or devices in the network are only allowed to communicate with a valid certificate.	TP_Client (multiple)	High
R_102	Encrypted Communication	The communication between machines has to be encrypted with the given algorithm.	TP_Client (multiple)	High
R_103	Security Level Configuration	Allow administrators to configure security levels for different TrustPoint components.	Admin, TPC_Web	Medium
R_104	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

Features Not To Be Tested

Feature (Description)	Reason

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 Python Cucumber (behave) to create behavior-driven development (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 behavior-driven integration tests using the Python Cucumber framework (behave).

   • 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 (Python Cucumber framework) 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 digital identities using the TPC_Web interface, the focus will be on validating the complete lifecycle of identity management through the web platform.

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

Following the creation, the admin user would edit the identity’s details, such as updating the name or identifier, and save the changes. The test should confirm that the modifications are reflected immediately and correctly in both the details view and any listings.

Finally, the test would validate the deletion process, where the admin removes the identity through the web interface. Once deleted, the system should ensure that the identity 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 identity.

Feature File

Feature: Manage digital identities via TPC_Web
  As an admin user
  I want to create, view, edit, and delete digital identities
  So that I can manage trusted identities effectively through the web interface.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario Outline: Create a new identity
    When the admin navigates to the "Create Identity" page
    And the admin fills in the identity details with <name> and <identifier>
    And the admin submits the form
    Then the system should display a confirmation message
    And the new identity <name> with <identifier> should appear in the identity list

    Examples:
      | name         | identifier |
      | AliceID      | ID1234     |
      | BobID        | ID5678     |

  Scenario Outline: View an existing identity
    Given the identity <name> with <identifier> exists
    When the admin navigates to the identity details page for <name>
    Then the system should display the correct details for <name> and <identifier>

    Examples:
      | name         | identifier |
      | AliceID      | ID1234     |
      | BobID        | ID5678     |

  Scenario Outline: Edit an existing identity
    Given the identity <old_name> with <old_identifier> exists
    When the admin navigates to the identity details page for <old_name>
    And the admin updates the name to <new_name> and identifier to <new_identifier>
    And the admin saves the changes
    Then the system should display a confirmation message
    And the updated identity <new_name> with <new_identifier> should appear in the identity list

    Examples:
      | old_name     | old_identifier | new_name      | new_identifier |
      | AliceID      | ID1234         | AliceUpdated  | ID5678         |
      | BobID        | ID5678         | BobUpdated    | ID9101         |

  Scenario Outline: Delete an existing identity
    Given the identity <name> with <identifier> exists
    When the admin navigates to the identity details page for <name>
    And the admin deletes the identity with the name <name>
    Then the system should display a confirmation message
    And the identity <name> should no longer appear in the identity list

    Examples:
      | name         | identifier |
      | AliceUpdated | ID5678     |
      | BobUpdated   | ID9101     |

  Scenario: Handle non-existent identities
    When the admin attempts to view the details of a non-existent identity "NonExistentID"
    Then the system should display an error message stating "Identity not found"

R_002

This testcase is related to requirement R_002.

Test Idea

Feature File

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

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

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. Since the code is the same, just executed in a Docker environment, we see no need to let those tests run automatically. Therefore, we will pass the test for this requirement if the container can be built and ran on another system.

Feature File

Nonexistent.

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

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

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 system automatically generates Issuing CAs based on configuration, we will test the following scenarios:

1. Successful Auto-Generation of an Issuing CA

   • The admin configures the system with predefined settings for an Issuing CA.

   • The system automatically generates the CA without manual intervention.

   • The CA appears in the list of available CAs.

2. Auto-Generation with Different Configurations

   • The admin sets different parameters for CA generation (e.g., key size, validity period).

   • The system creates the CA using the specified configuration.

   • The generated CA matches the given settings.

3. Failure Handling in CA Generation

   • The system prevents generation if required parameters are missing.

   • The system logs errors when CA generation fails.

4. Verification of Generated CA Details

   • The generated CA contains the expected attributes (issuer name, serial number, key usage, etc.).

   • The CA is functional and can issue end-entity certificates.

Edge cases:

• Attempting to generate a CA with invalid parameters.

• Generating multiple CAs in quick succession.

Feature File

Feature: Auto-Generated Issuing CAs
  The system must automatically generate Issuing Certificate Authorities (CAs) based on configuration.

  Background:
    Given the admin user is logged into TPC_Web

  Scenario: Successful auto-generation of an issuing CA
    When the admin configures the system for auto-generation of an Issuing CA
    Then the system automatically generates the CA
    And the generated CA appears in the list of available CAs

  Scenario Outline: Auto-generation with different configurations
    When the admin sets the following CA configuration:
      | key_size   | validity_period | subject_name   |
      | <key_size> | <validity>      | <subject_name> |
    Then the system generates a CA with:
      | key_size   | validity_period | subject_name   |
      | <key_size> | <validity>      | <subject_name> |

    Examples:
      | key_size | validity | subject_name |
      | 2048     | 365      | CA_Test1     |
      | 4096     | 730      | Secure_CA    |

  Scenario: Handling missing parameters during CA generation
    When the admin attempts to generate an Issuing CA with incomplete configuration
    Then the system prevents the CA from being generated
    And an appropriate error message is logged

  Scenario: Verification of generated CA details
    When the admin inspects the generated CA details
    Then the CA should contain:
      | attribute     | expected_value   |
      | issuer name   | TPC_Web_CA       |
      | key usage     | Certificate Sign |
      | serial number | Auto-Generated   |

  Scenario: Ensuring the CA can issue certificates
    When the admin attempts to issue a certificate using the generated CA
    Then the certificate issuance should succeed

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

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

Feature: EST Endpoint for Onboarded Devices
  The system must provide an EST endpoint to securely onboard devices.

  Background:
    Given the EST endpoint is available

  Scenario: A device successfully requests a certificate
    Given a new device with identifier "Device123"
    When the device sends a EST 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 EST 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 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

Feature: Language Selection and Translation
  The system should support multi-language UI options for global usability.

  Background:
    Given the system supports the following languages:
      | English | German | Spanish | French |

  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   |
      | Spanish  |
      | French   |

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

    Examples:
      | language |
      | English  |
      | German   |
      | Spanish  |
      | French   |

  Scenario Outline: Language setting persists after logout
    Given a user has selected <language> as their preferred language
    When the user logs out and logs back in
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |
      | Spanish  |
      | French   |

  Scenario Outline: Verify UI elements are translated correctly
    When the user selects <language> from the language settings
    Then the system should display the UI in <language>

    Examples:
      | language |
      | English  |
      | German   |
      | Spanish  |
      | French   |

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

@fixture.r013.setup
Feature: Remote Credential Download
	The system must allow users to securely download an issued application 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
		
	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
		
	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
		
	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
		
	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 only devices with valid certificates can communicate, we will test the following scenarios:

1. Device with a Valid Certificate Can Communicate

   • A device is provisioned with a valid certificate.

   • The system allows the device to establish communication.

2. Device with an Expired Certificate is Denied

   • A device presents an expired certificate.

   • The system denies communication and logs the attempt.

3. Device with a Revoked Certificate is Denied

   • A certificate is revoked by the system administrator.

   • A device attempting to communicate with the revoked certificate is rejected.

4. Device with a Self-Signed or Untrusted Certificate is Denied

   • A device presents a self-signed certificate.

   • The system denies communication.

5. Device with a Tampered Certificate is Denied

   • A device presents a certificate with altered data.

   • The system detects the tampering and blocks communication.

6. Device Attempts Communication Without a Certificate

   • A device attempts to communicate without presenting any certificate.

   • The system rejects the request.

7. Logging of Authentication Failures

   • Every failed authentication attempt due to an invalid, expired, or revoked certificate is logged.

Feature File

Feature: Device Certificate Validation
  Devices in the network are only allowed to communicate with a valid certificate.

  Background:
    Given the system enforces certificate validation for all devices

  Scenario: Device with a valid certificate is allowed to communicate
    Given a device has a valid certificate
    When the device attempts to establish communication
    Then the system should allow the communication

  Scenario: Device with an expired certificate is denied communication
    Given a device has a expired certificate
    When the device attempts to establish communication
    Then the system should "deny" the communication
    And log the authentication failure with reason "Expired Certificate"

  Scenario: Device with a revoked certificate is denied communication
    Given a device has a revoked certificate
    When the device attempts to establish communication
    Then the system should "deny" the communication
    And log the authentication failure with reason "Revoked Certificate"

  Scenario: Device with a self-signed certificate is denied communication
    Given a device has a self-signed certificate
    When the device attempts to establish communication
    Then the system should "deny" the communication
    And log the authentication failure with reason "Untrusted Certificate Authority"

  Scenario: Device with a tampered certificate is denied communication
    Given a device has a tampered certificate
    When the device attempts to establish communication
    Then the system should "deny" the communication
    And log the authentication failure with reason "Certificate Integrity Violation"

  Scenario: Device attempts communication without a certificate
    Given a device does not present a certificate
    When the device attempts to establish communication
    Then the system should "deny" the communication
    And log the authentication failure with reason "Missing Certificate"

R_102

This testcase is related to requirement R_102.

Test Idea

To verify that communication between machines is encrypted using the given algorithm, we will test the following scenarios:

1. Valid Encrypted Communication

   • Two machines establish a communication session.

   • The communication is encrypted using the specified encryption algorithm.

   • The system successfully verifies encryption.

2. Communication with No Encryption is Rejected

   • A machine attempts to communicate without encryption.

   • The system detects the unencrypted communication and blocks it.

   • The system logs the rejected attempt.

3. Communication Using an Unsupported Encryption Algorithm is Rejected

   • A machine attempts to use an encryption algorithm that is not approved.

   • The system rejects the communication.

   • The system logs the failed attempt.

4. Communication Using a Weak Encryption Algorithm is Rejected

   • A machine attempts to use a weak or deprecated encryption algorithm.

   • The system denies the communication.

   • The system logs the failure with a warning.

5. Communication is Encrypted with the Correct Key Exchange Mechanism

   • Two machines establish a secure session using the correct key exchange protocol.

   • The system verifies that the encryption is correctly applied.

6. Communication is Tamper-Resistant

   • A third party attempts to modify an encrypted message.

   • The system detects the tampering and terminates the connection.

Feature File

Feature: Encrypted Communication
  The communication between machines must be encrypted using the specified algorithm.

  Background:
    Given the system enforces encrypted communication with algorithm "AES-256"

  Scenario: Communication using the correct encryption algorithm
    Given a machine attempts to communicate using "AES-256"
    When the system verifies the encryption
    Then the communication should be "allowed"

  Scenario: Communication without encryption is blocked
    Given a machine attempts to communicate without encryption
    When the system verifies the encryption
    Then the communication should be "denied"
    And log the failure with reason "Unencrypted Communication Attempt"

  Scenario: Communication using an unsupported encryption algorithm is blocked
    Given a machine attempts to communicate using "RC4"
    When the system verifies the encryption
    Then the communication should be "denied"
    And log the failure with reason "Unsupported Encryption Algorithm"

  Scenario: Communication using a weak encryption algorithm is blocked
    Given a machine attempts to communicate using "DES"
    When the system verifies the encryption
    Then the communication should be "denied"
    And log the failure with reason "Weak Encryption Algorithm"

  Scenario: Communication uses the correct key exchange mechanism
    Given two machines establish a secure session using "ECDH"
    When the system verifies the key exchange
    Then the communication should be allowed

  Scenario: Communication is tamper-resistant
    Given an encrypted message is tampered with
    When the system detects tampering
    Then the communication should be "terminated"
    And log the failure with reason "Message Integrity Violation"

R_103

This testcase is related to requirement R_103.

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

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_104

This testcase is related to requirement R_104.

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

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

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

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

Glossary

Glossary

Abbreviation	Definition
TM	Test Manager
PM	Project Manager
Dev	Development Team
Client	Stakeholders or End Users