• 2008-07-12

    Dev聊QA

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/24621087.html

    有一天,我们的QA Lead让我谈了谈关于QA的看法,之后,对我说,我觉得你可以在QA Community活动上站在Dev的角度讲一些对QA的理解,这篇blog就是便是我所讲内容的一个总结。我知道,这绝对是一个费力不讨好的话题,因为在很多的开发人员眼中,自己是建设者,而QA是破坏者。所以,让一个开发人员在QA面前,尤其是在一群QA面前,对QA品头论足,是非常有难度的。

    所以,我讲一些自身的经历。

    说到QA,首先想起的便是测试。从我刚开始接触编程的时候,我就知道测试是必需的,否则,怎么能够知道自己写的程序是对的,就像考完试需要检查一下卷子一样。那个时候,除了了一些最基本的程序之外,我还写过一些有界面的Windows程序,于是,关于测试,留给我的第一印象就是点这点那,到处乱点。

    工作之后,虽然知道了QA这个角色的存在,但很长一段时间都没有和QA在一起工作过,所以,客观的说,那段时间一直觉得QA是一种没有技术含量的工作。直到有一天,一个长时间没有QA的项目,能够卖钱了,领导觉得有必要提高产品质量了,于是派了个QA进到项目组。他是我后来的一个非常好的朋友,当时是部门QA方面的负责人。

    我们的项目是一个服务器的应用,所以,从外部的角度来看,主要就是一个发起一个符合我们用到协议的消息包,然后看看得到的应答。其实,我一直对这个项目很有信心,因为它已经在一些地方上线运行了,而且从当时的情况来看,我们还算舒服,没有经常性的被客户从睡梦中叫醒。

    QA进行的第一个测试就是发了空消息包,结果系统报错了。我第一反应是“你怎么能这么用”,是的,感情上有些接受不了,甚至有些气愤,我一向很有信心的代码,就这么非常轻松让人给弄崩溃了。稍微平静了一下,我觉得其实也没有什么大不了的,毕竟是自己的代码中真的有问题,所以才让人抓住。

    经过一段时间,我越发深刻的认识到QA在项目中的作用,虽然我们在写代码的时候,已经考虑了很多的异常情况,但总还是有很多我们意料之外的情况被QA发现,随着项目的进行,发现和修改的bug越来越多,我们对自己的项目也越发有信心了,不过,回想起之前的代码,那样的产品质量也在线上运行了好长时间,多少有些后怕。

    这时QA在我心目中,已经不再是那个没有技术含量的工种,我对QA开始充满了敬畏。真的是敬畏,尊敬和畏惧并存,敬的是他们总能给产品质量带来提升,畏的是他们总能不断在自己感到骄傲的代码中发现问题。和我们的QA聊过几次才知道,原来QA的工作也分验证性和破坏性的,原来他们的工作也是需要缜密思考的,原来他们的工作也是需要很详细的计划。突然发现自己曾经对QA的理解,基本上完全是门外汉的水平,误解是很让人郁闷的,就如同每每我说自己是做软件开发的,家里的邻居通常会说,什么时候有空帮我们家装台机器吧!

    后来,我和这个QA兄弟一起跳槽到了另外一个部门。他的工作范围本质上说还是在QA的范畴。由于这个部门做的是偏研究性质的,所以,他的工作名义上称为验证,主要是看部门研发的算法有多大的进步。最开始的时候,一般是一周做一次验证,主要的原因就是因为运行加上总结需要很长的时间,于是,这位兄弟想办法开始把一些工作自动化,随着自动化程度的提高,验证周期也逐渐缩短,后来,我离开了这里,据说,现在这个自动化验证系统已经达到了很方便的程度,只要敲一下命令,它会自动部署到几台机器上运行,然后,搜集结果产生报表。就这样,原本一周一次的过程,简化到几乎随时可以做。如果让我选择这个部门产生出最有价值的东西,我会把票投给这个自动验证系统,甚至超过了部门研发的算法,只可惜养在深闺无人识。

    为了讨论这个关于QA的话题,我问了自己一个问题,为什么QA能够想到我们开发人员想不到的地方。我自己给出的答案是,二者站的角度不一样。开发人员通常是站在实现的角度,所以,通常我们会更多的关注如何把这个功能做出来,也就是规定动作,而QA是站在用户的角度,如同我们自己使用软件通常是不会看软件使用手册一样,QA总会用到一些规定动作之外的用法,也就是自选动作,所以,二者之间必然存在一些差别。既然存在差异,QA发现一些自己无法发现的东西。

    如同我之前对QA有一些误解,想必也有很多开发人员对QA也存在一些误解。所以,对于QA而言,增加与项目成员之间的沟通应该是一个很好澄清误解的方式。沟通,对于任何项目都很重要,不仅仅局限于开发人员和业务分析人员之间,QA也应该是这个沟通环节中重要的一部分。只要有可能,QA都应该是从项目最初介入,这样一方面保证了QA与项目成员之间在一开始就建立起良好的沟通环境,另一方面,他们的经验和技能可以保证大家在最初的阶段就注意到一些问题,正如我们QA Lead在Agile China所讲的一样,Build Quality In

    这个关于QA的话题的最后,再聊聊ThoughtWorks QA。作为一个ThoughtWorker,除了做好自己本职工作之外,我们也要把自己工作中总结出的好的方面告诉别人,无论是以文章、blog或是讲演的方式,所以,QA也不应该例外。
    分享到:

    历史上的今天:

    步入正轨 2006-07-12
    引用地址:

    评论

  • 曾经的一个项目,开发人员一见到QA就害怕,因为项目中缺陷较多,开发人员只要是碰上QA,基本上就代表缺陷找上门了(部门里面对缺陷有指标),最后搞的开发人员都神经衰弱了:)
  • 呵呵,有时我甚至很想转去做QA。感觉比开发更有挑战,也许是我在现在的环境待久了。
  • QA也是分层次的.最初级的QA,就是刚招进来的毕业生,根本就不了解QA是做什么的,就是乱点一些按钮,乱抱一些不在scope中,没有提供什么value的可有可无的bug.
    上层次的QA,能够有测试计划,能够写test case,能够从不同的角度去测试同一个问题.并且能够和BA与DEV一起协作,管理scope以及重现问题.写出来的bug报告也清晰易懂.
    再上一个层次的QA,是不但能够手工的去做这些测试,还能系统化有针对性的去把手工任务自动化.安排好开发周期一个级别的测试计划,积极参与到部署等非开发环节.
    QA是一个易学难精的职业啊.第三个层次的QA是凤毛麟角的.
  • 写的很中肯,QA也应该从自身考虑进步,一开始是手工---没技术含量,然后是写case,其实这个就很有技术含量,覆盖率,边界值。然后是尝试自动化,其实自动化只是一个工具,只是用来更好体现case思路的工具。然后再进一步,就不能光focus on bugs,要从软件整体的质量考虑,如何才能整体把握?只有通过process policy。