从测试开发到Delivery Manager

发表于:2018-1-23 09:16

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

 作者:晴空    来源:51Testing软件测试网原创

  写在前面:
  2017年,新的征程,自己不仅身为人父,而职业上的角色也有了比较大的转变,总结下自己从测试开发负责人到Delivery Manager转变过程中遇到一些事儿~ 也算是自己的年终总结。
  从0到1是很难很难的,而从1到N更是不易。一句话"大道至简,知易行难"再合适不过了,希望我遇到的问题以及应对策略对现在或者以后职业生涯中遇到类似问题的同学们有些许参考意义。
  --------谨以此文,献给那些热爱软件质量保证工作的亲们!
  一、那些转变
  1.1、工作内容
  作为自动化测试负责人时,我管控的工作任务项是下面这些:
  1:开发自动化测试框架。
  2:设计自动化测试用例。
  3:实施监控自动化执行。
  4:培训扩散自动化技能。
  而转变为Delivery Manager之后,之前的所有任务项就变成了任务的子集。有同学可能会问什么是Delivery Mananger?我个人理解是产品质量负责人,这个角色对版本能否发布上线有这最终的决定权,当然~权利越大,责任越大!
  Delivery Manager负责的工作任务项包括下面这些:
  1:发布流程规范化及流程推进。
  2:分层自动化实施(当然包括测试框架开发,用例设计,测试执行这些)。
  3:测试资源安排协调。
  4:测试执行。
  5:版本质量评估。
  6:招聘质量保证同学。
  7:新人培养。
  8:生产环境故障跟进。
  其实,总结起来就一句话:"只要可以保证版本质量的事儿,Delivery Manager都需要去尽力尽心的去做"。
  1.2、心态和手段
  自动化测试负责人对每个版本中自动化测试的执行结果负责,而Delivery Manager操心更多(自动化覆盖的场景之外,手工测试验证的场景也是非常重要的,此外,跨部门沟通在有些团队里不是易事)。
  心态上:从局部到全局的变化,要协调的资源多,肯定会出现各种幺蛾子,肯定会有很多变化在预期之外,自己更多的学会了如何权衡全局,如何对部分因素妥协。
  手段上:有人的地方就有江湖,有江湖的地方就有恩怨纷争。
  虚与委蛇,软硬兼施是必须的;我尝试过一直很强硬,然而,强极易折,很可能会导致团队和个人都很累,到最后疲于应对各种突发事件。道理大家都懂的,只是没经历过,很少人能体会从自身出发强行转变自己的风格的痛苦。在此鸡汤一回吧~  痛,说明你在成长,勇敢的去汲取知识和各种优秀的姿势,在痛苦中成长吧,多年后的暮然回首,你会感激曾经奋力拼搏的自己!
  二:流程规范化推进
  2.1、为什么要规范产品交付流程?
  优秀的过程不能保证结果,但是,没有优秀的过程,要求产出好的结果是难上加难,或者说几乎是不可能是事情。
  就好比学习,对大多数同学来说平时不用功考试临时抱佛脚,能考出好成绩那才叫见鬼。
  对一个研发团队来说,如果没有规范化的流程,想要出成果,想要交付优秀的产品 天方夜谭!!!
  个人认为:一个适合团队的,规范性的交付流程是持续交付优秀产品的必要前提条件。
  (PS:可能有同学会和我扯敏捷开发,别急,在最佳实践部分,咱们好好聊聊~)
  2.2、什么是最佳实践?
  首先,个人愚以为:适合自己的,才是最好的;适合自身团队的才叫最佳实践。
  其次,我想写写大部分同学说起敏捷开发所想到的,嗯!如下观点很常见:
   ... ...
  查看更多精彩内容,请点击下载:http://www.51testing.com/html/39/n-3723839.html
  2.3、如何把握流程中的关键点?
  (这部分和同学们聊聊从需求到发布各个阶段,作为测试负责人应该注意的事项,仅做参考)
  2.3.1、需求介入
  1.1、产品需求需列示以下内容:
  1) 需求提出单位(内部需求/外部需求,外部需求需注明客户全称、行业),用以帮助PM了解需求的行业背景和可能的业务逻辑;
  2) 客户的联系方式(如有),用以PM回访需求提出方,挖掘需求背景;
  1.2:项目kick off会议之前项目经理预估项目时间,需要在项目FBRD(最终用户需求文档)评审阶段给出项目周期时间段预估,PM在项目kick off之前申请好开发,UI,测试资源组成项目组。
  1.3:测试负责人跟进kick off(项目立项) 之后的项目所有流程,其中当概要设计评审之后需给出一份完整的带测试策略的测试计划。
  FBRD必须包括以下内容:项目背景,项目目标,项目详细功能及Demo。
  2.3.2、项目计划
  1)统一书写成甘特图,放置在石墨文档上(创建项目名称目录而不是版本号)。
  2)项目计划包含内容:时间deadline,开发/测试资源。
  3)计划变更
  a)如发现影响项目时间或任务安排的一定要在计划和进度安排上体现出来。
  b)发生偏差但不影响里程碑点和项目上线时间的情况下,无需调整进度安排文档,但需要做相应的跟进。
  c)生较大偏差,影响到里程碑点或发布计划的情况下,需要调整进度安排文档,由项目经理负责跟进项目上线计划。
  4)计划变更影响到项目里程碑日期的需要邮件通知项目组,抄送CTO
  2.3.3、测试计划
  1)测试范围及测试策略是测试计划中很重要的部分 
  但去除一些无用的部分,如测试退回后工作安排等
  2)测试进度安排
  如较小的项目直接用很简单的表格显示关键时间点即可,稍大的项目,测试工作量超过10人日或者测试人员3个及以上,需要进行进度安排
  注:小型测试项目定义:工作量<=10人日,不涉及跨产品线,参与人数3人以下(不含3人)
  3)测试策略
  增加可选项:项目中测试的重难点,最耗时的部分的测试策略
  4)人力资源
  去除非测试的其他角色,项目较小如一个人的时候可以不用填写,角色较多可进行填写
  5)环境资源
  直接写上负责人及环境绑定即可,公共环境作上标记
  6)环境部署方案
  有特殊情况的可以写一下
  7)风险列表
  注意要精简,不是越多越好。
 ... ...
  查看更多精彩内容,请点击下载:

版权声明:本文出自《51测试天地》第四十八期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • mg1207
    2018-1-24 08:54:44

    适合自己的,才是最好的;适合自身团队的才叫最佳实践。

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号