OpenCloud Compose: Comprehensive Test Plan

Introduction: Ensuring Quality in OpenCloud Compose

Testing is a critical part of the software development lifecycle, ensuring that the OpenCloud Compose project functions as expected, meets user needs, and remains stable and reliable. This document provides a detailed test plan for the OpenCloud Compose project. This plan covers various service combinations, configurations, and deployment scenarios. Following this plan will help identify and address issues, ensuring the successful deployment and operation of OpenCloud. The modular architecture of the repository allows for flexible testing across different components and configurations. This plan will be a living document, updated regularly to reflect the latest changes and features in the OpenCloud Compose project. Proper testing is essential to deliver a high-quality product. By carefully following the outlined test scenarios and procedures, we can confidently release the OpenCloud Compose project, knowing that it meets the required standards. This document serves as a guide for comprehensive testing. This will allow for the validation of the various features and integrations that OpenCloud Compose offers.

Test Environment: Setting Up for Success

Prerequisites: Setting the Stage for Testing

To effectively test the OpenCloud Compose project, a suitable test environment is essential. Before beginning any tests, certain prerequisites must be in place. This includes the correct versions of Docker and Docker Compose. Ensure you have Docker Engine version 20.10 or higher and Docker Compose v2 installed. These are vital for building, running, and managing the Docker containers that make up OpenCloud Compose. Sufficient disk space is also crucial. A minimum of 10GB of disk space is recommended to accommodate the various images and data associated with the project. It's also important to ensure that ports 80 and 443 are available, along with other ports depending on the specific configuration. These ports are frequently used for web services and need to be open to allow access to the OpenCloud instance. Test domains are essential for local testing. Configuring test domains in the /etc/hosts file or using DNS is crucial for simulating a real-world environment. Tools like mkcert can be used to generate local SSL certificates, providing a secure testing environment that mimics production setups. Following these prerequisites will ensure that you have a proper test environment to begin your work. The goal is to accurately test the product under the right conditions.

Test Domains: Navigating the Digital Landscape

Setting up test domains is essential for local testing of the OpenCloud Compose project. For local testing, add specific entries to your /etc/hosts file. These entries map domain names to the local IP address (127.0.0.1). This approach allows you to access the various services within the OpenCloud Compose project using friendly domain names, simulating a production environment. The use of domain names makes it easier to test and navigate between the different components of the project, such as the OpenCloud web interface, Traefik, Collabora Online, and Keycloak. When testing the project locally, the test domains will make the services easier to work with. These domain names should be correctly configured to ensure that the project functions as designed, and that you can access all the necessary services and features. Proper configuration of test domains will ensure that you can access each service easily and test it effectively. The /etc/hosts file is essential for local development. By configuring the domains correctly, it ensures that your testing environment accurately simulates a live deployment. The correct configuration allows you to work with the different services and components in an organized and manageable way.

Test Scenarios: Putting OpenCloud Compose to the Test

1. Basic Deployment Tests: The Foundation of Functionality

Test 1.1: Minimal OpenCloud with Traefik: Starting with the Basics

This test validates the most basic deployment of OpenCloud with Traefik, ensuring that the core components function correctly. Begin by specifying the configuration using docker-compose.yml and traefik/opencloud.yml. Environment variables are crucial for configuring the deployment, including the administrator password, domain, and an indicator for insecure connections. The test steps involve copying the .env.example file to .env, setting the necessary environment variables, and running docker compose up -d. This will start the containers in detached mode. You then have to wait for the containers to become healthy and then verify they are running. After these steps, you access the OpenCloud web interface and then log in using the configured username and password. The expected results include successful container startup, web interface accessibility, and successful login. These steps are designed to ensure that the core functionality is working. This test is a critical baseline for confirming the correct operation of the system.

Test 1.2: OpenCloud with Built-in LDAP Only: Focusing on Identity Management

