QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Motivation¶

Yam squad should take care at least of the following ALP areas:

• Web automation of D-Installer
  Having a clear strategy to apply integration testing to D-Installer is becoming more relevant. Because testing the full installation workflow for at least TW and ALP is a time-consuming task and we need to find new bugs ASAP.
  The problem is that openQA is not a good fit for checking the UI (driving the browser), although it is a good option for the rest.
  Developers are working on this strategy in https://trello.com/c/x01mLJzy/3223-8-research-design-a-qa-strategy and Yam squad plan to collaborate closely with them.

• Automation of YaST in Container
  It should be covered as well, at least for ncurses.

• Manual testing while no automation is available
  Additionally for new releases of ALP from December and next year 2023 we should keep doing some manual testing.

• Automation of Cockpit ?
  It shall be covered by different squads and need to be decided what web automation tool to use, upstream or the same for D-Installer. Therefore this area is not clear yet how much Yam squad will contribute.

Acceptance criteria¶

AC1: Create web automation for D-Installer
AC2: Create libyui-rest-api automation for YaST in a container
AC3: Perform manual testing of D-Installer for milestone when no automation is available.

Suggestion¶

ALP documentation: https://documentation.suse.com/alp/all/single-html/alp/index.html