QA » openQA Project » openQA Tests » qe-yam

Motivation¶

Existing SLE Micro tests MIGHT or MIGHT NOT serve as a base for ALP testing regarding the installer. Currently these are developed and maintained by Containers & Cloud team and QE YaST squad has been asked along with other squads to select the corresponding test suite related with the squad scope.

In case these test suites MIGHT NOT serve as a base for ALP, those are still in our scope, in the sense that they are using the steps of the installation, AutoYaST, etc. In that case it might be questionable how much we should increase the test coverage.
With Cockpit and D-Installer as a reality for ALP we would focus more in test web development application.

In case these test suite MIGHT server as a base for ALP, which we cannot really discard, as I confirmed with YaST developers, the existing YaST installer will be adapted and used in ALP and then there is more chance to reuse code and to own these test suites will be very beneficial. On the other hand we expect that not to happen and perhaps some help from YaST Developers to create an easy way for us to test these new web applications.

Scope¶

Flavor DVD:

The following test suites are suitable to be moved according to the testing scope of QE YaST squad:
slem_installation_autoyast -> after installation we can create a smoke test to simple check that transactional script and other basic things are there, but we don't plan to run the rest of the test modules. That testing should be done by the responsible squad using their own AutoYaST creational job.
slem_installation_default -> similar actions than above and we will also test it with libyui-rest-api.
slem_ssh_installation_{controller,target} -> remote installation that we can take, completely unnecessary if Cockpit will be a reality.

Not in scope¶

Flavor DVD:

slem_installation_selinux -> We already test in SLE Security Configuration/Major Linux Security Module with apparmor, so we can consider we cover the UI. Corresponding squad (Security?) should replace the interactive steps in the installation by and AutoYaST installation when this security setting is modified.
slem_installation_virt -> The only different with a default installation is the selection of pattern, a really old dialog in the installer, we covered this UI interaction extensively in SLE testing. Corresponding squad (Virtualization?) should replace the interactive steps in the installation by and AutoYaST installation with the patterns modified.

Rest of flavors.
Additionally it is out of scope to maintain qcow2 images for other squads or publish any image to be used by any other squad. Squads should have full control of their modified AutoYaST profiles, make them as thin/fat as they want, as maintenable as they can afford for themselves, avoiding dependencies among squads.

Acceptance criteria¶

AC1: SLE Micro 5.3 test suites in the scope of the QE YaST squad are moved to YaST group for Product validation
AC2: SLE Micro 5.3 test suites in the scope of the QE YaST squad are moved to YaST group for Maintenance Updates

Additional information¶

Additionally we should own test suites for TW (applying similar approach than in SLE with module post-installation):

• container-host
• microos
• microos_10G-disk
• microos_textmode
• remote_ssh_controller

For Leap they have the same names but starting with microos_*
And for ALP when it will be in an official job group (not development) the equivalent based on the previous analysis.