权且不说这些管理行为是否更加浪费工钱，我们应该很容易得到关于“产品开发初期测试人员该做些什么”的一致答复：测试计划在开发初期能写挺好，不写也没什么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个，让用户用上再说——无论是对一个已经经营多年的产品，还是一个刚起步的公司……
其实，对测试的理解不是点头说，测试很重要就够了； 对测试的理解不是去声称，我们有一柜子完整的测试文档；对测试的理解也不是只关心“做与不做”，而全然不理测试的有效性。
软件测试该如何理解如何执行，是一个很大的题目。在这里，我更关心的是在项目设计初期，我们该不该忽略测试人员，而测试人员又该做些什么样的工作。
微软最新的软件开发周期（product life cycle）分为产品定义（Product Definition），产品开发（Product Development），产品服务（Product Servicing）三个阶段。为了使资源得到最有效的使用，测试人员主要参与产品开发和后期服务这两个阶段。而在产品的定义阶段，则会有选择的要求一些资深测试工程师和测试经理一起参与。他们主要负责：通过验证产品核心功能或用户使用场景，确定产品各功能的优先级；参加产品使用场景定义的评审；参加用户体验文档的评审等。
当然每个公司应该定义适合自己的开发模式。但是是否让测试工程师参与这些工作的主要目标应该是没有区别的：首先是熟悉客户需求；再来测试工程师应凭借自身经验，从测试和维护的角度来判断被细分的客户需求中，哪些是合理的，哪些是不合理的，并反馈给项目经理或市场部门，以供他们参考；最后，则要根据这些项目需求以及软件架构的文档，给出测试计划。
上面这番描述是不是看上去并不很复杂，也不重要呢？非要在项目初期做吗？最终不都是根据需求文档来写测试计划嘛……
这当然是很重要的环节。理由如下：
1． 产品的可测性严重影响了后期测试团队的工作效率以及测试的有效性。越早提出此类相关问题，越可能进入开发工程师设计范围。同时，该项指标可为项目经理提供一个与“开发难度”并列的“测试难度”——这将会影响到项目负责人对开发周期的设计。
2． 除项目经理外，测试工程师是最需要了解用户需求以及用户使用体验的角色。参与这些由产品经理，项目经理编写的文档评审，会让测试工程师们得到除了列在文档上的核心需求外更多的信息——我们必须承认，因为人的因素，文档是不可能涵盖所有信息——这将会帮助工程师们以更快的速度对产品需求有更深层次的理解。
3． 使得测试经理能够更早做出“是否需要提前编写测试工具或搭建测试平台”的决定。而这是很重要的一点。测试在开发流程中，因其所处位置，很容易因为开发团队中的突发事件导致周期被压缩。而自动化测试工具虽然可以节省人力，但相比于手工测试，开发周期较长，见效较晚。通常一个工具从开发到可以用于测试需要一周到数月不等——完全取决于工具的规模。因此，尽快确定“是否需要编写测试工具”是必要的。它可以帮助测试团队“抢回”更多的时间用于设计和调试测试工具，从而达到更好的测试效果。甚至可以避免掉因为时间不够，而拒绝采用自动化工具转为手工测试的被动局面。
理由其实还可以列出很多。但是，我觉得这几点应是最为主要的。它们能足够说明为什么测试人员需要参与产品开发初期的工作以及他们需要做些什么的问题。这里再重复一下，在开发初期测试工程师需要：确定产品的可测性，了解用户需求，确定需要引入何种测试工具或平台。
所以，在开发初期做好测试计划并不是可有可无的；用户需求不是只要工程师“买单”就可以的；不理会测试团队而埋头开发的产品，将会是一场“噩梦”，特别是当产品发布/部署的时候。
但每个公司每个项目组不需要套用一样的模式。针对不同的需求，我们应该量体裁衣，做不同的剪裁。只是核心不该有变化，目标不该有变化。就如同国内一些公司对CMM的追宠——光有形，没有神，是实在不可取的。
文章来源于领测软件测试网 https://www.ltesting.net/
