建议：

　　计划是拿来实施的，不是拿来当摆设的。计划是否可行，是否行之有效，实施的风险是否可控制等等问题是我们在检查的时候必须考虑的。如果我们只是在文档字面上去检查那些文字错误的东西，是否太不负责任了呢？试问，如果在通过这样的计划评审后，在实施中，遇到风险过大等诸多问题，这个责任是谁来担呢？

　　所以我们检查计划，字面错误这种不痛不痒的问题几乎可以忽略它，这个计划能不能用才是关键。所以，我们应该主要检查：

　　1）我们测试的对象是什么？

　　2）在什么环境下实施我们的测试工作？

　　3）我们的测试所要花费的时间、经费和资源（好还是不要超出预算的为好，不然可能老板不支持我们的工作，反倒是个麻烦了！嘿嘿）？

　　4）制定的实施方案是否可行性？

　　5）制定的实施方案所担当的风险系数有多高？

　　6）是否还有更好的可降低风险的实施方案？

　　7）我们的测试工作以什么样的来衡量我们的工作成绩？（甚至是对工作的奖惩办法等）

　　8）是否有对于工作风险的控制方案。

　　9）工作中，任务交代的是否够清楚？以免让执行者随意瞎搞，导致对其测试工作不可控。

　　10）项目成员对这个要测试的对象的理解程度有多深？

　　11）测试人员的组织和管理方案是否可靠？

　　......

　　3、测试计划不是一纸空文。

　　现状：

　　一个很让人怀疑其可行性的测试计划通过之后，下一步工作是把它放到共享服务器上，供项目管理部检查，后??结束了。直到项目结项的时候，才把这个都快“发霉”的计划文档翻出来，准备结项工作。而且对于计划中没有完成的任务也不怎么提（因为大家都在担心一个问题：如果提出来，结不了项，怎么办？）。因为我们似乎都是很尽职的在发扬“扬长避短”的“优良”作风。

　　建议：

　　QA人员必须严格按制定的计划进行过程检查工作。一旦发现实施的计划与预定的计划有出入。应及时通报相关人员，了解其偏离计划的原因，尽快处理好计划实施不到位的问题。

　　4、实行计划跟踪。

　　现状：

　　计划中编写的时间进度表，在真正的实施中是很少用的。每个时间段里要生成什么工作成果，要评审什么文档，项目管理部似乎也在关心。但他们似乎只关心成果数量，而工作成果质量工作似乎被项目管理工作所取代了（QA被项目部同化了）。试问，一个项目真正是想要十几个甚至更多的没有实际意义的文档，还是要一个高质量的可使用的文档呢？对于这个问题，似乎走入了一个面子工程的地步（过程进行的风风火火，结果是一塌糊涂）。比如：在评审各项工作成果的时候，只检查字面的东西，而对于这个工作成果到底是不是这个项目的工作成果他们也不怎么怀疑？难怪很多项目文档描述的东西和实际开发出来的东西对不上号呢！（如：SRM系统）