灌水 我对版本的理解

onesbyones · September 15, 2019 · Last by 育才小学扛把子 replied at September 27, 2019 · 1509 hits

我对版本的理解

起因很简单,因为要在节前上线一个版本,而且是必须上线(无论如何、死都要的那种😂 ),为此研发同学从下午5点开始部署,直到晚上8:30还没搞定,其中缘由有网络、服务器等问题,这里就不细细的吐槽了。此时此刻的我真的想吟诗一首表达我内心的愤懑与感慨(在部署上线的过程中还因为多次的催促受到了研发大佬的批评和教育😅 ),闲话不多说下面谈谈我对版本的理解,希望能看到此文的同行各抒己见,小弟不才愿抛砖引玉。


首先来谈谈版本

我理解的版本就是在固定的时间节点,会解决哪些问题,需要测试研发评估版本的影响范围,从而创建一个版本节点并发布上线,最终会给用户带来什么样的影响。

很遗憾自从我进公司到现在,这里从始至终都没有版本这个概念。不对应该是没有子版本的概念,一味的都是以项目来命名的版本,而不是如在某某分支解决了几个问题而发布一个版本。

难道这种处理方式对研发没有影响吗?至少觉得对测试是有影响的吧?比如线上出现了生产问题,在测试环境复现的时候我们不应该是首先从一个大版本开始入手,然后再从大版本中的小版本开始一个个复现最终找出这个bug的源头,最终定位这个bug是出自研发改出来的bug、测试漏测的bug、测试未执行的bug???(黑人问号),这只是一方面。

另一方面版本的管理带来的好处就是,研发、测试、项目经理都能知道哪个版本的bug少、稳定性高,在我们测试需要做回归测试的时候不仅仅是功能性的回归,更需要针对性的回归。

接下来再讲讲上线

  1. 不是为了上线而上线

为什么要说这句话?因为发现我们有项目经理这个角色,这个角色真的是让我头疼啊(这里不是吐槽项目经理,请轻拍)。

恕我头脑简单、四肢发达,难道我们测试对测试的工作量评估、研发对需求的拆分实现排期都要按照项目经理的要求而压缩吗?

oh fuck!!你说上线上线就上线

oh shit!!解决不了的问题你说下个版本就下个版本,难道我们测试、研发对需求的理解、实现、难度会不了解??

大家都说测试是产品质量最后的一道防线,在以前待过的公司中只要测试、研发发话上线有风险并给出风险评估则不上线。其实不然,我觉得做一个产品至少每一个参与者都是一道防线。任何一位参与产品建设的都可以提出自己疑问、建议,不只是简单的理解产品就是研发实现、测试来保证质量、运营和客服的需求反馈、产品经理对需求的升级改造等等,就好比自己的孩子(当然谁都希望自己的孩子自己管)自己管不好的时候当然就会有别人(亲戚朋友、老师、甚至陌生人)来替你管,只要你能虚心接受我相信你的孩子会越来越优秀。

  1. 上线的原则

这个话题有点大了,相信互联网公司都有一套自己的上线原则,比如节假日不上线、周末不上线等等。为什么要给出上线原则?

一个是上线后万一出现了生产上的大问题公司就需要投入人力去复现、定位、解决问题,这样给用户的体验是不是极大的打击呢?万一是地推的过程中发现我靠,他娘的注册都不行怎么办,是不是啪啪的打脸了(当然这种几率非常低)。

还一个就是有原则就可以规避很多不必要的问题。比如像楼主这种不想加班的狗

  1. 上线的环境预估

这应该是最难的一种吧,虽然现在有预生产环境,因为我们不知道环境究竟会发生什么。除非遇到电缆被挖断了之类的,这就尴尬了,楼主在这一块经历的比较少就不多说了。

最后

好了,吐槽到此为止,能说到这个份上我的心情也平静了。另外插一句公司(平安某子公司)组织架构调整,遗憾的是我被划分到其他的测试团队,我敢保证不是因为技术能力原因(话不多说。。),还是希望能找到一份稳定的(毕竟快要当爹的人了),最好还是平安的子公司(要求太高了😂 )。多谢多谢

共收到 17 条回复 时间 点赞

谈版本

这个,我也是深有体会。原来的版本概念很强,不管后端还是apk,版本都是必须带的。直到我到了现在的公司、、一切都变得不一样了,因为现在发布简单了吗,比如丢到tomcat里、比如mvn tomcat7:run这些发布模式,基本都是在产品里面没有版本概念的,版本的概念也只出现在需求和代码分支里,这个跟以前大不一样


谈项目经理


项目经理是普遍存在的,而且我感觉多数公司的卡里程碑都是由项目经理拍板。。(至少我们公司也有这个杯具)


谈发布


这个应该是要分BUG级别的把,有些东西比较严重,必须得这次发布改完,一些需求型和优化型的可以让产品、 研发、测试、项目经理协商后决定需求排期还是不予修改


谈吐槽

团队之间的职责,在没有交集的情况下,沟通成本是很大的。很多团队做的决定,对合作团队都是一种折磨。
吐槽一下前段时间项目管理部的决定:
引入TB之后, 工时系统为了达到85%这个指标,要求请假或者调休人员,也要在工时系统录入。举个栗子:你周一到周五请了一周假,到周五的时候,你需要去TB上填个任务,这个任务是请假,然后任务耗时 5 * 8 =40 小时。
o my god!!! 后来被各界喷,最终花了一周时间改掉了这个方案。


PS: 你的排版,哈哈哈。嗯。!!!

我们的项目经理跟你那一模一样,过需求的时候他拍板哪个哪个下版本在上,弄的产品也是一脸无奈。所以很无语,到底这个版本控制是谁说了算呢,我个人感觉项目经理参与的太多了

领着不如开发的工资,干着比产品忙的多的活儿,操着最累的心;
大多数如此

通过楼主的表述,上线部署问题等,建议团队引入Jenkins来管理上线,虽然说前期会很麻烦但是配置好了,基本是一劳永逸;
另外通过Jenkins的引进,版本的问题也有了保证,推动起来个人感觉帮助还是蛮大的;
至于测试在团队的地位,除了花厂的测试地位很高外,其他的估计都认为测试就是花钱的团队......

除了为数不多的几个大厂,大部分企业还是处于作坊工作模式

Crisimple 回复

哈哈,一刀见血,很明显作者原来就是花厂的。😂

好奇问下,花厂是哪家?

陈恒捷 回复

华为

陈恒捷 回复

嗯嗯嗯,楼上说的对,名字来源于Logo吧(我猜)

老孙请为我保持一点神秘感😂

hellohell 回复

同感😀

hk 回复

有这个角色我不反对,但左右太多我就不爽了

Crisimple 回复

公司有一套自己的devops,但还是有那么多不可控的因子

你们公司流程比我们正规多了,毕竟一个花厂出来的人都在一块

最近不是在说深圳平安那边。优化20%。

回复

科技的不清楚啊,大佬

小编说的非常对!
所以我都是时刻准备战斗(视线锁定开发leader、产品经理、项目经理的下巴、太阳穴等位置,不爽的时候随时出拳),所以,我的测试进行的还算比较顺利!!!
祝小编找到心情舒畅的工作

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up