yes! In an agile setting preferably after a retrospective. When the strategy is part of contract work it’s more tricky - but still much required. eg. if the delivery approach is being changed, so should the test approach.
In my opinion, the strategy is the guidance for something, not the practical details. Usually, the guidance sticks and thus is more of a throw-away in the specific delivery. Often the guidance on eg. risk-based approach can be repurposed for the next delivery.
Relationships like that matter a lot. As well do integration points broadly speaking. Stating what you have control over (and sometimes not control over) is a key observation.
A great test strategy would indeed include the balance of what is tested exploratory, and what is not. Preferably both are represented in some tool, along with all other tests: automation, scripted etc.
Recommended tools are often discussed under tools for instance here: