action #152011
Updated by JERiveraMoya 7 months ago
#### Motivation As a Project Owner I would like to follow the migration process in a simple way using test matrix, checking the support image test suites and its corresponding migration test suites. At the moment due we are exposing migration details in the name of the test suite it is very difficult to track in openQA the whole path. Our spreadsheet for migration matrix contains all the information needed to translate this, but still tricky, additionally we created recently a Confluence page https://confluence.suse.com/display/qasle/How+to+generate+Migration+test+suites+base+on+test+matrix One example of unification: (1) Check row in spreadsheet about migrations with no module selection. (2) Go to support images job group and found `sle_autoyast_support_image_gnome_12sp5` for the 4 architectures, so far so good! go. (3) Due to the migration have different migration parameters the cell content is not exactly the same in (1) and this fact spread the test suites in, "offline_sles12sp5_pscc_def_full", "offline_sles12sp5_pscc_def_full_lock", "offline_sles12sp5_media_def_full", "offline_sles12sp5_media_base_def_full_zVM@s390x-zVM-vswitch-l2". - Visually it is difficult to related all this related migrations. - From the point of view of functional testing, we just need to provide migration with different origin system (meaning system role + packages/patterns). Other than that we are dealing just with detail which are not particularly fixed to any test suite, more like features that need to be tested in any test suite where it makes sense. #### Acceptance criteria **AC1**: Group all test suites for extension/module combination in migration matrix + role under same test suite name **AC2**: Fill in test suite description differently for each case in job group yaml indicating the differences contained in the cells of the migration matrix.