我再也不想找BUG了

一个从事了软件测试工作十年有余的软件测试工程说：“我再也不想找BUG了！”

“什么？你想改行吗？”

“不，不是的。我不是说找BUG不重要，我是说，我是做软件测试工作的，软件测试的目的其实不应该是‘找BUG’。测试的工作保存运行产品、信息沟通等很多其他的活动，找到BUG只是一种副产物。我讨厌发现大量的BUG，这些BUG早就该被发现或者这种错误根本就不应该发生。很多问题在交付给用户之后才发现，那时候为时已晚。我们不是想找到错误，而是要阻止错误的发生！”

现在大量的软件测试图书都在教人用各种办法发现bug，其中很多侧重于“寻找”，他们期望通过测试来提交软件质量，但这里可能有一个误解，测试本省，又怎么能够提高软件质量呢？

“测试不是目的”“测试要及早引入”“测试要绑定在软件开发生命周期的过程中”……但，最好的解决办法是将“预防错误的发生”放在首位。

以上是读“测试有道——微软测试技术心得”一书引用的一段话，现在所在的公司，也很注重开发期预防BUG的产生，但是可能力道还不够，开发人员比较依赖测试人员，以至于测试人员问一句，他们回一句，或者测试人员说一句，他们改一句，他们很少自测（或者只测正确的基本功能），对于一些上个sprint出现过的比较典型的BUG还需要测试人员的提示，或者还会引起其它的bug，他们不管，开发人员对于文档一向比较粗心，或许他们只对代码程序感兴趣，对于需求文档，有时测试比开发更熟悉，甚至最终的需求文档由测试方生成，或许当公司慢慢的开始看重测试的时候，开发与测试的关系并不是对立的，而逐渐演变成依赖，公司重视测试，开发人员刚开始或许不会太在意，一旦他们因为忽视测试而遭遇到麻烦后，会变的很乖，他们很聪明，在打tag之前不停的与测试人员交流，让测试人员帮忙测系统，从而在开发周期内解决掉一些相对比较严重的bug，其实这样只是效仿敏捷开发，并没有做到真正的敏捷，真正的敏捷是通过不断的总结，总结上一个sprint遇到的问题，在下一个sprint中开发会根据前面的经验来避免之前出现过的问题，而不是发包前的测试，这样反而影响项目的进度，延长的开发周期，延迟了测试的进行，其实在一个sprint开发周期中，越早送测越好，当然在送测前开发人员也需要对自己开发的功能模块进行自测，避免一些比较明显的问题传到测试人员手中，否则可能会影响个人的绩效，或者影响个人的水平，甚至整个团队，开发人员非常有必要做总结，虽然每个sprint周期后，测试人员会将所有找出的bug进行归类，并了解这些bug产生的原因，以及最好能记录住如何更好的避免此类bug的产生，但是开发人员自己也需要总结，这样开发人员可以加深对bug的理解，从而达到更有效的预防。

其实我所在公司的开发人员还是比较好交流的，从我来到公司，参加项目以来，对测试与开发对立的局面几乎没有映像，项目组中的开发人员都非常的可爱，当你给找到问题时，他们并没有太多的抱怨，而是很“无辜”的接受，并傻傻的抓着头，自言自语的思索到“这是为什么呢？”，(*^__^*) 嘻嘻……很可爱吧！在项目设计的时候我们也会参与进来，对于项目的设计问题，我偶尔也会提出自己的见解，每当得到他们认可的时候，我非常的开心，希望我永远也尝不到开发与测试势不两立的滋味，很享受现在公司的工作方式，也可以学到很多新的知识，我是一名刚从大学步入社会的女生，对生活和工作没有太多的经验，或许是上天对我的眷顾，让我进入现在的公司，在这里我学到了很多，认识了很多，发现了很多自己的不足，希望自己的人生道路可能走的很成功，欢迎所有的挑战，希望我的知识可以和敏捷一起越走越成熟……