Those who haven't learnt how to test may not do any proper testing at all - they may just run their script once or twice and if it produces something that looks right in those circumstances then that may be as far as they go. The may then be surprised to find out later that their script fails to work correctly for many of the people visiting their page where alternatives that were never tested frequently occur.
The problem is that if you don't run a test of all of the alternative paths through your code that there is no guarantee that all of them will work correctly. Unless you actually identify all of the alternatives and what should happen with each, there is no way that you can properly test your code. While an experienced programmer may be able to identify the three of four dozen possible paths through their simple code and be able to keep a test plan for all of them in their head (since they have probably run similar series of tests on hundreds of prior occasions), the only way that a newbie is likely to be able to identify all of the alternatives is if they write down all the options. Even then they are likely to miss a number of the alternatives since not all of them will necessarily be obvious to them. The only ways that the newbies are going to discover those alternatives that didn't occur to them is either through doing a course on testing or through finding out that their script is actually broken for one of the alternatives that they didn't test (assuming someone is considerate enough to tell them).
Even if you can't get a complete list of all the tests that are really needed to test your code, writing down all the ones that you do think of is going to be useful. Writing down all of the tests you can think of for making sure your script works will serve several purposes. Firstly once you have written down a test you don't need to remember it since the place you wrote it down will remember it for you. Lists of tests that you have written for one script are also useful places to look for ideas on what you might need to test for another script since often scripts have things in common and just because a particular option worked for one script doesn't mean you don't need to test it when it arises in further scripts. Also if you change your script at any time in the future you will need to retest it, not only to make sure that the new options work but to also ensure that what was working before hasn't been broken by the change and your list of tests will save you having to come up with the tests all over again.
Just listing the tests that you intend to run is a start but for your list to be really useful you should also include information on exact values to feed in to perform the particular test and what you expect the results of the test to be. If you don't know what result you expect from a test then you have no way of telling whether the test worked. By specifying the expected results in your list of tests you will have an effective and reusable test plan for testing that particular script.
While you may be able to test all of the most obvious paths through your script without having a formal test plan (and if you are experienced enough at testing may even be able to test all of the not so obvious ones as well for a simple script that doesn't have too many alternatives), proper testing of all but the simplest script will require that you produce a list of the tests that need to be run and the expected results from each test. If you missed a test at the time you first wrote the script you can add the test to your list when someone tells you about the alternative that doesn't work and will be able to use the list to retest your script to make sure that fixing that one alternative didn't break anything else.
Your written test plan also serves one additional purpose - it identifies those tests that you have run on the script (or have yet to run on the script) so that you know exactly where you are at in your testing.