The answer to this is simple and complex. You start by reviewing the requirement and writing what is called a Test Strategy and Impact Analysis. This is a general overview of the software, how it operates, the different functionality and, typically, I will assign a value to the 'importance' of each functionality.
By doing this you will naturally start to see pieces that should catch your eye as either critical pieces or overly complicated.
After this, you take your test strategy and compile a higher detailed version of the Test Strategy labeling what you want tested and how. Again, I will typically assign a value to each of these by order of importance. For example, a log in function will score much higher than an individual component since it impacts the most users.
Next, write out an extremely high detailed Tase Case Document that will contain your test cases. These will be what will be executed and what the result should be. Again, assigning a level of importance to each one.
Execute the test cases that you have written, filing defects for anything that you have found. Monitor which test cases found defects and keep track of them for later. After you have completed 100% run (all test cases ran, not all passed), re-run test cases that discovered a defect in the past until you have achieved 100% passed. If you run out of them, do exploratory and ad-hoc testing.
Once you achieve 100% passed, again, rerun all test cases that discovered a defect in the past to ensure that there was no issues with source control and re-run test cases based on their level of importance as marked above. During this run, stray from the written tests (while following their general guide) and think outside of the box some.