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