流程与标准
你身边的人员会这么抱怨吗:
我们一报Bug,开发就说用户根本不可能这么用,还说不知道我们怎么会这么测
送测单里根本不写测试范围或者寥寥几句跟没写一样
开发调整设计从来也不告诉我们
为什么产品经理和UI只和开发讨论需求变更?
为什么发布计划里不给测试预留测试时间?
为什么开发写完代码测都不测就扔给我们?
为什么客户那里发现了问题老问是谁测的、为什么没测出来?
测试老是一声不吭就把Bug优先级设置为Major
测试总是把大量时间花在用户根本不可能用到的功能上
测试分不清哪些什么是重点,你给他说他还老是一堆道理这了那了
测试提的Bug,现象描述也不准确,重现步骤也没有,有的根本就知道是不是误操作
测试老来打断我,一会儿叫一下一会儿叫一下,根本没办法专注开发
jira上的Bug重复率太高,一个问题提N遍,难道就不能合并一下?
测试发现Bug,一声招呼都不打就直接告诉老板了,搞得我很被动
测试就是专门挑刺儿的,有劲不往正地儿使,你倒是测测用户常用的功能啊
那么简单的Bug都能流出到用户那里,真不知道测试怎么测的
开发老嫌测试报告数据不漂亮,逼着我们调整
Ok,如果你身边的开发和测试从来没有过类似的问题,那很好,恭喜你,看来你们的团队人nice协作也很顺畅,棒棒哒。
假如你身边充斥着这样嘈杂的抱怨,那说明什么呢?开发、测试、发布这一套流程有问题?还是团队缺乏明确的指向来引导大家向积极、有效的行为靠近?
流程和标准总是有待解释的,再好的规则,歪嘴和尚也能把它念斜……
我们随便挑一个问题吧:为什么开发写完代码测都不测就扔给我们?这个问题普遍存在,它反映出的是程序员和测试人员的工作边界难以界定的矛盾。
程序员会说,我都测一遍,还要你们测试做什么?
测试会说,你测都不测,冒烟都过不了,有没有责任心?
程序员说,要我写测试用例,搭各种环境,遍历各种正常、异常逻辑,我还有没有时间写代码了?
测试会说,我们测试是垃圾桶吗,什么烂玩意儿都直接扔给我们,我们的时间就那么不值钱?
开发会说,测试本来就是干这个的,你不测谁测?
……
像这样的问题,能制定一个标准,说明什么样的逻辑开发要自测覆盖什么样的逻辑可以交给测试来测?能画一条三八线吗?
不能。所以,这个时候,靠谱的一线管理者就显得很重要。如何创造性的发现适合团队的方法来让大家顺畅地协同工作,比标准、制度更重要,这往往依赖于技术管理者的能力和团队成员的意识。没有普适的方法,只有适合这个组织的、此时此地的策略,加油吧,在战斗中摸索出最适合当下的道路。
那什么是靠谱的一线管理者呢?
温伯格《成为技术领导者》一书中对领导职责的定义如下:
领导的职责就是创造这样一个环境,每个人都能在其中发挥出更多的能力。
如果一个技术领导带领的团队,大部分人都能专心做与其能力适配的事情而不用整天泡在与本节前面所列类似的问题里,那他基本上就算是比较靠谱了。
至于像给测试预留多长的测试周期、调整设计要不要通知测试、需求调整要不要测试参与等问题,合理的流程和标准可以起到很大的辅助作用,技术领导者只要依据合理的制度,引导大家有效参与,就可以化解。
态度
场景一:
测试MM对阿猿说发现了一个Bug。
阿猿矢口否认:不可能,绝对不可能!
MM:真的有Bug,你过来看一下!
阿猿:我都不用看,在我这儿好好儿的。
MM:你来看一下嘛……
阿猿:看什么看,肯定你环境问题,动什么东西了吗?重启了吗?
场景二:
测试MM想在jira上提个Bug,先在QQ上对阿猿说:有个Bug,你过来看下?
阿猿:忙着呢,焦头烂额的。
MM:一分钟都用不了,你来看下吧。
原文转自:http://www.testwo.com/article/641