项目的第一阶段是需求定义。需求定义远比我们寻常的理解要复杂得多：它绝对不等同于用户需要什么功能，我们就把这个定义成一个产品需求。很多时候，用户都并不清楚他们真正想要的是什么。用户说，我很热。你可以给他一个风扇，甚至给他一台空调，但也许你给他一杯水就能解决问题。用户说，你们产品的更新过程太慢了，需要十几分钟！你可以去优化下载流程，压缩下载包尺寸，但也许你只要把更新工作放在后台执行而不影响用户的正常操作，他就很满意了。需求定义的工作一般是PM的职责，但是，开发团队是最终把需求转换成产品的人，开发对产品需求的理解和定义，也在很大程度上决定了产品在用户面前是什么样。这个时候，测试需要参与进来，和开发一起来理解需求，定义需求，Review需求。这个过程，在有些公司，叫做SRS（Software Requirement Specification）的形成。
开发在理解需求之后，就要开始设计了。设计决定了他将来的代码会写成什么样。好的开发流程，测试一样需要参与设计的Review；即使很多国内公司把这个都省了，开发直接写代码了，测试仍然有机会参与。可以跟开发聊聊他会如何实现，如果你经验丰富，他一样会很感激你给予他的反馈和帮助。代码写好之后，在正式Check In之前，还会有一个非常重要的环节：Code Review。作为测试，你如果想要知道你将来的测试用例该如何更有效率、更有针对性，你就得好好利用这个机会，好好Review。
测试参与CodeReview的好处远不止帮助开发发现一些显而易见的代码错误或是其他一些Code Review可以发现的Bug。Code Review可以帮助测试从设计上更好的理解产品。也许你不需要理解具体每一行代码他为什么要这样写，但你必须了解他的大体程序逻辑，有哪些输入场景、输出场景，有哪些条件判断，有哪些是复用稳定的旧的代码、哪些是全新写的代码，还有哪些是会被其他模块、甚至是需求从没讲过模块调用的代码功能......这些都是你后面设计测试用例的绝好素材。同时，你还可以根据你的经验，提醒开发应该把某些适合的基础场景实现单元测试，或是让开发自己做一些基础的冒烟测试。这些都对你后面的测试工作大有帮助。
好的开发流程对于软件质量的保障作用是非常大的。也有人抱怨，如果公司的开发很不讲流程怎么办？我个人的答案是，别人可以不讲流程，但如果你是一个优秀的测试，如果你懂流程、你可以证明按照你的流程结果更好，你还有一个责任，就是需要你去推动别人来遵循流程。不要以为那是经理们的事情；很多经理在这方面经验也许都没有你多；但好的经理他们会看清什么是对的，如果你在做对的事情，你肯定能够得到他们的支持。最重要一点还在于，如果你一直能够在带头做对的事情，在做你认为是TL、经理该做的事情，你离经理的位置也不会远。况且，测试流程也绝对不是只有经理们才需要关注的事情。
（这部分按照开发流程，应该写到设计用例的前面。）
如果这三个工作都做好了，可以说测试工作的大部分工作都完成了；剩下来的就是测试用例的执行了，以及为了提高效率的自动化、一些工具的实现、测试框架的精炼和使用，或其他一些琐碎的事情了。现在很多公司开始把测试用例执行外包了，说明这确实有需求市场；也有人在讨论这样会不会让外包公司的测试人员觉得测试低级而无趣了？我觉得对也不对。对确实是因为相比测试用例设计而言，单纯的测试执行在技术程度上要求要低；但不对，是想说，尽管是执行，测试人员一样有很多空间可以发挥。谁说测试执行过程中间就不能扩展更多、更有效率的测试用例了？被大家一直都看好的自动化测试难道解决的不就是测试执行的问题吗？探索性测试（ET）研究的重点不也是单纯的测试执行问题么？同一条测试用例，好的测试人员和普通的测试人员的执行结果和价值也是有很多不一样的。
这些工作做好了并不意味着，这些工作在前面阶段做完了，后面就再不需要做了。实际上，很多问题都是在测试过程中，根据自己经验调整原有的测试用例、甚至新增加一些测试用例发现的。我强调的是这些工作内容应该是测试人员日常工作中的主体。在整个开发流程上，它们往往会呈螺旋叠加的。
所以，我们用什么来做测试？答案绝不应该是某一个测试框架，或是某一个自动化工具。
如果你也是测试，你的答案是什么？
