<不能成為專業(yè)軟件測試人員的10大理由>終于在兩個夜晚苦戰(zhàn)到12點(diǎn)多翻譯完了，2，3年不接觸英文還真是很生硬，可能大家一看就知道是Chinese English，哈哈！只能請閱者委屈一下了，以后我也要多多學(xué)習(xí)英文啦～
原文作者是之前負(fù)責(zé)惠普公司QC的一名測試前輩，無意中看到他的文章，有些我覺得還是很在點(diǎn)子上的。所以就當(dāng)一邊學(xué)習(xí)英文，一邊總結(jié)測試相關(guān)的就出來這篇譯文了。
在譯文出來之后，有同行伙伴提出了一些疑問，在這里我也結(jié)合我的工作實際闡述一下。
1、文章中第二點(diǎn)，深圳的一位網(wǎng)友就提出了：在中國90%以上的中國IT企業(yè)很難做到讓測試人員在開發(fā)早期甚至需求早期就介入。
我不太確定他說的90%是否有數(shù)據(jù)支持，至少我所認(rèn)識的很多同行都會在需求階段讓測試人員介入，如果還不是這樣，我想測試人員是時候做些什么了吧？？絕不能坐以待斃.我待過2家互聯(lián)網(wǎng)公司，說說我的經(jīng)歷。一家是創(chuàng)業(yè)型公司，一家是中型公司，當(dāng)時我們是如何做的呢？創(chuàng)業(yè)型公司，或許很多這樣的公司，都沒有較為成熟的文檔化和流程，以快為先，唯快不破。沒有專職的項目經(jīng)理，甚至產(chǎn)品經(jīng)理都沒有，我們的CEO，CTO就是產(chǎn)品經(jīng)理，甚至我們每個人都可以為產(chǎn)品設(shè)計貢獻(xiàn)思路。老板們的想法已經(jīng)成型了，很多時候在腦子里，沒有文檔化，然后開需求宣講會議，因為人不多，開發(fā)測試都會參加，會議上也會有一些討論，這是大改，還有小改，可能就發(fā)郵件給大家，郵件也算是文檔吧。大多數(shù)時候大家很難在會議上就發(fā)現(xiàn)需求的全部漏洞，但是基于對系統(tǒng)的理解，有時候測試人員的思路也很活躍，“可以...不可以...如果...如果不...”類似使用場景的思路聯(lián)想到的問題可能起到作用。但是不去參加這個會議，可能就只能到了代碼寫完提交給測試了，這個時候最大的問題就是，如果開發(fā)人員理解的有偏差，測試人員如何保證產(chǎn)品的質(zhì)量呢？只有保證測試的需求與業(yè)務(wù)需求是一致的，才能真正的說明我們測試的是一款正確的產(chǎn)品。
其實如果不去參加那個宣講會議，就是那位網(wǎng)友說的情況了。在我看來，在沒有項目流程的公司里，測試人員要更加主動，主動承擔(dān)一部分項目管理的工作。如果沒有文檔，可以主動申請加入到需求宣講中去。其實參與到宣講中，至少還有一個好處，可以知道為什么這么改，有助于我們更加理解業(yè)務(wù)的初衷。如果是郵件發(fā)出來的，可能就沒有這么多來龍去脈。
上面說的是業(yè)務(wù)需求，其實對于開發(fā)設(shè)計的會議，我當(dāng)時也是非常樂意去參加的，你會知道他們的設(shè)計思路是什么，大致算法如何設(shè)計，有哪些異常處理，是否有異常報警機(jī)制等等。沒錯，我能想到的一些use case也會提出來，讓他們開發(fā)的時候考慮到。這樣子，我能更懂產(chǎn)品，測試思路也更寬闊，而且讓開發(fā)理解我們測試人的思路，如果他們也懂一些測試思路，很多問題在開發(fā)設(shè)計階段就可以規(guī)避了，這也是盡早測試的意義所在。
再說第二家公司也就是現(xiàn)在這里，流程稍微正規(guī)一些，不過也是一步一步建立起來的，測試人員也參與到流程改進(jìn)中去。有專職的項目經(jīng)理和產(chǎn)品經(jīng)理，需求是產(chǎn)品經(jīng)理事先設(shè)計好的，只不過設(shè)計的時候可能會閱讀原有的設(shè)計文檔或咨詢一下之前負(fù)責(zé)的開發(fā)或測試原來的業(yè)務(wù)邏輯，這也是為了取其精華去其糟粕，這是需求設(shè)計完成前測試人員唯一介入的；當(dāng)需求設(shè)計完成后會發(fā)給項目組成員，組織宣講，會議上可以提出相關(guān)疑問，產(chǎn)品經(jīng)理會記錄下來再進(jìn)行確認(rèn)或重新設(shè)計。之后需求設(shè)計freeze，如果不是特別大的問題，其他需求變更可以考慮延后處理，對于嚴(yán)重需求漏洞就需要及時變更，越往后成本越高.之后開發(fā)測試人員會依照新的文檔開始工作，但是在測試設(shè)計用例或開發(fā)代碼設(shè)計時經(jīng)過更深入業(yè)務(wù)理解之后可能又會發(fā)現(xiàn)需求的一些問題，會集中反饋出來，產(chǎn)品經(jīng)理一樣會酌情考慮是否延后處理.后面的階段就是進(jìn)行用例評審，組織測試等等了.總體來看流程比之前創(chuàng)業(yè)型公司順了很多，至少測試可以較早的介入.當(dāng)然，測試人員參與到流程改進(jìn)中也是一大保證.至少我的經(jīng)歷來看，項目延期的幾大殺手就是需求變更，無流程和糟糕的項目計劃.
2、對于第三點(diǎn)中的情況，我想作者的意圖也只是想要表達(dá)場景法設(shè)計用例的重要性，而且場景法設(shè)計用例的確是貫徹軟件測試的始末.如深圳的那位朋友所說，沒有一款產(chǎn)品是需要覆蓋100%的，我們的策略都是一定要覆蓋重要核心的業(yè)務(wù)，次要的備選流業(yè)務(wù)可以通過產(chǎn)品，開發(fā)及測試三方評審哪些需要覆蓋哪些不需要覆蓋，以得出測試的范疇，因為即使測試出了bug，也可能不修復(fù)，我想不被修復(fù)的bug是沒有意義的.而且評審過的測試范圍即使某天出現(xiàn)遺漏我們也有說法.
3、對于第一點(diǎn)中談的代碼能力.我個人意見是：這項技能是錦上添花，并不需要每個測試人員都需要具備.但是具備了就可以參與到項目的code review中去，在提測前期就可以發(fā)現(xiàn)很多問題，而且具有代碼能力的測試人員可能更懂得如何更有效的去測試。
據(jù)我對功能邏輯性bug的分析，記住是功能邏輯性的不包括其他類型諸如UIUE上的。主要有3類：
1）大多數(shù)bug是很簡單的代碼錯誤，如果一經(jīng)過大家的評審，就能發(fā)現(xiàn)出來；
2）一部分是業(yè)務(wù)理解錯誤，寫的代碼不符合業(yè)務(wù)需求，代碼走讀時也可以發(fā)現(xiàn)部分問題，但是不能發(fā)現(xiàn)全部，代碼走讀也可能只是對核心業(yè)務(wù)代碼或接口部分進(jìn)行的評審，而系統(tǒng)層面的需要在系統(tǒng)測試階段才能發(fā)現(xiàn)。如果在前期保證產(chǎn)品，開發(fā)和測試三方對需求理解的一致性，就可以減少很多這樣的bug，不是嗎？
3）還有一小部分可能真的是比較難處理的bug，難復(fù)現(xiàn)，難調(diào)試。這部分東東，測試人員也很難評審出來。
4、最后我再補(bǔ)充一條：能夠?qū)⒆詣踊褪止y試很好結(jié)合起來開展工作的也是一大挑戰(zhàn)。
我相信在很多公司，專業(yè)做自動化測試的團(tuán)隊對業(yè)務(wù)理解不夠深刻，他們很多時候都是在研究新的技術(shù)完善測試框架，或者按照手工測試用例的優(yōu)先級編寫腳本，然后只是讓自動化daily run。而且他們不一定知道測試哪個需求時需要自動化配合做回歸測試，或者哪些內(nèi)容可以提前把關(guān)鍵流程的用例事先實現(xiàn)自動化，等提測之后用來自動化smoke，哪些需求變更了又需要更新自動化。如果通過雙方測試人員溝通，這種溝通的成本我覺得也不少。熟練地掌握手工測試技能并且能夠自動化實現(xiàn)，在項目測試中很好的配合，以節(jié)省回歸測試時間，這是一個挑戰(zhàn)也是一個趨勢。
相關(guān)鏈接：
不能成為專業(yè)軟件測試人員的10大理由