然后产品出来了，需要进行测试，有测试流程、测试规范来帮助保证质量，这是最直接的。然后还有很多的环节还会发生错误，比如配置管理、版本的管理，也需要相关的支持来保证软件的质量。所以说软件质量保证不应该只是在一个环节上，比如测试环节来保证，而应该是整个的流程，我们应该全面地去改进流程来保证质量。
问： 做 SQA 这方面的人员，在沟通方面需要的什么样技巧和能力？
答： 首先从大的方面说，整个团队的沟通，首先是大家要讲同样的语言。 UML 只是这种语言的一部分，我们不要狭义地理解这种沟通语言就是 UML 。它还包括采用一个什么样的流程方法，整个团队都要理解。譬如你说项目正处于 " 精化 (Elaboration)" 阶段，这个团队都要能理解这个术语。
还有就是整个组织机构内部大家采用的流程都是要一样的。举个例子来说， Rational 有很多产品，其中很多都是收购来的。不同的产品团队采用的开发方法、开发工具都是不一样的，他们到了 Rational 之后做的第一件事就是整合。这个整合一方面是说产品要整合起来（我们有 Suite 产品）；同时也是针对开发团队开发方法的整合，例如 Rational 花了一两年的时间把所有产品团队统一到 RUP 和 ClearCase/ClearQuest 平台之上，这是我们的首选。实际上到了 IBM 之后也是一样， IBM 现在正在做的计划就是让所有的实验室、研发团队都要使用 IBM Rational 自己的开发工具，他们都在使用 IBM 自己的开发方法、开发平台。这就是让大家的沟通基于一个统一的基础架构 ―― 统一的软件开发平台，这也是增强沟通的一种方式。另外，讲到 SQA 的人员，在 RUP 里对应的就应该是 Process Engineer 。他的主要的职能就是定义流程，保证流程的执行，并且不断地改进流程。对他的要求就是要对流程要比较了解，有实际项目的开发经验，不然没有办法理解流程，这是技能方面；另外就是与人的沟通能力要强，跟一般的开发人员和项目经理是有区别的，沟通的能力一定要强，他要负责说服项目团队来遵循标准。
问： QA 人员与目经理和开发人员之间的关系是怎样的？
答： 首先彼此之间是一个合作的关系。如果片面理解 QA 人员只是 " 过程警察 " 的话，就可能把他和其他的角色对立起来了。实际上在一个团队内部要避免这种认识。因为大家都是在一个组织架构内部的，大家的目标是一致的，就是要把公司的业务做好。所以 QA 人员的职责和任务就是帮助这个项目团队更好地进行软件的开发。既然已经定义的流程是比较适合企业的，项目就应该遵守这个流程来进行开发。如果有时候项目因为赶工，或是其它的原因违背一些流程上的规定的话，就会对软件的质量会造成一定影响，他就有责任来帮助开发团队来纠正这方面的一些错误。还有就是进度方面的问题。如果不按照流程来走的话，短期内看起来进度是快了一点，但从整个项目的周期来看，有可能是给以后的工作带来隐患，客观上肯定是延长整个开发的进度的。所以对于一些流程管理得比较好的企业，你会发现他们的 QA 部门和开发团队是相处得比较融洽的，配合是比较紧密的。在我们的客户里就看到过他们的开发团队非常感谢自己的质量控制人员，觉得他们对自己是给了很大的帮助。
QA 人员跟每一个角色的关系，如果你对应到 RUP 的话， RUP 里就定义好每一个角色是做什么工作的。 RUP 里分了 9 个规程 (discipline) ，流程工程师是在环境规程里边，项目经理是在项目管理规程里边。每一个规程其实就是一类开发活动，其中的角色和他们所产生的工件集合，是一个分类。可以把项目经理相关的工作，他所涉及到的工件，比如说软件开发计划、风险管理计划、质量保证计划都放在一起，放在这个规程里面。所以 QA 人员跟项目经理的关系就是去检查项目经理在这个岗位上所做的职责是否到位，是不是跟流程相符合。其他的角色也是一样的，譬如一个测试人员，就要看你有没有根据规定把缺陷按正确的测试流程汇报，发现缺陷之后是否能够得到改正，并作一个复审，还有回归测试的时候有没有考虑测试的完备性等问题，就是看测试人员有没有做好具体的工作。 QA 人员和整个项目团队在工作中的关系就是看每一个角色是不是很好地完成了自身角色所应该完成的开发任务。标准是什么？就是这个组织的流程，流程是保证质量很重要的一个依据。
问： QA 人员如何判断其工作效果和质量？