Release 4.7.0 - Alpha 2 - E2E UX tests - Upgrade from 4.6.0 on Docker

[vcerenu]

End-to-End (E2E) Testing Guideline

• Documentation: Always consult the development documentation for the current stage tag at this link. Be careful because some of the description steps might refer to a current version in production, always navigate using the current development documention for the stage under test. Also, visit the following pre-release package guide to understand how to modify certain links and urls for the correct testing of the development packages.
• Test Requirements: Ensure your test comprehensively includes a full stack and agent/s deployment as per the Deployment requirements, detailing the machine OS, installed version, and revision.
• Deployment Options: While deployments can be local (using VMs, Vagrant, etc) or on the aws-dev account, opt for local deployments when feasible. For AWS access, coordinate with the CICD team through this link.
• External Accounts: If tests require third-party accounts (e.g., GitHub, Azure, AWS, GCP), request the necessary access through the CICD team here.
• Alerts: Every test should generate a minimum of one end-to-end alert, from the agent to the dashboard, irrespective of test type.
• Multi-node Testing: For multi-node wazuh-manager tests, ensure agents are connected to both workers and the master node.
• Package Verification: Use the pre-release package that matches the current TAG you're testing. Confirm its version and revision.
• Filebeat Errors: If you encounter errors with Filebeat during testing, refer to this Slack discussion for insights and resolutions.
• Known Issues: Familiarize yourself with previously reported issues in the Known Issues section. This helps in identifying already recognized errors during testing.
• Reporting New Issues: Any new errors discovered during testing that aren't listed under Known Issues should be reported. Assign the issue to the corresponding team (QA if unsure), add the Release testing/publication objective and Very high priority. Communicate these to the team and QA via the c-release Slack channel.
• Test Conduct: It's imperative to be thorough in your testing, offering enough detail for reviewers. Incomplete tests might necessitate a redo.
• Documentation Feedback: Encountering documentation gaps, unclear guidelines, or anything that disrupts the testing or UX? Open an issue, especially if it's not listed under Known Issues. Please answer the feedback section, this is a mandatory step.
• Format: If this is your first time doing this, refer to the format (but not necessarily the content, as it may vary) of previous E2E tests, here you have an example Release 4.3.5 - Release Candidate 1 - E2E UX tests - Wazuh Indexer #13994.
• Status and completion: Change the issue status within your team project accordingly. Once you finish testing and write the conclusions, move it to Pending review and notify the @wazuh/cicd team via Slack using the c-release channel. Beware that the reviewers might request additional information or task repetitions.
• For reviewers: Please move the issue to Pending final review and notify via Slack using the same thread if everything is ok, otherwise, perform an issue update with the requested changes and move it to On hold, increase the review_cycles in the team project by one and notify the issue assignee via Slack using the same thread.

For the conclusions and the issue testing and updates, use the following legend:

Status legend

• 🟢 All checks passed
• 🟡 Found a known issue
• 🔴 Found a new error

Issue delivery and completion

• Initial delivery: The issue's assignee must complete the testing and deliver the results by Nov 06, 2023 and notify the @wazuh/cicd team via Slack using the c-release channel
• Review: The @wazuh/cicd team will assign a reviewer and add it to the review_assignee field in the project. The reviewer must then review the test steps and results. Ensure that all iteration cycles are completed by Nov 07, 2023 date (issue must be in Pending final review status) and notify the QA team via Slack using the c-release channel.
• Auditor: The QA team must audit, validate the results, and close the issue by Nov 8, 2023.

Deployment requirements

Component	Installation	Type	OS
Indexer	Deployment on docker	Single node and multi node	-
Server	Deployment on docker	Single node and multi node	-
Dashboard	Deployment on docker	-	-
Agent	Wazuh WUI one-liner deploy using IP	-	Amazon Linux 2 aarch64

Test description

Test deployment of Docker repository.

• Test the Production installation guide in detail for both a single-node and a multi-node Wazuh cluster
• Test upgrade methods including into Upgrading Wazuh Docker documentation:
  • Using default docker-compose files
  • Keeping custom docker-compose files

Remember to edit docker-compose.yml to deploy the adequate development version for this v4.7.0-alpha2.

Known issues

• Journald support in Logcollector #12862
• Missing security events due to journalctl migration on certain OSs #18299

Conclusions

Summarize the errors detected (Known Issues included). Illustrate using the table below. REMOVE CURRENT EXAMPLES:

Status	Test	Failure type	Notes
🟡	Example Test: API Integration	Timeout issues on certain endpoints	Known issue: https://github.com/example/repo/issues/12345
🔴	Example Test: Data Migration	Data inconsistency in the new version	New issue opened: https://github.com/example/repo/issues/67890

Feedback

We value your feedback. Please provide insights on your testing experience.

• Was the testing guideline clear? Were there any ambiguities?
  • RESPONSE HERE
• Did you face any challenges not covered by the guideline?
  • RESPONSE HERE
• Suggestions for improvement:
  • RESPONSE HERE

Reviewers validation

The criteria for completing this task is based on the validation of the conclusions and the test results by all reviewers.

All the checkboxes below must be marked in order to close this issue.

• @davidjiglesias
• @wazuh/cicd