各位看官，可能看到标题的你一定认为这是一篇涉嫌“炒作”的文章，亦或是为了吸引眼球而起的标题，恭喜你猜对了一半，确实是为了吸引大家的关注而起的这个标题，不过不是为了“炒作”而只是为了让更多人关注bug，重视bug，从而挖掘bug的潜在价值--技术团队的财富。
Bug一词估计也只有相关从业人员才会比较了解，我想了解它的人没有一个不讨厌它的。这一点从给它起的名字就可以看出来，“bug”翻译成中文就是“虫子”，大家对虫子第一影响就是厌恶，所以没人喜欢它是人之常情，今天我们却要走相反的路线，好好的“夸一夸”令大家都不爽的“虫子”。
研发人员的“错题集”--bug追踪记录
说道错题集估计大家都不陌生，但凡热爱学习（关注成绩）的同学可能都有自己的“武林秘籍”--考试或者练习测验中做错的题目。通过对这本武林秘籍中的题目进行针对性的练习，来减少重复踩坑带来的分数损失。对于研发同学在研发阶段产生的bug和线上出现的事故，我们也可以做个类比，把它们称为研发同学的“错题集”。对于研发同学如何对待这本“错题集”，不仅仅关乎软件代码质量的提高，更关乎个人技能的持续成长。如何让一个人不重复犯同一类错误，如何让一个团队不重复踩相同的“技术坑 ”，如何把团队付出昂贵代价积累下的经验传承下来，一直都是技术管理者头疼的问题。那“研发团队错题集”不失是一种可行的方案，通过实际的bug案例，产生的原因、造成的影响、如何避免类似问题的产生，可以让新来的同学迅速继承以前趟过的坑。我认为对技术团队来说，技术积累大致可以分为两类，“成功案例”和“失败教训”，我认为失败教训对其他团队的参考意义更大，因为相对于成功来说，失败有更大的普适性。综上，认真对待自己犯过的“错误”，把它当做持续提高自己的“训练集”，既能完成软件代码质量的不断提高，又能让研发团队整体战斗力持续提升，你说它是不是一笔“财富”。
测试人员的“遗漏用例集”--非用例执行bug记录和在线bug记录
如果你认为bug只是针对研发同学的，那就大错特错了。对于测试同学bug也是一种“财富”，这不仅仅体现在“工作量”上，更体现在后续根据bug不断改进用例设计方法的实战经验上。相信测试同学大部分会有这样的经历。
经历A：
一期需求中辛辛苦苦准备了很多用例，开发提测后按照用例执行一遍发现没有发现几个bug，于是基于职业敏感，开始又一轮的探索性测试，又发现很多bug，甚至比通过用例发现的bug还要多，于是提出“设计测试用例无用论”。（私下认为，应该是设计用例的方法有问题，需要改进设计用例的方法，并推广之，让更少的同学经历A事件）
经历B：
辛辛苦苦熬到需求上线，发布不久出现线上故障，紧急回滚或者紧急线上修复，所有事情都忙完后，开始准备线上故障报告，包括故障原因，开始时间，修复时间，解决方法，后续避免措施，怀着忐忑的心情结束一天的工作。
其实经历A、B本质上讲都是由于用例设计不充分导致的，在互联网敏捷发布、持续交付的大环境下，如何更好更快的设计更加全面的测试用例是测试同学需要不断追求的，而bug集恰恰是最好的“场景数据”，从这个角度讲我想大家也都认为bug是一种财富。
bug不仅是软件研发中发生的错误，同时也是帮助大家技能持续成长的一种财富，如何把这种潜在资产的价值发挥出来，是研发团队需求不断探索和实践的。
网友评论