Release 4.9.0 - Alpha 2 - E2E UX tests - Change custom logos

[juliamagan]

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 DevOps team through this link.
• External Accounts: If tests require third-party accounts (e.g., GitHub, Azure, AWS, GCP), request the necessary access through the DevOps 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 objective and Urgent 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 https://github.com/wazuh/wazuh/issues/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/devel-devops 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 Jul 01, 2024 and notify the @wazuh/devel-dashboard team via Slack using the c-release channel
• Review: The @wazuh/devel-dashboard 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 Jul 02, 2024 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 Jul 02, 2024.

Deployment requirements

Component	Installation	Type	OS
Indexer	Step by step	Single node	Fedora 37 x86_64
Server	Step by step	Multi node	Fedora 37 x86_64
Dashboard	Step by step	-	Fedora 37 x86_64
Agent	Wazuh WUI one-liner deploy using IP	-	SUSE 15 x86_64

Test description

Follow and complete the documentation steps and the examples:

https://documentation-dev.wazuh.com/v4.9.0-alpha1/user-manual/wazuh-dashboard/custom-branding.html

Known issues

There are no known issues.

Conclusions

Summarize the errors detected (Known Issues included). Illustrate using the table below, removing 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?
• Did you face any challenges not covered by the guideline?
• Suggestions for improvement:

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.

• [ ] @rauldpm
• [ ] @wazuh/devel-dashboard