为了项目的进度, 开发部和测试部的难免要一阵子一阵子的死磕.
比如前段时间BBIT开始一半的时候, 因为测出来一个基站在启动时各个单板进入稳态时间不同, 而相关代码又没有交付的情况, 导致近一半的用例阻塞. 会议室里面火药味到处弥漫.
"这个问题严重阻塞测试进度, 必须今天攻关解决. 下班前没有定位出来, 晚上加班攻关! " 测试的头儿说, 底气十足的样子.
"这个问题的确很严重, 但是难道就完全没法测试下去了吗? 所有的用例都包含这样的场景吗? " 开发的头儿为自己找后路, 这样责任就不用完全压在自己兄弟身上了.
测试头儿继续逼迫, "是的, 剩下的用例中全都包括这个场景, 你让测试怎么进行?!! 不信咱们把testcase拿出来过一遍?!! " 尽管从来没有看过BBIT的测试用例, 测试头儿依然底气十足一口咬定这个严重的问题会导致测试阻塞. 因而他知道, 虽然他没有看过testcase, 但是开发头儿肯定从来没有也不会现在就来审核一遍余下的.
果然, 开发头儿心虚了, "好吧, 这个问题今天即使加班到12点也必须搞出来". 如此一来, 他只能向下面的兄弟施压解决问题了. 只是后来从我这了解到其实还是有部分用例是可以继续进行的时候, 他才后知后觉.
再比如, 因为头天合入了新的代码, 开发的兄弟没有评估代码对系统的影响, 第二天取版本来测试, 发现小区都无法建立了, NODEB和RNC之间IUB接口看不到任何消息. 我当场断定是昨天合入代码引起的问题, 如果这样, 按原计划覆盖IUB口往下测就不可行了. 看看开发的兄弟是如何来应付测试部的吧.
1) 一口咬定是RNC的问题, 解释说合入的代码必须与配套的RNC进行联调测试. 并强调说这两天计划拉通RNC的人一起搞这个东西;
2) 下午会议室过进展, 开发头儿坚持绕开接口覆盖进行测试, 并口口声声称为测试着想, "RNC的联调版本这么不稳定, 一旦升级RNC, 那么下面所有的NODEB测试都将遇到不可预知的问题, 对测试冲击很大!!!", 并且还反过来问, 那么多个版本使用一个RNC, 又不是咱们一个组, 这样的风险你们承担得了吗?
好家伙! 本来自己出来问题要急需解决的, 避重就轻, 把其他的风险放大, 让自己的问题不突出, 从而给下面的兄弟赢得解决问题的时间. 真想当场也横了, MD你别管我升级RNC的风险, 那个风险我们自己承担, 你先给我一个可用的版本再说!! 这样他们的阻塞问题就被列到最显眼的位置了. 可以俺小兵一个, 以后还得继续混, 不敢发作啊.
事后定位结论表明, 小区无法建立跟RNC一毛钱关系都没有, 完全是项目组方案实现的问题. 而所谓的跟RNC搞联调, 只是在嘴皮上过了一下吧.
我的角色其实尴尬, 既是半个测试人员又算是半个开发人员, 下午过进展的时候需要把进展和困难向上反应, 这边的老大要把阻塞性问题完全暴露, 早上又得和开发的兄弟过当天的安排, 他们又会委婉提示向上面反映太严重了, 让他们压力很大. 我则感觉夹在中间, 左右不是人啊.
再说说这两个头儿. 测试头儿协调能力极强, 口才也不错, 技术就差不多忘光了. 对版本质量有较高责任心, 对于"部门墙"现象十分反感. 开发头儿头脑运转十分快, 技术能力强, 思维反应极快, 会随机应变在各种场景下为自己争得有利位置.测试头儿最不爽的地方在于, 对于本身责任主体在自己但是却可以通过PK的方式让别人(甚至是来帮助自己的人)分得一部分责任的人, 与其共事是让他很不屑的. 现实很骨感, HW里面的基层主管目前都是这样的人, 而且风气有越演越烈之势. 类似开发头儿的人在越来越多, 对其下面的兄弟来说, 可以更好抢得资源, 更容易的做出绩效, 因而也是认可这样的基层领导的. 但是从公司的层面来看, 这并不是一个好的兆头. 因为大家都在为自己抢山头, 好功劳, 厌恶承担责任, 部门与部门甚至是同部门之间的协作成本越来越高, 对公司的总体发展不是推进作用, 反而是阻碍了发展的步伐.
就拿这次BBIT来说, 这个本身是有开发进行主导的, 责任主体应该在开发, 测试部只是起到协助的作用. 测试部为了防止过多的问题遗漏到后端, 不遗余力伸手向前帮助开发的兄弟拦截问题, 希望能够达到双赢的目的. 可偏偏人家把你当枪使, 自己的兄弟干着计划外的事情, 测试的兄弟加班加点测BBIT内容, 遇到问题时才过来定位. 上面催着测试进度, 测试主力就我一个人, 遇到问题还定位个2/3天, 测试头儿看不下去了, 于是介入, 有阻塞性问题就全员抄送短信, 让其感受一下压力, 督促定位效率.
这样, 才磕磕碰碰BBIT往下进行.