前几天Check in了几行代码，部署到了生产环境，一切正常，这个是我第一次把代码提交到生产环境。今天早上看到一篇文章“Who fixes the bugs?”。这篇文章是讲述了一个测试工程师是否应该去深入到代码，然后自己把发现的BUG修复，这样的一个事情。很有趣，我刚做完这样的事情，就看到一篇文章讲述同样的问题。读完那篇文章以后会发现，软件测试真的是一件跟上下文(Context)联系的特别紧密的事情。所以在做某一件事，或者讨论某一件事情的时候，最好先把上下文先弄清楚，然后再下判断。下面阐述一下文章的观点。
● 作为一个团队里面的成员，每个人都有义务和责任去提高产品的质量。
● 测试工程师来修复BUG这样的行为虽然不会京城在传统的软件行业里面发生，但是也不能以这个为理由去打击它。
● 你不必要去创造一个敏捷的过程来规定测试工程师可以修复BUG。
上面这三点非常模棱两可的观点，在我看来就是作者让读者知道，我们在充分了解上下文的前提下来进行判断。对于我现在所处的公司的环境下，昨天我做的事情是没啥问题的。
1. 公司没有严格的流程或者指引，规定了Tester不能往生产的代码库中check-in代码
2. 现在公司的Developer不是很多，有时候能帮的地方尽量帮助，自己也能学到东西
3. 对于我测试过的代码，熟悉起来还是会比较快
4. 我也需要对代码的质量负责
那么这样做会有什么问题呢?
1. 变相地成了自己测试自己的代码，不推荐
2. 对于测试小组来说，比较难留住人才(那篇文章的观点，也是一个现实)
在多数情况下，测试工程师的工作就是不断地折磨那个被测软件，不断地向被测系统提问题;然后等待被测系统的答案，从这些答案里面获得尽可能多的信息，软件测试在开发生命周期活动里面扮演一个服务者的作用，给开发经理，开发工程师，各个stakeholder们提供信息，所以软件工程师甚少去修 BUG。而且在大多数非常正规的企业中，测试工程师设置没机会看到代码，所以也没有办法能修复BUG。软件工程师可以修复BUG吗?可以，不过不常见。
文章来源于领测软件测试网 https://www.ltesting.net/
