前幾天Check in了幾行代碼，部署到了生產環境，一切正常，這個是我第一次把代碼提交到生產環境。今天早上看到一篇文章“Who fixes the bugs?”。這篇文章是講述了一個測試工程師是否應該去深入到代碼，然后自己把發現的BUG修復，這樣的一個事情。很有趣，我剛做完這樣的事情，就看到一篇文章講述同樣的問題。讀完那篇文章以后會發現，軟件測試真的是一件跟上下文(Context)聯系的特別緊密的事情。所以在做某一件事，或者討論某一件事情的時候，最好先把上下文先弄清楚，然后再下判斷。下面闡述一下文章的觀點。
● 作為一個團隊里面的成員，每個人都有義務和責任去提高產品的質量。
● 測試工程師來修復BUG這樣的行為雖然不會京城在傳統的軟件行業里面發生，但是也不能以這個為理由去打擊它。
● 你不必要去創造一個敏捷的過程來規定測試工程師可以修復BUG。
上面這三點非常模棱兩可的觀點，在我看來就是作者讓讀者知道，我們在充分了解上下文的前提下來進行判斷。對于我現在所處的公司的環境下，昨天我做的事情是沒啥問題的。
1. 公司沒有嚴格的流程或者指引，規定了Tester不能往生產的代碼庫中check-in代碼
2. 現在公司的Developer不是很多，有時候能幫的地方盡量幫助，自己也能學到東西
3. 對于我測試過的代碼，熟悉起來還是會比較快
4. 我也需要對代碼的質量負責
那么這樣做會有什么問題呢?
1. 變相地成了自己測試自己的代碼，不推薦
2. 對于測試小組來說，比較難留住人才(那篇文章的觀點，也是一個現實)
在多數情況下，測試工程師的工作就是不斷地折磨那個被測軟件，不斷地向被測系統提問題;然后等待被測系統的答案，從這些答案里面獲得盡可能多的信息，軟件測試在開發生命周期活動里面扮演一個服務者的作用，給開發經理，開發工程師，各個stakeholder們提供信息，所以軟件工程師甚少去修 BUG。而且在大多數非常正規的企業中，測試工程師設置沒機會看到代碼，所以也沒有辦法能修復BUG。軟件工程師可以修復BUG嗎?可以，不過不常見。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
