软件测试之旅,路漫漫,其修远兮,吾将上下而求索。 <<软测之魂>> 作者 擅长测试设计,嵌入式软件测试,测试自动化,测试体系建设,测试管理, 软件配置管理建设,医疗器械软件测试,教育。 新浪微博@Aullyxiao,邮箱aul516@126.com

发布新日志

  • 眼睛圆睁的测试经理

    2013-08-04 23:10:05Top 1 Digest 1

    【背景介绍】

       由于公司业务的扩展,需组建一个新的测试团队负责支持此产品软件业务的测试。这可困扰了测试部的部门经理陈先生。由于新组建的测试团队成员新人较多,资深一点的工程师又不太适合带团队,陈经理于是考虑启动社会招聘解决这一问题。他在给HR的该岗位职位描述中除了对测试工程师的一般要求外,还作了以下补充:有2年以上团队管理经验,能带领团队完成中大型软件项目的测试;善于分析与总结问题,推动测试流程的改进与测试平台的建设。

     

    人物表

    面试官:陈先生,XX公司测试部门经理

    求职者:阿黄,工作11年,其中软件测试工作6年,最后一家公司的职位是QA Manager

    时间:阳春三月的一个下午,天气:雷阵雨

    【故事内容】

     

      人才市场中,有一句流行的话,叫“金三银四”,意思是每年的3月份人才市场中人头涌动,是企业员工跳槽的高峰期,也是用人单位招人的黄金季节。

     

      阿黄,就是这个时候来求职的。

    3月的某一天,陈先生收到了阿黄的简历。简历是公司内部的员工推荐给HR,再由HR转给陈先生的。

    陈先生打开阿黄的简历,翻来翻去浏览了两遍,发现除了工作年限11年,年龄为34,最后职位为QA Manager外,没看到其他有什么特别的。但能收到这样的资深人士简历,陈先生心里想,这还得感谢公司某同事的推荐。于是通知HR约黄先生过两天来面试。

     向来,阳春三月,咋暖还寒。深圳的早春也不例外,这几天的天气还有雷阵雨。在接待厅见到阿黄的时候,是下午的4点一刻,陈先生刚送走前面的面试者。

      在陈先生的招呼下,阿黄从大厅的沙发上站起来,拎起随身携带的黑色公文包,跟随着陈先生来到面试间。

    就一接眼的时间,陈先生发现,阿黄与简历上看到的年龄比较匹配,中等身材,有些憔悴的样子。老套路,几句客套话后,他们便进入了正题。

    因为陈先生看到阿黄的最后工作职位是QA Manager,而要招的岗位是能带团队做事的资深测试工程师,是技术岗,而非管理岗。所以首先问道:“你是想要找什么样的工作呢。”

    阿黄不失和气地微笑着说:“我有6年的测试经验,对测试流程、人员管理比较熟悉,如果能有一个偏管理的测试工作会更能发挥我的价值。”

    陈先生问:“我们要招的主要是能带团队做事的资深测试工程师,偏技术,你是否愿意考虑呢?”

    阿黄赶忙回答道:“这个是愿意的,在来之前,已经做好了这方面的准备,其实刚来直接做管理也不太合适。”

    陈先生说:“可否分享你从事软件测试6年来的心路历程。”

    阿黄说:“对于软件测试,可说我是半路出家。大学里学的是电子与信息工程,毕业后的前几年一直在佛山的一间家电公司上班,在质量部门负责产品的质最审核程序。公司属国营性质,工作相对轻松。后来公司由于经营原因,面临倒闭。再三考虑后,在朋友的帮助下,2006年我来到深圳,并在深圳的一家软件测试培训机构进行专职的培训。近4个月的培训,差不多是边学习边找工作,半年后,终于找到了一家外包软件测试的公司,即简历中提到的A公司。”

    陈先生一边听着,一边作些笔记,偶尔抬头看看阿黄,以示关注及回应。

    见陈先生不插话,阿黄接着说:“在这家外包公司,我以测试执行为主,2年多的时间里,涉及到的项目较多,有金融类的,有电信类的,也有互联网类的,每个项目的时间不长,约为2-3个月,最长的也即0.5年。在外包公司非常明显的特点是,人员流动大,在A公司坚持做了2年,已算是老员工了。基本上是在1年后,我开始带团队负责项目的测试,主要的工作包括团队成员的工作分配,工作输出质量检查,用例的部分设计或修改。或许,没有归属感是外包公司的另一个主要问题。2年后,即在2009年,我离开了这家作为软件测试工作的第一个驿站,加入了简力上的B公司。”

    陈先生听着,继续示意阿黄说下去。

    阿黄说:“在B公司,我们部门的主要业务是开发安卓系统的应用程序,公司在深圳的规模不算大,约100来人。在这里软件测试我是第一个进入公司的,后来随着公司的业务发展,也就组建了测试团队。我主要负责测试团队的建设,日常工作安排,人员培养等工作。”

    陈先生经阿黄的一翻介绍,对眼前这个清瘦清瘦的他有了一些了解。于是问道:“在B公司,你负责的测试团队有多少人?”。

    阿黄说:“4人。”

    陈先生有点意外,因为一般作为一个部门的Manager,其下应会有多个主管,一线的工程师就更多了。于是接着问:“是4个工程师吗?”

    阿黄回答说:“是的。”

    陈先生继续发问:“你们是QA部门,是否还有另外一支专门做软件测试的队伍?”

    阿黄说:“没有,就是我们做。公司的很多做法、叫法,包括开发的流程,都不太规范。这也是我离职的原因之一。”

    陈先生听了只好似懂非懂地点了点头。心想,国内的确是有一些公司把测试团队放在QA部门的,尽管叫法不够专业,但做的事情类同。对阿黄这个QA Manager的头衔这个角色有了一些理解。

    接着阿黄的话题,问道:“刚听你说,公司的开发流程不够规范,能不能具体说是什么流程呢?”

    阿黄说:“比如,有时开发人员更改了软件,不知会测试,直接把软件发布了,一方面觉得这里有风险,另一方面觉得测试被加驾空了。”

    陈先生听了后,马上问道:“发生这种事后,作为Manager,你是如何处理的?”

    阿黄说:“我找过软件负责人,也是我的上司,反馈了这样做可能存在的风险等,但没用”。

    陈先生继续问:“你是否了解清楚了当时的版本具体改了什么内容,是否确实没有经过测试,还是仅是没有经过测试团队的测试?”

    阿黄回答说:“细节没有了解,是测试人员向我反馈的。”

    陈先生再问道:“你在找你的上司时,是否给出了解决你认为存在风险的问题解决方案,而且最好是多个方案让他来选择。”

    此时的阿黄,眼睛睁得圆圆的,定睛地看着陈先生,心里想着:“这个面试官确实有点能耐,问的问题真问到点子上了,我为什么之前没有这么想过呢?看上去这个面试官也只是30出头,可能还比自己小呢。”

    阿黄沉思了一会后,说“这个我确实没有考虑具体的解决方案,当时只是找领导说了我的想法

    面试到始,陈先生对阿黄这个QA Manager已有所了解,并在心中对其分析问题解决问题的能力打了分。但还是想对这个做了6年软件测试的资深人士有更全面的了解,于是问:“6年的测试经历,谅想你已积累了不少测试经验,你觉得那些方面是做得比较好的,或者说自己的亮点有哪些呢?”

    阿黄听到这句话后,马上重复地说了“亮点”两个字,然后声调提高了一倍很有信心地笑道:“我觉得都做得挺好的呀!”。

    陈先生可不怎么认为,心想很可能又是一个忽悠人的家伙,于是设题问道:“几年中测试过的软件,上线发布后是否有漏测的bug反馈?”。

    此时阿黄收住了刚才自信的笑容,答道:“有的,这是有的。”

    陈先生问:“可否分享一个案例,当收到用户端反馈的漏测bug后,你是如何处理的?”

    阿黄说:“好的,我就举一个最近发生的用户新增的数据不能删除的问题吧”。

    阿黄继续说:“当接收到用户的反馈后,首先我们去重现这个bug,以便确认问题。后来我们经一翻沟通与尝试,发现此bug的发生有一个条件,就是必须是开机后,删除一条记录,再新增一条记录,此时新增的记录不能被删除。开发更改了这个bug后,测试回归确认,然后重新发布了版本。同时,测试这边对所有相关产品都新增了这一用户场景用例,以便同样的问题不能出现。”

    陈先生说:“同样的问题不能再出现,测试作为软件质量的最后把关者,这是必须要做到的。当时是否想过这个问题你们是出在哪那个环节,例如是用例设计不全,还是用例执行不到位,或者其他什么原因导致漏测了?”

    此时,阿黄的眼睛又睁圆了,面试官陈先生猜他正在想东西,看样子还有点狡猾。

    一会儿装着假笑的样子回答说:“测试出现漏测很正常的吧,其实大家都很清楚,我们测试不可能把所有的bug都找出来,对吧。”

    陈先生知道阿黄说的不无道理,但这里有个度,于是补充说:“测试是有成本的,不可能把所有的bug都找出来,也没有必要,确实如此。但是你的老板肯定不喜欢听你这么说,其实我们做测试的,如何做好测试,需把握一个度,把基于风险的测试做好是一个关键。如能在项目的前期,推动项目做好相关预防,这是上策……

    阿黄听着陈先生的一番话,自知说漏嘴了,而且目前这位面试官是在纠正自己呢。心里已十有八九知道结果了。

     

    【思路点拔】

     

    为了能找到满足职缺的项目测试经理角色的人,陈先生在二个月内连续面试了上100号人,但结果确是差强人意,下面内容是他的分析总结。

    测试工作5年后,相对年龄大(大于30岁)的应聘者,普遍缺少对测试技术工作的激情,大部分倾向于做测试管理。然而现实中,国内的软件公司,规模较大(大于500人)的不太多,测试的管理岗位非常有限。而且万不得已时,一般不会直接从社会上招聘。特别是对于基层主管,一般是从基层的工程师中直接提拔,这也是企业用人、留人的重要手段。据悉,今年某公司XX事业部,正是因为空降了一个测试部门经理,正值其初来窅到,几名技术经理(主管)连续辞职。这种基层骨干队伍不稳定时,部门经理基本就是技术经理的代名词。空降的领导带来的影响极大,或许越趋向基层,越不适合空降。

    通过这一段时间的面试,引发的思考:35岁真是一个IT行业从业者的分水岭吗?特别是软件研发。行业的浮躁和短视已难于造铸就大批的资深专业人士,从价值取向看,我们官本位思想导致很多人都追求做管理,不去做技术。或许,这是陈先生面试了近两个月来,没有找到合适人选的最核心最本质的原因。

     

      选择技术也好,管理也罢,笔者的忠实建言:先搞清楚自己能做什么,社会或企业需求又是什么,然后去调整自己,尽可能的情况下去满足需求,或许这样,你离求职成功的距离会更近。

     

    本故事面试场景中的一些地方,可能你也似曾相识,觉得那些地方求职者或面试官可以做得更好呢。

    欢迎交流:aul516@126.com

  • 面试故事--面试不相信眼泪

    2013-06-16 22:18:31Top 1 Digest 1

    【背景介绍】

     

    求职者:朱红,女,毕业于国内211工程大学的某名校,硕士研究生,年龄32岁,已婚已育,应聘高级软件测试工程师。

    面试官1:男,MD公司某软件测试主管;

    面试官2:男,MD公司某软件测试经理;

    面试官3Anny,女,某IT民营企业,HR招聘经理,未婚。

     

    MD公司的面试流程是这样的,先进行业务技术面,一般为2轮,技术面通过后由HR进行综合素质面,最后的优胜者,为候选的录用对象。

     

    【内容介绍】

    送走朱红,Anny手握着她的简历,斜倚在35楼电梯口旁的玻璃阳台上,陷入了沉思……

    某某名校,那可是多少人梦寐以求的高等学府,且是硕士研究生毕业,谅想当年的朱姐一定也是“风光无限,有多少人羡慕还来不及的女高材生”,而几年后,却被现实打磨得如此七零八落。坦白地说,作为HR的面试官,在近5年的面试经历中,遇面试时吐槽至哭的人还真是极少数。Anny心里在跟自己这样说着。

    或许,出自同是女性的同情,又或许是马上自己也将面临同样的结緍生子过程,亦表示出理解。大都市生活节凑之快,一线城市高企的房价,生存的压力之大,种种原因或情况,从结果来看,Anny认为朱红这个时候加入工作强度如此大的MD公司,是不合适的。目送着她走出电梯后的背影……Anny 情不自禁地想起上中学时经常挂在嘴边的普希金的一首诗《假如生活欺骗了您》。

     

    假如生活欺骗了你,

    不要悲伤,不要心急!

    忧郁的日子里需要镇静,

    相信吧,快乐的日子将会来临。

    心儿永远向往着未来,

    现在却常是忧郁。

    一切都是瞬息,

    一切都将会过去。

    而那过去了的,

    就会成为亲切的怀恋。

     

    并在心底默默的祝福她,祝她早日调整好心态,平衡好工作与生活中的得与失,渡过难关。

    人,送走了,结果还是要知会业务部门的。Anny于是找来了面试朱红的2个负责技术面的面试官,一起进行回顾与评论。

     

    面试官1很直接,说话也快,首先开始评价道:

     

    1、她对测试过的软件能从多个角度分析,逻辑性思维好,对深度、复杂问题的分析有一定把握能力,这一点不错,是一个基础比较扎实之人;

    2、有4年的系统测试经验,做事看起来比较踏实;

    3、对原公司加班后无加班费存在看法,好像不太理解IT业的行情。

     

    接着是面试官2的评价:

    “我同意面试官1的评价,对其的分析问题、解决问题的能力比较看好,但觉得其缺少主动性与开创精神。作为研究生毕业并有一定潜力之人,在4年的工作中输出仍是平平觉得不太合符逻辑。但后面了解到,其4年的工作中,前2年是从学校毕业后做一般的测试工程师,工作的第34年便是怀小孩、生小孩。所以4年的工作时间,实际上真正做测试的时间只有2年多。再后来了解到其为什么不太愿意加班,说要照顾家庭,比较计较加班费的有无,是因为在深圳未买房,而在生小孩的这两年中,工资也未有长进。另外,与其交流的整个过程中,感觉其非常疲倦、委曲、不开心,甚至几次说话时看到她的眼睛里有泪水在眼框里打转。缺少一种她这个年龄知识女性该有的自信与成熟。”

    Anny 坐着,认真的倾听着两位技术面试官的评价,心想测试经理的判断还是比较靠谱的。然后,补充了自己的看法。

       “从HR进行综合面试的角度看,朱红的抗压能力、情绪控制能力是有限的。目前正遇家庭、工作如何平衡、调整的关键时期。今天正好是周六,她跟我说前两天刚把2岁的儿子从老家江城接过来,言之除了上班,工作之余需要照顾孩子。或许是生活的压力过大,或事情多不顺心,我感觉她已把我当成一个吐槽的倾诉对象。言之先生不在深圳工作,现在在租房养一个老人与孩子,孩子放在老家舍不得,所以再难也要接出来等。而原来的公司小,不太稳定,所以非常想进咱们MD公司,说着说着禁不住泪流满面,还抽泣起来。我只好递给她纸巾,同时稳住她的情绪。虽然是从事研发的技术工作,但这种情绪容易失控的行为是自我管理的重大缺陷,我们是否需再看看呢。”

      

    思路点拔

     

    求职,我们的目的很清楚,就是想通过面试,谋求一份理想的工作。面试的整个过程实际上是一个个人表现过程。无论是笔试,还是面试,都是要面试官认可你,才能闯过关。

    试想如果你是一个面试官,有人向你吐槽,还控制不住自己的情绪,说到心酸处,眼泪在打转,说话变调,这是为那班呢。

    求职的过程,是一个艰辛的过程,不仅是专业技术要过关,心理素质也要过关。

    逢人诉苦去搏同情,以引起面试官的共鸣,这只会适得其反,给面试考官一个心胸狭隘、心理脆弱的印象,让面试效果大打折扣,凭这种怯懦、自卑的心理去乞讨工作,结果是不言而喻的!所以,面试时应摈弃泪弹式的求职方法,将所有痛苦、委屈抛诸脑后,以百倍的信心勇敢去面试,就能大大地提高成功的机会。
     
  • 面试故事--聪明反被聪明误

    2013-06-01 22:10:13Top 1 Digest 1

    【背景介绍】

    NB公司的面试流程步骤多,严谨,正常情况下一个顺利的面试流程需经5个面试官的考核,真所谓过五关斩六将,能闯到最后一关者,绝非易事。----某公司的过来人如是说。

     

    求职者:王小姐,毕业后一直从事软件测试,工作4年。

    面试官:共5位,其中前3位为技术面,后2位为综合素质面。

     

    【故事内容:面试回顾】

       话说王小姐的面试还是比较顺利,用的是周六的时间,不用请假。虽早上7点多就开始准备,直到下午4点才面试完,但能在国内知名的NB公司面试,并闯入最后环节,当王小姐走出NB公司的大门,还是自我欣慰了一番,并自信的笑了笑。心想:NB公司的面试官确实个个都有不同的一面,问的问题有些还比较尖锐。说实在的,测试技术也就是那些,面试官非要纠缠一些细节。我只好……,这个策略也叫“兵来将挡,水来土掩”吧。

       也就在王小姐离开公司的一会儿,按惯例,HR组织几个面试官碰在一起交流下彼此对王小姐的评价。

    面试官1评价:沟通能力不错,整个过程没有不顺畅的地方。技术上没有发现明显的优势与劣势,但总觉得她的话不太符合逻辑。

     

    下面是面试官1的经典回顾。

    面试官1问:“工作过程中,是否曾主动总结过什么东西与他人分享?”

    王小姐说:“有的。”

    面试官1问:“是否有什么案例具体说说。”

    王小姐说:“我安装配置过给公司内部使用的XX软件,由于配置复杂,当时写了一份总结,并上传到网上我的博客空间了。”

    面试官1问:“是什么网站。”

    王小姐说:“不记得了。”

    面试官1心想,上传了博文,有不知道是什么网站的吗?一般情况下建立博客空间是要注册的。不太靠谱吧。

     

    下面是面试官2对王小姐的面试评价:

    1、 工作主动,有一定的过程总结能力。例如:她从自带的旅行包里取出一份测试报告展示给我看,报告内容详细、清晰,并提出某某图表是她主动做的。

    2、 有点过于自信,或自我认识不足。问及做了几年测试后,有没有遇到什么技术上的困难,或哪些方面觉得还有待于提高,回答各方面都做得很好,没有遇到什么困难。我表示怀疑。

     

    下面是面试官2的经典回顾。

    面试官2问:“你认为做好软件测试工作,哪个环节的工作做好最重要?”

    王小姐回答说:“每一个都很重要,每一个环节我都做过,包括测试计划,测试方案、用例设计,测试总结与报告等。”

    面试官2心想,既然都做得好,于是继续问:“在多年的测试过程中是否有遇到偶发的Bug,是如何回归偶发Bug的”。

    王小姐说:“可能运气好,真没遇到,发现的问题无偶发的并且开发都解决了。”

    面试官2心想,这位王小姐,是神马,还是浮云,这显然不符合正常情况的软件研发过程逻辑。

     

    轮到面试官3发表意见了,他略有所思,回忆了当时的面试场景。下面是他的经典回顾。

     

    面试官3问道:“从事测试4年多来,是否有感到自己哪些方面比较欠缺的。”

    王小姐说:“暂无感到有什么不足或缺点,工作上都挺顺利的。”

    面试官3心想这个王小姐,心有顾虑,不太诚恳。于是现场出一个题目来考考她,拿出一张白纸,并在纸上画出一个日常常用到的软件界面,在明确需求的基础上,要她讲述测试的分析思路。

    王小姐看了几眼,基本没作思考,便随口说了几个她所认为的测试思路。

    面试官3心想,都是表面的几个测试点。从这点上来看,觉得她很一般,没有突出的特点。

    面试官3继续问:“听你说,在公司各项工作开展都挺顺利的,也觉得自己没什么欠缺的,为什么还离职呢。”

    王小姐回答说:“公司业绩不好,没有奖金发,一年了也未加过薪,这是重点。其次是看不到什么发展空间。”

    对于王小姐回答的第1点,面试官3觉得可以理解,对于第2点有点好奇,于是追问道:“是什么原因使你认为看不到发展空间呢?”

    王小姐回答说:“我的老板,即我的上司,是在公司工作了7-8年的老员工,在业务与技术上,自己明显是比不上的,他们老员工也比较稳,一般情况不会离职。而公司目前的发展未有其他管理岗位可提供。公司的测试部门还有另一个平台组,主要负责公共模块的测试,测试工具的开发,偏向测试开发,而自己这方面的技术水平又达不到。”

    面试官3听了后,恍然大悟。

    心里评价道:“工作不踏实,自命清高。回答问题不诚恳,自作聪明。”

     

    思路点拔

    三国时期的历史典故,杨修的鸡肋事件,本无其事,最后引火烧身,与本处的“聪明反被聪明误”案例,似有相似之处。抑或是杨修之死,还是本处的案例,告诉我们:

     

    1、 诚实。面试过程,是相互建立信任的过程,不少面试者为了掩盖自己的不足,往往会说一些谎言。当然作某些善意的谎言,只要不影响本质,面试官也不是不能接受的。

    2、 逻辑清晰。说话表达注意逻辑,问A问题,不能答B内容。软件测试是技术性工作,思路清晰,有逻辑的封闭性,这是基本的素质。例如本案例中提到的求职者主动上传了博文,却不知道博文位于何网站。

     

    本故事面试场景中的一些地方,可能你也似曾相识,觉得那些地方求职者或面试官可以做得更好呢。

    欢迎交流:aul516@126.com

  • 面试故事--身在曹营心在汉

    2013-04-14 15:37:11Top 1 Digest 1

    【背景介绍】

    面试官:某名企资深测试经理

    求职者:毕业于国内某名校,硕士研究生,目前正供职于国内一家通信公司。

    时间:骄阳似火的八月,某工作日的晚上700左右。

    地点:深圳的某栋高楼写字间。

     

    【故事内容】

    正好是下班期间,某公司接待厅里人来人往。

    面试官如约来到接待厅,引领求职者到一间会议室,并招呼其坐下。客套几句后便安排求职者进行笔试,笔试时间为60分钟。

    地球人1小时后,面试官打开会议室的门,发现求职者正在看书。

    面试官觉得有些诧异,心想这个家伙的行为有些特别,会不会有作弊的嫌疑。于是问“题做完了吗”。

    求职者马上回答“做完了,看您还没来,我就看下书”,同时,把答完的试卷递给面试官。

    怎么一听,面试官心里排除了作弊的嫌疑,便好奇地问“在看什么方面的书呢?”,同时拿起求职者的试卷。

    求职者回答道:“算法”,同时把书的封面给面试官亮了亮,脸上露出丝丝腼腆的答容。

    “看他那腼腆的笑容里,有种傻傻的书生气,小小的满足感,这个家伙可能涉世未久”,面试官心细地想着。

    接着,面试官对他的答题情况进行了大致扫瞄,发现代码错误分析题都对了,用例设计题也写得很详细,细致程度就像老师经常跟我们说的“如果还有考试时间,能写则尽量多写”的感觉。但是思维比较局限,设计的测试点不太全面,明显经验不足的体现。测试工具应用方面写的是他所在公司自主开发的测试辅助工具。面试官心想,求职者答的题是诚实的,不过从另一方面也可判断其对业界流行工具不太了解,或知之甚少。

    在面试官扫视答题卷时,求职者继续低头看他自带的书。面试官心想这个家伙为啥怎么争分夺秒地看书,是不是有点做作?

    2分钟后,面试官问道“你觉得考题难吗?”。

    求职者说:“还好,基本都会做”。面试官心想,回答比较靠谱,就把试卷放一边了。继续问道:“是基于什么原因,在找工作面试的短暂时间里还带着一本书来看?”

    求职者说:“也是为了找工作的需要吧,因为从学校毕业后做的是黑盒功能测试工作,很少需要接触代码,一些开发的基础知识都忘了,这也是为什么我想换工作的原因之一。”

    面试官心想,又是一个对测试工作认识存在误区者。功能测试的方法有很多,灰盒测试,白盒测试,或其他专项测试方法都可以用,为什么要局限自己做功能测试只用黑盒来测试呢。于是问“功能测试过程中是否有遇到通过黑盒方法不能测试充分,需要采用其他方法,如用灰盒或白盒方法进行测试的场景。”

    求职者的眼神飘忽,满脸茫然的样子。

    从他茫然的表情及刚才的话,面试官估计这个家伙十有八九是未遇到,也未曾这样想过,也就更谈不上去做了。

    求职者茫然片刻后,假装放松,露出八颗牙齿,好似带笑地说,“我测试的内容比较简单,是开发人员开发的自动化测试工具,属开发内部使用的工具,不直接面向用户。公司对这方面也不太重视,基本是认为能用就行。我们是按照需求,对功能进行测试,涉及不到代码。”

    从他的这番话中,面试官心里很是打鼓。从他的笔试成绩,毕业学校,及在学校所获得的奖项,是个基础较好有潜力的苗子。虽然他对测试的认识,或是对工作的态度上有待提高的地方。为什么会这样呢,心中又是充满好奇。于是问:“你是在校园招聘时进入XX通信公司的吗。”

    求职者:“是的。

    面试官:“当时应聘的岗位是什么呢。”

    求职者:“当时的岗位叫软件工程师,说是从事软件研发工作,具体没有说是做软件开发还是软件测试,是入职后到公司培训,后来分配到软件测试岗位的。”

    求职者一边回答一边用双手擦着他纠结的脸,一腔无辜无奈的表情。

    面试官更加确定这个家伙其实心里是不想做测试的,于是直接设个引子。

    “你对算法那么感兴趣,笔试成绩也体现出了你在代码逻辑分析上的思维不错。根据刚才你反馈的一些信息,我们这边也正招聘软件开发的岗位,你愿不愿意试试。”

       求职者的脸马上转阴为晴,并爽快地应答道:“可以呀!”

       面试官:“我可以帮你推荐下,但是开发的面试要求是至少有三年嵌入式软件开发经验,不知道这方面你积累得如何?”

       求职者:“那没有,我主要是在实习时做过近一年的数据存储方面的开发工作”。脸上再次表示出纠结的表情。

       面试官心里想了想,非常明显的“身在曹营心在汉”的家伙(附图来自百度),自己还搞不清楚到底求什么职位,结果两边不讨好,误了自己,面试该结束了。于是礼貌性地问了其他几个问题,送客。

     

     

    【思路点拔】

      面试别人,或许,并不是每个人都经历过,但职业生涯也即打工仍是我等普罗大众的主要生存方式,我们自从学校毕业后,都曾经历过或多或少的求职面试场景。

     

      面试的成功与失败,很多人会提到机遇(有利的条件与环境)。但是命运的掌舵人恰恰是我们自己。就本故事而言,求职者是否重视了可能影响他面试结果的每一细节,包括从准备到面试的全过程,是值得我们思考的问题。

      下面是笔者对本故事的点评:

    1、 清晰的求职目标。清楚自己到底想求什么职位,而不是碰到什么求什么,首鼠两端,最后两边都不是。

    2、 重视面试过程的每一细节。例如面试官在阅卷时,实际上面试已开始,我们是否可主动发问,或诚恳地等待发问,避免进行其他小动作。这些都是相互合作、尊重的细节表现,也是顺利进行面试的潜在基本原则。

     

    本故事面试场景中的一些地方,可能你也似曾相识,觉得那些地方求职者或面试官可以做得更好呢。

    欢迎交流:aul516@126.com

     

  • 测试工作量评估的故事

    2012-07-15 23:23:01Top 1 Digest 1

    背景:某应用软件有多个模块组成,各模块都有不同的满足用户需求的业务功能,但“数据导出”比较特别,在多个业务模块中都有此功能。于是在设计时,开发人员对“数据导出”相关共性需求的处理函数进行了封装,对外只提供相关接口给其他模块调用。各业务模块与数据导出模块的关系如下图所示。此模块的测试由工程师陈X负责。

    业务模块与数据导出公共模块的调用关系图

    事件:在任务开始前,主管李A安排陈X先评估此任务的工作量,当陈X把工作量10天(即2周)报给其主管时,其主管几乎不敢相信会相差那么远,因为他自已评估的是2-3天,差了不少于3倍的时间,更何况陈X还是一个资深测试工程师。问题出在哪呢,为何会相差那么远?

    原因分析:主管李A找来陈X交流

    主管李A:数据导出的测试,你评估的工作量是10天,请具体说说这些时间的任务分布吧。

    X:数据导出功能,在整个软件中共有5个模块调用,由于每个模块的业务不同,导出的数据是不同的,需分别设计测试用例,及执行测试,估计一个模块花2天的时间,5个模块共10天。

       主管李A:从业务出发,每个模块导出的数据是不同的,但各模块是如何实现此共性功能的,是否作过分析。

       X:没有,也没见到开发有相关的设计文档。

       主管李A:是否找过相关开发人员沟通、分析过其实现原理。

       X:没有,我是按需求说明进行验证的。

        问到此处,主管李A只好把数据导出模块的实现原理,与各业务模块的接口关系对着开发的代码实现讲解了一遍,并让陈X理解各模块的测试边界在哪里,那些是共性的,那些是特性的测试。陈X听后,有种晃然觉悟的理解,回头再梳理了自己的测试思路,整理共性与特性的测试点,最后评估的测试时间约为4天。

    启示:工作量的评估,是我们经常遇到的,看似与技术无关,但通过上面的案例,相信读者能体会到其中对系统业务、设计、实现把握度的重要性。测试前期某测试任务的评估,隐含着初步的测试对象分析,测试方案、用例的设计,与测试效率有着直接关系,是一种测试综合技能的体现。

  • 《就这么做产品》读后感

    2012-05-13 11:50:54Top 1

       经典词句:

    1、产品是企业的灵魂

    2、好产品:专注,伟大产品:有愿景,乔布斯不同于常人的看法:满足客户需求是平庸公司所为,引导客户需求才是高手之道,

    哲学:眼界有多高远,就能走多远;心胸有多宽广,就能做多大的事

    领袖和跟风者的区别就在于创新。

    3、用户体体验:用户体验是个复杂的问题,越来越受关注的问题,

    用户体验:不是震撼性创新,而是把众多不被重视的细节做好,就是说“重要的不是你能实现什么,而是你怎么实现”

    产品之魂,用户体验,iphone的优势;Ipod,操作不到三次就能选择一首想要听的歌曲

    4、马斯洛五级需求层次模型,从下到上依次是:生理需要、安全需要、归属与爱的需要(或称社交)、尊重需要和自我实现的需要

     

    难得的是作者独到看产品的视野,把这个很难说清楚的大范围的产品概念,与道,天,地,法,将,联系起来纵述,好似谈古论今,视角宽阔,颇受启发。

  • 测试经理该做什么?

    2011-09-29 00:07:17Top 1 Digest 1

        即使工作再忙,时不时也会反问自己。自己作为测试部门经理的角色,该做些什么?哪些事是别人不能代替的,哪些事是可以安排他人做的。因为再也没有人会象主管安排工程师那样,把具体的事跟你说得很清楚,如什么时间点完成什么事等。部门经理拿到的通常是一个大的目标或任务,例如,公司计划用1年时间研发一款新产品,那么测试部门经理拿到这个目标后,需要分解目标,做好资源、技术的规划。任务分解过程中,涉及到哪些专业组,各专业组如何配合才能达成目标,完成任务等,更多的是如何使用这些资源完成共同的目标。而且很重要的是,如何利用任务(项目)作为平台,把人才培养的事完成,当一个项目(产品)完成后,也有一批人成长起来,从而达到公司与员工的双羸。

      

    作为软件测试方向的部门经理,个人的想法,下面两点比较重要:

    1、  重点:测试质量第一(专业方向)

    方法:1)提高测试团队测试对象分析的能力,以可以发现更深入的问题,影响分析可以做得更到位。具体是先培养这方面有比较突出能力的人作为第一梯队的技术经理(主管),然后由他们培养第二梯队人才,如此继续……

    2)改变测试方法单一,采用代码静态分析,动态功能执行,个别业务专项测试(压力测试,特性测试等),局部自动化测试。

    2、  测试价值认识的引领:带领测试团队(特别是测试负责人多做对项目有贡献的事,超出软件测试的范畴多做事),统一认识:项目的商业成功,才是测试的成功

    暂先写这些。

  • 面试随笔录

    2011-05-08 12:42:15Top 1 Digest 2

      昨天面试了7人,总体情况算还不错,是我们运气好,还是本次是因为我做的是二面?后者关系可能大些。但总体情况比去年这个时候要好。

    感受总结:

    1、  大部分(估计60%)的小公司都有软件测试,但人数不多(1-3人,小于10人),测试仍没受到足够重视。甚至一些大公司,如面试的一个自称是XXX公司管理着20多号人的测试主管,无论是技术还是管理经验,让人觉得头衔是拿来忽悠面试管的,水份相差太远了。

    2、  大部分应聘者特别是新生代(84年后的),他们都充分意识到代码能力对测试的重要性,有自学的,有原做开发转行的。这部分人大部分是认为自己的开发能力不足转过来,而转过来做测试却正好又是优势。这一点我倒是主张的思想,但有一点很重要,如果思想没有转过来,却并不一定是好事,即做了测试但却心里还看不起测试,所谓身在曹营心在汉,即心态没有摆正确。测试的技术方向走法是我一直主张的,也就是微软SDET推崇的思路,相信没有问题。

    3、   面试别人,有时也在想自己被别人面试的场景。透过他们看到外面的测试是啥样子,回顾所走过的测试之路,有值得庆幸或安慰的,也有不足。

    4、每一年面试新人,能感到这个行业的不断进步,如:有独立测试岗位的公司、应聘人员的思想、学习渠道掌握的知识等

      世界在变,测试行业也在变(需求及要求),越来越感受前方的缕缕阳光.....

  • 向下属说“不”

    2011-03-22 23:15:49Top 1 Digest 1

       当你收到一份下属的工作输出,漏洞百出,问题太突出,甚至有些比较低级,可说触到了自己对工作要求的原则性问题时,你会如何处理呢?把自己当时任务回收站,反馈后让下属不痛不痒,整改后再看看,OK即收工,还是就事论事马上进行面对面处理,再者进行公诸于众的全员上课?

       前些天,我遭遇了这份待遇,在考虑宽容下属,给一个改正的机会,第二次再犯时提出警告,第三次再说不,还是选择二不,着实让我考虑了一些时间。

       由于事情严重,正如前面提到,已触到了作为管理者对工作要求的底线(原则),难道自己就此罢休,允许有第二次吗,自己愿意成为任务回收站吗?在思索中时,正好看到孙继滨《知道力》中“如何对手下说‘不’”内容,正适合我用,其提到的说“不”的三个典型场景,违背你的原则,违背你的真理,把你当做任务回收站。我的这种情况不就第一种场景吗?且事实摆在面前,就事论事,向下属说“不”是很容易的,机不可失,时不再来。第二天一上班我就忙乎起这件事来了。与工程师约好时间,就事论事,交流了近1小时,收到了想要的效果,对方认识到了输出劣质报告影响的严重性,及接下来该如何做的一些思路。

        但还有一点,还是碍于情面的,我并没有说“不”给全员看的。

  • 品尝了一次失败的沟通

    2011-03-08 23:47:51Top 1 Digest 1

       今天是三八妇女节,但上午与手下就“关于集成测试如何做问题”的沟通让我感到比较失败。

       反思主要原因

    1、  自己太主观,在沟通之前,并没有把相关问题了解得足够清楚;

    2、  沟通对象不太清楚我要解决什么问题,一味地点头敷衍;也就是自己认为是问题,但对方却并不认为是问题。

    正好在看孙继滨的《知道力》,其中提到有效沟通的四个条件:

    1、  沟通的目的性:沟通要有明确的目标(觉得自己这一点没有做好,事先没有把这个想清楚,问清楚对方对事情的看法。沟通上关于涉及到对方工作不足的问题时,必须拿出具体的例子来,以此为引导,才能推动解决类似相关问题)

    2、  沟通的双向性:沟通不是单向的,而是围绕着沟通目的的双向沟通。(这一点由于前一点没做好,我的沟通对象很沉闷,甚至有一些情绪,也使得我也有一些情绪)

    3、  沟通的分工性:沟通目标应该由沟通对象来实现,而不是管理者。这一点手下最后说他会做,但我觉得有点别扭。

    4、  沟通的成功性:有两种沟通是成功的,一种是管理者认可了目标达成的沟通;另一种是管理者在沟通对象执行前决定放弃的沟通。(我的情况属于哪一种呢,从结果来看,现在还不能定论,因为任务未执行,但沟通不畅造成对彼此的影响是很不好的。

     

    从这四个条件来看,判断是否是有效沟通,是从结果来看的。如果经理人讲得很多,而实际上手下看似认真听了,但回到自己座位就忘了(没有用心去思考),也只能是失败的沟通。特别是一些表面上成功的沟通,而实际上后来证明是不成功的。举例,管理者想要手下画老虎,手下同意画老虎,但最后却画出个猫,即最后的工作输出与管理者的预期是不一样的,又得重新沟通,重新做,仍是失败的沟通。

     

  • 测试经理,今天你为你的团队服务了吗?

    2011-03-07 23:37:23Top 1 Digest 1

     

    上周五,收到产线其他部门经理的QQ,说是提供(应一些部门的要求)对公司推行已有2-3年的SPC(统计过程控制)进行培训,部门内可以推荐人参加。一开始我对此课的内容不太了解,于是向该经理要了份资料,对PPT太致翻了翻,由于粗略地看,觉得可去可不去。于是没有把资料发给下面相关人员。但后来又想起这句话“测试经理就是要为测试团队的利益提供服务的”,觉得自己应该听听其他人的意见,不能太主观,自己不想去不等于他们也不想去听。于是发给两位技术经理看。没想到,很快收到反馈,说比较适合某某方面的同事参加,再然后收到了各技术组工程师要求参加的报名 ,最后居然有10多位报名参加者。几乎是一闪念之差,就驳夺了自己团队学习成长的一个机会呀!

    坐其位,就得谋其事。测试经理,你的服务角色做到位了吗?时刻想到自己的团队,团队才想着你,这是相辅相成的。这不,通过这个例子,后来有一位工程师就问我可不可以参加其他专业方向的培训,还主动要来了他们的培训课程表发给大家。真是举手投足,影响不小啊。

  • 你工作在哪个测试G时代?

    2011-02-12 23:59:04Top 1 Digest 1

    一次,与一位朋友交流测试相关问题时,提出了一个有趣的比喻,就是以大家熟悉的移动通信技术的发展时代来比喻当今的测试发展时代,比对CMM的标准,我稍作整理,希望大家评论,补充。

    下面是一个初步想法,权且可以看作:

    1G:测试团队组建,相当于CMM1

    2G:测试流程、指南,文档体系化的建设,有明确清晰的测试管理流程体系等,谓之测试基础模型,相当于CMM2

    3G:测试效率提升,测试全面性(充分性)发挥,测试深度挖掘,并有量化的度量标准。具体来说引入可复用模块化用例基线,自动化测试,测试工具应用(代码覆盖率工具,自主开发小工具等),展开专项测试等;相当于CMM3-CMM4

    4G:专注于测试分析与设计,展开测试研究项目,研究成果的落地应用(测试新方法,新流程,新技术等),推动测试创新。相当于CMM5

      注:这些流程是一个逐层深入的过程,前一级别是后一级别的基础与前提,但同时它们也可以是一个局部交叉的过程,如:测试新方法的研究与应用,在前面的阶段也需要。只是到了4G时代,它成了测试工作的重点,属于过程的优化,改进级别。

     

  • 测试有路,抬头看岸----鄙视低头做测试

    2010-09-05 22:02:41Top 1 Digest 2

     

            昨天面试了一个西交大(国家重点大学)本科信息工程毕业的应聘者,又是一个陷入软测误区的典型例子。面试时,低着头好生委屈的样子说“同样一起毕业的几个同学,除了自己都在做开发,就是因为自己的第一份工作是在某某知名公司做测试。不知不觉中,一晃就是3年。虽然其间做过开发测试工具,但由于开发项目的实战经验缺乏,出来找开发的工作,没人要”。所谓“身在曹营心在汉”,这样的心态在测试行业中混,迟早会露马脚,测试工作又怎能做好呢?实际上有一定的开发能力,只要沉下心来,钻研测试技术,找到自己努力的方向,完全可以在测试工作上做出点成绩。却因为认识上的心态问题,出来后,非旦找不着自己的用武之地,可能连工作都很难找到,敢问首鼠两端之人哪家公司愿意用呢?惜哉!彷徨之人,人生宝贵的青春岁月就此蹉跎而去。误区呀!误区呀!都是对测试认识不足惹的祸。

           中国有句名言:三百六十行,行行出状元,做一行,爱一行,既然做上了测试,就爱测试吧,努力的付会,定会有收获。目前测试行业中不少测试人员存在的误区,相信随着行业的不断发展会越来越少,直至消失。对于已在路上的测试人员来说,需要做的就是从自身出发,改变心态,不断学习,不断改进测试方法,提高测试的有效性,不断地创造测试成功。抱怨,徘徊,消极无济于事。你不走,有人在走,过不了多久,你会觉得越来越落伍,到时前也走不进,退也觅无路。测试朋友,你愿意重蹈前面提到的应聘者的覆辙吗?

            既来之,则安之。成功之路有很多,条条大路通罗马。只有放开自己,抬起你的头,勇往直前,才能看到测试成功的彼岸。

     

  • 浮躁的测试界,为你惋惜!

    2010-07-01 22:38:19Top 1 Digest 3

      还在为自己选择的软件测试而迷茫吗?信息业的迅猛发展,互联网技术行业的崛起,只要有软件存在的地方,就需要有软件测试的存在。目前软件测试的入门还较低,这也就意味着还有很大的发展空间。

    昨天又集中面试了一批人,总体感觉,普遍的测试水平还较低,一些公司有专门的测试开发人员,但类似我们想要的作一些测试方法的研究,测试工具的开发人员,还暂无遇到比较合适的。俗话说“千里马常有,而伯乐不常有”,而现在好像是在逆道而行。一个公司,支持业务发展的是项目是产品,对测试来说最主要的还是业务测试。还有一个比较突出的点,就是外包公司的测试人员,比较多,约占面试人员的3/5。他们只做功能测试,遇到好的外包主,按他们公司的流程规范做,如中兴,华为,腾讯,还是比较幸运的,可以从大公司中学到一些正规的测试做法。就这一点来说,如果能在自己的公司测试软件,相比于外包,最起码在某些方面是幸运的,如归属感,话语权。培养测试技术人才,特别是往纵深方向发展的测试精英,需要有一个支撑平台,而这个平台,在外包公司里基本上是得不满足的。

    面试的结果虽不尽人意,但也有另外一番体会。象文思、东软、软通动力,易思博,从心底里感谢它们对基础测试人才的培养,是它们的存在,推动测试行业的基础发展,给了社会上很多毕业生,转行到IT行业的测试人予机会。但从另一方面来看,与应聘者的交流中,也流露出从一些无奈的现实。外包公司的测试人员,他们都几乎没机会接触到他们所测试产品的代码、核心代码。当然,测试的方法有很多,并不一定要进行代码测试,但是从软件构成的性质决定,如果我们只做黑盒功能测试,始终有一块代码是测试盲区,或者说这块盲区,在后续不断加强的功能测试中有时也能闯入发现一些问题,但是究其测试效率,测试方法来说,并不是一个很有效的方法。或许,也有人会说,很多公司开发人员有自己做单元测试,这当然是好事。但据我了解到的,真正把单元测试做得有声有色的公司并不多,一部分是宣称有做,只是偶尔做,一部分是做了,但效果没有监控,后来就流于形式了。留下的bug自然就到提交的测试版本中了。而是功能测试人员参发现大量的bug,一个10来万行的代码,就能提交3000多个bug(据统计,提交测试的版本平均千行故障率在15-18个)。

     

    而当问及遇一些严重、偶发bug测试如何处理,测试如何尽早发现这些bug时,基本上是瓶颈。突破瓶颈本身不是一件容易的事,但他们大部分是没有这个机会,而这个机会正是培养测试精英们所需要的。精英的成长需要平台、沃土,他们需要具备分析问题,定位问题的能力,而这些能力,就是从解决这些疑难杂症的问题中磨练出来的。

    对于偶发严重bug的重现,需要分析、定位,需要精通业务知识,掌据软件设计实现原理,而这时需要深入分析它的代码实现,如多线程的死锁,测试如何能及早发现这些致命的问题,需要分析,总结。有思考,有总结,才有改进。从问题着手分析,研究测试方法,推动测试流程或方法的改进就是一个不错的做法。

    面试归来,出现在脑海中的是这几个字“浮澡的测试界”。很大一部分应聘者才做了2-3年的功能测试,刚入行。而自己却认为没什么可学了,打算转去做测试管理。而真有机会做了管理后(测试小组长),其实也没做什么,一些协调、接口、测试项目的管理,就认为做到了管理,了不得。<<微软的秘密>>这本书很值得一看(已有再版),记得书中提到的一点,微软他们要的是哪些既懂技术,又懂经营(商业概念,商业模式)的人。微软的三套马车:产品经理、开发经理、测试经理,相信他们是要符合这种管理理念的。而我们的一些测试朋友,才做了几个月或是一年半载的测试组长,或是1-2年的功能测试,问自己,技术、管理,哪一项提得上精通?

    记得有一位国外的软件大师说过这样一席话(大致意思):一个人要在某一领域有所建树,先花三年时间把所有相关这个领域的书、资料收集起来研读;然后花三年时间实践、分析、总结,反反复复;最后再花三到四年时间总结、研究形成自己的独立体系知识,才谓得上精通。

  • 测试组织模式之三

    2010-06-28 23:07:38Top 1 Digest 2

    独立的测试组织模式

    独立的测试组织模式中,下图所示。

    项目经理,开发经理,测试经理并行,测试组织具有真正意义上的独立,具有权威的地位。测试资源与预算再也不用与开发一起合计,测试被调去支持开发调试的救火工作不属于测试部门,是开发部门内部的事了。当项目增加时,可以根据需要自由增加人力、技术的预算。向上汇报时,除了可以如实汇报外,您还可以根据产品的质量状态提出有建设性的意见或见议,管理部门会用完全开放的心态听取来自测试状态的报告,测试在研发系统中的影响力大,是测试组织管理的最佳模式。

     

    如果以项目为导向,我更愿意工作在第2种模式下的测试团队,这样与项目会走得更近,对于项目的成功与否,有着微妙的关系。

     

    第三种对于测试的独立性,权威性来说是最好的,意味着在行政线上测试团队工作在独立的测试部门,对应的开发团队及项目管理团队他们也工作在自己的部门中,为了一个项目,大家一起工作。此种情况的模式有一个显著特点就是,测试人员是对测试部门负责,一个人可以同时服务于多个项目。也就是说,对于项目来说,资源是不固定的,这对于技术平台化积累是很有效的。

     

    组织模式本质

    不管采用哪一种模式,大家都知道,天上不会掉陷饼,地球上没有天堂。公司是要通过销售产品来赚钱的,而不是通过开发它们来赚钱。当项目进度紧,版本发布必须在某一天拿出来时,质量与进度上的牲牺是一个永远达不到平衡的称陀。在项目中常表现为,开发在拼命改BUG,测试没有充分验证完成,版本顶不住市场的压力已发出了。

     

  • 测试组织模式之二

    2010-06-27 10:23:08Top 1 Digest 3

    以项目经理为核心的组织模式

    1、  以项目经理为核心的基础模式。下图所示,它是一种典型的以项目经理为核心的团队管理模式,开发小组与测试小组并存,隶属于项目经理领导。这使我想起建筑工程队的包工头,或许不太合适,但有异曲同工之处。这种模式,对于项目经理来说,是有利的,项目经理不管你是什么专业方向,对他来说都是资源工具,是完成公司交给他这项任务的必须的工具,他关注本项目的进度与质量,对于各技术专业组的技术积累,人员培养等超出他的管理范畴。但对公司来说,是需要考虑这些方面的,员工成长需要项目作为历练的平台,那么这种模式下的明显弊端需要如何弥补呢?于是出现了下面的以项目经理为核心的扩展模式。

     

    2、  以项目经理为核心的扩展模式

     

     

     

       此扩展模式中,出现了开发经理,在行政线上他管理着软件需求、开发与测试小组,这三个小组的人力资源使用情况,技术积累,人员培养情况向开发经理汇报。在项目的进度及质量上各技术小组单独向项目经理汇报。季度或年终绩效考核时,项目经理及开发经理分别在不同的管理方向对各技术小组进行评价。

      此种以项目经理为核心的管理模式中,资源稳定,整个项目团队凝聚力高,大家都在为着同一个目标:把项目做好,按时能交付产品给公司。如果项目经理的号召力强,有魅力,能把项目的内外关系处理好。又能赏识团队,在完成不同的里程碑阶段后,及时表扬项目成员,如举行适当的庆功会,犒劳员工,项目不成功都难。

       对于测试来说,比起以开发为核心的组织模式,错误报告和其他测试信息直接向项目经理汇报,有机会说真话了,测试主管与开发主管是同级,测试组织的声望更高了。但仍属同一个开发经理管辖,意味着仍需竞争同样的集中资金与预算。

    在用这种管理模式完成项目测试任务的过程中,我也曾遇到过一些尴尬的事情。

    1           资源利用率不够高效。由于给项目的资源是固定的,即一旦某位工程师加入此项目,需要到本专业任务结束或项目结束才能离开项目,对于某些特殊情况还需项目经理同意后才能释放资源。而实际上,在整个项目的开发过程中不同阶段不同技术组的任务量是不同的,比如在项目后期,主要是解决BUG使版本稳定,需求及开发人员相对工作量较少,此时有些人员完全可以加入到其他项目中,或一周安排一定的时间为原项目服务。但通常,项目经理是不会同意释放资源的。此时,即使是开发经理,也很无奈。

    2           技术平台积累不理想,技术平台积累的优先级永远低于项目任务的优先级。对于项目而言,目标很清楚,就是按时按质做出产品,提交公司生产、销售去赚钱。而对于技术部门而言,需考虑人力、技术成本。如果做完一个项目,没有一定的积累,再做同一个类似的项目时,人力、技术投入的成本有增无减,这是技术部门管理的失败。居以此,开发经理肯定会把这些担子压到各技术主管头上,要求技术主管在带领各技术小组完成项目任务的同时,必须考虑技术平台化的思路。提出要求:一个项目完成后,在下一个类似项目开始时,能全部复用或部分复用之前项目的成果,如需求架构,代码模块,测试方案或用例等。但在实际操作时,常会有一种身在江湖身不由已的感觉,为什么呢?在项目内工作时,项目的质量、进度永过远都是优先级最高的,在项目任务紧的情况下,首先考虑的是如何解决目前的问题,如新增了需求,必须先把测试方案与用例准备好,开发提交版本后,可以正常测试。对于此功能点,日后其他项目会不会用,及用在什么场合来不及考虑那么多。同开发设计一样,正在实现的设计或模块,首先考虑能满足本项目,如果再需要考虑满足日后其他项目,那么需考虑接口的封装或其他技术,需要较长的时间。

            

    3           双重考核的尴尬。项目经理在拿到公司对项目的考核结果后,根据项目完成情况开始把各种等级标准分到各技术组。各技术主管完成各技术组的一级考核后,发给项目经理进行二级考核,最后发给行政线经理,即开发经理进行最后的评定。由于开发经理没有实质性的项目结果包(或许可以理解为奖金包),评定更多的是留于形式,但也不排除出现残酷的一面,开发经理可以把项目经理定为“A”的工程师,开发经理站在其他角度调整为“B”或“C”。

  • 测试组织模式之一

    2010-06-25 22:24:17Top 1 Digest 3

    不同性质不同行业背景的公司,在其管理模式上,有些相差甚远,有些可能类同。随着信息产业的高度发展,或许可以毫不夸张地说,只要有软件在的公司,软件测试就存在。那么,各行各业的测试朋友们,你们的测试组织管理模式都是怎么样的呢?下面是笔者一些调查总结,与大家一起分享。欢迎讨论。

    不同的组织模式,决定着测试团队在项目中的位置,常见的有以下三种。

     

    n         以开发为核心的测试组织模式

    ü         以开发为核心的基础模式

    ü         以项目经理为核心的组织模式

     

    n         以项目经理为核心的测试组织模式

    ü         以项目经理为核心的基础模式

    ü         以项目经理为核心的扩展模式

    n         独立的测试组织模式

     

    下面介绍以开发为核心的测试组织模式  

      1、  以开发为核心的基础模式

    以开发为核心,测试是开发队伍中的一部分,测试负责人向开发经理汇报,多见于规模不大的一些小公司。在这种组织中,开发工程师除了负责设计的实现外,还需参与编写需求,或者需求直接由开发主管,甚至是开发经理编写,也即某些开发人员承担着双重或多重的角色。开发经理也是项目经理,带着大家一起做一个项目。在公司的发展初期常会有这种情况。

    以开发为核心的组织模式

     

    2、  以开发为核心的扩展模式

    随着公司的发展壮大,项目的开发需求增加,上面的模式已不足以支持多项目并行开发的模式,需要把某些工作从某些身兼数职的人身上剥离出来,独立成立某专业组,使分工变明确,清晰。于是下图表示的以开发为核心的组织扩展模式出现了。此模式中,成立了项目管理组,软件需求组,软件需求组向开发经理汇报,项目管理组通常向更高一级,如总监级汇报。

    这种模式,很有趣的一点,属同一软件部门的软件需求、开发、测试小组,与项目接口时,开发主管作为代表与项目接口,参加项目的各种会议。另一突出特点此种模式分开了行政线与项目线。在行政线上,各小组在人力资源管理及专业技术上向开发经理汇报,但在项目线上,工作进度与质量上,接口人向项目经理汇报,各技术小组向开发主管汇报。开发经理与项目经理并没有什么隶属关系,项目经理需要资源时需找开发经理,经理再安排主管,进行传递与控制。

     

     

     

    以开发为核心的组织扩展模式

    注:图中虚线表示项目线,实线表示行政线

     

        这种组织模式有哪些优点?在项目的接口上,只派出了开发人员为代表,可以减少接口沟通上的成本。但这其实是一把双刃剑,一方面从表面上看是可以减少各专业组直接与项目组其他专业组接口的开销,但开发代表是否足可以代表需求与测试小组,参加项目会议回来,信息传递是否能到位,是否了解需求与测试小组对项目的需求是什么?

    再从反面分析,它有什么问题吗?

    第一,   测试主管在行政线上向开发经理汇报,测试主管会感到有一种特殊与微妙的关系,报告项目的测试结果时不带上有色眼镜是不现实的。在项目线上,汇报进度与质量时,开发主管在某些方面会作一些过滤,不可能把最真实的项目质量情况反映给项目经理。当然,这种带上的有色眼镜在原则上是有度数的,不能太离谱,否则产品到了用户手上再反馈回有严重问题,情况就不那么简单了。

    第二,   在有突急任务时,在开发主管的要求下,有一些测试资源常会安排去做协助开发的调试工作(就是开发改一个问题,测试帮忙验证是否改好,常是验证突发解决用户端某些问题的临时版本)。

    第三,   测试人员需充当多个角色,如软件部门的配置管理员,软件帮助文档,手册的编写等。

    最后,测试小组在整个部门,乃至在项目中的影响越来越小,测试人员中有渴望转为开发人员,也有人想转为需求设计人员,随着时间的流逝,测试组织非但壮大不起来,反而可能消失。

       综上所述,此开发模式适合于公司发展的初期,属于一种过渡的组织模式。

    ----待续

  • 测试的价值体现:测试人员如何影响开发人员

    2012-10-27 22:25:09

                     测试的价值体现:测试人员如何影响开发人员

     新浪微博:@Aullyxiao   邮箱:ch_testinfo@126.com

    说明:本文原登于<<测试人>>杂志 No.3,转载请注明来源

    精辟名言

       当你读一本书,读到某句话或某场景,是否有这种感觉,有很多想说的话,竟然作者替你说了;有很多场景,似曾相识,貌似曾经经历过,一切都是那么的熟悉。心中自然激起一层层共鸣的涟漪,或掩卷而思,或“拍案叫绝”,或许这也就是所谓“书中自有黄金屋,书中自有言如玉”的读书之妙处吧。这样的书,谓之好书。由于每个人的背景都不同,你认为的好书,他人并不一定能找到同感。由于工作原因,读测试专业相关的书籍不少,但让我记忆深刻,并会常常拿出来翻来翻去的好像并不多,不过JWJames A.Whittaker)的<<探索式软件测试>>是例外,主要原因并不因为它是目前市上讨论的焦点之一,而是书中的一些精辟名言让我觉得很受用。

    例如:最近发生在身边的一些事情,让我一直在反思“测试的价值到底是什么?”,围绕这一主题思考,便又想到JW在书中提到的这句精辟名言:

    “软件测试的真正价值并不体现在代码中找出了多少缺陷,而是发现设计和编程人员解决问题方法上的局限,思路中的狭隘和技能方面的不足 托尼.霍尔,1996)“

    当第一次看到这句话时,正如前面提到的,激起了我思想的层层涟漪,似曾相识,道理亦明,似是心中埋藏很久的一句话,终于有人替自己说出来了。怎么好的至理名言,不敢独享,于是把这句话放在新浪微博上,与圈中朋友分享,见如下截图,自是引来不少同仁的反馈。

     为什么会激起我思想的层层涟漪,品着这句话,回顾过去。如果说过去我是无意识地去影响开发,那是因为有足够经验的驱使,为了把产品做好,不仅是软件开发人员,还是需求设计人员,甚至是产品开发链的其他成员,我都会主动出击去影响他们(或许这也是一个加勒比海盗学者的特点之一,读<<学习要像加勤比海盗>>后的自我发现)。常常,在面试时我会问应聘者:“做测试工作,让你感到自豪的事是什么?”,大部分人回答的是:“发现Bug,特别是一些让开发难于解决的严重bug,是最开心,最有成就感的事了“。而相反,测试大师们恰恰建议我们要丢弃软件缺陷数量、缺陷严重性、测试用例的多少、自动化代码量等可量化的衡量指标,转而通过观察测试人员提高了多少开发人员的工作绩效来评估。面对这些差距,笔者倒也觉得正常,如同做任何一件事都有一个循序渐进的过程,毕竟软件测试在国内的起步较晚,据去年我做的一些数据调查,基本上晚了约20年。但,这并不意味着我们只能望洋兴叹,站在巨人的肩膀上,我们可以看得更高更远。

    前行中的反思

       就测试而言,质量如生命,效率如健康。软件测试人员是质量的最后把关者,守护神,这个我们都谈得很多了。谈到质量,我们会提及很多方法,如黑盒,白盒,灰盒,最近比较流行的敏捷测试,探索性测试等。谈到效率,我们会不由自主提及自动化测试,自动化工具等。测试的使命就是围绕产品的质量、效率转。我们的出发点都很好,但在解决问题的方法上,往往是集中在结果上,即出现了什么结果,再去想办法解决它。对于测试来说,可以理解这个“结果”就是软件的缺陷。我们经常也谈,测试要尽早介入,尽早发现问题,尽早把bug消灭在摇蓝中等。这些说的都是事,而我们恰恰忽视了一个很最重要的东西,就是在整个产品开发链中,产生这些事的人的问题。(注:这里不是谈人的管理问题)。如果我们能盯住人(角色),因为这些问题实际都是由前面的人产生的,我们是否可更加轻松。

    把我们的眼光放得更宽远一些,锁定可能会出现问题的设计人员或编程人员身上,用心去发现他们解决问题时的方法局限,思路狭隘或技能不足的体现,便能尽早发现问题。下面是案例分享。

     

    【案例】用户场景联调

    说明:故事是真实的,但为便于阐述及机密原因,案例中的人物及相关信息,采用化名

    人物:

    D0:软件项目经理

    D1Team 1的软件开发工程师

    D2Team2的软件开发工程师

    D3Team3 的软件开发工程师

    T0:测试负责人

     

    背景:

       P-001是一款基于Linux平台开发的医用设备软件,属于嵌入式软件系统,按计划明天早上需发布带打印功能的软件版本。

    发现问题:

    为顺利开展明天要测试的软件打印功能,测试负责人T0已把相关测试人员的工作安排就绪。按惯例,开发人员提交代码正式发布版本前,应该确认自己所提交的功能是否符合需求,不存在低级问题。例如:打印功能,在UI层用户通过点击“打印“按钮即可得到一张数据报表,这也是团队对开发人员的基本要求。但是,此打印功能涉及多个子模块,这些子模块分别由不同的开发团队完成,各子模块的逻辑关系如下图所示。

    打印模块设计框图

     

    T0很清楚一些开发人员的想法、特点,也即是他们的思路狭隘点。尽管有流程或规范要求要如何做如何做,据过去一些项目的经验,总会有一些开发人员爱犯错,事后找一堆这样那样的理由,言之什么是意外,什么什么又是意外等(其实是没有克服一些困难)。

    负责P-001项目软件开发团队的办公位置离测试人员并不远,抱着几分担心与怀疑,T0在发版本的前天下午便主动过去“打听军情”。得知负责打印模块的开发工程师D1并无用真实打印机确认他的程序是否能在用户场景下跑。他给的解释是这样的:“我调试过程序,是没问题的。为什么呢?我负责打印的应用层部分,责职是收集用户的数据,并按要求准备好指定格式的数据,然后把这些数据发出去,只要能发出去,就说明我的程序是没问题的。目前我是采用虚拟打印机,即采用打印到文件中的方法进行调试的,我认为这样做是能达到预期的”。同时,T0也清楚地知道,负责打印模块中间层的开发人员D2属于另一开发团队,目前正在为其他项目服务,同样负责底层打印驱动的工程师D3也不在项目中。

     

    解决问题:

    T0明白D1的调试思路,但如果打印数据子模块与打印平台(逻辑处理)子模块接口间存在问题,对于用户来说不是一样吗,即打印失败。于是向他分析这样做可能存在的问题,如果问题一旦发生,测试人员必将会提交bug,并要求重发版本。与其这样,不如开发人员做一些必要的用户场景使用的联调。D1表示也理解,好像该这样做,但表示他的时间有限,且他不知道哪里有打印机等等。T0于是又把P-001的软件负责人D0找来,说明清楚问题发生的可能性,影响情况,并表示愿意提供打印机等资源协助相关开发人员进行用户场景的联调。

    第二天早上一上班,T0发现并没有收到自动构建版本发布的邮件与QQ消息,问及软件开发负责人D0,回答:“打印平台与打印数据的接口地方存在问题,昨晚已安排两人进行问题的排查,正在更改打印平台的相关代码,版本稍后发布”。事情正如T0所料,不过,问题能在版本发布之前发现,要比留到测试端发现,提交bug后再解决成本低很多,这也正是T0想要的结果。

     小结:

    测试朋友,很熟悉的开发与测试工作场景吧。T0的行动,推动了把问题暴露在版本提交测试前,这对产品质量的稳定,开发过程的成本降低无疑是有贡献的。或许,你会说测试人员提交的bug能说服开发人员去解决,已不是一件容易的事,更何况推动开发人员按你的思路去做某件事呢?而这正是真正体现测试人员价值的地方。这不仅涉及技术、流程,还有沟通协调等。需要有足够的经验或知识去影响开发,帮助开发,让开发人员信服,充满挑战。

    细心的读者,也许你已从案例中发现了挑战的起点、方法。这里再补充两点可操作的思路,第一:从开发的差异性角度入手分析,例如通常情况下,对产品的业务知识熟悉程度,测试人员比较优势,可帮助开发人员掌握更多的用户场景,及分析存在风险的地方;第二:对发现的bug进行归类,分析,通过提供这些数据,帮助开发解决问题时能更充分与更完备,尽量减少重打开的bug数。

    末了,送大家一句话,也是笔者常激励自己的一句话“测试之路,路漫漫其修远兮,吾将上下而求索”。

     

  • 一种测试人才培养模式

    2012-02-23 23:57:54

       每年的年终或年初都是在忙于绩效面谈、年初计划商谈等。这不,今天算谈完了两个,由于上班第一天,相对时间比较宽裕,与每人都聊了近1.5小时。

       回头想想,真羡慕他们,还有人如此重视他们总结中反馈的问题,并一一沟通落实。晓之理,动之以情。对她们的疑问、困惑进行分析、讨论、解决。对于刚转正的新员工,据其特点,指引方向,以免走弯路。对于老员,针对其不同的诉需,给到提高的机会等。

    针对刚转正毕业生的培养,往哪些方向上努力、牵引,下面是一个示意图:

     

    测试人才培养模式

    图中表示,学生进入公司后,在通过同一道门的培训后,尽管安排在同一岗位,但所接触的东西不同。一小段时间,如2-3个月后,据其掌握情况的不同,判断其优劣势,然后因材施教,进而在不同发展方向上的进行牵引。先易后难的学生(从UI功能开始),日后再深入到系统底层的工作相对比较难,重点在功能黑盒测试上发展。反过来,先难后易的学生,只要能突破这个难点,然后再熟悉业务,很自然会透过UI功能,理解到其内部实现,容易形成系统全局的思维,往深度方面考虑测试方法,对发现深层次问题更有优势。

    所以,毕业后的第一份工作或第一个岗位是做什么,对学生的职业生涯影响很大,甚至是决定性的,一点不假。

  • Bug and Defect的区别

    2009-08-02 10:27:13

    在不少BUG管理工具中,BUG录入界面常看到“BUG详细描述”字段被“缺陷详细描述”代替,认为两者是等同的。这两者是不是有同样的意思,它们之间的区别又是什么?

     

    Bug: n.臭虫,在计算机软件中是指设计上的,或者是编码上的错误,也可能是需求上的错误等,它是一个错误。根据严重度的不同,可分成有不同级别的Bug

    Defect: n.缺陷, 是指设计不合理,或设计上存在漏洞有待改进。

    下面是关于bugdefect的由来的故事

    时光倒转到了我们还使用电子管技术制造计算机的那个年代,那是计算机的主机重达数吨,并常常占据整个房间的时代。在某个实验室的某个平常的早晨,这个庞然大物突然停止了工作,我们的IT前辈们马上就开始寻找出现这种情况的原因。凭借设计图纸的引导,他们很快就圈定了可能发生问题的那一部分。在接下来的检查中,他们发现这次故障原来是一只虫子在经过两只继电器时造成了短路所致。在修复了计算机并重新开始工作之后,负责计算机维护的工程师把这次故障记录在了一份备忘录上,以便将来其他人遇到类似的情况可以迅速的找到答案。当然,他还写了一份文档给计算机的设计人员,希望以后在主机的散热孔那里可以加装一层更加细密的金属网,即不影响散热,又可以防止虫子爬到主机里。

    发现上面的区别了吗?一只虫子爬进主机引起短路的这个事件,更多的被我们称为Bug,这个名词一直从计算机硬件故障沿用到了计算机软件故障。那么Defect又是什么呢?

    还是看上面的这个例子。真正的Defect是计算机维护工程师提出来的那个问题:在主机的散热孔那里可以加装一层更加细密的金属网,即不影响散热,又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方,是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说,BugDefect的一种表现形式,而一个Defect是可以引起多种Bug的。

     

Open Toolbar