测试管理大杂烩

标签: 未分类 | 发表时间:2012-04-18 17:22 | 作者:童战
出处:http://qa.taobao.com

测试管理FAQ一。

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

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

 

优点:职能划分明确。

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

 

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

 

优点:测试提前。

缺点:测试成本偏高。

 

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

 

优点:测试速度快。

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

 

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

 

优点:测试成本低。

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

 

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

 

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

缺点:并行工作较多。

 

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

  • 测试时间短
  • 测试质量高
  • 善于交流
  • 专业
  • 深入了解产品
  • ……

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

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

  • 草创,先不管别的能把基本的测试需求满足就好。
  • 上升,普通的功能测试趋于成熟,开始引入性能、自动化测试等等,多采用第三方测试工具。
  • 突破,有相当的测试积累,有较为丰富的测试资源,开始建立独有的测试体系,包括各种方法论与测试产品。
  • 平稳,该做的好像都做的差不多了,也想不出什么革命性的创意,保持现状吧,开始著书立传。
  • 下滑,人浮于事,毫无激情。

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

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

 

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

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

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

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

  • 测试成本:测试到底能为我带来多大的收益?这是每个老板都会问的问题。ROI是每个人心里的一本账。笔者一直阐述资源利用率最大化、能量守恒的原因,就是建议用最少的资源办最多的事,要一个人承担多个任务而不是多个人做一件事。讲到这很多人会说你当我们不知道啊问题是怎么做到。如何降低测试比例下文会谈到,但笔者在这首先想问,作为主管的你真的想缩小团队规模吗?是否因为其它因素反而想扩大规模?
  • 技术含量:一家企业到底是以商业为主还是技术为主,这点不用费脑子多想,至少我们都是做技术的。测试技术到底包含哪些内容?上文提到过这里不重复。如果仍不清楚可以查阅笔者一系列文章。在这就说一点,很老套也很朴实,能发现更多更深入的别人发现不了的缺陷,就有技术含量,不管你在过程中使用了何种技术何种方法。你说你用了多少高精尖的技术结果愣是一个缺陷没找到,有用吗?
  • 产品质量:这条不用多说,缺陷预防才是王道啊。
  • 团队协作:如果你认为开发、测试是两个团队,那么就一定是两个。职能划分明确没问题,但自扫门前雪就很有问题。这故障是开发弄的与测试无关,一旦有这种想法何谈协作?

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

 

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

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

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

  • 能量守恒:测试工作量不会消失而只会转移,转移给机器,转移给非测试人员。目前大多数团队的作法是转移给机器,这就是自动化测试长盛不衰的原因。题外话,虽然笔者并不认为自动化测试是银弹,但承认它至少是颗子弹。然后有少部分团队的作法是转移给人,即把测试工作发散出去,发散给非专业测试人员。说白了就是很容易开展测试活动,是个人就能来进行测试。想达到这点必须满足一个前提条件,待测产品具有极高的可测性。这也是笔者一直鼓吹的全民测试,测试工厂化、傻瓜化等等等等。具体如何提升产品可测性,请参看笔者另一篇文章《测试手段多样化》。
  • 测试传承:百年老店,首重传承。这玩意的好处不想多说,当你团队人员流动率高的时候你就体会到了。传承要有体系,有脉络,绝对不能做成零散的海量信息。具体作法可参考国家图书馆、档案馆。笔者一直在做产品测试脉络图,也就是针对某个产品的各种功能点,分别要采用何种方法、手段进行测试,并把各个点给串起来,形成类似人体经脉那样的结构。
  • 技术创新:智能化测试遥遥无期,笔者研究多年也没啥成效,汗颜。测试行业发展到现在,有多长时间没看见划时代革命性的创新了?就说放眼望去的大大小小测试工具,有哪一个是与众不同的?科学技术是第一生产力,同时,科学技术需要转换为生产力,尽量避免开发不实用的技术,更不要以开发不实用的艰深技术来展现自身能力。笔者建议大家,把各种测试手段融入到业务产品当中,也既是产品本身就具备测试功能,现在很多测试工具所实现的功能都可以放进去。最后,期待业内的测试专家,能开发出真正革命性、划时代的测试产品,很期待。

 

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

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

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

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

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

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

 

 

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

相关 [测试 管理] 推荐:

测试管理大杂烩

