• 测试管理大杂烩


    测试管理FAQ一。

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

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

     

    优点:职能划分明确。

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

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

     

    优点:测试提前。

    缺点:测试成本偏高。

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

     

    优点:测试速度快。

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

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

     

    优点:测试成本低。

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

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

     

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

    缺点:并行工作较多。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 相关阅读:
    IOC Unity的配置问题
    编译时常量与运行时常量
    Revit二次开发,将插件按钮(Ribbon)变灰或者隐藏
    C#类库读取App.config配置文件
    winform固定窗体大小
    Revit二次开发,获取模型版本信息
    JavaScript:文件保存自動下載函數:Save和SaveAs
    JavaScript:年月日時分秒設置
    JavaScript:字符串の空格刪減和字符刪減功能
    JavaScript:獲取數據の類型
  • 原文地址:https://www.cnblogs.com/chenxuan/p/2455653.html
Copyright © 2020-2023  润新知