這個(gè)文章必然是有爭(zhēng)議的，我在我的微博上討論過(guò)很多次了，每次都是很有爭(zhēng)議的。有不同的觀點(diǎn)，有爭(zhēng)論總是一件好事，這樣可以引發(fā)大家的思考。所以，對(duì)于我的這篇博文，如果你贊同我的觀點(diǎn)，我會(huì)感到高興，如果你會(huì)去認(rèn)真地深入思考，我也會(huì)高興，如果你反對(duì)，沒(méi)關(guān)系，可以討論。

　　在此之前，我想說(shuō)明一下我觀點(diǎn)里的這個(gè)“專職QA”是怎么定義的。

　　1、其是很多公司成立的專門(mén)做測(cè)試的技術(shù)人員，僅測(cè)試不開(kāi)發(fā)。

　　2、這些QA對(duì)于軟件開(kāi)發(fā)技術(shù)并不熟悉，甚至不懂。

　　我經(jīng)歷過(guò)一些公司都有專職的QA團(tuán)隊(duì)（專職的測(cè)試人員），自從上個(gè)公司我的開(kāi)發(fā)團(tuán)隊(duì)在一個(gè)項(xiàng)目上被QA部門(mén)搞得一團(tuán)糟，我越來(lái)越懷疑專職QA存在在意義。我的觀點(diǎn)不一定對(duì)，但請(qǐng)讓我鮮明地表達(dá)一下??我覺(jué)得是不需要全職的QA的，甚至不需要QA這一專職角色或部門(mén)，因?yàn)，不懂開(kāi)發(fā)的人必然做不好測(cè)試。像不懂開(kāi)發(fā)的研發(fā)經(jīng)理必然管不好研發(fā)團(tuán)隊(duì)一樣。我越來(lái)越覺(jué)得Dev應(yīng)該應(yīng)該是做測(cè)試合適的人選，這必然是未來(lái)的趨勢(shì) （因?yàn)槲乙呀?jīng)看到了中國(guó)程序員的進(jìn)步，相比起10年前，的程序員已經(jīng)是非常全面了，再來(lái)十年，必然證明我的觀點(diǎn)是對(duì)的）。

　　在我正在展開(kāi)說(shuō)明之前，我想引用兩篇文章：

　　兩篇文章

　　一篇是“關(guān)于測(cè)試和測(cè)試人員”，本文的作者Sriram Krishnan是一名程序員，曾在Yahoo和微軟工作過(guò)，開(kāi)發(fā)過(guò)很多軟件，曾被紐約時(shí)報(bào)報(bào)道，寫(xiě)過(guò)一本書(shū)，本文是他的一篇博客。他在文章中表達(dá)了這幾個(gè)觀點(diǎn)??

　　大多數(shù)的開(kāi)發(fā)團(tuán)隊(duì)并不需要一個(gè)獨(dú)立的測(cè)試角色。即使要有，那么所有的開(kāi)發(fā)時(shí)間比上所有的測(cè)試時(shí)間應(yīng)該 >20：1的證據(jù)嗎？光看看一些從古至今成功的軟件開(kāi)發(fā)團(tuán)隊(duì)知道了。不論是當(dāng)今的Facebook，還是30年前初的NT團(tuán)隊(duì)，很多偉大的產(chǎn)品都是出自沒(méi)有或很少測(cè)試人員的團(tuán)隊(duì)。

　　開(kāi)發(fā)人員應(yīng)該測(cè)試自己的代碼。沒(méi)什么可說(shuō)的。背后的道理并不重要。這包括單元測(cè)試，全覆蓋的自動(dòng)化測(cè)試或手工測(cè)試或組合測(cè)試。如果你的開(kāi)發(fā)人員不能/不愿意或認(rèn)為這“不歸我管”，那你需要更好的程序員。