- - Taobao QA Team
1、 测试团队结构是怎样的. 大多数测试团队,或者说传统测试团队,一般按照测试类型构建团队体系,如图所示:. 缺点:技能发展单一,协调成本较高. 有部分团队按照测试粒度构建体系,如图所示:. 还有的按照测试阶段或者说测试能力构建体系,也就是通常说的流水线,如图所示:. 缺点:测试职业发展容易形成瓶颈.

测试管理那些事儿

- - Taobao QA Team
首先注意人员流动和人才流失的区别. 人才流失是一定要控制的,当然如何评判是不是人才这是门学问,有道是千里马常有而伯乐不常有,本文不展开此问题. 而正常的人员流动是很有必要的,吐故纳新并不一定是坏事,所以我们才有轮岗才有末位淘汰. 我想任何老板都不希望自己团队成为养老部门. 测试工程师有别于其他技术人员的一个明显点是对于技术广度的掌握,这是工作性质所决定,必须先了解待测产品的各种背景才能正常开展测试活动.

软件测试知识库管理方案——大结局

- Ben - Taobao QA Team
淘宝测试团队的知识沉淀发展到今天,经历了无数风风雨雨,到现在各个产品线的沉淀方式,仍然没有完全统一,处于群雄割据的局面. 我们先简单看看淘测试的知识沉淀的发展历史. 在混沌初开的年代,大家基本都是用MS Word来编写沉淀文档,然后放在一个共享目录下面. 后来wiki概念兴起,产生了很多这一类型的web应用程序,MS share point(SP)是被普遍使用的.

Testacular:Google开源的JavaScript测试执行过程管理工具

- - 博客 - 伯乐在线
Google 已开源  Testacular,一个基于 Node.js 的 JavaScript 测试执行过程管理工具(Test Runner). 该工具可用于测试所有主流Web 浏览器,也可集成到 CI (Continuous integration)工具,也可和其他代码编辑器一起使用. Testacular 可以在不同的桌面或移动设备浏览器上,或在持续集成的服务器上测试 JavaScript 代码.

阿里巴巴是如何管理测试环境的?

- - InfoQ推荐
互联网产品的服务通常是由 Web 应用、中间件、数据库和许多后台业务程序组成的,一套运行环境就是一个自成一体的小生态. 最基本的运行环境是线上环境,部署产品的正式发布版本,为用户提供持续可靠的服务. 除此以外,还有许多不对外部用户开放的运行环境,用于产品团队日常的开发和验证,统称为 测试环境. 正式环境的稳定性,除去软件自身的质量因素,主要与运行的主机、网络等基础设施相关,而测试环境的稳定性则更多受到人为因素影响.

Android公共库选型 单元测试 依赖管理等调研

- - Trinea
抱歉,最近一个多月一直比较忙,博客许久未更新. 后续更新周期会慢一些,不过依旧会陆续分享一些原创. 最近在调研一些事情,欢迎大家留言告诉我自己公司的一些情况、经验及想法. 测试辅助框架选型,Quality Tools for Android, android-test-kit, robolectric, Android FEST指标同上.

测试

- 香姜 - 韩寒
测试......>>点击查看新浪博客原文.

功能点估算法(一)_软件质量管理、项目管理、过程改进、软件自动化测试咨询与培训。-CSDN博客_功能点估算法

- -
功能点估算法是软件项目管理众多知识中比较有技术含量的一个. 在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要,如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义. 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及,对软件项目范围的估算有很多种方法,常见的就是LOC代码行和FP功能点法,它们之间的区别和关系如下:.

管理

- - 人月神话的BLOG
对于中小企业而言现在管理上欠缺的不是人治或者说儒家佛家等东方管理思想,而真正欠缺的是西方法治的科学管理方法. 现在很多中小企业花很多钱去听什么东方管理思想的培训是误入歧途,东西方管理思想需要融合,但是基础还是科学的管理方法和模式. 而在这个里面最重要的仍然是流程管理,知识管理,质量管理,项目管理这些内容,而不是简单的纯管理.

Android单元测试与模拟测试

- - 神刀安全网
考虑可读性,对于方法名使用表达能力强的方法名,对于测试范式可以考虑使用一种规范, 如 RSpec-style. 不要使用逻辑流关键字(If/ese、for、do/while、switch/case),在一个测试方法中,如果需要有这些,拆分到单独的每个测试方法里. 测试真正需要测试的内容,需要覆盖的情况,一般情况只考虑验证输出(如某操作后,显示什么,值是什么).