This test focuses on deploying OpenCloud without Traefik, utilizing the built-in LDAP for user authentication and management. First start OpenCloud. Then check the logs for successful LDAP initialization and admin user creation. The environment variables remain consistent, which include the administrator password and domain. The expected results include the successful startup of the OpenCloud container and successful initialization of the built-in LDAP, along with the creation of the admin user with the configured password. This test validates the core identity management component. Proper identity management is a critical aspect of any cloud platform. If these initial tests fail, then there will be a need to evaluate the reasons behind the failure.

2. Web Office Integration Tests: Enhancing Productivity

Test 2.1: OpenCloud with Collabora Online: Integrating Office Capabilities

This test verifies the integration of Collabora Online with OpenCloud. This allows for document creation, editing, and saving. Configuration involves specifying multiple Compose files, including Collabora, Traefik, and OpenCloud configurations. The environment variables include settings for the administrator password, domains, and Collabora settings, such as the admin user and password, as well as enabling SSL if needed. The test steps start by deploying the full stack. Then verify the successful startup of all containers. Log into OpenCloud as admin and create a new document. You then must verify that the Collabora editor opens. You will then type text, save it, close the editor, and then reopen the document. Afterward, access the Collabora admin panel and verify the WOPI server connectivity. The expected results include the successful startup of Collabora and the WOPI server, the ability to create and edit documents, and access to the Collabora admin panel. This test confirms that users can perform their daily work. This verifies that you can create, edit, and save documents within the OpenCloud environment.

3. Identity Management Tests: Secure User Access

Test 3.1: OpenCloud with Keycloak and LDAP (Shared User Directory): Centralized User Management

This test validates the integration of Keycloak and LDAP for a shared user directory. This is useful for centralized identity management. Configuration involves specifying the necessary Compose files, which include configurations for Keycloak, LDAP, Traefik, and OpenCloud. Environment variables will include domain settings, Keycloak, LDAP, and database credentials. The testing process begins by deploying OpenCloud with Keycloak and LDAP. Then verify that all containers start successfully. You have to wait for Keycloak realm import to be complete. Then you will have to access the Keycloak admin console, log in to Keycloak with admin credentials, and verify that the OpenCloud realm exists. You will need to check the LDAP user federation setup. You will have to create a test user in Keycloak and then log into OpenCloud with the test user. You then will have to verify the user in OpenCloud user management. The expected results include all containers starting successfully, the initialization of Keycloak with the OpenCloud realm, the configuration of LDAP federation, and the ability for users created in Keycloak to log into OpenCloud, and the sharing of the user directory between Keycloak and OpenCloud. This ensures that the user authentication and authorization process is working correctly.

Test 3.2: OpenCloud with External IDP (Auto-provisioning): Seamless Authentication

This test focuses on the integration of OpenCloud with an external Identity Provider (IDP). This facilitates auto-provisioning. The configuration involves the Compose files for external IDP, and OpenCloud. Environment variables will include domain information and settings for the IDP, as well as the LDAP bind password. The test starts with setting up an external Keycloak and deploying OpenCloud with the external IDP configuration. You will need to verify the successful start of the LDAP server. After that, you will have to access the OpenCloud login page and be redirected to the external IDP for authentication. After logging in with the external IDP credentials, you then verify the auto-provisioning of the user in OpenCloud LDAP. You will then check if the user can access the OpenCloud dashboard, and finally verify that the account edit link redirects to the external IDP. The expected results include successful redirection to the external IDP, authentication using the external IDP credentials, auto-provisioning of the user account in OpenCloud, synchronization of user data from the IDP to OpenCloud, and redirection to the external IDP for account management. These steps confirm the correct operation of the external IDP integration.

4. Storage Backend Tests: Ensuring Data Availability

Test 4.1: OpenCloud with S3 Storage (MinIO): Reliable Data Storage

This test validates the use of S3 storage, specifically MinIO, as a storage backend for OpenCloud. The configuration specifies the Compose file for decomposed S3, and Traefik. The environment variables are designed for the admin password, domain, and S3 endpoint. They also configure the region, access key, secret key, and the bucket. The test steps include deploying OpenCloud with the S3 storage backend, verifying the successful start of the MinIO container, and then confirming that OpenCloud connects to MinIO. Log in to OpenCloud, upload a test file, and then confirm that the file is stored in the S3 bucket. You will then have to download and delete the file, then confirm that the file is removed from S3. The expected results are the successful start of the MinIO container, correct connectivity of OpenCloud to the S3 backend, the proper functionality of the file operations with S3 storage, and the storage of files in the configured S3 bucket. This ensures that the system correctly stores and retrieves user data using the S3 backend.