　　另一篇文章是鄒欣的“現(xiàn)代軟件工程講義 9 測(cè)試 QA 的角色和分工”，這是一篇很不錯(cuò)的文章。他在文章里提到了分工的必要性，比如第三方的鑒定機(jī)構(gòu)，并且也指出了分工的一些問(wèn)題，比如，畫(huà)地為牢的分工，無(wú)明確責(zé)任的分工，等，這些問(wèn)題直接命中了分工的要害。我隱約覺(jué)得，我和鄒欣的很多觀點(diǎn)是相同的，我們內(nèi)容上是相同的，只是形式上還有分歧。另外，我的觀點(diǎn)太鮮明了，從而容易導(dǎo)向極端的理解。

　　你看，我們都同意，Dev要懂測(cè)試，QA要懂開(kāi)發(fā)，只不過(guò)分工不同，既然你中有我，我中有你，那不要分彼此了，一起攜手開(kāi)發(fā)測(cè)試吧。（另外，我個(gè)人覺(jué)得不懂開(kāi)發(fā)的測(cè)試人員不可能測(cè)試得好）

　　我的故事

　　我再說(shuō)說(shuō)我糟糕的QA經(jīng)歷吧，這個(gè)公司的QA部門(mén)只做測(cè)試，他們的leader覺(jué)得所有的test design和test 的過(guò)程都不需要Dev參與，他們是獨(dú)立于Dev之外的部門(mén)，他們幾乎不關(guān)心Dev的設(shè)計(jì)和實(shí)現(xiàn)，他們只關(guān)心能跑通他們自己設(shè)計(jì)的test case。但是去執(zhí)行Test Case的時(shí)候，又需要Dev的支持，尤其在環(huán)境設(shè)置，測(cè)試工具使用，確認(rèn)是否是bug方面，全都在消耗著Dev的資源，扯的是，他們對(duì)任何線上的問(wèn)題不負(fù)責(zé)，反正出了問(wèn)題由Dev加班搞定。

　　我有一次私自review他們的test case的時(shí)候，發(fā)現(xiàn)很多的test case這樣寫(xiě)到 ? “Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在test case design的時(shí)候，沒(méi)有說(shuō)明test environment/configuration 是什么？沒(méi)有說(shuō)明test data在哪里？Test Case、Test Data、Test Configuration都沒(méi)有版本控制，還有很多Test Case設(shè)計(jì)得非常冗余（多個(gè)Test Case只測(cè)試了一個(gè)功能），不懂得分析Function Point做Test Design。另外，我不知道他們?yōu)槭裁茨敲礋嶂杂谠O(shè)計(jì)一堆各式各樣的Negative Test Case，而有很多Positive的Test Case沒(méi)有覆蓋到。為什么呢，因?yàn)樗麄儾恢篱_(kāi)發(fā)和設(shè)計(jì)的細(xì)節(jié)，所以沒(méi)有辦法設(shè)計(jì)出Effective的Test Case，只能從需求和表面上做黑盒。

　　在做性能測(cè)試的時(shí)候，需要Dev手把手的教怎么做性能測(cè)試，如何找到系統(tǒng)性能極限，如何測(cè)試系統(tǒng)的latency，如何觀察系統(tǒng)的負(fù)載（CPU，內(nèi)存，網(wǎng)絡(luò)帶寬，磁盤(pán)和網(wǎng)卡I/O，內(nèi)存換頁(yè)……）如何做Soak Test，如何觀察各個(gè)線程的資源使用情況，如何通過(guò)配置網(wǎng)絡(luò)交換機(jī)來(lái)模擬各種網(wǎng)絡(luò)錯(cuò)誤，等等，等等。

　　測(cè)試做得也不認(rèn)真，大量的False Alarm，都是環(huán)境問(wèn)題，比如：安裝新版本后沒(méi)有重啟服務(wù)，沒(méi)有使用新的配置文件，網(wǎng)絡(luò)配置，等等，等等。

　　在項(xiàng)目快要上線前的一周，我又私自查看了一下他們的Test Result，我看到5天的Soak Test 的內(nèi)存使用一直往上漲，很明顯的內(nèi)存泄露，這個(gè)情況發(fā)生在2個(gè)月前，但是一直都沒(méi)有報(bào)告，我只好和我的程序員每天都加班到凌晨，趕在上線前解決了這個(gè)問(wèn)題。但是，QA部門(mén)的同學(xué)們像沒(méi)發(fā)生什么事似的，依然正常上下班。哎……

