• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

一个 SQA 的工作日记

发布: 2008-1-24 14:40 | 作者: QAMM | 来源: 不详 | 查看: 57次 | 进入软件测试论坛讨论

领测软件测试网

宣战( 2004 年 3 月 Z 日,晴)

    连续两天,看着公司高层领导们闭门会议,就知道有重大决定。果不其然,第三天,技术总监召集所有的项目经理和开发人员,宣布公司向 CMM 三级冲击,本人有幸被任命为 SQA (软件质量保证)经理和 SEPG (软件工程过程组)成员(成员仅有 3 人,真有象当选为“政治局常委”)。

    感觉真是不错,走出每天呆着的写字楼,看看大街上来来往往的人,爽啊!

    下班回家,郑重向“老婆”宣布,决定下馆子小辍一顿,一时间,踌躇满志,感觉飘然,好像公司的软件产品质量将获得重大提升,震撼业界。回想多年走过的历程,两年的程序员,三年的项目经理,终于熬出头了,上司发现了我这块“可造之材”,并委以重任。经过这么多年的风风雨雨磨练,终于有机会向上司展示才能,我当然要“涌泉相报”。

赋职( 2004 年 3 月 Y 日,多云)

    一早 6:10 就醒来,再也睡不着了,算了,还是起床吧。兴奋了一晚上,精神居然还挺好。

    8:00 就到公司了,时间太早,一个同事都没来,真想找个人侃侃自己的志向,毕竟“老婆”不是这一行的,有些东西还不能完全理解。上网溜达了一会儿, QQ 也没有好友在线,毕竟还没上班呢,只能看看 CMM 的最新动态和国内软件企业的新闻。没多久,同事们也陆续到了,上班时间到了。

    好不容易等到公司高层经理们开完了碰头会,我想,迟早我也会有机会挤进去参与的。 10:30 ,研发部经理向我们传达,经过领导们的一致同意,决定选择 XX 公司作为我们的 CMM 咨询顾问,鼓吹一通 XX 公司的业绩,(这不是有点象给他们做广告?)然后又宣布了参与培训的人员,都是一些公司的“栋梁之材”和“老马”。榜上无名的以极其羡慕的眼神看着这些幸运儿,榜上有名的“唯技术论”者则以不屑之表情,并不时发出 “项目太紧,没时间”的抗议。经理则非常明确,“高层决定,没商量,要么找老总协商”,试问有哪位有这等胆量。唉,朽木不可雕也,这些人也只能一辈子做技术了。

    完事后,经理又把我单独叫到他的办公室,问我打算如何组建 SQA ,说公司以后过 CMM 主要就靠我努力了,心头一阵激动。不过,经理接下来的话让我凉了半截,建议我 SQA 组下暂时只设一人,考虑一下小崔。不是吧?我的心有点凉了,公司里水平最差最笨的人就给我?这个人,不是仗着与老总有点不太近的远亲,估计早就给开了。我刚准备抗议,经理立马安慰,“所以才要你领导,有你在, CMM 应该不成问题,我们才放心。”

培训学习( 2004 年 4 月 X 日,晴)

    经过将近一个月的培训,今天总算毕业了,感觉就像脱胎换骨,到底 CMM 是面向软件行业,就是比 ISO 更专业。因为是由鬼佬上课,好像自己的英文水平也提高了不少,而且还挺正规的,发了“毕业证”。真是获益良多啊!给我印象最深的还是那个北大的计算机硕士翻译,水平挺高,人也长得漂亮。

    课程结束后,顾问公司的咨询人员还特地给了我这个新上任的 SQA 一些建议:要熟读 CMM “兵书”,在项目组成员对执行情况有异议时,才能够据理力争,以理服人;在实际的软件项目开发过程中,要多与项目经理和项目组成员沟通,注意处理好人际关系问题,不要轻易上报,否则很容易引起抵触情绪。

    虽然很感激他的意见,不过我更相信我的能力。

