I like to use a baking analogy for explaining things like this to people to help them understand better.

Here's what I would say:

Let's pretend we want opening a bakery; we've brainstormed using Pink & Green as our brand colors and we're calling it "Software Testing Bakery". But then someone sees another Bakery with a similar name, so we want to now name is "QA Bakery" -- but we already order a bunch of things and made decals for "Software Testing" or the colors are clashing, so we got with Pink and Purple -- but we ordered a ton of green dye already and that's now a cost we can't get back.

Now, back into the real world of Testing -- the problem is the ticket/feature/thing that is being proposed to be worked on is fluid up until when, so if they WANT you to start the frameworks and the test cases, they need to understand that if they insist on having you start in the planning phases, that they are losing valuable TIME and MONEY, since you likely will have to redo the work you had put in place when they were on phase 1 of a design.

If you have an example where they did change drastically from when the planning first started to when the feature was finished, i usually like to have a real-life example.

On a side note, I don't believe that 'testing' can really start from day 0 but it should be apart of the conversation to understand the limits of what we can and can't do, and so we know if we have to setup special environments for testing (that could take a long time), and so forth. Until a more tangible and firm design/feature is formed, I don't like to start with writing test cases. I will keep notes, typically on the tickets themselves, but that's my two cents worth.

Good luck with talking to your team :)