1.0 ADBox test execution results

1.1 TCER: install ADBox shipping TRB-001

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Running the container with the -s flag

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-017 ADBox shipping install

Attribute Value
test-date 2024-12-10
tester AAT
defect-category 0 = flawless
passed-steps 1
failed-steps 0
not-executed-steps 0
release-version 0.3
verification-method T

1.2 TCER: ADBox deployment TRB-002

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: clone the repo

  • 0 = flawless

Test case step 2: change directory

  • 0 = flawless

Test case step 3: build the image

  • 0 = flawless

Test case step 4: make the container executable and run it

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-001 Deploy ADBox via Docker and shell scripts

Attribute Value
test-date 2025-01-17
tester AAT
defect-category 0 = flawless
passed-steps 4
failed-steps 0
not-executed-steps 0
release-version 0.3

1.3 TCER: ADBox in dev container TRB-003

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: clone the repo

  • 0 = flawless

Test case step 2: start Docker Desktop

  • 0 = flawless

Test case step 3: open project folder in VS Code

  • 0 = flawless

Test case step 4: open project in dev container in VS Code

  • 0 = flawless

Test case step 5: run poetry install in the container

  • 0 = flawless

Test case step 6: run ADBox via its entrypoint

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-003 Install ADBox as dev container

Attribute Value
test-date 2025-01-17
tester AAT
defect-category 0 = flawless
passed-steps 6
failed-steps 0
not-executed-steps 0
release-version 0.3

1.4 TCER: ADBox console TRB-004

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: run the siem-mtad-gat-container container in interactive mode.

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-004 Run ADBox console

Attribute Value
test-date 2025-01-17
tester AAT
defect-category 0 = flawless
passed-steps 1
failed-steps 0
not-executed-steps 0
release-version 0.3

1.5 TCER: ADBox in default mode with Wazuh TRB-005

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: run the adbox container without any parameters

  • 0 = flawless

Test case step 2: input y after the choice prompt for running in default mode

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-005 Run ADBox in default mode with a Wazuh connection

Attribute Value
test-date 2025-01-22
tester AAT
defect-category 0 = flawless
passed-steps 2
failed-steps 0
not-executed-steps 0
release-version 0.3

1.6 TCER: ADBox UC scenario 2 with Wazuh TRB-006

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: run adbox with use case scenario number 2

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-009 ADBox use case 2 with a Wazuh connection

Attribute Value
test-date 2025-01-23
tester AAT
defect-category 0 = flawless
passed-steps 1
failed-steps 0
not-executed-steps 0
release-version 0.3

1.7 TCER: ADBox UC scenario 3 with Wazuh TRB-007

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: run adbox with use case scenario number 3

  • 0 = flawless

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

N/A

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-011 ADBox use case 3 with a Wazuh connection

Attribute Value
test-date 2025-01-23
tester AAT
defect-category 0 = flawless
passed-steps 1
failed-steps 0
not-executed-steps 0
release-version 0.3

2.0 RADAR test case execution results

2.1 TCER: Setup RADAR foundation TRB-008

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Verify working director availability

  • 0 = flawless: soar-radar directory available.

Test case step 2: Verify configuration of .env file

  • 0 = flawless: available as indicated in the test case specification.

Test case step 3: Verify Ansible configuration, setup and reachability

  • 0 = flawless: remote agent configuration successful
  • 0 = flawless: remote manager configuration successful
  • 0 = flawless: vault creation and setup for agent and manager successful
  • 0 = flawless: sudo setup for access to controlled node successful
  • 0 = flawless: Ansible reaching nodes in the SSH group successful

Test case step 4: Verify creation and setup of SSL/TSL certificates

  • 0 = flawless: certificates created and stored successfully

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-041 Setup RADAR foundation

Attribute Value
test-date 2025-12-03
tester AAT
defect-category 0 = flawless
passed-steps 4
failed-steps 0
not-executed-steps 0
release-version 0.5
verification-method T

2.2 TCER: RADAR build suspicious login TRB-009

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

In Wazuh Manager

Test case step 2.1: Custom 0310 SSH decoder deployed:

  • 0 = flawless: 0310-ssh.xml exists, and is owned by root:wazuh, with mode 0640.

Test case step 2.2: Default 0310 decoder is excluded in ossec.conf:

  • 0 = flawless: 0310 SSH decoder contains the decoders sshd-*-with-radar (e.g., including RADAR fields like ASN, country, geo_velocity).

Test case step 2.3: RADAR decoders for suspicious_login are in local_decoder.xml:

  • 0 = flawless: a 0310-ssh_decoders.xml line appears (at least once) within the enclosures.

