测试的目的是为了保证生产出来的产品满足甚至超出客户的需求。测试的角度要从客户的角度分析客户的显性需求和隐性需求。所以，做好测试，你必须要清楚得掌握客户的需求。要掌握客户的需求，首先你得清楚你的客户是谁？
传统的客户定义主要有三种：Customer、User和Operator。customer是和你签订合同的对方；user是使用你的软件的单位 （点）；operator是操作者。一般：user和讨论功能模块，和operator讨论操作场景，和customer签合同。比如你要做个电信软件， 跟你签订合同的customer就是这个电信公司；使用你的软件的user就是各个电信营业厅；操作你的软件的operator就是各营业厅里各个服务 员。
CMM里还有一个关于客户的定义：“负责接收产品并且付给开发组织报酬的个人或组织。”
那么我们的客户是谁呢？
答：
软件质量可以从两个角度看，Producer和Customer. 对应到楼主的定，Producer就是楼主的customer；Customer就是楼主的User和Operator。
从producer的角度看质量是：Meet the customer’s requirement the first time and every time.
从Customer角度看质量是：Fit for use.
测试的职责是缩小和弥合两者的差距。用图说明一下：
测试部门在SDLC的不同阶段对需求的范围和关注程度是不一样的，是动态的。
SDLC 前期，比如需求分析阶段，如果测试介入早，会去和producer和Customer做沟通，关注两者理解的需求是是否一致。这个阶段采用Static testing的方法，比如：Review， walkthrough. 这个阶段发现的问题，解决的成本最低。
到SDLC中后期，假设Customer的需求都确定了，PRD和其他需求文档定稿了。测试就会着重关注共同约定的需求，开始测试设计。我们就要确保producer做出来的东西和否和需求吻合。
问：
Tester必须比producer更了解customer，比customer更了解的producer，这样才能更有效得缩小两者的gap，对吧？
答：
‘Tester必须比producer更了解customer’，应该说是Tester要确保Producer理解的和Customer要的一样， 如果Tester和Producer对某个需求有疑义，就需要Customer澄清确认。‘比customer更了解的producer’应该是成立的。 举例如下：
第一阶段：
当Customer的需求确定并记录确认后，Business Prime（代表需求方-customer）产出BRD（Business requirement document），然后Business Analyst （相当于淘宝的PD，可以是customer方，也可以是Producer方）扩展细分后产出PRD。测试人员要通过Review/walkthough 等方式确保PRD和BRD一致，没有脱节，没有遗漏，无疑义。
第二阶段：
PRD同时分发给测试和开发组，开发着手准备 SRS/SDS（Software Requirement Specifications/Software Design Documents），而测试开始准备测试计划和测试设计。同时测试需要对开发的SRS/SDS评审，确保和ＰＲＤ一致。
以上都是Static testing. 属于Independant Verification.
进入第三阶段，搂主的表述‘比customer更了解的producer’应该是成立的，因为Customer不知道也不一定关心Producer具体是如何实现的。而测试去一定去了解和跟踪。
这个阶段，开发根据SRS/SDS开始编码，测试开始设计测试用例。等编码完毕，提交测试，测试开始执行测试用例。Validate and evaluate系统是否和PRD需求一致。
问：
跟进两个问题：1、我们如何来保证Business Prime和Business Analyst一致？2、如何保证Business Prime与Operator Requirement 一致呢？
答：
1、Business Prime和Business Analyst可以不一样，君子不器。但是二者的产出BRD和PRD必须保持一致。BRD中应当有一个需求列表，列出该项目，该阶段应该满足的用户需求。 PRD对该表诠释，细化，标准是Testable.如果测试人员认为某些需求太含糊，有歧义等，就要提出问题，直到测试人员接受，认为是 Testable。在这当中暴露的问题和gap，Business Prime有最终话语权。
2、为保持Business Prime与Operator Requirement 一致，客户，开发和系统使用者可以使用以下方式沟通，确保Operator Requirement被正确理解。
a）用户调查方式（Customer surveys）
b）JAD （joint application development） sessions – producer and user negotiate and agree upon requirements
c）让用户更多的参与到项目中（More user involvement while building information products）
d）前期建立系统原型和客户沟通，有一个直观认识（prototype）
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
