Just because you don't have a formal test plan for testing your script doesn't mean that you are not going to test the script. If you don't test the script then you do not know if the script works or not.While running ad hoc tests doesn't necessarily prove that your script will run correctly in every circumstance, it does demonstrate that the script does work for those instances that you actually have tested. Just how useful this is depends on how complex your script is and how many of the alternative paths through the code that your ad hoc tests actually use.
The vast majority of JavaScript is in fact relatively simple and has at most a few dozen mostly obvious paths through the code. Running an ad hoc test of each of the obvious situations that the script needs to test with is therefore for the majority of scripts going to be quite sufficient to show you that your script does work at least most of the time.
The basic purpose of ad hoc testing is to be able to prove to yourself that the script works the way it is supposed to without your needing to develop a formal test plan in advance (something that those who haven't done any courses on program testing will probably not even consider doing anyway).
Ad hoc testing is not as good as formal testing but is much better than not testing at all.Also with the simple JavaScript that most JavaScript newbies write, ad hoc testing is going to test most if not all of the paths through the code anyway and so effectively saves the time that developing a formal test plan would take without seriously compromising the confidence that you can have that your script actually works.
Perhaps the most likely thing to get overlooked if you do ad hoc testing is to actually test the script in different browsers. Since JavaScript is implemented within the browser itself and different browsers implement different JavaScript engines there is always a possibility with JavaScript that what runs in one browser will not run quite the same in another browser. The biggest difference in this regard is Internet Explorer which implements JScript instead of JavaScript and while the two languages are similar enough for JavaScript with a bit of feature sensing added to also run as JScript, some of the more obscure differences between the two languages can catch you out.
One thing that you do still need to know beforehand even with ad hoc testing is just what you expect the result of your test to be. If you don't know the expected result then you have no way to tell whether the test worked or not - or at least there will be some situations where you don't know. Just running the script without knowing what you expect the result to be in advance can still detect those errors that stop the script from being able to run at all - since not running is obviously not the expected result even if you are not quite sure what the expected result is supposed to be. So running an ad hoc test without any prior planning can still be useful, particularly for those new to JavaScript who are more likely to have made errors in the code that will prevent it running at all.
If you didn't work out the expected result and your test obviously fails then you know that it needs to be corrected. If the script doesn't obviously fail then you need to work out what the result of your test should have been and compare that to what you actually got in order to decide whether the test did or didn't work.
Where a test did work exactly as expected then you can move on to the next test. If the script didn't produce the required result then you need to work out why it didn't and to then correct the code that is doing the wrong thing. To be able to find out why the script doesn't work and where it is going wrong you need to have a more detailed understanding of just how the script is supposed to be generating the required result so as to be able to look at the various pieces of the code in order to determine whether or not those sections of code are progressing the script toward generating the right result or are the cause of the script going off track and producing the wrong result.
You might call this ad hoc approach to locating the error in the code "divide and conquer" since what you have to do is to effectively test whether each piece of the code is doing what it is supposed to in the same way your original test attempted to see if the entire code did what it is supposed to do.