Test case step 2.4: RADAR rules for suspicious_login are in local_rules.xml:

  • 0 = flawless: local_rules.xml contains a <!-- RADAR_RULES: suspicious_login BEGIN/END --> block with rules for suspicious SSH logins.

Test case step 2.5: Suspicious login rules are bound to active responses:

  • 0 = flawless: suspicious login rule ID(s) references the intended <group>, <options> or <active-response> that trigger ad_context_* and email_ar.py.

Test case step 2.6: Agent is registered with the manager:

  • 0 = flawless: an entry exists for each agent.

Test case step 2.7: Wazuh Manager is running after restart:

  • 0 = flawless: the status output indicates the manager is running with no error messages.

In endpoints running agents

Test case step 2.8: RADAR helper directory and script are installed on the SSH agent host:

  • 0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.9: radar-helper.service systemd unit is installed, enabled, and running:

  • 0 = flawless: the service is active.

Test case step 2.10: Agent ossec.conf on SSH agent includes the suspicious_login RADAR snippet:

  • 1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a <!-- {_marker}: suspicious_login BEGIN/END --> block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.11: Active response scripts for suspicious_login are present on SSH agents:

  • 0 = flawless: files from soar-radar/suspicious_login/active_responses/* are present under /var/ossec/active-response/bin/ with owner root:wazuh and mode 0750.

Test case step 2.12: Wazuh agent service is running on SSH agents after restart:

  • 0 = flawless: the status output indicates the agent is running with no error messages.

Post-test cleanup

Test case step 3: Check the cleanup after successful validations, the command output should be empty:

  • 0 = flawless OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-042 RADAR: build suspicious login

Attribute Value
test-date 2025-12-09
tester AAT
defect-category 1 = insignificant defect
passed-steps 13
failed-steps 0
not-executed-steps 0
release-version 0.5.1
verification-method T

2.3 TCER: RADAR build non-whitelist GeoIP TRB-010

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

In Wazuh Manager

Test case step 2.1: Whitelist file exists

  • 0 = flawless: /var/ossec/etc/lists/whitelist_countries exists, its contents match the scenario’s whitelist_countries, and its owner is root:wazuh, with mode 0644.

Test case step 2.2: ossec.conf has <list> entry for whitelist_countries

  • 0 = flawless: under <ruleset>, there is a <list>...whitelist_countries</list> entry with the RADAR marker for geoip_detection.

Test case step 2.3: Custom 0310 SSH decoder deployed

  • 0 = flawless: 0310-ssh.xml exists, and is owned by root:wazuh, mode 0640.

Test case step 2.4: Default 0310 decoder is excluded in ossec.conf.

  • 0 = flawless: a <decoder_exclude>0310-ssh_decoders.xml</decoder_exclude> line appears (ideally once) under <ruleset>.

Test case step 2.5: RADAR rules for geoip_detection exist

  • 0 = flawless: local_rules.xml contains a RADAR_RULES: geoip_detection block rules use whitelist_countries to detect non-whitelisted countries.

Test case step 2.6: GeoIP non-whitelist rules are bound to active responses

  • 0 = flawless: GeoIP non-whitelist rule ID(s) reference the correct <active-response>.

In endpoints running agents

Test case step 2.7: RADAR helper directory and script are installed on the SSH agent host.

  • 0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.8: radar-helper.service systemd unit is installed, enabled, and running.

  • 0 = flawless: the service is active.

Test case step 2.9: Agent ossec.conf on SSH agent includes the geoip_detection RADAR snippet.

  • 1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a <!-- {_marker}: geoip_detection BEGIN/END --> block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.10: Wazuh agent service is running on SSH agents after restart.

  • 0 = flawless: status output indicates the agent is running with no error messages.

Post-test cleanup

Test case step 3: Check the cleanup after successful validations, the command output should be empty:

  • 0 = flawless: command output empty.

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-043 RADAR: build non-whitelist GeoIP detection

Attribute Value
test-date 2025-12-09
tester AAT
defect-category 1 = insignificant defect
passed-steps 11
failed-steps 0
not-executed-steps 0
release-version 0.5.1
verification-method T

2.4 TCER: RADAR build log volume growth TRB-011

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

In Wazuh Manager

Test case step 2.1: RADAR snippet for log_volume is present in ossec.conf

  • 0 = flawless: ossec.conf contains a RADAR: log_volume BEGIN/END block with the log volume-related settings.

Test case step 2.2: RADAR decoders for log_volume exist

  • 0 = flawless: local_decoder.xml contains a RADAR_DECODERS: log_volume block defining decoders that produce a log_bytes field.

Test case step 2.3: RADAR rules for log_volume exist

  • 0 = flawless: local_rules.xml contains a RADAR_RULES: log_volume block with rules using log_bytes for anomaly detection.

Test case step 2.4: OpenSearch template radar-log-volume is present

  • 0 = flawless: HTTP status is 200 and the template JSON exists with mappings for log_bytes as a numeric type.

Test case step 2.5: log_volume rules are bound to active responses

  • 0 = flawless: log volume anomaly rule ID(s) reference email_ar.py as intended.

In endpoints running agents

Test case step 2.6: RADAR helper directory and script installed on the SSH agent host

  • 0 = flawless: /opt/radar exists with mode 0755 and owner root:root; radar-helper.py exists with mode 0750 and owner root:root.

Test case step 2.7: radar-helper.service systemd unit is installed, enabled, and running.

  • 0 = flawless: the service is active.

Test case step 2.8: Agent ossec.conf on agent includes the log_volume RADAR snippet.

  • 1 = insignificant defect: /var/ossec/etc/ossec.conf exists with owner root:wazuh, mode 0640, and contains a {_marker}: log_volume BEGIN/END block inserted before </ossec_config>; the verdict is 1 = insignificant defect because the markers are not replaced, i.e. {_marker} found instead of RADAR, but this does not hamper functionality or usability.

Test case step 2.9: Wazuh agent service is running on SSH agents after restart

  • 0 = flawless: the status output indicates the agent is running with no error messages.

Post-test cleanup

  • 3 Check the cleanup after successful validations, the command output should be empty:

  • 0 = flawless: command output empty.

Defect summary description

Almost defect-free test execution, i.e., defect category: 1 = insignificant defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-044 RADAR: build log volume abnormal growth

Attribute Value
test-date 2025-12-09
tester AAT
defect-category 1 = insignificant defect
passed-steps 10
failed-steps 0
not-executed-steps 0
release-version 0.5.1
verification-method T

2.5 TCER: Add log volume growth anomaly detector TRB-012

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, N/A
  • Hardware deviations: aligned with test case specification, N/A

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Verify that...

  • 0 = flawless OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

docs/specs/c5-keyword.py

Parent links: TST-045 Run RADAR for log volume abnormal growth

Attribute Value
test-date yyyy-mm-dd
tester ACR
defect-category 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
passed-steps 0
failed-steps 0
not-executed-steps 0
release-version 1.0
verification-method T/R/I/A

2.6 TCER: Validate RADAR suspicious login detection TRB-013

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 210*** listed.

  • 0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

  • 0 = flawless: email received.

Defect summary description

Successful test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-046 Suspicious login detection validation

Attribute Value
test-date 2025-12-09
tester AAT
defect-category 0 = flawless
passed-steps 2
failed-steps 0
not-executed-steps 0
release-version 0.5.1
verification-method T

2.7 TCER: Validate RADAR non-whitelist GeoIP detection TRB-014

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, with controller node running Ubuntu 22.04.5 LTS (Jammy Jellyfish)
  • Hardware deviations: aligned with test case specification (VMs handled via QEMU KVM hypervisor)

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: In the Wazuh Dashboard Discovery page, alert with rule ID starting with 100309 listed.

  • 0 = flawless: instance observed.

Test case step 2: Recipient email address specified in .env receives an email about the alert.

  • 0 = flawless: Email received.

Defect summary description

Successful test execution, i.e., defect category: 0 = flawless

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

Parent links: TST-047 Non-whitelist GeoIP detection validation

Attribute Value
test-date 2025-12-09
tester AAT
defect-category 0 = flawless
passed-steps 2
failed-steps 0
not-executed-steps 0
release-version 0.5.1
verification-method T

2.8 TCER: Validate RADAR log volume growth anomaly detector TRB-015

Relevant test environment and configuration details

  • Software deviations: aligned with test case specification, N/A
  • Hardware deviations: aligned with test case specification, N/A

Test execution results

Here we report the results in terms of step-wise alignments or deviations with respect to the expected outcome of the covered test case.

Test case step 1: Verify that...

  • 0 = flawless OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Defect summary description

Defect-free test execution, i.e., defect category: 0 = flawless OR 1 = insignificant defect OR 2 = minor defect OR 3 = major defect OR 4 = critical defect

Text execution evidence

See linked files (if any), e.g., screenshots, logs, etc.

Comments

Any additional informative details not fitting in the above sections.

Guide

  • Defect category: 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
  • Verification method (VM): Test (T), Review of design (R), Inspection (I), Analysis (A)

docs/specs/c5-keyword.py

Parent links: TST-048 Log volume abnormal growth validation

Attribute Value
test-date yyyy-mm-dd
tester ACR
defect-category 0 = flawless; 1 = insignificant defect; 2 = minor defect; 3 = major defect; 4 = critical defect
passed-steps 0
failed-steps 0
not-executed-steps 0
release-version 1.0
verification-method T/R/I/A