Manual - Test Plan Design for Release 4.4.0

[Mayons95]

Introduction

In this issue, we will track all the efforts being made to test Wazuh release 4.4 on all the supported platforms. The test plan described here comprehends regression tests, so will only cover the specific changes made in this release. The complete tests suite will be run as part of our automated testing process.

Platforms:

• Elastic 7.16.3
• Elastic 7.17.5
• Wazuh Dashboard 2.2.1
• OpenDistro 1.13.1

Plan

#4428 Render nested field rows in security alerts table

The goal of this PR is to filter correctly by searching by nested fields on the Security Events table, please look for the evidence attached on the linked PR.

Test - 1 Given the wazuh admin user is logged When the user navigates to the Security Events Module And there are Nested fields available And the user add a filter by a nested field (eg: data.aws.requestParameters.rules) Then the displayed data on the module should be filtered by the nested field previously selected.

Comments How can I add mocked nested field to test this issue? You should add mocked logs in: var/ossec/logs/logs/alerts/alerts.json var/ossec/logs/logs/alerts/alerts.log

Useful screenshots:

#4425 Fixed dashboard nested fields filtering

Test - 1 The goal of this PR is to filter correctly by searching by nested fields on the Security Events table, please look for the evidence attached on the linked PR.

Given the wazuh admin user is logged When the user navigates to the Security Events Module And there are Nested fields available And the user add a filter by a nested field (eg: data.aws.requestParameters.rules) Then the displayed data on the module should be filtered by the nested field previously selected.

Comments How can I add mocked nested field to test this issue? You should add mocked logs in: var/ossec/logs/logs/alerts/alerts.json var/ossec/logs/logs/alerts/alerts.log

Useful screenshots:

Test - 2 Given the wazuh admin user is logged When the user navigates to the Security Events Module And there are Nested fields available And the user search a nested field using the search bar And the user confirm the search Then the displayed data on the module should be filtered by the nested field previously selected.

Comments How can I add mocked nested field to test this issue? You should add mocked logs in: var/ossec/logs/logs/alerts/alerts.json var/ossec/logs/logs/alerts/alerts.log

Useful screenshots:

#4376 Improve alerts summary performance

This PR changes the way the Alerts Summary tables are created in PDF reports to improve the dashboards loading time. Now the tables configuration is the PDF report folder segregated by modules and the request to obtain the data is made by the backend of the app instead of the frontend. This avoids unnecessary loading times when the user does not use the reporting feature.

**Test -1 ** Given the wazuh admin user is logged When the user navigates to the Security Events Module Then the user generated a PDF report And the PDF report is generated correctly.

Comments

As developers / QA the goal is to check if the request that performs the creation of the PDF report is executed when the user presses the "Generate Report" option and not when the user navigates to the module.

Useful video: Screencast from 07-09-22 09:25:09.webm

#4363 Agents section performance

The goal of this test is to check that the loading of the different charts displayed on the agent page are loading independently from each other

**Test ** Given the wazuh admin user is logged When the user navigates to the Agent page Then the user verifies that the loading of the different charts are independent of each other

Comments To check this easier you can use the google chrome developers tool, the network throttling tool, and select the slow 3G connection option.

Uselful videos: Network setting: Screencast from 07-09-22 14:10:29.webm Test evidence: https://user-images.githubusercontent.com/104914131/188913526-e9802383-4489-4ea2-96fa-be58a554b754.webm

#4174 Refactor ruleset management

Summary

All calls to action and navigation elements should be tested in Rules, Decoders, CDB Lists modules. When in doubt, compare the behavior of the feature with any 4.3.x Wazuh version

Tests -1

All table features

Pagination Sorting Row clicking Links within the table rows Search input Custom action buttons (Manage rule files, Add new rule file, Refresh, Export formatted, etc.) Manage rule / decoder files button should clear previous filters before switching the table Custom rules / decoders filter button Clicking a row in the rules or decoders tables should open a flyout with the details of the selected item.

In the details flyout information accordion, there are "links" that should close the flyout and filter the property in the background table. Clicking a row in the table within the details flyout should replace the information in the flyout with the selected item. Clicking the rule / decoder filename in the tables should load the file content view. Clicking a rule.id in the Events table should load the rules view with an open flyout showing the selected rule information image

Useful videos: Please check the related PR

#3905 Added agents windows events

Test -1

Preconditions: Have a Windows agent installed

Given the wazuh admin user is logged When the user navigates to Agent/configuration/WindowsEvents And the user navigates to the options displayed at the right Then the user see the lof format window.

Uselful screenshot:

#4508 Changed terms of Office Max Rule Level - Office 365

The goal of this PR is to display correctly the Max Rule Level Test - 1 Scenario: Open the main Office 365 dashboard Given the wazuh admin user is logged When the user navigates to Office 365 module And the maximum alert level is defined Then the Max Rule Level should show the correct value and match with the value shown in the Events by severity over time graphic

Comments How can I add mocked nested field to test this issue? You should add mocked logs in: var/ossec/logs/logs/alerts/alerts.json var/ossec/logs/logs/alerts/alerts.log

Useful screenshots:

#4516 Modify agent overview page

The goal of this PR is to check the resize of a particular agent page

Scenario: Open the summary page for an agent Given a screen width higher than 1360px Then the elements should be shown without overlapping or issues

Scenario: Open the summary page for an agent Given a screen width lower than 1360px and higher than 768px Then the elements should be shown without overlapping or issues

Scenario: Open the summary page for an agent Given a screen width lower than 768px Then the elements should be shown without overlapping or issues

Comments

Useful screenshots:

Screencast from 21-09-22 15:26:21.webm

Tasks

(all browsers are in their latest versions, with no plugins)

• [ ] Execute test plan for Elastic 7.16.3 in Google Chrome / Firefox
• [ ] Execute test plan for Elastic 7.16..2 in Google Chrome / Firefox
• [ ] Execute test plan for Wazuh Dashboard 2.2.1 in Google Chrome / Firefox
• [ ] Execute tests plan for Opendristro 1.13.1 in Google Chrome / Firefox

[Mayons95]

Updating Issue, adding https://github.com/wazuh/wazuh-kibana-app/pull/4508. Add PR details to the test plan

[Mayons95]

Updating Issue, adding #4501 Add PR details to the test plan

[Mayons95]

Updating Issue, adding https://github.com/wazuh/wazuh-kibana-app/pull/4503 Add PR details to the test plan

[Mayons95]

Updating Issue, adding https://github.com/wazuh/wazuh-kibana-app/pull/4504, https://github.com/wazuh/wazuh-kibana-app/pull/4505, https://github.com/wazuh/wazuh-kibana-app/pull/4507 Add PR details to the test plan

[Mayons95]

We closed this issue because 4.4.0 RC1 is out, we are going to use this issue to perform the regression testing.