软件测试人员应该在合适时间介入软件开发流程之中，已经不是一个新鲜的问题。

　　许多软件测试前辈或“软件人”告诉我们，测试人员介入开发流程越早越好，这样就能尽早地发挥测试人员的功能，减少出现软件缺陷，降低软件工程后期的成本。

　　测试人员介入软件开发工程，多早是早，多早为好呢？现成的答案：即从需求开始，从整体设计开始。总之，早早介入就是想让测试人员直接参与其中，以测试的视角，超前发现问题，并协助各干系人，将软件缺陷解决在萌芽状态。如此，可收到“未雨绸缪”“防患于未然”之功效。

　　目的已明确，节点瞅准，具体应该如何操作呢？从多年的项目经历中，我总结出一套行之有效的做法，我把它称为“谈心式”软件测试法。

　　不论在任何开发模式下的项目组，都会有日例会、周例会或月例会，以及各种各样的例会。有的例会是为了发布什么消息，有的例会是安排当下的工作，有的例会是讨论某个问题（有时是需求问题，有时是开发问题，有时也可能是测试问题），有的例会是各种评审。我发现，就某些实际问题而召开的例会，大多数情况下是没有什么结果的，而这些问题往往是在会后、少数人参与的局部讨论中，则寻求到了答案。

　　这是为什么呢？我从多年的工作经历中，归纳出这么两个比较突出的原因：

　　1、时间问题

　　例会的时间常常比较短暂，尤其是在快节奏的开发模式（如敏捷模式）下的例会。因为整个项目开发周期短，任务紧，会议时间就十分有限。在例会上，每每是大家的思想还没有或刚刚撞出一星火花儿时，会议就结束了。

　　2、与会人员的性格问题

　　有很多与会人员，并不适应在会议上，面对众多人员的环境下畅谈自己的观点，而在会下人比较少的情况下，反而能畅所欲言。由此，这就严重阻碍了参会人员的思想交流。还有一些人，对跟自己没多大关系的问题，经常持一种不置可否的态度，这也会阻碍相互之间的思想交流。

　　由此，我摸索出来的“谈心式”软件测试法就有了用武之地。

　　一、针对开发设计人员

　　在项目的每一个迭代阶段初始，阅读或分析需求是测试人员必须做的步骤。只有熟悉了需求，测试人员才能更好地参与到需求评审或设计评审中。在这个阶段，我会做两件事：

　　1、分析、思考如何制定相关的测试策略和计划；

　　2、尽可能地发现需求中的问题。

　　这个所谓的需求中的问题有两种：一种是自己不太明白的点；另一种是需求本身可能存在的问题。

　　测试人员在做这些工作的时候，开发设计人员大多数也处在阅读分析需求阶段。这时，我就会带着自己的问题，对症下药，针对不同的性格和喜好的开发设计人员，采用不同的方式去和他们“谈心，以求各个“击破”。对待喜欢直接谈话交流的人，我会选择面谈；对待不喜欢这种交流方式的人，我会选择用一个文档或邮件的形式进行沟通。

　　不管用什么方式，“谈心”的目的无非这么几个：

　　（1）表露自己对这个需求的看法、对新功能或功能改动的测试思路，针对这些思路，询问开发设计人员的看法；

　　（2）针对已经发现需求本身存在的问题，首先寻求开发设计人员的帮助（因为，每个人的经历、阅历和能力有差异，对同一个问题的理解是不一样的）。如果开发人员也已发现了这个问题，或是经你提醒，确认这确实是个问题，而彼此眼下，都还没有较好的解释或答案时，可以联名向需求人员或客户直接提出，以寻求进一步的确认和答复；

　　（3）根据测试人员对开发设计人员工作习惯或“毛病”的了解，可用一种善意的方式，提醒他不要再犯以前曾经出现过的问题（即有可能是粗心或对需求不正确的理解所导致的问题）。