如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当前测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。
简陋的测试流程
下面是一个简单的测试流程图：
需求分析与架构设计：
笔者做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体给某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既担任了需求分析师，又担任了架构师的角色。
程序员编码：
因为我们开发语言用的是JAVA语言，IDE用MyEclipse中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。
测试：
笔者入职后的第一个任务是搭建缺陷管理工具，禅道项目管理，通过推广对发现的问题进行跟踪。后来证明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢测试人员能当面反馈，这样更能提高效率。对一个小BUG通过当面交流的方式就可以将问题修复。
对于当时的环境，并没有测试环境。开发人员在本机上将项目进行部署，测试人员通过局域网访问开发人员的机子进行测试。或在测试人员本机上进行部署测试，这也是一个致命的缺点，因为开发人员使用的电脑存在太多不稳定因素，这些都会造成问题的出现，有时候难以判定是系统的问题还是环境问题。
上线：
经过测试人员测试通过后，开发人员部署上线。
A程序员流程
你会发现在流程图中，A程序员是先发上线之后，再进行测试。这是我们一个面向大众用户的网站，上面给于测试人员的定位是测试兼用户体验，测试将发现的bug和体验问题提交到缺陷管理系统，由经理对问题进行分析，指派开发人员解决，定期对系统进行更新。
流程分析：
这个流程唯一的优点，就是能快速的发现并修复问题。
缺点就非常多了，相信许多小软件公司也有类似的流程。
这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。
对于测试来说，需求很不明确，测试文档与用例也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写用例。我只能收集一些通用的测试用例，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用性”用例，以便在测试过程中做参考。功能测试的多了，拿到一个功能，测试思路也就出来了。
规范的测试流程
现在的测试流程：
需求分析：
需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。
需求评审：
这里会叫上多有参与项目人员进行，开发人员、测试人员。QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性，当然开发负责人也是要参与的。测试人员主要对需求的理解提出疑问，才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需要了解需求。
开发人员编写排期：
开发人员需要根据需求功能点进行排期。然后将开发计划转交给测试人员。
测试计划排期：
测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等，然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。
编写测试用例：
根据详细的需求文档，开始进行用例的编写。
用例评审：
在用例进行评审期间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。
然后，测试人员进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体事先进行把握等等。
提交基线：
开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。
具体测试流程：
开发人员对于基到测试线的功能进行测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基线。
测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后堆积先后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
测试通过：
经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过，编写测试报告与验收方案。
验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行，QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求更高，除了关心功能，还需要关心整体流程与质量。
流程分析：
对于刚接触这个流程的来说，这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而有效的保证了软件产品的整体质量。
那么这个流程是不是完美的呢？不，这个项目流程太强化各种文档。我们来看测试的工作内容，测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。其实，我们真正用于测试的时间非常少，在一周的时间，也许只有一天或不到一天的时间是在进行测试的，测试人员只有在测试的时候才能体现他的价值，而大部分工作却不能体现他的价值。
当然，这里省略了与测试主流程无关的东西，真正的测试工作中琐事很多。
敏捷测试流程
下面来看看敏捷测试，笔者本人并没有接触过敏捷，对敏捷也没花时间学习与研究，唯一接触就是听我们测试经理流程讲了两个半小时，听讲的人很多，受益匪浅。
前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能成为瀑布式，对于一个三个月的项目来说，产品把需求分析完了给开发，然后产品就没事了；开发完成后给测试，然后开发人员也不忙了，测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里支队单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事的。
敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
• 下面是笔者理解中的敏捷测试流程图：
第一阶段：
通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定的会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：
开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会在开发团队中抽出一个人员来用于解决测试发现的问题，但开发进度并没有因为测试而停止。
流程分析：
在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可能两个月或两个半月就会完成。
但这种流程并非完美，假如一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
• 对测试问题的处理
上图更能清晰看出对问题的处理过程。
第一块面板中是开发人员未实现的功能，第二块面板是开发完成的功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。