5. Search Integration Tests: Enhancing Data Discovery

Test 5.1: OpenCloud with Apache Tika Full-Text Search: Powerful Search Capabilities

This test validates the full-text search capabilities using Apache Tika. The configuration involves specifying the Compose file for Tika, and Traefik. Environment variables include the administrator password, domain settings, and the Tika image. The test steps start with deploying OpenCloud with Tika search and verifying the successful start of the Tika container. Then you will log in to OpenCloud, upload various document types like PDF, DOCX, and TXT files. You will have to wait for indexing to complete, then perform search queries for document content. Finally, you will have to verify the correct results from the search. The expected results include the successful startup of the Tika container, proper indexing of documents for searching, accurate results for the full-text search, and the extraction of metadata from the different file formats. These steps are essential to verify that the integrated search functionality works.

6. Monitoring Tests: Ensuring System Insights

Test 6.1: OpenCloud with Monitoring Enabled: Gaining System Insights

This test verifies that the system has monitoring enabled. The configuration uses the Compose file for monitoring, as well as Traefik. Environment variables will include the admin password and domain settings. The test steps involve creating an external network, deploying OpenCloud with monitoring, and then accessing the metrics endpoint. You have to verify the metrics in a Prometheus-compatible format. You will then perform operations in OpenCloud, such as login and file upload. You have to check that the metrics reflect the operations. Also, verify that the collaboration metrics are available. The expected results are that the metrics endpoints are accessible, that the metrics conform to the Prometheus format, that the metrics are updated based on OpenCloud activity, and that both the proxy and collaboration metrics are available. This test confirms that the monitoring tools are properly integrated and provide the necessary data.

7. Calendar/Contacts Integration Tests: Facilitating Collaboration

Test 7.1: OpenCloud with Radicale: Centralized Calendar and Contacts

This test validates the calendar and contacts integration using Radicale. The configuration involves specifying the Compose file for Radicale, and Traefik. Environment variables include the admin password, domain settings, and Radicale image information. The test steps involve deploying OpenCloud with Radicale and verifying the successful start of the Radicale container. Then, log in to OpenCloud and access the calendar and contacts interfaces. Create a calendar event and a contact entry. After that, test the CalDAV and CardDAV endpoints with a calendar and contacts client. The expected results are the successful start of the Radicale container, accessibility of the calendar and contacts interfaces, successful event and contact creation, the functionality of the CalDAV/CardDAV endpoints, and the ability of external clients to sync with Radicale. These steps verify that users can manage their calendar and contacts.

8. External Proxy Tests: Extending Accessibility

Test 8.1: OpenCloud with External Proxy (Port Exposure): Testing Reverse Proxy Functionality

This test validates the usage of an external proxy configuration, and the exposure of port. The configuration specifies the Compose file for the external proxy. Environment variables will include the admin password and domain information. The test steps include deploying OpenCloud with the external proxy configuration and verifying that port 9200 is exposed. Access OpenCloud through http://localhost:9200. You will have to configure an external reverse proxy (Nginx or Caddy) to forward traffic to port 9200. Access OpenCloud through the external proxy and then test all the basic functionality through the proxy. The expected results include the accessibility of port 9200, the correct functionality of OpenCloud behind the external reverse proxy, and all features working properly through the proxy. These steps will confirm that the setup with the external proxy works.

Test 8.2: Collabora with External Proxy: Validating Office Suite Integration

This test validates the integration of Collabora with an external proxy. The configuration specifies the Compose files for Collabora and the external proxy. Environment variables include the admin password, domain settings, Collabora domain, and WOPI server domain. The test steps involve deploying the configuration with the external proxy and verifying that the required ports, such as 9200, 9980, and 9300, are exposed. You will need to configure the external reverse proxy to all services. Access OpenCloud through the external proxy. Create and edit documents using Collabora through the proxy and then verify that WOPI communication works correctly through the proxy. The expected results include the proper exposure of the required ports, that the services work correctly behind the external proxy, that the Collabora editor works, and that WOPI server communication is successful. These steps ensure the effective operation of Collabora through the proxy.

