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