实战( 2004 年 5 月 W 日,多云)

    新项目从立项开始已经三个礼拜过去了,还挺顺利的。

    首先,立项时给项目组成员作了一次培训。让全体的开发人员感受一下 “ 软件质量保证 ” 的功效。 SQA 的一个职能就是对项目组成员进行必要的软件的过程培训,理论和实际相结合,而不只是用于纸上谈兵。美中不足的是,培训会议室的优雅环境给一些人提供了一个比较理想的休息场所。

    在项目经理拟定计划时,提供必要的规范给项目经理参考,参与项目估算,组织召开项目计划评审会,邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性。

    紧接着又是组织需求评审,并邀请用户参与,对其用户的意见进行跟踪检查是否纳入需求规格说明书,同时与用户签字确认。

    在此过程中,对项目的配置管理工作的作了一次比较细致的评审,发现了配置管理中存在的问题并提出了一些建议,使项目的配置管理工作更有效率。

    我在项目组中的工作如此繁忙,大家也逐渐接受了。同时, 公司高层似乎也感到“ SQA 工作确实很有成效”。

挫折( 2004 年 8 月 V 日,多云)

    经过三个月的摸爬滚打,项目开发任务总算进入尾声,剩下的就是测试了。不过, SQA 工作却不尽人意,好像没什么突出的贡献,倒是经常和项目经理和部门经理争执不休,今天下午又和项目经理争了一把“开发已经接近完成,关键模块是不是需要评审一下”,没想到居然给“羞辱”了——你又不懂,尽是找一些鸡毛蒜皮小错误,不要老是制造麻烦。而且,居然还告到经理那“项目组有了 SQA ,可是设计和代码的质量还是不高”。

    想起 CMM 培训结束时,我们搞了一个模拟小项目热身,好像有模有样的,当时老总和技术经理还特别予以召见, SEPG 组和项目经理几个向“组织”表决心的情形还历历在目。然而,事情发展到今天这个样子,我这个 SQA 当然是难辞其咎的。

    经历了这么一段时间,多少对顾问公司的一番临别赠言有了更深的体会。

    SQA 的主要任务是项目过程监控,是间谍,所以 SQA 的地位是很微妙,也很尴尬的:在开展项目以前,高层非常希望有一个耳目来监控项目的开发情况,项目组也希望有一个角色协助使开发和管理更加规范有序。当一个项目启动后,又是另一种局面:不管你对项目开发管理有多大帮助,只要你打了项目组的“小报告”,受到项目组成员排挤是很正常的事。只要你存在,对项目组成员就是一种压力。对于组织而言,报告的不符合项、建议多了,高层会嫌你啰嗦,还会质问 SQA 为什么没有能力协调解决,那要 SQA 干吗?漏报了(这是在所难免的),又会说你不够尽职尽责,总之两头不讨好。当你看到一堆问题时只能干着急,却没有权力去纠正,所能做的只是:报告、建议、协调,虽然向管理层报告了,也不一定会马上处理(高层管理者自然有他的道理,如果是老板的小舅子那就更没辙了),你会是什么感想?上级又有什么想法?

    下班前,还特地找了部门经理诉苦, 公司既然制订了制度,实际上就相当于公司的法律,如果有法不依,执法不严,违法不究,久而久之这套制度就只是一纸空文了,以后还会有用处么?

    吃饭时都感到郁闷,喝了一瓶啤酒,郁闷的是经理所说的“ SQA 工作更需要的是人际关系技能”。人际关系技能,那找个销售不就得了,还要我们这些技术人才干吗?

