什么样的QA令人讨厌 [原]

QA是一个有一些尴尬的职业。而其中很多原因是我们自己造成的。其实很多时候我们都在找别人的问题，改进别人的缺点。但我们自己呢？谁注意到我们自己身上的问题。谁在关注我们自己的问题，我想大家可以先总结一下那些QA的行为最容易引起开发人员的反感，这样对我们以后的工作也有好处。 

只讲教条的QA实在令人烦 
    我在做一个开发人员的时候，我们当时的一个管理人员（当时还不叫QA），是从德国回来的一个海龟，为了加强管理，给我们来了一个工作时间统计，要求我们记录每天的工作情况，而且要精确到分钟，他要每周检查。如果你和别人联调，你们两个人的工作记录必须完全对应的上。当时我们的工作的确很忙，而且也不原意作这么详细的记录。结果是每周周末的时候我们所以开发人员都在一起凑报告。报告当然很漂亮了，但最后所有的开发人员都不愿意和他合作。最后他离开了我们部门。就这个事情事后回想起来让人感慨很多。 
首先，他使用的方法应该是提高工作效率比较高的方法。但这种方法总给人一种我们被监视，不被信任的感觉。而当时我们所有的开发人员都希望将这个项目做好，所以这种感觉就让我们很不舒服。 
其次，管理强度一下改变太多。我们原来没有很详细的工作计划和检查，当时我们这些开发人员也注意到了这些问题，如果工作记录以日，上午/下午甚至以小时为单位我们都会接受的，但以分钟为单位就太细致了，我做每一个工作的时候都要去看表记录时间，这也太不现实了。（打断工作的顺流） 
所以，我个人感觉作为一个QA人员在实际工作的时候一定要考虑开发人员的承受能力，不能教条的照搬书本和原来工作单位的QA方法，否则一定会产生相反的结果 

不能照顾开发人员的QA是很令人讨厌的 
    还是那个项目，当时我们有很多的开发统计数据需要做，我们开发人员因为很忙，所以都不愿意去做这些统计工作（也因为当时的经验认为这些统计没有意义），记得一天QA来了，向我们要数据，我们告诉他还没有统计完，（当时已经晚上10点了多了），QA认为实在不配合他工作，而那些数据必须今天作好。于是说将所有的数据都给他，他来做报表，明天上午给我们，我们已经干了一天，一听这话自然乐意地将所有数据都给了他，于是打道回府，谁知道，我刚进家门。我家里人就告诉我单位有人来电话说我们房间的门无法锁，我的妈呀，出门的时候，我刚问了他有没有钥匙锁门，他说有，这才几分钟，而且12月的寒冬，我们已经苦干了几个月，每天都是16个小时的工作，怎么遇上这么一个QA，没有办法只好又杀回单位，那QA见我来了，大喜，和我一起锁了门就走了。分手的时候，我问了一句“报表做完了”。"没有,明天再做"。听了这话，差一点将我气得背过气去，如果你认为可以明天做。为什么要避开发人员非今天作。难道你不知道开发人员现在都处于一种开发状态吗？ 
问题1，QA并没有让我们看到那些统计报表的意义，而且也不愿意告诉这么做有什么好处，当开发比较紧张的时候，必须抽出时间作和开发无关的事情（开发人员认为）是很令开发人员反感的 
问题2，QA既然答应帮我们做，而且告诉我们什么时间给我们，就应该实现的承诺，否则开发人员认为他是一个没有信用的人，（技术人员都很轴的，在这种时候不会听你的解释的） 
问题3，俗话说，己之不欲，无施于人，如果你不能完成的事情，也要考虑别人的感受，在可能的范围内给别人一定的范围，不要逼得人太紧 

不学习的QA是令人讨厌的QA 
   QA工作有很象开发人员，需要不断的学习，否则必然遭到淘汰，很多时候，QA的开发知识要比开发人员还要丰富。 
今年的新生培训工作领导很重视，让我们负责，我们组织QA去讲解开发，其中一个人讲解软件工程，一个人讲解测试，先说说讲解测试的这个同志。 
该同志进行了很好的准备，在讲解的时候，对测试的原则、方法、使用的工具都做了很详细的介绍，但更重要是他能够结合实际工作情况讲解，比如测试人员会和开发人员产生那些问题。比如开发人员容易犯那些问题。比如各种开发方式的核心是什么，主要解决那些问题。还有我们在原来开发的系统存在的问题，这些问题在用户那里会产生什么样的后果，以及为什么会产生那些问题。新来的工作人员都听得很高兴。 
另外一个哥们讲的软件工程就不是太好了，他只是将很多理论放到ppt上，很多东西都无法举出实例来，一味的念稿子，成了概念的堆砌，而且很多新的开发方法，比如rup，xp，psp，tsp干脆就不知道。结果新生们好的开始看书，有一些干脆开始睡觉。 
对比这两个同志的工作效果，其实有很多有趣的东西，那个讲测试的同志一直工作在开发的第一线，而且善于总结学习。我们单位的很多东西都是他总结出来的，而后一个哥们后来当了领导，不原意在做第一线的开发工作，一直在吃原来的老本。对新的技术和方法已经失去了其应有的敏感性，这样的QA人员是不能适应和开发人员的交流的。