测试管理群聊天记录20050617_读后感

skinapi

一、测试经理的技术水平
讨论意见：
1、最好是大于组员
2、测试经理 和 测试组长有一些区别。测试经理偏重于管理，技术上能比组员强自然是好事，但我觉得他可以不是技术最强的，不过至少水平上也比较均衡
3、因为我以前也算是带过测试队伍的，但因为还要分管质量那块的工作，所以技术力量肯定不如测试人员的强。所以在工作中还是遇到很多问题的
4、测试经理当然应该把管理放在第一位，但技术比较强更有助于工作
5、特别是对测试组在做测试计划的时候，有时候会把计划计划的超长。。因为我不太了解新的测试工具，所以一点办法都没有
6、做管理技术不精通做起来太痛苦啦，这就是我个人的经验。。。虽然说测试管理是需要管理，但这个应该是技术型的管理。。。要不真的难众呀

我的看法：
1、同意测试经理水平要均衡的说法，测试相关的方面都要有相当的认识，这样和下属沟通起来才不会有大的障碍
2、一个好的测试团队，除了需要测试经理在大方向上做决定外，还需要有几个测试专家，这些专家都是关注于某一方面，比如自动化测试，有相当的专长，这样遇到一些技术问题，比如采用新的测试工具会带来多大的风险等可听听这些专家的意见再做判断


二、单元测试由谁来做
讨论意见：
1、单元测试还是让有开发经验的人或开发人员完成比较好
2、可以的话，单元测试应该交给tester来完成——现在最大的阻碍恐怕是技术问题，tester 水平不够，无法完成。双重矛盾
3、让测试开发员做单元测试还差不多

我的看法：
1、单元测试由谁来做不是重点，关键是如何保证单元测试的质量
2、通常单元测试可以采用以下几种方式：
   a)谁开发谁测试，这样的优点是开发人员开发时会比较认真，缺点是开发人员可能会不自觉的刻意让测试通过
   b)开发人员A开发，开发人员B测试（交叉测试），这样的优点是单元测试的效果有保障，缺点是进度上不好控制（A、B都有开发任务，不能完全保持同步）、A开发时容易马虎
   c)测试人员完成单元测试，这样的优点是进度上好控制、单元测试效果有保障，缺点是对测试人员提出较高要求、开发人员开发容易马虎
可以结合公司的实际情况来进行选取，但都需要注意其优缺点，结合评审、定硬指标等方法来保证单元测试的质量


三、测试考试认证
讨论意见：
1、目前测试方面的认证，好像 我就听过 软考 的软件评测师。 至于MI的认证，属于专业厂商的，也可以考虑，不过比较贵，呵呵2、基础知识还是很重要的,所以本人建议考软件评测师比那些厂商认证更实际
3、软件评测师，书可以看，考，我认为意义不大
4、通过考评测师,对于基础的巩固我想是有很大帮助的,如果你注重准备的过程而不是单纯为了考试
5、我考了软件评测师的认证，觉得学习的过程更享受，让我确实知道了很多，不过题目我觉得挺难的
6、pcl版主 不也考了MI的LR认证了

我的看法：
1、很赞成注重准备过程的说法，不要为了考证而考证，这样对自己提高不大
2、含金量高的证书是很好的敲门砖，能拿当然要拿了^_^


