自己学习质量管理有半年的时间了，以前虽然也接触过，但从未把自己看成质量管理人员来看待，其实说自己是质量管理人员很不恰当，自己更想从事的是软件过程改进人员。

　　学习质量管理和过程改进并不难，难的是需要坚持，孤立的坚持，最糟糕的是，你的想法没人认可，英雄无用武之地。但有一点我坚信，我只要准备好，那个机会始终会到来。

　　走上这条道路，目的单纯的很。自己在以往的测试过程中，发现绝大多数项目管理混乱，管理者也不知道该从何处下手，有力没处用。

　　所以项目的成功与否，完全靠大家的发挥，项目组抗风险的能力很低很低。一方面高层埋怨项目组的无作为，一方面项目组出力不讨好。所以我想，一个人测试能力在高，那么他最大的作用也就是多发现几个缺陷，如果我们加强了项目的质量管理，寻找到一条行之有效的途径进行过程改进，那么这个作用将是巨大的，他完全能保证项目的成功。鲁迅弃医从文，不就是医身不如医心吗？我不敢与他老人家相比，但确实感觉质量管理和过程改进在国内是一个不该被忽视的领域。

　　1.   目前国内从事质量管理和过程改进的人，大多是学习国外成熟的质量模型，然后进过改进，制定一条符合自己的质量过程。这是一条捷径，但不是一条可持续发展的路子。穿别人的衣服和鞋子，总有不舒服的地方。即使完全合身，你自己也觉得别扭，不如穿自己的来的自然。所以我觉得学习别人的理论，根据理论寻找解决问题的方法，要远比直接学习别人的方法好的多。

　　2.   国内游很多过程改进的咨询公司，可以说鱼目混杂，但有一点可以肯定，他们都是拿别人的东西，来给你做咨询，至于做的好与不好，那要看这套东西是否适合你了。你去买衣服，如果没有这个号码的，你就买不到，或者根本不合身。我理解很多公司过cmmi并不是从质量角度思考，更多的从利益方面思考。cmmi过级可以提高企业的知名度，竞争力，关键是国家税收政策，可以给与cmmi过级企业给与很多优惠。这就是为什么很多cmmi过级公司，其质量实质没有发生变化的原因。

　　3.   我们非常缺少质量人才，这与市场需要有关系。大家去面试，面试官问，会写用例吗？答：会。ok，明天报道，月薪3000；  再问，会用什么工具？答：会功能自动化或者性能测试。ok，明天报道，月薪5000； 又问，会什么编程语言呢？ 答：会java，能够开发自动化测试工具和脚本。 ok，明天报道，月薪8000。 或问：以前从事过管理吗？ 答：从事过质量管理和过程改进。面试官面色不悦，说回去等通知吧。其实心里说，回去等死吧，我难道会招个指手画脚的人吗？

　　上面说的虽然有点搞，但确实是一个普遍的实情。不能得到实惠，很少有人乐于从事，个别人走上这条路子，也是公司需要半路转行过来的。

　　4.   我们学习质量管理和过程改进，方法不对头。变现为把一门很有艺术很有理论基础的学问，编程一门学习文档模板的过程，把质量过关看成是制定模板，强行推行模板和评审。这是受所谓咨询公司和专家的毒害。我无意质疑他们的能力，但确实路子错误。我们中国很山寨，但这个不能山寨，确实不能山寨，模板改来改去，还是没有自己的东西，你如何知道他符合公司的要求，如何来提高自己呢？ 即使符合，要知道你的每一篇模板，都是要付费给专利所有者的。  什么？你是从论坛免费下载的？，呵，那最初的那个人从那弄的呢？

　　下面说下，我在学习质量管理和过程改进的心得。 可以说，我不懂cmmi和ISO9001，最所知道他们是怎么回事；也没去深挖mccall和其他一些质量模型，最多知道他们提出了那些质量度量；我半年来，只做了一件事，专心看软件工程。我看的是《软件工程实践者的研究方法》（不是广告，这是美国人写的，可惜中国人写不出来）。里面只讲理论，让你轻易地明白软件过程的每个环节是怎么回事，然后你就有如梦方醒的感觉。别说是自己能寻找解决问题的办法了，就连老总也不放在眼里了（玩笑话，我们要谦虚）。所谓，朝闻道，夕可死，不过如是而已。

　　我是如何看到自己在这方面能力的提高的呢？ 在这期间，我去参加了两次外企面试，全是海归面的。我发现他们和我们本土的项目经理有几点区别：1.他们穿着讲究，谈吐优雅，这不是说人品就好。2.他们全用标准的普通话面试，不夹杂任何英文单词，即使有，也会帮你解释。3.他们基本不会问编程和工具，不像其他公司的，面试官会拿自己的优势来面试你（我面的是管理职位）。4.面试完后，他们会直接告诉你，你有哪些优点那些不足。其他的问的基本都是理论方面的东西，我当然回答的非常好，所以自信这半年时间没有白费。

　　再次强调，我说的只是个人两次面试的感觉，不代表全部。

　　最近，在策划一种质量管理工具，是集需求管理，版本管理，用例管理，缺陷管理，数据统计，报告分析于一体的。 重点在于，软件过程各个环节的依赖关系，各个部门的角色和权限。这样，我们就能依赖这个工具，很容易的进行质量管理。

　　举个例子：

　　这样一个流程：需求管理中记录来一个需求的最初来源-----这个需求得到有关人员的确认-----需求分析人员把他从技术角度解读----这个需求被技术人员详细的写进设计文档----测试人员根据以上生成测试需求----测试需求被分解成多个测试点----测试点生成测试用例树----测试人员完成用例设计（用例覆盖）----执行测试----缺陷管理----提取缺陷统计来分析测试过程----生成报告

　　说的比较简单，做起来要麻烦的多。

　　现在框架我基本想清楚了，希望有专业人士一起讨论，帮我拟补很多缺陷和不成熟的想法，人多想法多吗，我也需要有人一起探讨。有愿意的人，站内短消息给我。我们不求把这个工具整出来，只当成自己学习的过程吧。因为我算过，这个工具至少需要200W的研发资金才可以。

　　或者以后可以呢？

本文出自kuailederen的51Testing软件测试博客：http://www.51testing.com/?117068

版权声明：原创作品，转载请保留链接，标明本文原始出处、作者信息和本声明，否则将追究法律责任。