软件测试员的角色

发表于:2008-3-04 17:01

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:网络转载

分享:

经验5 迅速找出重要程序问题

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

·首先测试经过变更的部分,然后测试没有变化的部分。修改和更新都意味着新的风险。

·首先测试核心功能,然后测试辅助功能、测试产品所完成的关键和常用功能,测试完成产品基本任务的功能。

·首先测试能力,然后测试可靠性。先测试每个功能是否完全能用、然后再深入检查任何一个功能在很多不同条件下表现如何。

·首先测试常见情况,然后测试少见情况。使用常用的数据和使用场景。

·首先测试常见威胁,然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。

·首先测试影响大的问题,然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。

·首先测试最需要的部分,然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。

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

经验6,跟着程序员走

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

经验7,询问一切,但不一定外露

  不问问题当然可以测试,但是不可能测试得好。问问题是测试员对项目发挥作用的基础。不问问题.测试就没有目标,就是呆板、机械的。不过很直白的问题会刺激别人,常常使人产生顾虑。

  问题就像是一剂猛药,最好采用低剂量,或与饭一起吃(即结合其他沟通形式)。幸运的是,这样问问题的价值并不低于直白地发问。测试员所想到的任何问题都会有助于启发自己的思想,最终产生对问题的至关重要的认识。

  如果测试员在测试时发现对产品提不出问题,那么还是先停下来。
经验8,测试员关注失效,客户才能关注成功

  测试是项目团队中唯一不直接关注成功的角色。其他所有人都在创造什么,或创造性地指导创造。但测试员却是消极的。测试会是一种沉闷的工作,几乎像希腊神话所说:“测试者在孤岛上,注定要不停地寻找不会存在、也不应该存在的东西,深信成功会为神带来不幸。”

  重新定义比较积极的测试员使命是错误的,例如确认程序正常。即使“确认程序正常”作为使命交给测试员,测试员也要忠告客户,这样的确认是不可能的。这种确认成本极高。除非运行所有可能的测试,否则就不能证明程序正常。测试员只能够说:“就我所执行的测试来说,没有发现产品不正常。”但是反过来的确认就非常经济了:只需一个测试,就可以说明产品不正常。

  测试员关注失效,是因为这可以增加发现失效的机会。用自己全部的创造力和技能,寻找产品中的关键问题。如果测试员没有找到关键问题,程序员就不能改正,以后用户可能会替测试员找到。通过发现程序中客现存在的问题,测试员能够帮助项目团队更加了解自己的技能和产品风险,帮助他们将产品做得更好,更具可支持性,在市场中有可能更成功。

经验9,不会发现所有程序问题

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

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

经验10,当心“完备的”测试

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

  ·完全发现了产品中每个问题。

  ·完全检查了产品的每个部分。

  ·完成了自认为是有用和经济的测试。

  ·尽自己所能,完全达到了项目团队制定的目标。

  ·完成了约定的测试。

  ·完成了在一定条件下人所能够测试的所有内容。

  ·完成了自己知道如何测试的所有内容。

  ·完成了自己所承担的测试部分,不考虑其他人的工作。

  ·完成了对产品很广、但是不深的测试。

  ·完成了对产品的一种测试。

  ·用完了分配给测试的时间。

  如果测试员小心地澄清自己的意思,不要有“完备”、“完成”、“结束”等含义,则可能会很安全,由于有些工作没有做而受到的责备可能更少,在受到责备时可以更好地为自己辩护。请注意,“完备”的定义并不是在项目一开始就

  能够最终确定的,随着测试项目的进展,随着新测试任务的突然出现,需要重新考虑。

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

经验11,通过测试不能保证质量

  测试员太容易把自己看作是质量卫士了。但是测试员既不会提高质量,也不能降低质量。测试员表现出好像是自己“制服”了产品,但实际上产品到测试员手中时已经被制服。质量来源于构建产品的人,有时这对他们来说是要背负的沉重负担。测试员使命中的很大一部分,就是帮助他们更有效地对付真正的负担。如果测试员自认为是项目团队中惟一关心交付好产品的人,就不能很好地完成这部分使命。

  测试小组的任务可能叫做“质量保证”,但是测试经理可别真的也这样认为。测试员的测试和错误报告提供促进项目质量保证的信息,但是这种保证要来自整个项目团队。

经验12,永远别做看门人

  有些测试员梦想对产品的发布具有否决权。不妨给他们点教训,让他们梦想成真。问题是当测试员获得控制产品发布的权力之后,同时也承担了产品质量的全部责任,团队其他成员可以为此放松一点,也许还会大大地放松。如果问题逃过测试,走出项目团队大门,团队其他人员会(并且也将)耸耸肩膀,并责备测试员。谁让测试员交付有问题的产品来着。另一方面,如果测试员延误发布,作为这种质量狂,会被严厉追究并承担很大压力。

  最终,要由控制项目、条件最好的人承担发布产品的责任。但是我们所看到的大多数非常有效的项目团队,都采用某种方式的集体决定是否发布产品.如果读者被授权决定产品的发布,我们建议毫不犹豫地立即坚持与项目团队的其他角色一起分担这种权力。


经验13,当心测试中的不关我事理论

  测试是如此复杂.与其他项目活动如此密切关联,以至于测试员总想通过采用狭隘的测试使命观进行更好的控制。有些测试员认为.自己的使命就是找出产品和规格说明之间的差别。任何超出这个范围的问题,例如可使用性问题、需求问题、数据质量和可支持性问题,都“不关我的事”。我们强烈要求这样的人把眼光放宽一些。所有其他事情都一样,测试员的使命应该是尽其所能,通知团队可能会对产品的价值产生消极影响的所有问题。因此,优秀的测试团队应由理解项目总体问题的不同类型的人员组成:产品将怎样设计、制造、市场开发、销售、使用、服务和升级。

  说“不关我的事”的另一个原因是测试员处于困难的测试环境。负责程序设计的同事编写的规格说明可能很差,可能交付代码太迟,以至于没有时间执行合理的测试过程。他们可能声称测试员发现的重要问题实际上是测试员自己的主观臆想。在这种环境下,很想拒绝测试。测试员可以说,解释模糊的规格说明或在这样短的时间内进行某种测试不是自己的事。如果情况很严重,这样做也许不错,但是首先应该考虑一下自己的期望是否实际,考虑一下是否有其他方式能够得到自己所需要的条件。如果测试员接受这样的哲学.认为自己的工作就是付出合理的努力去适应和灵活应对各种情况,则程序员更有可能把测试员当作恩赐,而不是负担。而这反过来又会促使他们把帮助测试员看作是自己的事。

经验14,当心成为过程改进小组

  有时测试员会对查找问题感到厌烦,并考虑是否最好能够防止问题的发生。也许程序员更仔细一些,问题就会更少一些。就问题而言,这确实很有意义。但是同样有意义的是,满怀好意地告诉自己所爱的人怎样生活得更好。如果尝试一下就会知道,好的忠告并不总能被真正接受。问题不在于是否能够认识到,而在于感情。不管过程改进要干什么,它永远都会涉及感情。

  即使测试员通过测试着手推进质量改进有管理层强有力的支持。但是团队其他成员同时会有很多方法避开测试员的努力,并使测试员看起来无能。是的,如果过程改进是整个团队的工作,则测试员可以成功地参与工作,并获得成功,但是我们强烈要求测试员不要试图把测试小组“提升”到扮演过程批评角色。这样做是愚蠢的。

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

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

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

22/2<12
重磅发布,2022软件测试行业现状调查报告~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号