9. SSL/TLS Configuration Tests: Ensuring Secure Connections

Test 9.1: Let's Encrypt Certificate Configuration: Secure Communication Setup

This test validates the setup of Let's Encrypt certificates for secure communication. The configuration specifies the Compose file for Traefik and OpenCloud. Environment variables include the admin password, domain settings, Let's Encrypt email, and settings for TLS configuration, along with disabling insecure connections. Prerequisites involve having a valid public domain with DNS configured and ports 80 and 443 accessible from the internet. The test steps involve configuring the environment with a production domain and deploying the OpenCloud stack. You must monitor Traefik logs for the ACME challenge. After that, you need to verify the issuance of the Let's Encrypt certificate and access OpenCloud via HTTPS. You have to verify the valid SSL certificate in the browser and check the details of the certificate. The expected results include successful completion of the ACME challenge, successful issuance of a valid Let's Encrypt certificate, a secure HTTPS connection, and no certificate warnings in the browser. These steps are essential to verify that the secure HTTPS connection works.

Test 9.2: Custom Certificate Configuration (Development): Custom SSL Certificate Validation

This test validates the use of custom certificates in a development environment. The configuration specifies the Compose file for Traefik and OpenCloud. Environment variables include the admin password, domain settings, settings for TLS, the directory for the certificates, and enabling insecure connections. The test steps involve generating the certificates using mkcert. You will also need to create the Traefik dynamic config, in addition to deploying the OpenCloud stack. Then you will have to access OpenCloud via HTTPS and verify that the custom certificate is being used. You will need to check the certificate details in the browser. The expected results are the successful loading of the custom certificates by Traefik, the HTTPS connection using the custom certificates, and no certificate warnings, assuming that the mkcert CA is trusted. These steps are essential to test the use of custom certificates in a development environment.

10. Additional Services Tests: Expanding Functionality

Test 10.1: Email Notifications with SMTP: Enabling Email Alerts

This test validates the use of email notifications with SMTP. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include the admin password and domain settings. You will need to enable the notifications service. Configure SMTP settings, such as SMTP host, port, sender, username, password, authentication method, and transport encryption. You need to deploy the OpenCloud stack and then log in and enable email notifications. You will trigger a notification event, like sharing a file, and verify that the email is sent, checking its content and formatting. The expected results include the successful start of the notifications service, the successful establishment of an SMTP connection, the correct sending of notification emails, and appropriate email formatting. These steps are necessary to verify email notification functionality.

Test 10.2: Antivirus Scanning with ClamAV: Integrating Virus Protection

This test validates the integration of antivirus scanning using ClamAV. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include the admin password, domain settings, enabling the antivirus service, and settings for the scan size. The test steps involve deploying OpenCloud, and then waiting for ClamAV to initialize and update its definitions. Upload a clean test file, and then verify the upload is successful. Then upload an EICAR test file, and verify the file is detected and blocked. Check the logs for virus detection. The expected results are the successful start and updates of the ClamAV container, the successful upload of clean files, the detection and blocking of virus test files, and appropriate user notifications upon virus detection. These steps verify the correct operation of virus scanning.

Test 10.3: Demo Users Creation: Creating Demonstration Accounts

This test validates the creation of demo users. The configuration specifies the Compose file for Traefik and OpenCloud. Environment variables include the admin password, domain settings, and enabling demo users. The test steps include enabling the demo users and deploying OpenCloud. Check the logs for the creation of the demo users. Log in with each demo user, such as Alan, Mary, Margaret, Dennis, and Lynn, using the password demo. Verify that each user has access to the dashboard. The expected results are the successful creation of all demo users, the ability of each demo user to log in, and that the demo users have the appropriate default permissions. These steps confirm that the demo users are properly created and can access the necessary features.

11. Complex Integration Tests: Comprehensive Scenario Testing

