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?

Can we use Browserstack to validate this? https://live.browserstack.com/ has android devices.

@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.

The question here is: What exactly does this test suite cover in terms of functionality to the end-user?

Adding QS-Test-Automation to keep aware of this, this is a great effort. Where's test coverage going to be documented? Will it flow to https://doc.wikimedia.org/cover-extensions/ or somewhere else?

To be clear, I agree. I'm just trying to figure out who needs to do that work based on where the code lives that needs to be updated.

@KReid-WMF Can you add links to the following to help us out:

@vaughnwalters Can we estimate how long this test would take to create? We may hold off on implementing this until we can rely on Catalyst to set up CentralAuth and use it.

What code changes would need to be made to make this happen? That will help determine what team needs to make the changes:

for QS-Test-Automation and anyone else who might be able to answer:

Agreed the layer you're looking at (code-level testing of API requests) fits the need - we (QS) have successfully used Pytest in the past but as you mention there's integration costs. Some early attempts at documentation are here. As you can see, it required a fairly robust effort to create and support.

Hey folks! I'm very interested in helping out here, since you mentioned liaising with QA. From what I've read so far some general thoughts:

It's worth reviewing anyway - there's a couple of assumptions I'd like to answer:

So was the root cause here that external crawlers were causing an overload of our ability to handle traffic, and the root cause was blocking those IPs? Just trying to learn here.