职业经验 测试开发之路--让我们把产品质量变得更好 (测试人的转型探索)

孙高飞 · 2016年12月03日 · 最后由 BugBear 回复于 2019年09月24日 · 129 次阅读

前言

我们应该都有过这么一段迷茫期,不论我们设计多少测试用例,编写多少自动化测试脚本,执行多少测试计划,产品质量依然没有按照我们想的那样发展。原来开发延期的依然延期,原来提测 bug 多的依然多,线上漏测的依然漏测。我们貌似都已经习惯了这些场景:延期,压缩测试时间,需求不对,部署事故,漏测。后来我们知道了 Google 的工程生产力团队,后来我们知道了 CI,CD,Devops,后来我们知道了光靠 QA 来保证质量是不行的。。。。越来越多的新概念冲击着原有的理念。很多的 QA 大部门被裁撤,我们想着不要被淘汰,所以我们要改变,要进化,要去做以前没想过的事。

以质量为中心,发散式工作

之前我说过这种理念,我希望不仅仅局限于测试行为这一条路。任何能提升质量的途径我都要尝试。上一篇帖子里我也写过这样一句话:

我开始了各种各样的,无所不用极其的野路子之旅来提升质量,提升生产力。

提升产品质量有两种路子,一种是测试行为,这是最直接的方式。这一点我们研究了很久我不多说了。只是我们发现了很多的问题。我列几个常见的

  1. 如果 RD 开发延期了,压缩了测试时间。我们有足够的时间去做测试么?
  2. 如果 RD 提测的质量不好,全是 bug。我们有足够的时间把 bug 都修完再重新测试么?
  3. 如果系统过于复杂,过于高科技,有些东西我们不测不了。RD 能够自测么?
  4. 如果都开发完了,产品才发现与需求不符,我们有足够的时间重新来过么?
  5. 如果团队每个人都因为这些原因疲于加班。我们还有时间创新么?

我们现在面临了一些我们控制不了的风险,例如开发延期,提测质量差。也许以前我会说那是 RD 的事,我不 care。但是最后加班加成狗质量还上不去的状况就会找上我。前面我说要改变,所以我们得做点什么,把技术能力转变为生产力,提升团队所有人的效率。于是我们开始了探寻第二条路子去解决这些问题。他是软性的,是间接的,是以提升生产力和效率的方式间接的解决上面我们遇到的风险。

技术能力转变为生产力

我以前写过 CI 的文章,详细到每个分支的策略是怎么制定的,写过环境管理的文章,详细到开发,测试,预演,预上线环境每一个都怎么做的。写过单元测试架构,详细到 Jenkins 上每个配置都怎么设置的。我还做过一些别的零散的,运维的事只不过没写出来。这些都是我做过的努力。我发现要想让其他人对质量负责,就得给他们提供更简单的方式。例如:

  1. 我们希望 RD 能够自测,那我们就得有简单的方式让 RD 自测,太麻烦太耗费时间是不行的。
  2. 我们希望 RD 不拖延进度,那就别让琐碎的环境问题拖延他们。别让需求不明让他们返工。
  3. 我们希望产品人员更好的预演产品,设计需求。那就给他们个保持代码更新并稳定的环境让他们使用。
  4. 我们希望运维人员更好更快的部署产品,别再部署时期出问题。那就严格的按运维的标准去编译,出包,部署,测试。保证到了运维手里的东西,一定是可靠的。
  5. 我们希望运维和 RD 有更多的时间提升架构,监控,运维自动化。那就让他们从琐事中解放出来。例如我承担了除生产环境之外的一切环境部署自动化管理。所有模块的自动化编译出包的工作。

