You can have too much documentation.
Check-list numbers should be scalable, due to size and complexity of the project and keeping to KISS principle also always works with lists.
The number of business and technical requirements should give you a rough feel of how many check items you will have, however your first list should be based on risk assessment/heuristics guided by accessibility, audit-ability and completeness\thoroughness of your coverage . This is more important than the number of check-lists. (google: Rapid testiing by James Bach)
My consultancy approach and on mostwww.loadverify.com projects we initially use the Rapid testing methodology on every project, this will dictate the initial list you test from therefore may cover 50-60% of whatever check-lists you come up with in the long run hopefully you also apply the use of the 80/20 rule.
For neatness and simplicity – I typically split the testing checklists into several categories so end up with 4-5 on average :
1. Risk based heuristics checklist (usually covering core functionality, financial impact, complex processes with complex code\integration, high business priority, high risk areas depending on platform or changes being integrated etc etc)
2. Functional and business requirements checklist
3. Usability checklist
4 Load and Performance checklist
5. Go-live checklist
^ etc as a rough idea to formulate my areas of coverage.
As a personal guide, the 80/20 rule should always be applied to all check-lists and should be check items should also be prioritised as such after risk-based heuristics (especially in time critical projects) if not already covered in the original heuristic list.
