In such a case using some boilerplate template would be no good, I’d start with having one-on-one meetings with all the stakeholders, noting down their concerns and interests in order to be able to include them in the test strategy.
Additionally, in this situation, it would be probably beneficial to include all these stakeholders in reviewing the test strategy so they can actively contribute to it, and in the end we should have a test strategy that actually brings value to our project - regardless of what format it is in.
I think a helpful starting point is to run a Stakeholder Mapping exercise. This post does a good job of describing it, as well as how to prioritise keeping different “stakeholder types” informed.
Something I’d definitely want to do is ask each stakeholder what their priorities are, then analyse them to find any places they contradict (like when we test requirements before development). For example, stakeholder A wants the project to be done for a strict deadline, stakeholder B wants the appearance to be really polished, but implicitly the structure of the work is more important, so what happens if we don’t have time for the finishing touches? Then I would highlight such contradictions and deal with potential conflicts beforehand, when there isn’t time pressure and people aren’t so stressed, and bake that into the test plan, eg by planning a meeting some time before the deadline to reassess how much we will be able to do realistically.
Sensible option, reminds me of the - you can have it quickly or cheap but not both. It’s always worth highlighting the differences to stakeholders and see if they can prioritise them.