四、如何让公司认可过程改进
讨论意见：
1、上午刚刚开完会，整整和开发人员和项目经理争吵了一上午，主要就争执开发与测试关系的问题，以及开发文档到底应该写成什么样，感觉阻力很大啊
2、今天上午已开始在分配下一阶段的工作任务，接着我就提到需求文档需要完善，结果开发人员觉得麻烦，不想搞，结果就开始就各类情况争吵
3、文档问题一定要力争，它对测试工作很有帮助
4、其实就是开发管理问题，开发人员认识不足
5、他们开发人员不知为什么，不喜欢写文档是通病
6、对测试到底需要那些工作和资源根本就不知道，还没有给他们讲道理呢，就拿一些特例和我争执，所以说还是一个意识问题，他们会体会到这样做的好处的
7、上午和他们进行争论，主要是财务行业的项目经理安排工作，对于开发文档有点想省略或者简化的意思，而且下面的开发人员对于文档的作用认识也不清楚，所以我才很着急
8、开发人员不写文档确实有很多堂而皇之的理由，比如他们会告诉你详细设计文档 没有写的意义，因为伪码无法进行debug，真正开发的流程不是先写LLD，再coding，而是coding完，debug之后了，才开始写注释，写LLD
9、可惜，他是开发人员出身，而且对自己的技术很自信，所持的理念是优秀的开发或者水平高的人，写出来的代码错误很少，需要很小量的测试，这好像是整个中国软件业的通病，是公司急功近利的一种表现
10、你听到这样的解释理由还真没办法，你如何说服他们？因为他们的理由听起来还确实挺有道理。所以正是这种原因，最后由于项目进度的拖延，详细设计文档不了了之，干脆取代以 user manual了
11、同时由于没有LLD文档，造成我们的单元测试更是无从实施——所以单元测试也做不起来。当然另一方面的原因是单元测试实施起来工作量太可怕，耗费的成本让PM看不到收益的可能。他觉得风险大，没办法实施。加上tester往往要靠开发的帮忙才能进展工作。就更加困难了
12、其实问题都很普遍，关键是你的作用范围太小。digman一定体会到了，为什么推行起来难度这么大，其实是你的分量不够，呵呵
13、就以文档的事情来说，靠你一个测试组长的建议不够的，这种牵扯到过程改进的东西，需要更高一级领导的介入，就是组织级的推动

我的看法：
1、过程改进本身就是一件很困难的事，大家想想我们要想改变自己的一个习惯也不是那么容易的
2、推进过程改进不要把管理层和开发人员都推到我们的对立面去了，争吵和责怪不能解决问题
3、要推进过程改进关键还是要让公司所有人认可过程改进
4、针对管理层和一般研发人员（包含开发和测试了）要采取不同的策略：
   a)对于管理层，管理层关心的是你反映的问题会对项目整体或者公司本身产生多大的影响，以及你有什么好的对策，可以进行哪些过程改进，记住一定要具体明确，只会发牢骚是管理层最讨厌的一件事
   b)对于一般研发人员，他们关心的是过程改进对自己有什么帮助，会对自己产生什么影响，所以要采取引导的方式，可以和他们进行沟通，了解他们在工作中有哪些觉得不方便的，哪些觉得不合理的，并让他们给出一些建议，这样参考了他们的意见的过程改进才更容易被接受和认可


五、软件评审
讨论意见：
1、测试用例的评审可以交给测试组长来负责，问题在于你的分工没做好，测试组长当然应当对这个项目熟悉。测试经理－（测试主管）－测试组长。组长都不熟，那你还做什么项目啦
2、这说明你的测试工作安排有问题，当你没有经理介入项目的时候，应该安排一个相关的测试负责人介入项目——毕竟总有人在做测试，写TC对吧，所以要学会适当的放权
3、用例评审因为涉及到从测试角度去考虑问题，所以理应由项目的测试组长负责。除非PM比较开通，对测试也比较了解，否则评审会出问题
4、我们每个项目配备一个测试人员，从需求就开始介入，但是自己写的东西自己能进行评审么
5、把自己作为经理的角色去考虑，然后找一个项目测试负责人去做项目的具体测试所有工作
6、你搞一个评审，很多人会认为占用他们的时间，而且对他自己意义不大
7、真实情况，测试组三个人，我是负责人，每个人手底下同时有两个以上项目进行测试，每个项目只配备一名测试人员，现在这种情况，用例怎么控制
8、我的原则：多少人就做多少事
9、评审的七大误区，可以参考参考。
误区一：评审参与者不了解评审过程
误区二：评审人员评论开发人员，而不是产品
误区三：评审没有被安排进入项目计划
误区四：评审会议变成了问题解决方案讨论会
误区五：评审人员事先对评审材料没有足够了解
误区六：评审人员关注于非实质性问题
误区七：忽视细节
10、大家开个会，先把评审的工作过程定下来再做评审，否则恶性循环，评审让人觉得在浪费时间
11、评审是会请开发人员参加的，但这个时候开发人员基本上是不会指出技术问题的，因为谁也不愿说自己做差。。如果说了，别人就会问，既然你知道这不对，为什么不事先改正呢
12、你这样的评审本身存在问题，开发人员是进行交叉评审。比如一个项目组5个人的话，那么A的部分其实是BCDE在评审
13、还有，评审有很多，比如测试用例的评审，那就是开发的在协助评审测试用例了，就不是“自己”的问题了

