When many people think about a test plan they envision groups of scripts with specific purposes of testing the functionality of a program or website that need to be performed during the life cycle of the project. Scripted testing is important for tracking the progress and stability of a project and to find bugs and issues that are present in the program or website. While this is a good way to find some issues and to verify proper functionality of features not all bugs can be found with a script that tells a tester how something should work, in fact many deep down and hindering issues are found by performing ad-hoc or unscripted testing. The purpose of this form of testing is to not follow any script or instructions on how to test something, but to think as a regular user and to try things that users will do. In my experience some of the more destructive or hindering bugs have been found when I've just tried something off the top of my head that isn't an obvious user path, an example is backing out of a screen when the loading bar reaches a certain point causing a program to crash. A strong test plan is one that has scripts to test and verify the functionality of the program or website, but also has allocated time for the tester to perform some unscripted testing as well.