以法家理念有效说服研发修改bug

转载请保留：本文出自zengyixun的51Testing软件测试博客：http://www.51testing.com/?981051Testing软件测试网'|;{!~3Qu

    没有什么时间写东西了，原来很多好的想法，都不能系统的进行阐述，只会在看到有的贴子时，给一些零星的回贴，这一次居然得了个每日一问二等奖，看来此回贴还是受到认可的，看了一等奖（ID：sun_0910）的回答，真的很棒，很有一些严禁的味道，思考特别全面，一看就是特牛P的权威人士，一看就是受过极正规的训练，这种写文章与做事的严谨作风值得大家学习，而我的个人的文章风格就是喜欢简单化，口语化，形像化，具体化，但在工作上就应该像sun_0910一样才好，而且我是一个测试领域的法家份子，也希望能将法家的思想与质量测试理念相统一，一家之研究吧！

    原贴地址：http://bbs.51testing.com/thread-130627-6-1.html（测试如何更有效去说服研发修改bug？）

    由于我做过两年的开发，5年的测试，在测试过程中，自己也做过些测试工具，也有测试人员对我的测试工具来进行测试的经历，所以我首先站在一个开发人员的角度来看，什么样的bug与测试人员能说服我呢？要说这个问题，我们首先要有有一个假定：假定开发人员不是一个神经病（多数其实都不是，如果是，那么应该由人力资源部负责），既然开发人员不是神经病，那么你一定要相信他对于自己所做的模块也是抱着认真负责的态度，希望把功能顺利实现，而不会出现什么意外状况的，所以当有人给我提出一个bug是我确实没有想到的，而又实在的影响到这个模块的功能，我做为一个开发人员会考虑修改这个问题，如果这个问题还有一点点深度，我会更加开心，抱着挑战的态度，也抱着赶快把此功能搞定的急迫心情去修改它，由此得到一个好的绩效与认同，所以像这样的bug，需要测试人员来说服我么？当然不需要。然后再看看什么样的问题我不喜欢，曾经我做过一个测试工具，新来的测试人员对我的工具进行了测试，在测试的同时，也使新人学习了各种业务知识，在这些测试者中，我就很明显的对那种能提出功能性错误，或者我考虑不周造成的错误（这一定要用专业的测试方法才能测出的）的新人，我会报着一种对他的欣赏的态度去修改他提出的问题，而对那些，没事找事，总是按自己的主观意愿提出一些使用上问题的人，给以鄙视，比如新来的测试负责人，在我修改完所有问题后，叫我把下拉框改成tab页，嘿嘿，你喜欢tab页，我就喜欢下拉框，测试部难到没有别的事情做了吗，做这么无聊的事，也就是说，有关操作习惯问题本就是你有你的习惯，我有我的习惯，凭什么就说你的习惯是代表了广大人民群众呢？是吧？
\we0p)@r {#yN0    看了上面一段，相信大家就知道了什么样的问题会得到认同，这样的问题，根本不用你去说服谁，但是，这个世界如果如此简单，就不会有战争了，是吧，所以，我刚才说的只是开发人员的立场，说这些只是让大家明白一个心理特性，并不意味着，开发人员的这种立场在任何场景都是正确的。51Testing软件测试网O[x&s6L
    所以，还有一个测试人员的立场问题，对测试而言，我们有各种测试方法去发现bug，有时有的测试方法做出来的测试结果确实发现了问题，但这个问题可能会引发开发人员的反感，这是因为开发人员对测试的工作不了解造成的，比如，我们用边界测试发现一个问题，但开发人员会说，谁会去输入这样的数值呢，在实际工作中，人家是不会这样操作的，所以拒绝修改这样的问题，怎么办呢？这个时候，其实如果一味的让每个测试人员去与每个开发人员讲道理做宣传，其实效率是低下的，而应该把这一类问题记录下来，由测试部门进行一个评估，然后与项目负责人进行沟通，在一个适合的时间点（致命问题、严重问题都改得差不多且还有时间的时候），对此类问题进行一个全面的修改，如果是一个好的公司与部门，还会就此类问题进行总结归类，并对此类问题定义出严重程度与修改的优先等级，如此就完成了一项过程改进，当下个项目出现类似的问题时，一个制度化的结果已经在这里了，开发人员再次见到类似问题，自己就会在已经把致命与严重问题修改完成的情况下，对此种等级的问题再进行修改，而不需要再次做没有必要的沟通了。再比如使用操作性问题，其实就是一种体验测试，如果这种问题由每一个测试人员零星提出，不但没有科学调查与说服力，也会得到开发人员的白眼，所以有关使用方便的问题，也应该单独的当成一个整体事件去做，而立下科学调查的标准化决议，当项目组与测试部与市场都搭成统一标准后，做这些事，还会有阻力吗？
X$T.Vk w^ t0b0

.qa ])@d:f0转载请保留：本文出自zengyixun的51Testing软件测试博客：http://www.51testing.com/?9810

    我看有的人的解决方法是人情世故，有的人的方法则是权利压人，还有的人的方法是每回都去以理服人（以德服人，怎么感觉测试总是低声下气的？难怪人家不改你的问题），还有总总方法，但不是有后遗症，就是回回都要如此，搞得效率低下，所以真正的方法应该是，把一项不太受到开发人员重视，但又确实是不可小视的那些问题，想办法通过外交努力，搭成统一的科学的标准化的制度化的行业规范，当一个制度在这里时，没有人会觉得你是和他过不去，只会觉得，这是制度的要求，我们本就都该这样做，就好像你迟到了，你不会认为是人事MM对你有偏见，也不会认为人事MM水平低，不懂得以人为本的道理吧？当然不会，因为几点上班是一项制度。有人见过搞人力资源的人在网上发贴问：请问人事如何更有效的说服员工们不要迟到呢？呵呵，一家之言哈！51Testing软件测试网)m2[6cWo'|
    至于那些根本就不是问题的问题，求求你们千万不要用你和开发人员的好关系，把不是问题的问题给修改了（还好有问题审核与软件配置管理），我的主呀，阿米托佛！
%S%F9l7U[[MR\R P"F051Testing软件测试网8Vd2Kx+C
S