仲夏叶 | Stornado

生命就是用求知的欲望燃烧自己

测试员的角色

一个角色就是一种关系。这意味着人们不能控制自己的角色,但可以协商。别人期望从测试员那里得到的可能并不合理。当测试员由于低质量的产品受到指责时(这种事时有发生),不管是谁指责,可能都存在分不清角色的问题。也许他们认为测试员的工作,就是在产品交付之前使用“质量魔术棒”敲打产品,他们也许认为测试员敲打得还不够狠。

当测试员清楚了自己的角色之后,在协商角色内容时,就有了在可能出现的任何情况下确立对自己预期的基础。但是,即使是清晰和恰当的测试角色也是一种苛求。

测试员的使命决定要做的一切

测试员的使命,可能要取决于自己的行业、公司、项目或团队的个性,测试项目也千差万别。把测试作为一种工艺发展的挑战,一直是建立测试实践对话所面临的困难,这种测试实践要跨越我们之间的文化和技术差异。这些差异中的很多内容,决定了测试团队的不同使命。以下任何要求都可能决定测试员的使命。

  • 快速找出重要软件问题。
  • 对产品质量提出总体评估。
  • 确认产品达到某种具体标准。
  • 帮助客户改进产品质量和可测试性。
  • 保证测试过程能够达到可分清责任的标准。
  • 就测试和测试员协作方式培训客户。
  • 采用特定的方法集或遵循特定的规则集。
  • 帮助预测和控制成本。
  • 帮助客户改进其过程。
  • 以最小化成本、时间或尽可能减少副作用的方式,完成自己的工作。
  • 为满足特定客户要求,完成所有必要的工作。

如果测试员将时间和精力都投入到客户并不关心的需求上,就会冒做无关工作或生产率低的风险。测试员要与自己的经理协商使命问题,并明确使命,如果不能就使命达成一致意见,就不会有做任何工作的好基础。

如果测试员不知道该做什么怎么办?一种回答是评审使命。这样做可以找出自己的核心问题。如果测试员明确自己的测试使命,就可以为自己的工作辩护,并明确地确定下一步要做什么。测试员还可以用简单的描述,向其他人解释自己的角色。如果由于某种原因不能完成自己的使命,应该立即把这个问题汇报给管理层。

如果测试员确切地知道要做什么该怎么办?经常重新考虑自己的使命,保证自己的计划不会由于过于偏重测试问题的一个方面,而忽略其他方面。

测试员为很多客户服务

测试是一种服务角色,要乐于接受这种角色,因为测试员提供的服务是至关重要的。服务就意味着有客户,即要被服务的人。测试员是否成功,主要是看其是否很好地满足了客户的要求和最佳利益。这不会太难,不过测试会有很多客户,这些客户都有自己的需要,而且他们的各种需要不一定一致。

  • 项目经理。项目经理有资格了解测试员的工作进展并施加影响。测试员根据要求向其报告工作状态。指挥项目是项目经理的特权。测试员的责任就是告诉项目经理自己能做什么,不能做什么,有关项目的决策和条件会对测试产生什么影响。
  • 程序员。通过尽可能迅速地提供好的错误报告,使得程序员的工作更容易一些。努力提高自己的技能并了解产品,以免用错误的或用毫无意义的报告浪费程序员的时间。如果测试员可以做到这一点,就可以赢得更多的信任,而这种信任又可以转化为支持和影响。
  • 技术文档编写员。与测试员一样,负责编写文档和在线帮助的技术文档编写员也不能得到产品的完整信息。测试员可以帮助他们理解产品到底怎样发挥效能,并为其指出文档中的错误。技术文档编写员也会帮助测试员。当技术文档编写员研究产品,以及必须阅读文档的用户会怎样使用产品时,会了解到一些测试员不知道的信息。如果测试员与技术文档编写员有很好的关系,编写员就会告诉测试员有关产品的新特性、新用法、测试计划中的漏洞和他们所发现的软件问题。这些问题中的一部分永远也不会被报告,除非某个文档编写员知道哪个测试员关心这些程序问题。
  • 技术支持员。遗留在产品中的任何问题都会为技术支持员带来负担。测试员通过告诉技术支持员可能会给用户带来麻烦的产品问题,向其提供服务。如果测试员在开发期间与技术支持员一起工作,有时技术支持员会帮助测试员找出应该更正的软件问题。测试员也应该通过研究发现的难题,为技术支持员提供帮助。通过这种方式,能够把测试员与技术支持员拉得更近,进而与客户也更近了。
  • 市场开发员。市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。对于程序员来说是很小的程序问题,对于市场开发员来说可能会是至关重要的问题。他们也许能意识到这种程序问题会使客户较难完成某种重要任务。此外,通过评审市场开发计划文档或描述,测试员可以帮助市场开发员对产品能力有更精确的认识。
  • 管理层和项目相关人员。测试员服务于公司业务,这也是为什么测试员必须小心,不要像个质量狂,而不是通情达理的人的原因。特别是到了项目要结束的时候,测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要以明确、简洁的词汇编写测试状态报告,一遍执行经理能够感到有做出决策的依据。
  • 用户。在测试员的心中,要想着将要使用该产品的人。当然,用户的满意是项目的最高利益。但是还要考虑满足主要用户对项目团队的特殊要求。

