Christian Rackerseder wrote "Don't Test What You Don't Control", and includes this gem as the core axis for the advice:
Control means something more practical: can the team make the dependency predictable enough for this test, and can the team act when it fails?
The article's quite worth reading on its own. It says a lot of good things about tests:
A pull request test should answer a specific question: did this change break the behavior this team owns?
A company-level system test answers a different question: does this whole system landscape still work together right now?
A vendor integration test answers yet another question: does the real third-party service still behave in the way our product depends on?
Those questions are related, but they are not the same. When we confuse them, we create fragile pipelines, noisy teams and quality gates that people slowly stop trusting.
He talks about scope, control, configuration as part of tests, integration and interoperation with external vendors (can tests yield things others can use?), and how to think about staging servers and their roles in testing.
It's a good article.