软件测试人员应该在合适时间介入软件开发流程之中，已经不是一个新鲜的问题。
许多软件测试前辈或“软件人”告诉我们，测试人员介入开发流程越早越好，这样就能尽早地发挥测试人员的功能，减少出现软件缺陷，降低软件工程后期的成本。
测试人员介入软件开发工程，多早是早，多早为好呢？现成的答案：即从需求开始，从整体设计开始。总之，早早介入就是想让测试人员直接参与其中，以测试的视角，超前发现问题，并协助各干系人，将软件缺陷解决在萌芽状态。如此，可收到“未雨绸缪”“防患于未然”之功效。
目的已明确，节点瞅准，具体应该如何操作呢？从多年的项目经历中，我总结出一套行之有效的做法，我把它称为“谈心式”软件测试法。
不论在任何开发模式下的项目组，都会有日例会、周例会或月例会，以及各种各样的例会。有的例会是为了发布什么消息，有的例会是安排当下的工作，有的例会是讨论某个问题（有时是需求问题，有时是开发问题，有时也可能是测试问题），有的例会是各种评审。我发现，就某些实际问题而召开的例会，大多数情况下是没有什么结果的，而这些问题往往是在会后、少数人参与的局部讨论中，则寻求到了答案。
这是为什么呢？我从多年的工作经历中，归纳出这么两个比较突出的原因：
1. 时间问题
例会的时间常常比较短暂，尤其是在快节奏的开发模式（如敏捷模式）下的例会。因为整个项目开发周期短，任务紧，会议时间就十分有限。在例会上，每每是大家的思想还没有或刚刚撞出一星火花儿时，会议就结束了。
2. 与会人员的性格问题
有很多与会人员，并不适应在会议上，面对众多人员的环境下畅谈自己的观点，而在会下人比较少的情况下，反而能畅所欲言。由此，这就严重阻碍了参会人员的思想交流。还有一些人，对跟自己没多大关系的问题，经常持一种不置可否的态度，这也会阻碍相互之间的思想交流。
由此，我摸索出来的“谈心式”软件测试法就有了用武之地。
一 针对开发设计人员
在项目的每一个迭代阶段初始，阅读或分析需求是测试人员必须做的步骤。只有熟悉了需求，测试人员才能更好地参与到需求评审或设计评审中。在这个阶段，我会做两件事：
1. 分析、思考如何制定相关的测试策略和计划；
2. 尽可能地发现需求中的问题。
这个所谓的需求中的问题有两种：一种是自己不太明白的点；另一种是需求本身可能存在的问题。
测试人员在做这些工作的时候，开发设计人员大多数也处在阅读分析需求阶段。这时，我就会带着自己的问题，对症下药，针对不同的性格和喜好的开发设计人员，采用不同的方式去和他们“谈心，以求各个“击破”。对待喜欢直接谈话交流的人，我会选择面谈；对待不喜欢这种交流方式的人，我会选择用一个文档或邮件的形式进行沟通。
不管用什么方式，“谈心”的目的无非这么几个：
（1）表露自己对这个需求的看法、对新功能或功能改动的测试思路，针对这些思路，询问开发设计人员的看法；
（2）针对已经发现需求本身存在的问题，首先寻求开发设计人员的帮助（因为，每个人的经历、阅历和能力有差异，对同一个问题的理解是不一样的）。如果开发人员也已发现了这个问题，或是经你提醒，确认这确实是个问题，而彼此眼下，都还没有较好的解释或答案时，可以联名向需求人员或客户直接提出，以寻求进一步的确认和答复；
（3）根据测试人员对开发设计人员工作习惯或“毛病”的了解，可用一种善意的方式，提醒他不要再犯以前曾经出现过的问题（即有可能是粗心或对需求不正确的理解所导致的问题）。
通过这样的“谈心”交流，有时可以拓展自己在制定测试计划或测试用例时的思路，有时可以解决开发设计时的需求理解问题，甚至可以避免因开发人员的人为因素而造成的缺陷发生。
我一直觉得，测试驱动开发，是一种测试“驱动”开发方式。测试人员主动参与设计，诚挚跟设计、开发人员“谈心”，不仅可以帮助他们从测试的角度去看待一些问题，还可以使测试人员本身的思路更加清晰，而且，开发人员也可以拓展测试人员的思维。更为实在的是大大提升了工作效率，缩短了开发周期，降低了公司和客户的成本。共享多赢，何乐而不为？
二 针对需求制作人员
起初，我仅仅把“谈心式”软件测试法应用到了开发设计人员层面。后来，我发现这个方法不仅可以应用到与开发设计人员的沟通上，也可以用在需求制作人员的身上。
需求制作人员在制作需求文档的时候，经常要从两个角度出发，一是从客户的角度出发，因为他们要制作出客户满意的需求来。二是从软件开发角度，他们要思考功能实现的可能和成本。
不管怎么说，需求人员在对客户需求做二次加工的时候，就会自然而然地注入其个人的观点或意愿。测试人员在阅读、分析需求文档的时候，如果发现什么疑问，比如说新需求和软件系统以往的风格有出入，或功能点描述模糊，或其他一些问题，测试人员就可以直接与相关需求人员沟通，寻求问题的确认和帮助。这样的“谈心”，不仅仅是对需求的一定评审，同时也是对自己的测试工作的帮助。最为主要的是与需求制作人员多交流，多沟通，致使对需求更加明确无误，以免多走弯路，影响工期，增加成本。
三 针对客户
随着阅历的拓宽和实践经验的积累，现在的我已不满足和需求人员、设计开发人员“谈心”，有时也会与客户直接“谈心”。
在敏捷开发模式或其他快速开发模式下，项目组成员和客户的直接交流已成为可能，而且变得越来越频繁，越来越重要（比如我们现在的项目组）。
“测试从客户的原始需求开始”，已经是我的一种工作方式。
在遇到需求制作人员也无法给予答案的问题时，我就会直接和客户“谈心”。毋庸讳言，有很多时候，客户的需求是模棱两可的，甚或是想当然的。有时他们提供的原始计算方法或运算流程（在很多软件项目，客户所用到的计算方法或公式是很专业的，所以必须由客户直接提供）是不正确的。在这种状况下，如果测试人员发现了这方面先天不足的问题，并及时与客户“谈心”沟通，将之扼杀在萌芽状态下，必然会避免项目组宝贵时间的浪费，挽回客户相当的损失。
“谈心”不仅可以发现问题，解决问题，“谈心”还可以让测试人员更多地了解现在开发的软件所涉及的行业规范及其他知识。同时，也能为测试人员更好地测试当前软件、系统或产品提供准确的知识背景；能让测试人员制定出更符合此软件的测试用例；能有针对性地发现更多不符合行业规范或要求的软件缺陷。多年的经验告诉我，对于一个前沿的测试人，对当前系统所涉及到的行业、领域知识，在一定程度上，比测试技能（测试方法的应用、测试工具的使用）更为重要。
测试人员直接与客户“谈心”，似乎有“越俎代庖”之嫌，倘若遇到多虑的需求制作人员，有时难免会造成一些误会，生出一些不必要的嫌隙。在此值得一赞的是，我比较庆幸自己加入了一支奋发向上、相互尊重、团结和谐的团队。只要是有利于项目开发，有利于客户需求，我们这个团队，从不过多计较所谓的“规矩礼数”。
其实，测试人员不仅仅可以和文中所提及的这三类人员“谈心”。只要是项目干系人，均可用“谈心”的方式去直接或间接地对软件进行测试。测试人员可以把思路打开，不要仅盯着软件、系统本身。整个项目组从人员、到流程，都可以成为测试人员的测试对象。套一句时髦概念，此可称为“大测试”理论。