Test 11.1: Full Production Stack: Simulating a Real-World Deployment

This test validates the full stack, integrating all the services. The configuration specifies the Compose files for Collabora, Keycloak and LDAP, Tika, monitoring, Radicale, Traefik, and OpenCloud. Environment variables will include domain settings, and settings for Collabora, Keycloak, LDAP, Tika, Radicale, etc. The test steps involve creating an external network, deploying the full stack, and verifying that all containers start successfully. Log in to the Keycloak admin console and create test users in Keycloak. Log in to OpenCloud with the Keycloak user. Upload and edit documents using Collabora, perform a full-text search, and create calendar events and contacts. Access the metrics endpoints and verify that all integrations work together. After that, you must test user management across all services. The expected results are that all containers start without conflicts, that services integrate seamlessly, that the user authentication flows through Keycloak, that the document editing works with Collabora, that the search indexes and returns results, that the calendar and contacts are functional, that the metrics are available for all the services, and that there are no port conflicts or networking issues. These steps will confirm the correct operation of the full stack.

Test 11.2: High Availability Test (Collaboration Service Scaling): Testing Scalability and Resilience

This test validates the high availability features, specifically for the collaboration service. The configuration specifies the Compose files for Collabora, Traefik, and OpenCloud. The test steps include deploying OpenCloud with Collabora, scaling the collaboration service, and verifying that all collaboration instances are running. Open multiple documents simultaneously from different browsers and then verify that the load is distributed across instances. You will have to stop one of the collaboration instances and verify that the remaining instances continue to serve the requests. Create new documents during the instance failure. Restart the stopped instance and verify that it rejoins the pool. The expected results are the successful start of multiple collaboration instances, the proper distribution of requests, the continuation of service during instance failures, no data loss or corruption, and the automatic recovery when instances restart. These steps test the high availability features.

12. Persistence and Data Integrity Tests: Ensuring Data Reliability

Test 12.1: Data Persistence with Docker Volumes: Validating Data Persistence with Docker Volumes

This test validates data persistence using Docker volumes. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include the admin password and domain settings. This test uses default Docker volumes. The test steps involve deploying OpenCloud and logging in to create test data, like files and folders. Stop the containers. Then verify that the volumes exist. Then restart the containers. Log in and verify that all data persists. Test the removal of the volumes, and then restart the containers again and verify the fresh installation. The expected results are that the data persists across container restarts, that the volumes maintain data integrity, and that a fresh installation occurs when the volumes are removed. These steps verify that data remains intact.

Test 12.2: Data Persistence with Host Paths: Validating Host Path Data Persistence

This test validates data persistence with host paths. The configuration specifies the Compose file for Traefik and OpenCloud. Environment variables include the admin password, domain settings, and also settings for the configuration directory, data directory, and the apps directory. The test steps involve creating the host directories with correct permissions. You will have to deploy OpenCloud, create test data, and then verify the data appears in the host directories. Then, you will stop the containers, and inspect the host directories directly. Restart the containers and verify that the data persists. The expected results are that data is stored in the host directories, the correct maintenance of permissions, the data persisting across restarts, and the possibility of direct host access to the data. These steps confirm that data is correctly stored and accessed via host paths.

13. Logging and Debugging Tests: Facilitating Troubleshooting

Test 13.1: Log Driver Configuration: Verifying Proper Logging Setup

This test validates the configuration of log drivers. The configuration specifies the Compose file for Traefik and OpenCloud. Environment variables include the logging settings like LOG_DRIVER, LOG_LEVEL, and LOG_PRETTY. The test steps involve configuring the logging settings and deploying OpenCloud. You must generate various log events, like logins, file operations, and errors. View the logs and verify that the log format matches the configuration. Test the different log levels. Also, check the Traefik access logs if they have been enabled. The expected results are that the logs are formatted according to the configuration, that the log levels filter appropriately, that the logs are human-readable, and that all log events are captured. These steps are crucial to confirm that the logs are configured correctly and that you can debug the environment.

Test 13.2: Traefik Dashboard and Access Logs: Validating Traefik Functionality

