This doesn't mean that you should leave writing your test plan until that late in the process. The earlier in the process that you write the test plan the more useful that test plan will be. The ideal time to write the test plan is before you start writing the script.The reason for this is that a test plan isn't just useful for testing, it can also assist with the earlier steps in the development of the script.
If you write the test plan straight away once you decide that you are going to write the script then the test plan will assist you in deciding exactly how the script is supposed to work. Your test plan will list all of the possible situations that the script needs to be able to deal with and that can mean a list of questions that you need to answer. While the main paths through the script may be obvious as to what is supposed to happen, the test plan needs to cover all of the paths that you expect to have with the script and needs to answer the question of what should happen when each of those situations occurs. By giving thought to the expected results of all the tests at the start you will be able to better design your script to cater for all these less common paths in the most appropriate manner instead of only finding out how your script handles it when someone actually tries to run the script live with the conditions for that path being applied in which case chances are the script may not do what you would have wanted.All is not lost however if you have already designed the script before writing the test plan as you can always go back and amend the design if necessary. You can even treat the test plan as a part of your design since it specifies what the results should be when specific conditions are met.
The test plan can also be useful when writing the script since the test plan clearly identifies all of the paths that you expect the script to have. Referring to the test plan while writing the script can help to answer questions as to what the script is supposed to do next. One thing that you do need to be careful of when using a test plan to help you to write the script is to remember that most of the tests on your test plan will be only examples of the conditions that should lead to a specific path being followed. Where a particular path is supposed to be followed when a particular field contains a positive number you may have tests for when that field contains 1 and for when it contains 15 but that doesn't mean your code should specifically test for those two values since the path is meant to be followed for any positive number.
With a really complex script what may be useful when you are actually writing the script is to develop a separate test plan for individual sections of the code so that you can then test each small section of the script as you write it and eliminate any errors in that section before you start writing the next. By doing that you reduce the amount of code you need to consider when trying to determine why a particular test has failed since if you know that a particular function has been properly tested for examples of all the values it is expected to be able to deal with then the only thing you need to look at with regard to that function when testing the code that calls it is what the value passed to the function is and whether or not it is in the expected range. If it is then the error lies elsewhere in the code and you have eliminated one possibility. If it doesn't then you have narrowed down the problem to the piece of code that works out the value to pass to the function (unless it turns out that you have overlooked valid values that the function needs to handle).
Another useful purpose in having a test plan as you write the code is that you can easily rerun the same tests after adding each piece of code so as to make sure that the tests you have already run that worked do not suddenly stop working as a result of the subsequent changes you have made to the code.
Having a proper formal test plan that lists both the tests to perform and the expected results for each test makes each stage in creating a new script easier as it clearly defines what the script is supposed to do in many different situations.You are far less likely to overlook a given test if you have them all written down and also of you do discover a test that you overlooked at any stage during the process of creating your script you can add it to the test plan and it can then be taken into account in all the subsequent steps in your development.
A test plan also serves one additional purpose and that is later on if you ever need to make changes to the script. Any changes that are needed to the script will perhaps add new tests that will be needed and perhaps change the expected results of others. Most of the tests and expected results should remain the same unless you are making huge changes to the script. If you make the expected changes to the test plan first before you make the changes to the script then you will not only have the new tests that you need to run to test the changes but will also have a list of tests that can be run to make sure that the changes have not impacted on any of the rest of the script.