一、测试经理的技术水平
讨论意见:
Ø 最好是大于组员
Ø 测试经理 和 测试组长有一些区别。测试经理偏重于管理,技术上能比组员强自然是好事,但我觉得他可以不是技术最强的,不过至少水平上也比较均衡
Ø 因为我以前也算是带过测试队伍的,但因为还要分管质量那块的工作,所以技术力量肯定不如测试人员的强。所以在工作中还是遇到很多问题的
Ø 测试经理当然应该把管理放在第一位,但技术比较强更有助于工作
Ø 特别是对测试组在做测试计划的时候,有时候会把计划计划的超长。。因为我不太了解新的测试工具,所以一点办法都没有
Ø 做管理技术不精通做起来太痛苦啦,这就是我个人的经验。。。虽然说测试管理是需要管理,但这个应该是技术型的管理。。。要不真的难众呀
我的看法:
v 同意测试经理水平要均衡的说法,测试相关的方面都要有相当的认识,这样和下属沟通起来才不会有大的障碍
v 一个好的测试团队,除了需要测试经理在大方向上做决定外,还需要有几个测试专家,这些专家都是关注于某一方面,比如自动化测试,有相当的专长,这样遇到一些技术问题,比如采用新的测试工具会带来多大的风险等可听听这些专家的意见再做判断
二、单元测试由谁来做
讨论意见:
Ø 单元测试还是让有开发经验的人或开发人员完成比较好
Ø 可以的话,单元测试应该交给tester来完成——现在最大的阻碍恐怕是技术问题,tester 水平不够,无法完成。双重矛盾
Ø 让测试开发员做单元测试还差不多
我的看法:
v 单元测试由谁来做不是重点,关键是如何保证单元测试的质量
v 通常单元测试可以采用以下几种方式:
l 谁开发谁测试,这样的优点是开发人员开发时会比较认真,缺点是开发人员可能会不自觉的刻意让测试通过
l 开发人员A开发,开发人员B测试(交叉测试),这样的优点是单元测试的效果有保障,缺点是进度上不好控制(A、B都有开发任务,不能完全保持同步)、A开发时容易马虎
l 测试人员完成单元测试,这样的优点是进度上好控制、单元测试效果有保障,缺点是对测试人员提出较高要求、开发人员开发容易马虎
l 可以结合公司的实际情况来进行选取,但都需要注意其优缺点,结合评审、定硬指标等方法来保证单元测试的质量
三、测试考试认证
讨论意见:
Ø 目前测试方面的认证,好像 我就听过 软考 的软件评测师。 至于MI的认证,属于专业厂商的,也可以考虑,不过比较贵,呵呵
Ø 基础知识还是很重要的,所以本人建议考软件评测师比那些厂商认证更实际
Ø 软件评测师,书可以看,考,我认为意义不大
Ø 通过考评测师,对于基础的巩固我想是有很大帮助的,如果你注重准备的过程而不是单纯为了考试
Ø 我考了软件评测师的认证,觉得学习的过程更享受,让我确实知道了很多,不过题目我觉得挺难的
Ø pcl版主 不也考了MI的LR认证了
我的看法:
v 很赞成注重准备过程的说法,不要为了考证而考证,这样对自己提高不大
v 含金量高的证书是很好的敲门砖,能拿当然要拿了^_^
四、如何让公司认可过程改进
讨论意见:
Ø 上午刚刚开完会,整整和开发人员和项目经理争吵了一上午,主要就争执开发与测试关系的问题,以及开发文档到底应该写成什么样,感觉阻力很大啊
Ø 今天上午已开始在分配下一阶段的工作任务,接着我就提到需求文档需要完善,结果开发人员觉得麻烦,不想搞,结果就开始就各类情况争吵
Ø 文档问题一定要力争,它对测试工作很有帮助
Ø 其实就是开发管理问题,开发人员认识不足
Ø 他们开发人员不知为什么,不喜欢写文档是通病
Ø 对测试到底需要那些工作和资源根本就不知道,还没有给他们讲道理呢,就拿一些特例和我争执,所以说还是一个意识问题,他们会体会到这样做的好处的
Ø 上午和他们进行争论,主要是财务行业的项目经理安排工作,对于开发文档有点想省略或者简化的意思,而且下面的开发人员对于文档的作用认识也不清楚,所以我才很着急
Ø 开发人员不写文档确实有很多堂而皇之的理由,比如他们会告诉你详细设计文档 没有写的意义,因为伪码无法进行debug,真正开发的流程不是先写LLD,再coding,而是coding完,debug之后了,才开始写注释,写LLD
Ø 可惜,他是开发人员出身,而且对自己的技术很自信,所持的理念是优秀的开发或者水平高的人,写出来的代码错误很少,需要很小量的测试,这好像是整个中国软件业的通病,是公司急功近利的一种表现
Ø 你听到这样的解释理由还真没办法,你如何说服他们?因为他们的理由听起来还确实挺有道理。所以正是这种原因,最后由于项目进度的拖延,详细设计文档不了了之,干脆取代以 user manual了
Ø 同时由于没有LLD文档,造成我们的单元测试更是无从实施——所以单元测试也做不起来。当然另一方面的原因是单元测试实施起来工作量太可怕,耗费的成本让PM看不到收益的可能。他觉得风险大,没办法实施。加上tester往往要靠开发的帮忙才能进展工作。就更加困难了
Ø 其实问题都很普遍,关键是你的作用范围太小。digman一定体会到了,为什么推行起来难度这么大,其实是你的分量不够,呵呵
Ø 就以文档的事情来说,靠你一个测试组长的建议不够的,这种牵扯到过程改进的东西,需要更高一级领导的介入,就是组织级的推动
我的看法:
v 过程改进本身就是一件很困难的事,大家想想我们要想改变自己的一个习惯也不是那么容易的
v 推进过程改进不要把管理层和开发人员都推到我们的对立面去了,争吵和责怪不能解决问题
v 要推进过程改进关键还是要让公司所有人认可过程改进
v 针对管理层和一般研发人员(包含开发和测试了)要采取不同的策略:
l 对于管理层,管理层关心的是你反映的问题会对项目整体或者公司本身产生多大的影响,以及你有什么好的对策,可以进行哪些过程改进,记住一定要具体明确,只会发牢骚是管理层最讨厌的一件事
l 对于一般研发人员,他们关心的是过程改进对自己有什么帮助,会对自己产生什么影响,所以要采取引导的方式,可以和他们进行沟通,了解他们在工作中有哪些觉得不方便的,哪些觉得不合理的,并让他们给出一些建议,这样参考了他们的意见的过程改进才更容易被接受和认可
五、软件评审
讨论意见:
Ø 测试用例的评审可以交给测试组长来负责,问题在于你的分工没做好,测试组长当然应当对这个项目熟悉。测试经理-(测试主管)-测试组长。组长都不熟,那你还做什么项目啦
Ø 这说明你的测试工作安排有问题,当你没有经理介入项目的时候,应该安排一个相关的测试负责人介入项目——毕竟总有人在做测试,写TC对吧,所以要学会适当的放权
Ø 用例评审因为涉及到从测试角度去考虑问题,所以理应由项目的测试组长负责。除非PM比较开通,对测试也比较了解,否则评审会出问题
Ø 我们每个项目配备一个测试人员,从需求就开始介入,但是自己写的东西自己能进行评审么
Ø 把自己作为经理的角色去考虑,然后找一个项目测试负责人去做项目的具体测试所有工作
Ø 你搞一个评审,很多人会认为占用他们的时间,而且对他自己意义不大
Ø 真实情况,测试组三个人,我是负责人,每个人手底下同时有两个以上项目进行测试,每个项目只配备一名测试人员,现在这种情况,用例怎么控制
Ø 我的原则:多少人就做多少事
Ø 评审的七大误区,可以参考参考。
l 误区一:评审参与者不了解评审过程
l 误区二:评审人员评论开发人员,而不是产品
l 误区三:评审没有被安排进入项目计划
l 误区四:评审会议变成了问题解决方案讨论会
l 误区五:评审人员事先对评审材料没有足够了解
l 误区六:评审人员关注于非实质性问题
l 误区七:忽视细节
Ø 大家开个会,先把评审的工作过程定下来再做评审,否则恶性循环,评审让人觉得在浪费时间
Ø 评审是会请开发人员参加的,但这个时候开发人员基本上是不会指出技术问题的,因为谁也不愿说自己做差。。如果说了,别人就会问,既然你知道这不对,为什么不事先改正呢
Ø 你这样的评