[functional][y][saga] Establish YaST team split
|Category:||Enhancement to existing tests||Estimated time:||76.00 hours|
|Target version:||QA - future|
We agreed that we should focus on YaST more as it's developed internally and close feedback loop.
Basic idea is to do QA with backlog which is synced with development. It includes integration testing, as we currently do, but more focused on YaST and being a precondition for other tests if installation doesn't work.
It will allow us to test features during the development and provide feedback, so it's cheaper and easier to change things. Additionally, it will prevent broken build from reaching integration testing when multiple QA teams will be affected
- AC1: separate job group for QA SLE YaST team; this should concern o.s.d
- AC2: We know how the openSUSE community, including release managers of Leap and Tumbleweed, would like to benefit from this (and if they see this as a benefit)
- AC3: We have a clear list of test scenarios which the QA SLE YaST team owns
- AC4: The purpose of each test scenario owned by the Y team is described
Short-term: split job group, take responsibility for the review, set it as a precondition for other functional tests. If installation is broken, there is not much sense in testing other components.
Establish process to judge overall product quality.
Long-term: sub-team joins SysMgmt team for the QA and helping to establish earlier testing
Recommendation: Take care of better communication around this change (as discussed in f2f conversation - perhaps even a simple set of slides. We hate them. But we need to get the message across)
- reduce scope for the reviewer (better focus), hence better understanding of the tests
- will be easier to involve YaST team and collaborate with them
- not much benefits for U-subteam, but definitely no harm
- potentially will affect collaboration between subteams, learn HPC/HA experience
#6 Updated by sebchlad over 1 year ago
Thanks Rodion for writing down the idea of having separated QA SLE YaST team. It is a very clear statement and I see it fully aligned with what we've discussed over last several months.
I will add Alex C. as a watcher as his team members participate in the QA SLE YaST team.
I wonder why we consider finishing this by Milestone 26. This seems like we tackle here a very complex problem, but to me, I must admit, it doesn't look like that.
Of course this is a long term, perhaps more of a vision than a task: "Long-term: sub-team joins SysMgmt team for the QA and helping to establish earlier testing".
Looking at the project schedule - SP4 is about to be finished (from our pov).
SP1 will be entering quite important phases in 2-3 months from now.
I would consider more aggressive schedule for finishing this saga.
@okurz: @riafarov: what do you think?
I will propose some changes to the description of this ticket to better reflect "what should be done" in down-to-earth terms.
#11 Updated by sebchlad over 1 year ago
As a result of our discussion, I will change relations to have only mandatory tickets which have to be resolved and other, which aim improvements on established process.
+2. Definitely a good idea.
If you don't mind I will propose some specific mandatory tasks, which we should get done in order to fulfill the exit criteria
- Assignee changed from okurz to riafarov
Move to new QSF-y PO after I moved to the "tools"-team. I mainly checked the subject line so in individual instances you might not agree to take it over completely into QSF-y. Feel free to reassign to me or someone else in this case. Thanks.