Project

General

Profile

Actions

action #115319

closed

Adapt test suite configuration with YAML feature default+flows for non-product selection in s390x

Added by JERiveraMoya over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-08-15
Due date:
% Done:

0%

Estimated time:

Description

Motivation

In general the flow of the screen is predictable and we can fix expectation, but there are some corner cases where this is not true.

Example of this are for example these two:

Product selection is something that normally happens during installation, but if there is only one product to select, for example in s390x when no SUMA available, this screen doesn't appear. In SLE-15-SP4 GM we have no SUMA for Offline and we have it for Online.
https://openqa.suse.de/tests/9313573#step/accept_license/1
https://openqa.suse.de/tests/8751121#step/accept_license/1
https://openqa.suse.de/tests/8751247#step/install_SLES/1

Beta acceptance is also something that happen until certain point during product development
https://openqa.suse.de/tests/9313573#step/access_beta_distribution/1
https://openqa.suse.de/tests/8751121#step/accept_license/1

We have available mechanism with default+flow to achieve that.
Therefore we can say that the main goal of this ticket is to have single place to update this. Instead of focusing only in fixing the test, we should start to organize our test coverage based on defaults. Remember that 'flows' were created initially to account for all the strange variation on the test coverage that are performed and that the PRD doesn't reflect so it is up to us to make something reasonable. We can start to remove those flows and move them to default files for each flavor.

Acceptance criteria

AC1: The problem with no product selection is solved using yaml feature default+flows.
AC2: Solution is applied to select_modules_and_patterns+registration@s390x-kvm-sle12

Suggestions

As we are actually testing the final product, we can say that the default should be how it will look in GM. Then on top of that we can add our flows to modify that behavior.

A possible implementation would be to create a flow no_product_selection.yaml which will clean up the key product_selection in default.yaml making it an empty hook and add this flow to all test suite in s390x. The problem is that we need to add that flow to all the test suite in one architecture, so there is no single place.

In this case I think it would make more sense to create default_s390x.yaml. We could reuse default.yaml and use merge keys mechanism to update in one place this behavior, afir remember multiple included were messing up with the order of the key, but please verify that, if we use one include and multiple key override it might work.

In case this doesn't work, we might need to copy paste all the content in default to this new yaml. At the end we can consider single place as all the files for default inside its own folder, that might be acceptable, otherwise, if we want 'true' single place we need to implement some keyword in yaml to be able to include and overwrite multiple keys.

With this change we should fix the following two test cases besides solving the beta issues after publicbeta:
https://openqa.suse.de/tests/9313573#step/accept_license/1
https://openqa.suse.de/tests/9313575#step/accept_license/1

The beta problem is for all the architectures, so we can rely on default.yaml and update it in single place when corresponding. Nothing to do then for this case (just was an example), only to migrate test suite to this new mechanism in follow-up tickets.

Actions #1

Updated by JERiveraMoya over 2 years ago

  • Subject changed from Remove test suite for SP1 to Adapt test suite configuration with YAML feature default+flows for non-product selection in s390x
  • Description updated (diff)
Actions #2

Updated by JERiveraMoya over 2 years ago

  • Description updated (diff)
Actions #3

Updated by JERiveraMoya over 2 years ago

  • Description updated (diff)
Actions #4

Updated by JERiveraMoya over 2 years ago

  • Description updated (diff)
Actions #5

Updated by JERiveraMoya over 2 years ago

  • Description updated (diff)
Actions #6

Updated by JERiveraMoya over 2 years ago

  • Tags changed from qe-yast-refinement to bug
  • Status changed from New to Workable
Actions #7

Updated by JERiveraMoya over 2 years ago

  • Tags deleted (bug)
Actions #8

Updated by zoecao over 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to zoecao
Actions #9

Updated by zoecao over 2 years ago

  • Status changed from In Progress to Workable
  • Assignee deleted (zoecao)
Actions #10

Updated by hjluo over 2 years ago

  • Assignee set to hjluo
Actions #11

Updated by hjluo over 2 years ago

  • Status changed from Workable to In Progress
Actions #13

Updated by openqa_review about 2 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: ssh-X@ppc64le-hmc-single-disk
https://openqa.suse.de/tests/9679975#step/accept_license/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.

Actions #14

Updated by JERiveraMoya about 2 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF