Hello! This is approved. Thank you.

In T404403#11978672, @aude wrote:

Having daily selenium (or playwright etc) tests would also be great, running against catalyst and high-level UI tests are also great.

The purpose of this task is that we want to catch when the phpunit/integration tests break in extensions like ReadingLists because of a change in MediaWiki core. We don't care to have Wikibase etc. tests run for ReadingLists patches and vice versa, but only the things that are actually related or would impact ReadingLists.

That looks good to me. Can one of you just write up something to share on QS-Test-Automation once it's there, so people know where to look?

Thanks for bringing this to my attention. From the QS side we've been doing a few things (and are planning on doing) that might help:

Slotted in to begin in Q1. Initial work is being done by a contractor (thisDot) to create a reusable architecture and begin automated testing.

For Q1 Emeka will be picking up this work

@zeljkofilipin - Do you know where the appropriate place for this dictionary would be? There's probably an existing old QTE page I'm not aware of that would benefit from a glossary

Hey Daniel! It's a little unclear to me what exactly is being tested here. I'm familiar with helm charts and orchestration tooling, are you looking for help figuring out what should be the test running architecture that runs existing tests (the foundation has a huge amount of existing unit, integration and UI layer tests) or are you looking at spinning up a new set of automated tests to validate some new functionality (or functionality that is currently uncovered)?

@HSwan-WMF : This test suite was discovered by Elena + Vaughn and seems to serve no purpose other than sometimes breaking CI, so it either needs to be deleted or refactored into becoming useful. Our recommendation would be to simply delete the test based on what we're seeing.

We need to figure out how this prioritize this against APP priorities for the next year: Would this make it better/easier to run critical user journeys or use to help engineers know what tests to refactor or ask for help on?

Taking this on as part of the Growth sprinthackular.

Already ahead of you! I created the new form and just need to promote it to the QTE team now.

Added a new form:
https://phabricator.wikimedia.org/maniphest/task/edit/form/141/

In T422931#11847467, @ppelberg wrote:

Priority
Set as high as QA is blocking start of survey, currently scheduled for Thursday, 23 April 2026.

Assigning this to Armen and myself for collaboration and cleanup

I'd agree. Popups -> RelatedArticles. It's also good to know the Minerva tests are going to get removed. Does the list you created automatically remove things that are no longer showing up, @vaughnwalters?

Thanks Lucas! In this case the work to be done was to investigate the overall build - which people have flagged as being "flaky" - to see what is actually flaky about it. The work is necessarily broad until root causes are identified.

Hey! With Vaughn's role in QS-Test-Automation we're trying to tighten down ownership of various spaces. It's still a bit imperfect but this ticket feels more likely to be able to be fixed by either Test Platform or Release Engineering (they are working on Catalyst).

I chatted with Tyler, this is a QS + RelEng + TP collaboration. QS will own and drive this forward.

Discussed this in refinement for QS-Automation today:

Yeah that's what I was thinking about this supporting. I think that's the environment that should be targeted and these could run fast against that. Is there a tag that can be added to link the two together so we can keep aligned as work progresses?

Thanks for assigning the tag, Michael. We'll try to be more diligent about that in the future, referencing the Maintainers list to figure out who to alert. In this case, Vaughn (from QS) is planning on handling the work - so it's truly for visibility to Growth. If there's learnings to share back we'll document it on-ticket (as he's been doing above).

@ppelberg Looks like this was made high priority recently, is it blocking additional work or is there a deadline coming up?

Can we use Browserstack to validate this? https://live.browserstack.com/ has android devices. I'd do it, but I don't have a handy beta account that is set up to see revise tone tasks.

@Ryasmeen Just wanted to flag this to you - if you think my testing is sufficient just go ahead and close it out!

I'm stepping in since this is a high priority ticket and Rummana is out. Apologies if I'm missing something simple.

Out of curiosity I grabbed this task temporarily to investigate testing Tone Check via Patch Demo. Some notes:

Results from conversation with qs-test-automation this morning:

Broad testing strategy - This feels like it might be served by T418966. Is this a different project than that?

We should be able to take this in for Q1 work.

Closing this ticket based on the above comment.

Update: I had a conversation with Dennis yesterday about this - we believe there may be an opportunity here to use PHPUnit or some other lower-level testing framework to test this without a specific need for a flaky, slow E2E UI test. I'm doing further research on this to continue to explore that possibility. Assigning this to myself for the moment as I seek more information.

For now the link in the Description is fine for now.

@vaughnwalters Is this detailed enough to start working on? I'm trying to get ahead of refinement a little bit.

Based on refinement this morning: GrowthExperiments Cypress take ~5 minutes. This is already starting to get long.

Based on refinement this morning:

Based on refinement conversation this morning:

@vaughnwalters This feels like a really good ticket to intake and work on once 6.1.3 is wrapped up - it would help us be on the same page with everyone else as we get started.

Who are we waiting for a code review from? The owner of the test suite?

Potentially a good starting point for this would be to figure out a test plan for https://phabricator.wikimedia.org/T408468 - and try to create automated tests to fulfill that test plan.