When setting up- your test plan for your script one of the things you need to consider with respect to each test that you plan on running is what the particular data that will form the input to the test. While there can be a whole range of different values that may occur in the script once you place it live on your site you need to select specific values to use for your tests in order to be able to also define the specific result that you expect that test to give when that test is run. Only when you know the exact result that is expected in advance of running the test can you tell for certain whether the test worked or not.
One thing to consider when selecting test data is boundary conditions. Where there are a range of possible values where there is a boundary between those that are expected to work in one way and those that are expected to work in another way then the values either side of the boundary will make good test data in order to test that the code is placing the boundary in the right place. This is most obvious if we consider the testing required for a script that is validating an input field. Let's say that valid input is an integer between 1 and 10 inclusive. This gives us several boundary values that we can use to run our tests. The most obvious test values to use are 0, 1, 10, and 11 so as to test the lower and upper boundaries. These are not the only boundaries that we have to test though. Another boundary to test for is that the value is an integer and so values such as 1.1 and 'A' are also suitable starting values for tests. We may also want to consider values such as ' 4' and ' 2 ' so as to test that the script correctly handles leading and trailing spaces. Yet another possible test value is '4A' so we can tell if the script correctly handles where the field contains both an integer and something else.If you think about it for a while you will probably come up with further boundaries to test for - perhaps those involving the relationship between the value in this field and in some other field.
A script that runs automatically when the page first loads or which is triggered by a visitor clicking on a link will also have lots of boundary conditions to test but in this case working out what those boundary conditions are is a little more difficult. With an animation script you may be able to test a lot of boundary conditions all one after the other during a single execution of the script. If you have an object moving randomly about the browser viewport then the most obvious boundaries are what happens when the object reaches any of the four edges of the viewport. If the animation is supposed to be moving about the entire page rather than just the viewport then you have additional boundary conditions to test for where it reaches the edge of the viewport where it isn't the edge of the page and also where it meets the edge of the page where that isn't the edge of the viewport. All of these tests assume that the web page is stationary and that the viewport is a constant size and so you will also need tests for what happens if your visitor scrolls the page or resizes the browser during the animation.
Even a relatively simple script such as a clock script that shows the current time has a large number of boundary conditions to test for. In this case the obvious boundaries are where the minute, hour, or day changes. Less obvious boundaries for this script would include where the person changes any of the clock settings in their operating system to either change the time or the timezone.
All of the boundaries I have mentioned so far are with respect to a single script running on your web page but it is quite likely that you will have more than just that one script in the page. With two or more scripts you have additional boundary conditions to test for to determine if an action taken by one of the scripts has the intended effect on the running of the other script. For example if your visitor clicks on a link to trigger a second animation then does that have the desired effect on the animation that is already running (usually the desired effect would either be to have no impact on the first script or to stop the first one so as to replace the one animation with another. Possibly you may want it so that your visitor must first stop the animation that is currently running before being able to start another and so you have a boundary to test whether there is an animation already running or not when they click on the link to try to start another. Where multiple animations are allowed you need to condifer another boundary and that is what should happen if your visitor continues to start additional animations one after the other. How many animations should they be allowed to run at the same time? Here's an instance where testing in different browsers is likely to give different results since the resources that the different browsers have available will place different upper limits on how many animations a given browser can run at the same time before the available resources have an impact on how the scripts operate.
The actual JavaScript engine that is used to run our JavaScript is going to be different in different browsers and so we are going to have to run at least some of our tests in a number of different browsers just to confirm that the different JavaScript engines treat our code the same. While it might seem obvious that testing the boundaries for validating our integer form field should produce the same results in each browser there is still the possibility of the code that we are using to retrieve the value out of the form into the JavaScript in order to validate it performing differently in different browsers. In particular Internet Explorer provides automatic mapping of named form fields into correspondingly named variables in our script which could result in the script not running correctly in that browser simply because of a field name clash. There are ways to avoid such problems by writing your JavaScript in a way that removes such conflicts but you still need to test to ensure that the code works correctly in the various browsers.
Identifying as many as possible of the different boundary conditions that can apply to your script is an essential part of determining what data is appropriate for your test plan since values on either side of those boundaries should take different paths through the code so as to give different results and so by testing the values on either side of the boundary you can both test the different paths through your code and test that the boundary is in the right place.