v Lengthy plans which could tire the reader and the audience during a review meeting
v Multiple test plans for the subprojects in a project with data overlapping
v Usage of needless Jargons and irrelevant terms for the target audience
v Absence of references which may lead to lack of clarity of the document
v Missing out proper definition of roles and responsibilities
v Inadequate preparation which may leave a lot of sections to be under discussion
v Incomplete Documentation due to lack of information
v Use drafts to stimulate discussion
v Build the test plan with necessary information like Software being Tested, Test Objectives and risks
v Have a single master plan for the various Test activities involved in your project to avoid information redundancy
v Keep the Test Plan practical, focused and short
v The writing style matters, Avoid passive verbs. Don’t say that something is to be done, Instead mention exactly who is to do what and when
v As a rule of thumb, when using TBD, it is desirable to record who's responsible for resolution of the TBD and a target completion date
v Define the roles and responsibilities clearly
v Keep Jargon, buzz words and so forth limited to those appropriate for the audience
v Maintain a reference section to promote clarity
v Ensure that standards / templates followed for the sake of it does not lead to loss of focus, credibility and relevance
v Use the Test Plan as an opportunity to communicate with the test team, development colleagues and the management.
No comments:
Post a Comment