This test validates the Traefik dashboard and access logs. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include enabling the Traefik dashboard and access logs. Configure the Traefik domain and the basic authentication users. The test steps involve deploying the stack. You must then access the Traefik dashboard and log in with the configured credentials. You must verify that the dashboard displays the services and routers. Generate traffic to OpenCloud. Monitor the access logs in the Traefik dashboard and check the container logs for Traefik access entries. The expected results are that the Traefik dashboard is accessible and that the authentication works correctly, that the services and routers are visible, that the access logs capture all requests, and that the log level provides the appropriate detail. These steps are important to confirm that the Traefik setup is correct.

14. Security Tests: Protecting the System

Test 14.1: INSECURE Flag Impact: Verifying Security Configuration

This test validates the impact of the INSECURE flag on the security configuration. The configuration specifies the Compose files for Collabora, Traefik, and OpenCloud. The test cases include scenarios with INSECURE=true and INSECURE=false. For the case with INSECURE=true, deploy the configuration and use self-signed certificates. Then verify that the services work without SSL verification errors. Test the Collabora integration with self-signed certificates. For the case with INSECURE=false, deploy the configuration and use valid certificates. Verify that SSL verification is enforced. You need to test that the invalid certificates are rejected. The expected results are that INSECURE=true allows self-signed certificates, that INSECURE=false enforces proper SSL validation, and that production environments should use INSECURE=false. These steps will confirm the correct handling of the INSECURE flag.

Test 14.2: Password Policy Enforcement: Validating Password Strength

This test validates the enforcement of the password policy. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include the administrator password and settings to enable and configure the password policy. The test steps involve deploying the configuration with the password policy enabled. You will have to create test users with different passwords, which includes weak passwords, passwords without uppercase letters, without special characters, and valid passwords. Verify that the weak passwords are rejected and that strong passwords are accepted. Test the banned passwords list functionality. The expected results are that the password policy is enforced correctly, that the weak passwords are rejected with clear error messages, that valid passwords, which meet all the criteria, are accepted, and that banned passwords are blocked. These steps are essential to verify that the password policy functions.

Test 14.3: Public Share Password Requirements: Protecting Shared Data

This test validates the password requirements for public shares. The configuration uses the Compose file for Traefik and OpenCloud. Environment variables include settings to enforce public share passwords, both for read and write access. The test steps involve deploying the configuration with the public share password requirements enabled. Log in and create a public share without a password, and verify that a password is required. Create a public share with a password, and verify that the share creation succeeds. Test the read-only and writeable share password requirements. Access the public share externally and verify that a password prompt appears. The expected results are that the public shares require passwords when configured, that the password enforcement works for both read and write shares, that the public share access requires the password entry, and that password protection is effective. These steps will verify that public shares are secure.

15. Upgrade and Migration Tests: Ensuring Smooth Transitions

Test 15.1: Version Upgrade Test: Validating Seamless Upgrades

This test validates the version upgrade process. The configuration specifies the Compose file for Traefik and OpenCloud. The test steps involve deploying the system with a specific version tag. You will create the test data, and then stop the containers. After that, you must update to a newer version. Then start the containers, monitor the logs for the migration processes, verify the data integrity, and test all the functionality after the upgrade. The expected results are that the upgrade completes without errors, that the data migrations run successfully, that all existing data remains accessible, and that the new version features are available. These steps confirm that the upgrade process works correctly.

Test 15.2: Rolling vs Production Image Switch: Validating Image Switching

This test validates the switching between rolling and production images. The steps involve deploying the system with the rolling image, creating test data, and then switching to the production image. Redeploy the system and verify the compatibility and data access. The expected results are that the image switching works correctly, that the data compatibility is maintained, and that no data loss occurs during the transition. These steps ensure a smooth switch between images.

16. Network and Connectivity Tests: Maintaining Network Integrity

Test 16.1: Multi-Network Configuration: Validating Network Setup

This test validates the multi-network configuration. The test steps involve creating a custom network, adding services to multiple networks, and verifying inter-service communication. Test the isolation between networks and verify external access through Traefik. The expected results are that the services communicate within the custom network, that the network isolation works correctly, and that Traefik properly routes between networks. These steps will test the network setup.

