小公司测试人员的出现,一方面是为了适应产业的发展需求;另一方面也是为了提升产品质量、加强公司的竞争力,保证公司不被市场所淘汰。但这样一来也就直接增加了公司的管理、人力及资金成本(测试人员的薪水虽然相对比开发人员低,但也是一个不小的数字);最后因为小公司制度及管理的欠缺,暴露出很多问题,往往直接或间接的导致开发、和测试的不和谐,这也是我们今天讨论的话题。
这个是缺陷!这个不是缺陷!
对于是不是缺陷这个话题往往被很多人很厌恶,大家都厌恶谈论这个话题,因为谈及他往往令人不愉快,但很多的时候他却在我们身边真实发生。
测试人员认为某个情况是缺陷,但开发人员认为这个不是缺陷,而争论具体的情形在需求中也没有明确的描述,公说公有理,婆说婆有理,说不清了!如果只是开发、测试对于工作上理解的差异还好,但往往争执由此开始,矛盾也就由此产生,不和谐的气氛由此埋下种子。
出现上述的情况的原因有几种:
① 公司在没有对原始需求进行评审、整理、并书面化形成文档(需求也是需要测试的,这点很重要)
② 公司完全没有需求这一档子事,完全在没有需求的情况下进行开发、测试(走一步看一步的情况)
③ 开发、测试对需求的理解存在差异(开发、测试没有良好的沟通)
④ 需求本身的定义存在二义性(与①相关,没有对需求进行测试)
⑤ 个人的性格与情绪
问题出现了,如何解决?
不管是开发人员还是测试人员:
① 思想要保持统一的认知,我们所做的都是为了公司,为了我们的产品,任何的争论都不存在任何的个人感情与感****彩
② 出现问题时,都要先从自身找原因,很多时候往往是因为我们自己的简单思维而导致,所以,当你在工作中对某个事情存在疑问时,多问自己几个为什么,再向他人请教,或回复他人
③ 我们讨论的只是问题,不直接关系到个人的工作能力与工作作风,人非圣贤,有错就改,并不失面子
当无法确认是否为缺陷时,测试人员:
① 发现无法确认的缺陷时,如果有其他的测试人员可以征求其他测试人员的意见(同行评审,同行评审往往能发现80%的问题),如果彼此都认为此应该是缺陷时,可以找到相应的开发人员进行讨论。如果开发人员同意你们的意见,则可以提交缺陷,着手修复(如涉及比较重大的业务逻辑时应该要向上级汇报,申请确认)
② 如果开发(甚至多位开发人员)对缺陷不认可时,我们可以向测试组长(或测试总监)请教,请求对缺陷进行确认,如果领导和开发人员都认为此不是缺陷,并且无修复的必要时,我们可以保留我们的意见,同时记录下此缺陷(到后期如果有时间再进行评审)
③ 如果测试组长(或测试总监)也认为此是缺陷,但在无论如何解释的情况下开发人员仍不认可时,我们可以由测试组长(测试总监)与开发项目经理(技术经理)进行交涉、确认,最终确认缺陷情况
④ 如果有必要,我们可以邀请开发、测试、需求(如果有)、产品(如果有),甚至技术总监(CTO)进行开会(需求或缺陷)评审
⑤ 最后,也是最重要的一条,不管是开发,还是测试,都不要越级汇报
另外,有部分许多公司把缺陷作为开发人员和测试的员的业绩指标,在某些大公司这些确实是在施行、也是可行的,但在中小型公司或管理达不到CMMI4或5的情形时,我个人不赞同那样的作法。因为你不是他,你就做不到他……
而你那样做产生的直接结果就是让开发和测试从此不和谐,彼此勾心斗角,何必呢?!
最后,要相信办法总是比问题多,每一个问题都有至少一个解决办法!