我的看法：
1、评审的质量的确不好控制
2、按照一般的评审过程，评审的对象发到各评审人员后，各评审人员会提交意见，然后汇总意见，再开评审会对意见进行确认，最后作者根据确认的意见进行修改，个人觉得这种标准模式容易导致评审形式化，问题出在评审人员单独评审提交意见这个环节（由于各方面原因不会有太好的效果）
3、是不是可以考虑直接通过头脑风暴的形式来进行评审（省掉评审意见的提前提交），所有人员聚到一起，作者对他的思路和内容进行详细说明，大家集中精力来进行分析和讨论，确定存在的问题，这样的效果肯定比标准的流程好，缺点就是评审时间会比较长


六、环境的搭建和维护
讨论意见：
1、我们的系统测试环境是我自己搭建的，根据开发部门列出的配置清单，我们有个visual work，每个系统都有它自己独立的配置，独立的IP
2、举两个例子。测试环境代码的更新，交给开发组专人负责，还是测试组专人负责？利弊何在？如果测试环境交由测试组自己搞定，那么像权限脚本的生成、代码编译等事情在提交到生成环境的时候将由另外的人去做，这样会不会存在问题？你们认为应该 测试环境 和生产环境（实际运行环境） 的搭建是统一由一个人来做还是各自为政
3、问题在于，测试环境如果自己搭建，到时候投入实际环境运行时，搭建环境的可能是：开发部、运维组、工程组、系统组等的其他人在做，这里存在一个问题，不知道大家有没有想到
4、我们比较简单就是程序员自己去给用户搭建，而且程序员比我们测试人员更懂，我们只是模拟用户实际安装配置时可能遇到的问题，事实证明，这样做很有必要
5、说说我的想法，我认为需要有这么一个“角色”，专门负责环境的搭建，无论是 开发环境、测试环境，还是用户环境。不知道大家怎么看
6、如果软件规模不大，技术难度不高，那么可以各自为政，但是一旦规模庞大或者环境搭建的技术难度很高，就可能出问题
7、分工应当明细化，各司其职，不应当什么人什么事都做。这就跟早期的 开发自己开发自己测试 一个样。没有明细的分工，最后会发现，大家做的事都好像差不多，测试组 跟开发组 、工程组，有很多重叠的工作
8、开发环境肯定是和测试环境分开了的，问题在于不管开发环境还是测试环境还是用户环境， 这个环境搭建需要统一管理

我的看法：
1、环境本身是一个很宽泛的概念，要对其进行讨论，是不是应该先将环境细化，然后再分别讨论
2、环境的搭建有时候是很考验技术能力的，不是什么人都能搭建
3、环境的搭建需要考虑的一个问题是重复进行的问题，一是不要多个人或者组织都去独立考虑环境的搭建，二是环境搭建的自动化问题（最好不要每次都从头考虑，还要方便共享）
4、环境的搭建最好通过一些专家来进行，搭建好后，一方面是形成文字上的东西，也就是搭建手册，如果谁想自己从头搭建可以参考，二是搭建好的环境要方便复制，其它的人能很方便的拿过去直接使用

songfun

同样感谢skinapi大哥的整理！