Test 16.2: DNS Resolution Between Services: Verifying Internal Service Communication

This test validates DNS resolution between the services. The steps involve deploying the full stack. Then exec into the OpenCloud container and test the DNS resolution using ping collabora and ping keycloak. Verify that the service discovery works. Check the connection to LDAP, Postgres, etc. The expected results are that all the service names resolve correctly, that the inter-service communication works, and that there are no DNS resolution failures. These steps will confirm the correct service communication within the environment.

Test Execution Guidelines

Test Phases: A Phased Approach to Quality

This test plan is organized into a series of test phases to ensure a structured and comprehensive approach to testing.

1. Smoke Tests (Priority: Critical): These tests are the highest priority. They involve testing 1.1 and 1.2 to quickly validate that the basic deployment is working. The success of the smoke tests determines if the project can move forward with more in-depth testing.
2. Integration Tests (Priority: High): Integration tests involve tests 2.1, 3.1, 3.2, 4.1, and 5.1. The tests focus on validating service integrations. These tests ensure that the various components of the system can work well together.
3. Complex Scenario Tests (Priority: Medium): Complex scenario tests are a step beyond the integration tests and involve the testing of test 11.1 and 11.2. They cover full-stack deployments and more intricate scenarios.
4. Edge Case Tests (Priority: Low): Edge case tests, such as security, upgrade, and network tests are less common scenarios. The edge case tests are used to evaluate specific aspects of the system.

Test Environment Matrix: Tailoring Tests to the Environment

To ensure that the testing efforts are appropriately allocated, a test environment matrix is used. This matrix outlines which tests should be performed in different environments.

Test ID	Dev	Staging	Production
1.1	✓	✓	✓
1.2	✓	✓	-
2.1	✓	✓	✓
3.1	✓	✓	✓
3.2	✓	✓	✓
4.1	✓	✓	✓
5.1	✓	✓	Optional
9.1	-	✓	✓
9.2	✓	✓	-
11.1	-	✓	✓

Success Criteria: Defining Success

To ensure that the testing efforts are effective, well-defined success criteria are used. A test is considered PASSED when all containers start successfully, there are no error messages in the logs (excluding expected warnings), all features work as documented, the data persists correctly, and the performance is acceptable. A test is considered FAILED when the containers fail to start, critical errors are present in the logs, the features do not work as expected, data loss occurs, or the services are unreachable.

Reporting: Keeping Track of Progress

Test results must be well documented. Test results should be documented with the test ID and name, date, and tester name. The status of the test must be included, whether it is a pass or fail. Logs or screenshots of failures must be provided. Steps to reproduce issues must also be provided. Version information, such as the versions of Docker, Compose, and OpenCloud, must be included.

Known Issues and Limitations: Anticipating Challenges

This test plan acknowledges the following known issues and limitations:

1. Monitoring Tests (6.1) require manual network creation.
2. Let's Encrypt Tests (9.1) require a production environment.
3. Load Balancing Tests (11.2) may require additional resources.
4. Demo Users should never be enabled in production.

Automation Recommendations: Enhancing Efficiency

To improve the efficiency of the testing process, it is recommended that the following tests be automated. These include test 1.1, test 1.2, test 12.1, and test 16.2. Automation should be done using tools like Docker Compose, shell scripts, curl for HTTP endpoint testing, docker compose ps for health checks, and docker compose logs for log validation.

Appendix: Test Data: Supplying the Necessary Information

Sample Files for Upload: Providing the Data for Testing

Provide the necessary data for testing, this includes the sample files for upload. These files include text files, documents, images, and the EICAR test file for antivirus testing.

Sample Users: Providing the Necessary Accounts

Include the sample users. This includes the admin users, demo users, and test users. Create test users in Keycloak as needed.

Sample Test Queries for Search: Providing Search Test Queries

Provide the search test queries. These queries include the "OpenCloud" keyword, file content from uploaded documents, and metadata fields.

To find more information about OpenCloud, you can visit the official OpenCloud website OpenCloud.