说个详细点的例子。也许对大部分团队来说,自测和联调一般不是什么问题。搭建个环境还不是分分钟的事。但我们团队不是,业务复杂,架构复杂,配置复杂,多语言构建。每个模块的编译和部署方式可能都不一样。靠各自模快的 RD 一起拼是拼不出几个环境的。大家在一个环境上互相踩踏,互相影响。 我们期望 RD 能从整个产品的角度来设计,来自测。希望除了单元测试以外他们能从 UI 上从产品的角度测试。但没有一个专属的他个人的环境让他随意破坏那是绝对不靠谱的。所以我们才提供了一套以 docker 为基础的自动化部署开发环境的机制。注意这里是开发环境,不是测试环境。有什么区别呢,区别是测试不需要编译环境,不需要源代码,测试要模拟真实环境所以测试是按产品环境的结构部署的,所以测试只需要部署包。 但开发不是,它希望这个环境能供他随意折腾。可以随意编译源代码,可以随意在环境中开发。那是他的实验室,怎么搞他说的算。
所以我们给开发人员的环境都是完整的编译环境 + 部署环境,有源代码,ssh,mysql client,git client,hadoop client,spark client。定制了各种方便的脚本拉代码,重启单个服务,重启所有服务等等。

同样,为了让 RD 能自己触发回归测试。我们在 Jenkins 上配置了相应的 job,一个按键就能让我们的自动化测试项目跑到他的环境上测试。测试报告里有每一步骤的日志,失败截图,环境信息。后来 case 越来越多,运行越来越慢,一套测试下来 2 个小时,RD 等不起。我们就分布式处理,从 2 小时降到了 20 几分钟。后来用这个 job 的 RD 越来越多,排队时间越来越长,所以我们计划着加资源,加机器。不让 RD 排队等待。

于是我们的提测质量越来越好,因为 RD 自测的越来越好。

与人方便就是与己方便。

也许以前我会觉得这些事让他们自己操心去。但后来我发现,只有我让他们能开心的测试了。我自己才能开心的测试。否则一定是提测阶段我痛苦的像条狗。恩,与人方便与己方便。

  • 我们提升了 RD 的开发效率就能让他们更快的完成产品开发,我们也有更多的时间测试--与开发方便就是与己方便
  • 我们让 RD 自测的更快更方便就能提升了提测质量,减少我们的工作量--与开发方便就是与己方便
  • 我们给产品人员的预演环境做蓝绿部署,永远有最新的稳定产品给他们用。让他们及时纠正需求,更好的设计产品,减少返工--与产品方便就是与己方便
  • 我们按运维标准承担了所有模块的编译出包的自动化,让运维在何时何地都能一键拿到他们想要的包,让他们更快更好的部署-- 与运维方便就是与己方便
  • 我们承担了除产品环境外所有环境的部署和维护自动化,让所有人都从这些破事中解放出来,专注自己的事情让产品变得更好-- 与人方便就是与己方便

总结

恩,这是我想到的方式,它没什么名字,没什么固定的套路。它就是一个思路,一个用自己的技术去解决团队中一个一个的痛点的思路。也许在你的团队中,我碰见的这些问题都不是问题。但总有属于你自己团队的问题。找到它,解决它,别让他们成为影响你产品质量的根源。我受谷歌影响颇深,所以路子十分像他们的工程生产力团队,但略有不同,我期望能由我们来辅佐甚至打通 devops 的路,说不定以后会有一个新的职位诞生,例如叫什么 devops 工程师,团队工程化工程师等等。产品质量已经不是单打独斗的天下了

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 27 条回复 时间 点赞

互相配合才能搞好质量但是配合哪有那么容易,天天就是在产品和开发之间跑。自己都快成为产品了,能安稳坐一会的时候自己也要搞自己的自动化。半个产品半个开发工资没有一个赶上他们。尽管如此为了产品质量不断的跑来跑去。

#1 楼 @gz19891020 这个是比较看团队的。不同的团队的发展方式是不同的。有些团队的方向是工程自动化 devops 方向,各个职位界限没那么清楚,崇尚极限编程,不喜欢条条框框的死规定扼杀团队的创造力,如我们团队是这样的。 有些团队的方向是流程严谨化,管理规范化,崇尚把所有事都规定一套流程进行把控,如一些传统金融公司。 我个人觉得现阶段互联网还是倾向于前者发展的