无奈( 2004 年 9 月 U 日,阴)

    每天准点上班,准点下班,默默地无休止地折腾那该死的软件。今天也不例外。

    从上礼拜二开始,经理就让我主要担任这个项目软件的测试,美其名曰“软件质量保证”,就要保证软件的质量,测试当然是保证质量的方式之一。我没有争辩,心知争辩也是徒然,而且高层不希望我成天找项目经理的茬,影响进度。资本运作当然不是我所能左右的!

    每天我机械地运行程序,检查结果,检查数据库,截图,填写缺陷报告,跟踪缺陷修复。虽然做得规范,无可挑剔,我成了孤独的斗士。

    实际上,测试是事后检验产品的质量,保证产品符合客户的需求;而 SQA 的职责是审计过程的质量,保证 CMM 中各个 KPA 过程被正确执行。因为 SQA 人员同样要检查测试的工作是否也遵循了开发过程要求,也是要被审计的,由 SQA 同时担任测试,那么谁来保证测试工作的过程质量呢?这些道理经理其实都明白,只不过项目经理完成的工作其价值是可见的,谁又能说出 SQA 产出了什么呢?

    中午休息时上了一个 CMM 的论坛蹓达,其中有一个帖子比喻得就极其形象:项目组就像是一家餐馆,项目经理是当班经理,他决定做什么,有多少人多少资源来做多大,有多大的风险;系统架构设计师就是主厨,他设计具体做法;程序员就是厨师,配置管理员、系统集成人员、数据库管理员等角色是厨房里面的服务人员。而 SQA 和测试工程师更像是第三方的检查人员, SQA 检查的是制作流程是否正确,材料是否使用正确,卫生是否做好了,他检查所有人的工作,包括项目经理。 SQA 虽然没有决定权,但是他有建议权,他向餐馆老板负责。测试工程师则更像是试菜的,看看炒出来的菜有没有合不合口味,有没有按照客人的意思多放点辣椒,如果口味不对,他们要告诉厨房就可以了。

    唉,算了, 就当混口饭吃 ,知足吧。

出局( 2004 年 10 月 T 日,雨)

    又是一个阴雨天。

    上班了,像往常一样,上网看看新闻。

    项目已经做完了,不过心里极其不爽。 我,虽然挂名 SQA 经理,实际成了一个打杂的,真正 SQA 工作早就抛在一边。比如协助完成测试、配置管理,研究实用的测试工具,改进一下开发环境和工作过程,甚至帮助项目经理汇总文档、总结实施经验、协助客户培训 ……

    10:00 ,经理找我,觉得我更适合担任测试组长一职,但待遇要低一级,问我是否接受。这是公司对待“鸡肋”的一贯策略,我明白,上级对我的 SQA 工作予以否定。这一天终于来了,当时的我居然平静的谢绝了经理的好意,感谢公司在这段时间给我提供了这么多的锻炼机会。然后就说,那我收拾东西去了,经理还愣在那。

    没什么可埋怨的,可能是上级对 SQA 的期望太高。实际上,根据现代软件工程项目的调查研究,项目管理是项目失败的主要原因。问题是,这个事实说明了“要保证项目不失败,我们应当更加关注管理”,但是并没有推论“良好的管理一定可以保证项目的成功”。 质量保证的最终目的是希望能保证质量,但质量是过程、人、技术三者缺一不可。除了过程外,还与人员、技术有关,而人员素质和技术水平的提高并不是依赖 SQA 就能保证的,所以 SQA 虽名为质量保证,实际上也就成了项目失败的直接责任人。

    难怪现在网上有一种说法“在中国做不了编程的人去做测试,做不了测试的人去做 SQA 。”实际上,这从就反映了 SQA 的作用并没有得到大家的认同,在大家的眼里, SQA 做的都是文档功夫。

    呜呼唉哉!

    感觉真是一种解脱。吃饭时喝了一瓶啤酒,深圳的秋老虎仍然厉害,体验着啤酒冰爽的感觉,幸福啊 ∶ )

    下周又要开始投简历了,找工作是一个漫长的过程。希望下次我能够找个好婆家,理解这些。还是要思量一下是不是继续干 SQA 。

    下过雨后,凌晨两点的城市空气清新,望着远处霓虹闪烁,好美。

后记:

    据了解,我的前任婆家在我离开公司的五个月之后通过了 CMM3 的正式评估。小崔,我的继任者,编程虽然极差,文档却是可以按要求完成的,不过,听说所有的项目文档都是由他执笔的。唉,怎么还是变得跟 ISO 一样了呢?只是名称改了一下。到了中国,任何的标准都有点变味了。

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: sqa SQA


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网