I normally think of the SQA documents as built in three layers.
The test strategy doc describes what it is you're going to test and in what environments using what tools and what methodologies (white vs black box, automatted vs manual, etc). Later versions also have a roll up of all resource requirements. It's audience is everyone involved, including some non-technical people. You can scare marketing into writing better requirements by listing their favorite features in the "things not be tested" section (ostensibly because you consider the requirement to fuzzy to be testable). It should also include how you plan to do defect tracking, what risks you forsee and how you plan to mitigate or manage them. They are usually 8 to 10 pages long.
The second layer is the test plans. There can be many. I look for areas that are common between products and put them in their own test plans to facilitate re-use. These describe all of the parameters that should be varied and which are interdependent and which are independent. It does not list out the test cases. It is assumed that anyone can take a list of parameters and create an dimensional matrix. It's audience is the developer/designer of the component. If this is a low level component, I also show it to any developers that rely on that component. If it is a high level component (UI) I also show it to support, marketing, etc. It is 2 to 3 pages long.
The third layer is the test specs. If the testing will be fully automated,
it is embedded in the source code and can be grep'ed from there or the
log files. If it is not automated, this is the step by step procedure that
anyone with basic knowledge of the product(s) can execute. When I write
these, I assume that a new hire will execute them, because I know I won't
have time and they'll probably throw people at me at the last minute to
pull the schedule in. These can be 1 to 100's of pages long.