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