感觉已经不是单纯的测试了,会参与部分开发,还得给客户和实施人员解答疑问。尤其问题多的时候,更是忙于应付,没时间静心专注的思考用例,写代码了。这样有点累啊

#3 楼 @jphtmt 所以我觉得这种模式依赖高度的工程自动化。免得我们在琐碎的事情上疲于奔波。 就像我说的,设计用例,执行测试是一种提升质量的路子。 这种以提升生产力和效率的方式是另一条路子。 倒不是说会参与开发,产品的代码还是开发人员去写的。 我们要编写的代码是为了提升工程自动化。以前我们是把测试用例自动化。只是现在除了测试用例的自动化外。还要把工作中其他的东西也自动化起来。 同时推进和完善更好的流程,培养团队中的 RD,产品,运维都参与到质量保证的过程中来。虽然这种方式不比测试行为来的直观。 但效果往往是非常好的。 还有就是,我觉得即使在测试中,我们也有我们的局限性。我们想到的 case 开发人员想不到,开发人员想到的 case 其实我们也想不到,因为我们分别站在了不同的角度分析产品。我们不理解底层实现。那么有谁比开发出这段程序的人更了解它,更适合测试它的呢?所以,想让他们也参与到测试中,就要简化他们的测试成本。这就是我们搞工程自动化的目的之一了。

你这样的应该是研发 LEADER,老板最喜欢~想做到还真不容易。

干的漂亮

—— 来自 TesterHome 官方 安卓客户端

这才是正规路子,将琐碎的事交给 “自动化” 留出更多的时间专心做好 “本职工作”!👍

#5 楼 @yangchengtest 额,其实不是啦,我代码比较菜,研发的 leader 要更有水平的。 我们做的有点像谷歌的生产力团队

@ycwdaaaa 哈哈,断句错了。。。
我的意思是老大应该都喜欢你这样的~
加油吧,与公司共成长~~~

#9 楼 @yangchengtest 恩,大家一起成长 哈哈哈

点赞!感觉这是未来的 QA 之路,工具化开发是必然

能解决问题的都是好路子。

能做到这样很不错,不过我觉得如果不是自己全包,因为这样要求确实很高。而是能让各自人员一起协调把流程做好会更好,这个不是靠一个人能打通整个流程的,更多需要整体都有这个意识,然后能去支持这个事,当然这事由测试发起没什么不好的

#13 楼 @tcat 恩是的,只不过一开始的时候,可能先由某个职位开始做这个事情

赞一个

和我部分经历比较相似,曾经成功地改变了整个部门的质量文化意识, 研发自测,代码静态分析, 单元测试。。。(现在还记得我去给研发培训如何写单元测试代码的时候,大家看我的眼神)而现在越接近前线,越能发现产品之路的各种无奈, 唏嘘。。。

#16 楼 @pingcredit 是的。。。我也是碰上了一个好团队。 换了另一个团队,我估计我也是感叹英雄气短的命了

#11 楼 @pcccheng 我也是这么想的

#17 楼 @ycwdaaaa现在有没有创业的想法呀,可以出来交流一下呀

这个是不是项目经理。。。

#20 楼 @unclex 不是啊。。。。我只负责想办法提高效率。。。

#21 楼 @ycwdaaaa 我总觉得这些问题是项目经理应该去想的,只是项目经理只是负责协调,楼主直接给干了....😂

#22 楼 @unclex 国内的项目经理一般更关注项目进度方面吧~~ 像 CI,CD 环境管理这些的他们貌似不关心。。。。

干的漂亮,继续加油!

以前测试要用好工具,现在感觉变成要做好工具。大势所趋

zy 大家怎么认为 QA1.0 到 QA2.0 是什么样的转换? 中提及了此贴 09月04日 07:15

天天找测试数据,三方联调,三方修复问题几个小时,几天,然后前端的瓜皮乱传,验收测试过不了,各种问题 哪里有时间做啊,羡慕楼主

思想很好....收藏了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册