　　為什么會(huì)這樣？我覺(jué)得有這么幾點(diǎn)原因（和鄒欣的觀點(diǎn)一樣）

　　1、給了QA全部測(cè)試的權(quán)力，但是沒(méi)有給相應(yīng)的責(zé)任，

　　2、QA沒(méi)有體會(huì)過(guò)軟件質(zhì)量出問(wèn)題后的痛苦（解決線上問(wèn)題的壓力），導(dǎo)致QA不會(huì)主動(dòng)思考和改進(jìn)。

　　3、QA對(duì)Dev的開(kāi)發(fā)過(guò)程和技術(shù)完全不了解，增加了很多QA和Dev的溝通。

　　4、QA對(duì)軟件項(xiàng)目的設(shè)計(jì)和實(shí)現(xiàn)要點(diǎn)不了解，導(dǎo)致了很多不有效的測(cè)試。

　　注：我無(wú)意在這里貶低QA的能力工作。只是我看到了QA因?yàn)闆](méi)有參與開(kāi)發(fā)的一些現(xiàn)實(shí)問(wèn)題。

　　我的觀點(diǎn)

　　鄒欣對(duì)于分工出現(xiàn)的問(wèn)題給出了兩點(diǎn)解決方法：

　　● 充分授權(quán)和信任（Empower team members）

　　● 各司其職，對(duì)項(xiàng)目共同負(fù)責(zé)（Establish clear accountability and shared responsibility）

　　我的觀點(diǎn)是，理論上正確，操作上太虛了。這像我們喊的“為人民服務(wù)”的口號(hào)一樣，沒(méi)有具體的方法，根本無(wú)法落實(shí)。

　　我無(wú)意在這里貶低QA的工作，我也無(wú)意因?yàn)檫@個(gè)事走向另一個(gè)極端。但是，我在現(xiàn)在公司的經(jīng)歷，還有很多新興公司的做法，我越來(lái)越覺(jué)得軟件開(kāi)發(fā)，真的不需要專職的QA，更不需要只寫(xiě)代碼不懂做測(cè)試的專職的Dev。觀點(diǎn)如下：

　　1）開(kāi)發(fā)人員做測(cè)試更有效

　　● 開(kāi)發(fā)人員本來(lái)要測(cè)試自己寫(xiě)的軟件，如果開(kāi)發(fā)人員不懂測(cè)試，或是對(duì)測(cè)試不專業(yè)，那么這不是一個(gè)專業(yè)的開(kāi)發(fā)人員。

　　● 開(kāi)發(fā)人員了解整個(gè)軟件的設(shè)計(jì)和開(kāi)發(fā)過(guò)程，開(kāi)發(fā)人員是清楚應(yīng)該怎么測(cè)試的，這包括單元測(cè)試，功能測(cè)試，性能測(cè)試，回歸測(cè)試，以及Soak Test 等。

　　● 開(kāi)發(fā)人員知道怎么測(cè)試是有效的。開(kāi)發(fā)人員知道所有的function point，知道fix一個(gè)bug后，哪些測(cè)試要做回歸和驗(yàn)證，哪些不需要。開(kāi)發(fā)人員的技術(shù)能力知道怎么才能更好的做測(cè)試。

　　很多開(kāi)發(fā)人員只喜歡寫(xiě)代碼，不喜歡做測(cè)試，或是他們說(shuō)，開(kāi)發(fā)人員應(yīng)該關(guān)注于開(kāi)發(fā)，而不是測(cè)試。這個(gè)思路相當(dāng)?shù)腻e(cuò)誤。開(kāi)發(fā)人員應(yīng)該關(guān)注的是軟件質(zhì)量，需要證明自己的開(kāi)發(fā)成果的質(zhì)量。開(kāi)發(fā)人員如果都不知道怎么做測(cè)試，這個(gè)開(kāi)發(fā)人員是一個(gè)不合格的開(kāi)發(fā)人員。