测试管理大杂烩

  测试管理FAQ一。

  1、 测试团队结构是怎样的?

  大多数测试团队,或者说传统测试团队,一般按照测试类型构建团队体系,如图所示:

  优点:职能划分明确。

  缺点:技能发展单一,协调成本较高。

  有部分团队按照测试粒度构建体系,如图所示:

  优点:测试提前。

  缺点:测试成本偏高。

  还有的按照测试阶段或者说测试能力构建体系,也就是通常说的流水线,如图所示:

  优点:测试速度快。

  缺点:测试职业发展容易形成瓶颈。

  有极少数团队按照测试专业程度构建体系,这也是目前甚嚣尘上大肆鼓吹的结构,如图所示:

  优点:测试成本低。

  缺点:容易脱离实际业务。

  上面几种结构本身并无高下之分,可结合团队实际情况进行选择。笔者所处团队的结构目前是第一种、第三种和第四种的混合体,如图所示:

  优点:资源利用率最大化。

  缺点:并行工作较多。

  2、 开发需要什么样的测试?

  ●测试时间短

  ●测试质量高

  ●善于交流

  ●专业

  ●深入了解产品

  ●……

  随随便便可以列一堆要求,但其实核心就一条,能做开发做不了的事。闻道有先后术业有专攻,测试自有其专业领域,测试人员的核心价值应该体现在哪?开发与测试的关系既泾渭分明又水乳交融,身为团队主导者应能准确辨别在当前整个研发体系中测试团队处在什么位置应起到何种作用。由此制定团队目标确定团队发展方向,而不是拍脑袋乱想,或者把测试团队孤立出来单独订目标。技术储备很重要,但技术储备的方向要靠主导者来确定,比开发更懂测试比测试更懂开发,这句玩笑话说出来真的很心酸,因为四不像。

  一般测试团队会经历这么个过程:

  ●草创,先不管别的能把基本的测试需求满足就好。

  ●上升,普通的功能测试趋于成熟,开始引入性能、自动化测试等等,多采用第三方测试工具。

  ●突破,有相当的测试积累,有较为丰富的测试资源,开始建立独有的测试体系,包括各种方法论与测试产品。

  ●平稳,该做的好像都做的差不多了,也想不出什么革命性的创意,保持现状吧,开始著书立传。

  ●下滑,人浮于事,毫无激情。

  笔者见过的测试团队大多处在“突破”阶段,在此阶段要注意技术研究与实用性的关系。

  说了半天,其实这个问题应该变成,企业需要什么样的测试团队。

  3、 老板需要什么样的测试?

  和上面问题有什么区别?有,上面是群体对测试的要求,这里是个体对测试的要求。

  首先,这里的老板指的是整个研发体系的负责人,什么产品、开发、测试都在他那。

  其次,有一说一,大多数老板对测试领域并没有太多深入的了解,对测试的认知更多来自其它团队的反馈及产品的最终质量。所以老板最关注的测试问题是什么呢?

  ●测试成本:测试到底能为我带来多大的收益?这是每个老板都会问的问题。ROI是每个人心里的一本账。笔者一直阐述资源利用率最大化、能量守恒的原因,就是建议用最少的资源办最多的事,要一个人承担多个任务而不是多个人做一件事。讲到这很多人会说你当我们不知道啊问题是怎么做到。如何降低测试比例下文会谈到,但笔者在这首先想问,作为主管的你真的想缩小团队规模吗?是否因为其它因素反而想扩大规模?

  ●技术含量:一家企业到底是以商业为主还是技术为主,这点不用费脑子多想,至少我们都是做技术的。测试技术到底包含哪些内容?上文提到过这里不重复。如果仍不清楚可以查阅笔者一系列文章。在这就说一点,很老套也很朴实,能发现更多更深入的别人发现不了的缺陷,就有技术含量,不管你在过程中使用了何种技术何种方法。你说你用了多少高精尖的技术结果愣是一个缺陷没找到,有用吗?

  ●产品质量:这条不用多说,缺陷预防才是王道啊。

  ●团队协作:如果你认为开发、测试是两个团队,那么就一定是两个。职能划分明确没问题,但自扫门前雪就很有问题。这故障是开发弄的与测试无关,一旦有这种想法何谈协作?

  无可否认,在整个研发体系中,测试不是核心,至少在当今各种各样的研发流程里它都不是。明确这一点,也就能明确老板到底需要什么样的测试团队了。

  4、 如何提升测试开发比?

  测试开发比应该是1:3?1:4?1:10?甚至干脆就没有测试。这是个哲学问题,争论无止境。不过笔者还是要说,单纯的谈论测试开发比是毫无意义的,它涉及的因素太多太多,绝对不是越高越好。

  列几个提升比例的切实有效的思路:

  ●能量守恒:测试工作量不会消失而只会转移,转移给机器,转移给非测试人员。目前大多数团队的作法是转移给机器,这就是自动化测试长盛不衰的原因。题外话,虽然笔者并不认为自动化测试是银弹,但承认它至少是颗子弹。然后有少部分团队的作法是转移给人,即把测试工作发散出去,发散给非专业测试人员。说白了就是很容易开展测试活动,是个人就能来进行测试。想达到这点必须满足一个前提条件,待测产品具有极高的可测性。这也是笔者一直鼓吹的全民测试,测试工厂化、傻瓜化等等等等。具体如何提升产品可测性,请参看笔者另一篇文章《测试手段多样化》。

  ●测试传承:百年老店,首重传承。这玩意的好处不想多说,当你团队人员流动率高的时候你就体会到了。传承要有体系,有脉络,绝对不能做成零散的海量信息。具体作法可参考国家图书馆、档案馆。笔者一直在做产品测试脉络图,也就是针对某个产品的各种功能点,分别要采用何种方法、手段进行测试,并把各个点给串起来,形成类似人体经脉那样的结构。

  ●技术创新:智能化测试遥遥无期,笔者研究多年也没啥成效,汗颜。测试行业发展到现在,有多长时间没看见划时代革命性的创新了?就说放眼望去的大大小小测试工具,有哪一个是与众不同的?科学技术是第一生产力,同时,科学技术需要转换为生产力,尽量避免开发不实用的技术,更不要以开发不实用的艰深技术来展现自身能力。笔者建议大家,把各种测试手段融入到业务产品当中,也既是产品本身就具备测试功能,现在很多测试工具所实现的功能都可以放进去。最后,期待业内的测试专家,能开发出真正革命性、划时代的测试产品,很期待。

  5、 怎样才是好的测试主管?

  男要帅女要美,真的,不开玩笑。没看古时候入朝为官的士人讲究一表人才吗,长得挫状元都能给你降为探花。所以第一要素是形象气质俱佳,最好再有一副好口才。

  第二,不要加班,没看错,至少不要明目张胆的加,要加偷偷摸摸的加。主管长期在公司加班很容易在团队内形成加班文化,甚至造成组员刻意把部分工作留在下班后完成。一旦形成此氛围对工作效率会造成极大的损害,大家会想反正要加班的,不急。忙或闲,每个人心里都清楚,最重要的是拿结果,能把活搞定管你在哪加班。

  第三,是技术型还是管理型或者混合型都没差,但不能什么都不是,要有一方面在整个团队里无人可比。当然,指的是工作中用得上的能力,如果吃饭比别人吃的多那你顶多是个饭桶。题外话,能力与职位不符很痛苦的,不具备对应的能力还是别坐这个位置的好。做人做事讲天赋,不是什么能力都可以培养出来。

  第四,准确评估工作合理进行工作分配。此点非常难做到,随便找本项目管理的书里面至少有一半在讲这个。在资源不足工作量大且有多数工作并行的情况下要做到合理分配那是难上加难,如果在此形式下还能让团队正常运转并且不加班,来来来,让大家叫你一声大师。

  最后,好主管并不一定是好同事,做好主管就行了,无需要求自己面面俱到。

  小记:从团队结构说到外部对测试的要求,再说到测试成本及团队管理者本身,其实笔者全文想说明的是,在他人眼中什么样的测试团队才是好团队,或者说能得到大多数人认可的团队是怎样的。很多测试团队内部的问题没有进行说明,犯懒,有时间再写吧。一家之言,欢迎拍砖。

