Let this be something you'll always remember and take into account from here on out. Planning planning planning planning. Draw yourself up a plan, literally, write it down whether on a piece of paper or by creating a file with vi, notepad, whatever you use. Doing so will almost always yield better results and save you time in the long run. "To Do List" applications work well for this.
Doing this accomplishes a few things:
1) Helps you remember to ALWAYS establish a structured test
2) Helps you keep things organized (especially if you're using checklists)
3) Allows you to document findings - you cannot possibly remember every hiccup
I would approach the task in the following manner: 1) Learn about the system while doing so 2) Learn about project management while doing so 3) Learn about documentation which is EXTREMELY important when you have to write post-testing reports 4) Learn how to manage your time (remember time equals money)
Step 1) Install an operating system
Step 2) Determine what applications would be used on this machine
Step 3) Determine what types of security would be used on that type of machine
Step 4) Analyze how this security application works
Step 5) Look for methods to circumvent it
When I approach personal based testing, I approach it from the systems, network and architect perspective. For example, I needed to test some SAP stuff. So what did I do? Did the research on typical SAP installs. Documented what I perceived it would do, what machines I needed for it, how I needed it to run, who was going to connect to it and why, what type of security would be on it.
After I got it up and running, everything was documented, it was easy for me to go back revert things, uninstall-reinstall, fiddle around pre-security testing. Then came the fuzzing (Peach and Klocwork for those wondering what I use), then came the patch management, security management, re-fuzzing, breaking, etc.
It's a lot easier to be able to dissect things in the long run. For example, on a step by step basis (validating your findings) you would be able to determine that X occurred because of Y. For example, if you were able to pop shells on a machine prior to say installing ProgramY, you'd know when/how/what you need to work around