转自：http://blog.csdn.net/imlogic/archive/2007/03/22/1537328.aspx

测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.偶第一次发现这种问题的时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵.

测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.

测试工程师最憎恨听到的话:"为什么这个bug没有在测试的发现呢?"这句话经常是客户发现bug后,老板对测 试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种"踢猫"的行为.对于这句话,偶第一次听到这句话的反映是"我们怎么可能发现所有的bug呢",后来变成"制造bug的人不是我们,是开发",到现在的"让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样"的回复.

测试工程师最郁闷的事:"刚才那个版本打包打错了,你们要重测".新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.

测试工程师最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.

测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的标准,建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.

测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了,找出的问题给开发人员一顿臭扁,无比丢人啦.

测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.偶有时会难过的吃饭都没心情.搞得偶的开发朋友说了一句最让人吐血的话:"要不要我在代码里放几个bug给你呀,hoho"

测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.偶有一同事在调薪的第二天就申请转开发,说测试太没前途了.

测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug 库).有时总会碰到一些很小的或是很难判断的问题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.

测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.

测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理.

在我看来管理就是怎么样让人尽其才、物尽其用，用最少的资源完成一件事。

软件测试中的物主要就是需求文档、测试用例、测试脚本、Bug报告，为了管理这些物，产生了需求管理、用例管理、配置管理、缺陷管理以及配套的工具，这些工具以后会慢慢融合。

其实，物的管理主要决还是解CRUD（增删改查），放的时候知道往哪放，找的时候知道去哪里找，修改和删除的时候要有记录可追踪可恢复。这些物没感情没思想不需要理解，只要根据人的需要合理安置。

人就不一样了，经常让你觉得无所适从无处安放，怎样在把人当成物一样管理和发挥人的主观能动性之间找到契合点难之又难。做得好的闷着头发大财，做得不好的看着各种方法论这样那样的争论眼冒金星。

到底该如何管好人，或者说如何改进流程呢？我想从建立组织内部的知识库做起是比较好的选择。

建立知识库的主要目的是加强老成员的交流与合作，促使组织的经验与知识显式化，帮助新成员尽快融入团队，尽早上手工作。这些目的本身就与流程改进的目的接近，建立知识库的过程某种程度上就是流程改进的过程，而且又有物作为行为的导向，SCM这么普及大概也是因为CMM2中最容易形成物的原因吧。所以，行之有效的知识库的建立是过程成熟的重要标志。

 

那么如何建立测试知识库呢？每周一问里面讨论过这个http://bbs.51testing.com/thread-120097-1-2.html

我来个总结一下就是：BBS+Blog+Wiki+FileServer

我觉得BBS就是开会，虽然有的单位开会太多太假不好，可是老不开会一潭死水也不好，把会开得有理有趣最好，当然最重要的是有效果。看看BBS在中国的流行程度就知道这种形式蛮适合中国人的。适当管理和引导的内部论坛，肯定能为组织的知识库建设打下良好基础。

Blog就是大会总结，一般开完会都会让大家写个总结啥的，把分散的东西经过自己的加工处理形成自己的，把论坛帖子直接发到Blog当然也行，最好是自己的回复都可以，现在的论坛和Blog的结合还是不太紧密。

Wiki就是总结汇总，经过大家讨论达成共识的总结写入Wiki，作为组织知识库的主要表现形式。不过组织内的Wiki我想可能会是业务知识为主，测试技术方面的还是像51这样的公共论坛来建立比较好，嗯，去建议版提个建议去。

FileServer主要用来存放标准、规范、模板、软件等组织的文档和工具。

当然不一定要采用这些手段，随着技术的发展，以后也可能会产生更好的软件来帮助我们建立知识库，不过促进成员交流与进步，改进组织流程的基本目标是不会变的。

 

觉得我们公司的过程有点乱，管理不太到位，所以这几天看了一些质量管理和过程改进的帖子与文章，说一点自己的理解。
质量管理是为了对外提高产品质量而对内采取的一系列措施和要求，以及随之产生的方法论和辅助工具在管理活动中的指导和应用。
在软件企业中，影响质量最重要的三个因素是人、技术、过程，人与技术紧密相连又难以控制管理，所以最初避重就轻选择了过程改进来提高软件质量。
经过几十年的研究和实践，过程改进取得了很多有效的成果，比如需求管理、配置管理、缺陷管理这些都是过程中的一部分，这些部分各方比较容易达成共识，而且在一系列过程中适于独立并安排专人管理，因此逐渐规范化，为他们服务的工具也逐步完善。在过程改进是提高软件质量主要途径的指导思想下，各个企业不断梳理改进自己的过程，使企业的生产率和产品质量都有了比较大的提高。
但随着过程改进的深入，开发人员被要求做越来越多额外的工作，在他们看来这些工作不仅无助于提高产品质量而且降低了工作效率，CMM等过程改进思想显得老旧沉重成了矛头所向，更能被开发人员接受的敏捷思想呼之即出。我想敏捷只是一个代号，发出了开发人员渴望人性化管理的心声，这就要求管理者更多的考虑管理中人与技术的因素，多思考怎么留住人，而不能过分注重人员会不断流动假设下的过程改进，也就是以人为本。
就我自身的感受来说，我觉得一个过程混乱的组织谈不上什么以人为本，首先要做的应该是理清思路，让自己的过程流利起来。