时间: 2024-09-20 14:54:53

测试管理大杂烩的相关文章

测试管理工具TestDirector

Mercury方案中的对应测试管理平台产品是TestDirector,一个用于规范和管理日常测试项目工作的 平台.它将管理不同开发人员,测试人员和管理人员之间的沟通调度,项目内容管理和进度追踪.而且 ,Mercury的测试管理软件TestDirector,是一个集中实施.分布式使用的专业的测试项目管理平台软件 . (1) 测试需求管理 程序的需求驱动整个测试过程.TestDirector的Web界面简化了这些需求管理过程,以此您可以验证 应用软件的每一个特征都功能正常.TestDirector的

如何在CentOS 7.x上安装Zephyr测试管理工具

测试管理指测试人员所需要的任何的所有东西.测试管理工具用来记录测试执行的结果.计划测试活动以及汇报质量控制活动的情况.在这篇文章中,我们会向你介绍如何配置 Zephyr 测试管理工具,它包括了管理测试活动需要的所有东西,不需要单独安装测试活动所需要的应用程序,从而降低测试人员不必要的麻烦.一旦你安装完它,你就看可以用它跟踪 bug 和缺陷,和你的团队成员协作项目任务,因为你可以轻松地共享和访问测试过程中多个项目团队的数据. Zephyr 要求 安装和运行 Zephyr 要求满足以下最低条件.可以

