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