熊志男：敏捷測試頭腦風(fēng)暴
2012年11月3日下午，外面滂沱大雨使得氣溫驟然下降，在中國科技會展中心的一間會議室里，卻被熱烈的氣氛包圍著。嘉賓們和參會者的大腦高速運轉(zhuǎn)產(chǎn)生的熱量，在室內(nèi)空調(diào)熱力配合下，使得屋內(nèi)顯得很熱。
我也在積極思考“敏捷”這兩個字的含義，努力著在以往的測試實踐和學(xué)習(xí)經(jīng)驗中尋找相關(guān)的體會。我希望通過向嘉賓提問更多的問題，來獲取更多的知識。
我想起我頭腦中也產(chǎn)生過一下幾種對于敏捷測試的態(tài)度：
一、敏捷崇拜者，因為敏捷是新技術(shù)思想，所以和其他的新技術(shù)崇拜一樣，當(dāng)時年輕的心總想學(xué)習(xí)先進的新的知識來超越自我。
二、旁觀者，經(jīng)過對于敏捷的初淺認(rèn)識和測試實踐，發(fā)現(xiàn)敏捷并沒有真正出現(xiàn)在我的實際工作中。而且，敏捷是一種應(yīng)用在整個開發(fā)流程中的思想模式，那么只有在敏捷開發(fā)流程中的測試才可稱之為“敏捷測試”。那么單獨的“敏捷測試”應(yīng)該是個偽命題了。而且我又適應(yīng)了現(xiàn)在的工作，無法改變開發(fā)的流程，那么敏捷與我無關(guān)了？
三、敏捷反感者，當(dāng)然這不是我自己的想法，但是我可以清楚得感覺到一些合作過的同事、同行是持這種態(tài)度。他們已經(jīng)適應(yīng)了現(xiàn)有的流程，對于敏捷的***印象“敏捷就是沒有詳細(xì)的文檔”，那怎么行，我們需求從哪里獲取？測試用例描述不細(xì)致，我們測試執(zhí)行參考什么？流程如何控制？其實我不清楚他們是害怕還是不愿去接受新鮮事物。
在參加這種技術(shù)交流時，常常感覺很恥于說出自己沒有什么敏捷的經(jīng)歷。好像這就證明我能力有限，所經(jīng)歷的公司水平有限一樣。我想無論是否是我低估了自己和自己所處的環(huán)境。還是要面對自己，才能夠成長進步。
那么記憶中與敏捷沾邊的工作，就是2009年在廣聯(lián)達公司的測試工作。印象最深的幾點：
一、測試用例簡化，以往的花了很長時間編寫的測試用例，除了在***輪測試時候會參考執(zhí)行以外，作用非常有限，而且維護困難，每次例會討論用例維護的方案總是不了了之。用例簡化后，針對每個功能點列出簡要的測試點在QC中，而不去寫詳細(xì)的用例。在每一輪的測試過程中都會去維護增加新的測試點。
二、測試提前，區(qū)別以往等待開發(fā)人員給出正式版本后再進行測試。而是，在得到需求的***時刻，列出相應(yīng)的測試點并發(fā)給開發(fā)人員確認(rèn)，在與開發(fā)的溝通過程中得到對于需求的統(tǒng)一認(rèn)識。然后在開發(fā)做完每一個新功能時，一個測試和一個開發(fā)坐在開發(fā)的工位上按照測試點，逐一在本機上驗證。這樣就不用從服務(wù)器上等到正式版本再測試了。
三、組織結(jié)構(gòu)，拆散原來獨立的測試部和開發(fā)部，根據(jù)產(chǎn)品、功能、地區(qū)版本劃分，開發(fā)和測試以大概2：1的比例組成一個團隊，當(dāng)然由于需求人手緊張，所以一個需求人員會同時參與幾個團隊的工作。這樣轉(zhuǎn)變了原來開發(fā)與測試的對立局面。
四、每日站會，其實當(dāng)時對于每天早上開會有些反感，也許是因為還沒有真正體會到他的意義。
如果說敏捷中的測試必然都是需要自動化的，那么我們當(dāng)時的自動化測試只是應(yīng)用于冒煙測試和基本功能驗證。無論是不是完全意義上的敏捷，還是有所收獲的。記得后來曾經(jīng)參加其他公司的面試，說起敏捷經(jīng)歷，我還會拿出此段經(jīng)歷來充數(shù)，汗！
那么回到現(xiàn)在的測試項目中，是否可以按照敏捷的思想來施行呢？會起到什么作用？解決什么問題？
從賀炘老師的PPT中看出，分析現(xiàn)在項目是否適合敏捷可以從以下幾點來看：
1.項目特點
那么我們的項目是離岸的測試項目，作為開發(fā)的客戶是在美國，在項目特征上我們無法實現(xiàn)開發(fā)和測試結(jié)合的團隊結(jié)構(gòu)。而且由于時差問題，我們發(fā)出的問題只能在第二天得到答復(fù)，就無法實現(xiàn)敏捷所要求的及時反饋和溝通。
2.支持環(huán)境
正因為我們是獨立的項目，在自主性上比較強，采取何種形式的測試流程和方式，不會太受制于人。另外我們的自動化回歸測試一直在比較穩(wěn)定得運行。以此來說，是屬于比較適合的。
3.人員素質(zhì)
我們的項目一直以來秉承著建立一個小而強的團隊的原則，僅有的5個測試人員，從業(yè)務(wù)水平、代碼能力、測試能力方面來說，都是能夠獨當(dāng)一面的。
那么是無法做到敏捷了？敏捷的真諦是什么？是一定要符合幾個關(guān)鍵字嗎？還是一種解決問題的思路呢？
今天的會議中嘉賓們對于敏捷的意義探討有幾點：快速的價值交付、更加透明和有效的溝通、減少項目中的不必要的時間浪費。
回過頭來，這不正是我們項目中存在的問題嗎？
不得不說我們有很多人已經(jīng)非常習(xí)慣于這個功利社會的游戲規(guī)則，也許一個人推動敏捷測試、推動探索測試、推動自動測試，真正目的是為了績效、薪資和升遷。我們不能否認(rèn)這是錯的，但是如果解決了不了實際問題，反而由此產(chǎn)生的很多問題會給這些優(yōu)秀的思想和技術(shù)臉上抹黑。還是在以后的項目中，踏踏實實學(xué)習(xí)，小心翼翼實踐吧，共勉！