测试管理工具QualityCenter的使用

--测试工具: (1)功能测试工具 QuickTest Professional(QTP) (2)性能测试工具 LoadRunner (3)测试管理工具 QualityCenter.TestDirector 全部是HP公司产品,最早由Mercury Interactive(MI)开发 (4)白盒测试工具 Junit.Jtest(parasoft) --如何访问 1.打开DOS,查看虚拟机的IP ipconfig 2.打开IE浏览器 输入: http://172.166.0.252:8080/qc

测试管理在DevOps中扮演着怎样的角色?

  论DevOps.测试管理和QA部门之间如何共同合作,以达到更快地交付. 在敏捷操作下,DevOps正在蓬勃发展并成为大量机构的主要优势.由于DevOps为业务.开发.运营和质量保证部门开辟了协作战线,它能够有效的向客户提供更新和更强的功能.DevOps符合敏捷项目所固有的精益.精敏的内在价值观,团队须尽最大努力确保提供合适的配置以应对挑战. 经验证DevOps可以从测试管理的使用中获益匪浅.然而,有些人可能会想知道这个过程如何适应整个DevOps环境的细节.随着软件开发变得越来越复杂,Dev

【转载】外包测试管理之组织篇

问题描述 1组建有"战斗力"的测试团队   外包测试是智力密集型工作,测试团队的能力决定了测试的质量.测试团队的建设要考虑两个问题:第一是组织结构,包括需要多少测试经理.测试组长.测试工程师.第二是每个岗位需要的技能,例如测试技术经验.项目管理经验等.  由于外包测试受到项目成本和资源的制约,由测试专家构成的"梦幻团队"是不切实际的.有"战斗力"的团队是现实目标,由具有测试管理经验的人员担任测试经理,掌握测试技术和熟悉被测App的人员担任测试组长

浅谈测试管理—兵者诡道也

测试管理,如领兵打仗. 既然是征伐,一味蛮干,只懂得身先士卒,是不够的. 谋定而后动,还是有一定道理的.今日姑且小议一句话."兵者诡道也". 情景一: 为了项目进度,需要晚上加班测试. 如果你是个leader此时极有可能听到team中各种声音. "怎么会加班呢?啥时候能回家啊?" "今天能搞定嘛?不会通宵吧" "这要搞到啥时候?我还有事呢" -- 分析: 诚然这些声音多少包含消极的因素,然却无可厚非. 正如我一贯主张,劳逸结合

基于会话的探索性测试管理

探索性测试是一个特殊的测试过程,它的测试活动和测试内容是动态变化的,更多的是通过测试执行的结果来指导后续的测试活动,花在文档上的时间很少,这也就意味着探索性测试的可管理性不强,对于每个测试人员执行的测试活动的进度和效果很难监控.为了更好地开展探索性测试,Jonathan Bach提出了一种"基于会话的测试管理(Session-basedtest management,缩写为SBTM)"方法,这种方法可以对探索性测试进行更好地管理,把探索性测试的优势更好地发挥出来. 基于会话的测试管理是

使用IBM Rational Quality Manager(RQM)V2.0来优化测试管理

为远程测试联合使用 Rational Quality Manager 与 Rational Functional Tester 的集成 引言 IBM Rational Quality Manager 解决方案是 IBM Rational 最新的质量管理环境.构建在 Jazz 平台上,Rational Quality Manager 是一种能够提供大量选项的灵活工具.本文还展示了怎样实施 IBM Rational Quality Manager 和 IBM Rational Functional

浅谈测试管理—应对需求变更

今天想和大家说的,其实无非是和我们如影随形的需求边变更.似乎自我入行一来一直听到这个词语.先说何为需求?我按照广义和狭义简单的区分了下. 所谓广义需求,及时一切和项目有关的想法,建议反馈,都叫做需求.所以狭义,就是产品经理提出的需求文档.其实一定时期内,我们不得不承认,广义需求是相对稳定的,并且有一定的经验可谈.何意?广义需求可以是用户的一个反馈,可以是今年流行的一种设计风格,可以是近几年流行的聚焦区域.再具体点说,就是,用户可以希望音乐播放软件提供高品质,免费,且海量的搜索结果,这个要求可能是