以上列出的各条没有什么特别顺序,不过在实际项目中可能有一定顺序,因此要认真研究,找出对项目最重要的人,找出要服务的人。这是做好测试工作的第一步。

当心“完备的”测试

测试员的任务就是找出并报告重要的程序问题,但是不会发现所有的程序问题。为了发现全部程序错误,测试员必须检查所有可能有问题的地方,要在所有可能发生的不同条件下观察这些地方,还需要一种十分可靠的方法,当所有类型的程序错误发生时,都能够识别出来。如果测试员认为自己能够做到这些,那么要么产品非常简单,要么测试员的想象力太差。

知道并承认自己不能做所有的事之后,测试员必须选择如何使用自己的时间。

有一些测试员承认自己不知道是否发现了产品中的全部问题,但仍然不准确地讨论结束测试的含义。”对这个产品我需要测试5天“可以解释为,他可以在5天之内对产品进行完备的测试,也可能意味着他会在5天内发现所有问题。完备性常常是隐含地表示出来的,而不是明说出来的。不管是哪种情况,这都是必须小心对待的概念。请考虑完备测试可能的含义:

  • 完全发现了产品中的每个问题。
  • 完全检查了产品的每个部分。
  • 完成了自认为是有用和经济的测试。
  • 尽自己所能,完全达到了项目团队制定的目标。
  • 完成了约定的测试。
  • 完成了在一定条件下人所能够测试的所有内容。
  • 完成了自己所承担的测试部分,不考虑其他人的工作。
  • 完成了对产品很广、但是不深的测试。
  • 完成了对产品的一种测试。
  • 用完了分配给测试的时间。

如果测试员小心地澄清自己的意思,不要有“完备”、“完成”、“结束”等含义,则可能会安全,由于有些工作没有做而受到的责备可能更少,在收到责备时可以更好地为自己辩护。请注意,”完备“的定义并不是在项目一开始就能够最终确定的,随着测试项目的进展,随着新测试任务的突然出现,需要重新考虑。

为了解决在完备性上的普遍沟通问题,可让客户想想了解测试过程。总结自己实施的测试,以及为什么值得实施这些测试,并告诉客户自己没有做的其他值得做的测试,以及为什么没有做这些测试。

迅速找出重要程序问题

测试员的使命很可能包括找出重要的(与无意义相反)程序问题,而且要迅速找出。如果是这样,那么这对测试员所执行的测试意味着什么呢?

  • 首先测试经过变更的部分,然后测试没有变化的部分。修改和更新都意味着新的风险。
  • 首先测试核心功能,然后测试辅助功能,测试产品所完成的关键和常用功能,测试完成产品基本任务的功能。
  • 首先测试能力,然后测试可靠性。先测试每个功能是否完全能用,然后再深入检查任何一个功能在很多不同条件下表现如何。
  • 首先测试常见情况,然后测试少见情况。使用常用的数据和使用场景。
  • 首先测试场景威胁,然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。
  • 首先测试影响大的问题,然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。
  • 首先测试最需要的部分,然后测试没有要求的部分。测试对团队其他人有重要意义的任何不等的任何问题。

测试员如果对产品、产品必须与之交互软件硬件以及将使用的人越了解,越有可能更快地找出重要问题。应好好研究这些方面的内容。

跟着程序员走

为程序员提供支持,很可能是测试员使命的关键部分。在测试员测试程序员正在编写或刚刚完成的程序时,测试员的反馈有助于提高程序员的工作效率。程序员交付软件后,应该马上测试;程序员修改代码后,应该马上测试所做的变更。尽可能建立最短、最快的反馈环路。当程序员正在苦苦地思索测试员刚刚发现的程序问题时,测试员又开始寻找更多的程序问题。(对于测试员来说,)理想情况是,程序员为了修改测试员找出的程序问题忙得团团转,使程序员,而不是测试员,成为项目的瓶颈

别指望任何人会理解测试,或理解测试员需要什么条件才能搞好测试

让客户了解为了有效地完成测试工作都需要什么条件,完全要靠测试员自己。测试员要受管理层和程序员决策的很大影响。如果他们的计划不明确,或设计出的产品很难测试,测试工作就会很难进行。测试员也许不会得到想要的一切,但是测试员可以向管理层和程序员提供帮助自己的机会。

管理层和程序员并不是不关心测试或质量,他们也许只是不理解自己的行动会对测试过程产生的影响。测试工作的一个重要部分就是向客户解释测试。测试员的解释就像是流感疫苗,有利于健康而又不那么痛苦,但是疫苗的作用会逐渐衰退,必须一遍又一遍地解释。

摘抄自《软件测试经验与教训》