本篇要讨论的话题是测试员要在项目中起什么作用。
像很多有关测试的问题一样，这个问题初看起来答案很简单、很平凡，但其实不然。
老规矩，从我们的实际工作中举例来说明。很多刚参加工作的测试新人常常遇到这样的疑惑：
- 领导交代了一项测试任务，时间紧张到正常测试时间都可能不够，但按照流程还要写一些计划之类的文档，这时候应该如何抉择？
- 领导交代了一个测试项目，作为负责人的你，可能能力只够做一些简单测试，而重点模块或者高风险模块，以你当前的能力难以承担测试，这时候应该如何进行工作？
- 测试完了，按照规定需要你提交测试评估报告，但你心里可能都没底，这时候应该怎么办？
- 项目上线以后发现了一个漏测的问题，项目经理因此来指责你的工作，他认为你的工作不到位，这时候应该怎么做？
- 某一天突然接到一个在你看来超出工作范围的任务，比如让你培训客户，这时候该怎么办？
- 。。。。
其实以上种种，或多或少都牵扯一个问题，也就是今天讨论的这个话题：测试员要在项目中起什么作用。换句话说，在项目中测试员承担什么样的角色。
测试员的角色真的像乍看起来那么简单吗？在我看来，一个角色就是一种关系。这意味着我们不能控制自己的角色（可以协商）。别人期望从我们测试人员这里得到的可能并不合理，所以当我们测试人员因交付了低质量的产品而受到指责的时候，不管是谁指责，可能会存在分不清角色的问题。
那么测试员的角色应该是什么呢？
工作久了就明白，这取决于测试团队在这家公司的使命。测试员的使命决定要做的一切。测试员的使命，可能要取决于自己的行业、公司、项目或者团队的特性，这些要素的千差万别，决定了测试团队的不同使命。例如，在有些测试团队中，测试计划只是为他们提供帮助的工具，他们的测试计划可能只流传于口头，或者写在草稿纸上，但仍然有效。而有的测试团队中，测试计划是一种“产品”，必须随软件一起交付。他们的测试计划必须遵循严格的格式和内容要求。
那么有哪些可能决定测试员的使命的要求呢？举几个例子：
- 快速找出重要软件问题
- 对产品质量提出总体评估
- 确认产品达到某种具体指标
- 帮助客户改进产品质量和可测试性
- 保证测试过程能够达到可分清责任的标准
- 就测试和与测试员协作方式培训客户
- 采用特定的方法集或采用特定的规则集
- 帮助预测和控制维护成本
- 帮助客户改进其过程
- 以最小化成本、最短时间或尽可能减少副作用的方式，完成自己的工作
- 为满足特定客户的要求，完成所有必要的工作
当测试员清楚了自己的角色之后，当协商角色时，就有了在任何情况下确立对自己预期的基础（当然，实际情况往往是即使是清晰和恰当的测试角色也是一种苛求）。
另外，我觉得对测试角色一个比较好的定义是：测试员是一个向客户提供信息的服务角色。
首先说“提供信息”，我们给谁提供信息，提供什么信息，为什么要提供信息？举个例子：如果把做项目比喻成一群人开车去一个地方。有些项目很简单、很平常，就像是白天开车去超市买东西，并不太需要我们测试。但是大多数值得开发的项目就像是夜间在山里开大越野。这些项目就需要一个指明灯就像大越野需要一个前灯，我们测试员要照亮前面的道路，使程序员和经理尽管还在拿着地图争吵，但是至少可以看清他们在哪儿，要从什么样的路面上开过去，离着悬崖峭壁有多远。每个公司测试团队的使命都不尽相同，不过这些细节背后的要素都是一样的：测试就是要找到信息，有关项目或者产品的重要决策都是根据这些信息做的。
再说“服务”。测试员是提供服务的角色。服务即意味着有客户，即被服务的人。测试员是否成功，主要看其是否很好的满足了客户的要求和最佳利益。这不会太难，不过测试员有很多客户，比如项目经理、程序员、技术支持、市场人员、管理层、用户等等所有跟项目相关的人员，这些客户都有自己的需要，而且他们的需要不一定一致。在某些特殊项目中，我们客户也需要进行一些优先级排序（关于对每种客户提供的信息不在本次讨论范围内，后期会有专题讨论 ）。如果测试员将时间和经理投入到客户并不关心的问题或需求上，就会有做无关工作或工作率低的风险。测试员要跟自己的经理协商使命问题，并明确使命。如果不能就使命达成一致意见，就不会有做任何工作的好基础。 总之，多研究，找出对项目最重要的人，找出要服务的人，因为这是做好测试工作的第一步。
结束语
如何不知道该做什么怎么办？评审使命。这样做可以找出自己的核心问题，如果明确自己的使命，就可以为自己的工作辩护，并且明确的确定下一步该做什么，还可以用简单的描述向其他人解释自己的角色。
如果确切的知道要做什么该怎么办？经常重新考虑自己的测试使命，保证自己的计划不会因为过于偏重测试问题的一个方面，而忽略其他方面