向敏捷測試轉變

引言

簡潔，輕量的敏捷開發模型是為了提供給軟體開發團隊一種迅速應對客戶需求變化，能夠高效完成專案工作，降低整體風險的開發模式。敏捷的測試也是服務於這個目標的測試團隊對測試工作的敏捷定義。

傳統測試模式下成長起來的測試團隊要如何轉向敏捷，從個人和團隊的兩個層面又要做出那些轉變呢？有什麼方法和標準衡量敏捷測試團隊的績效？如何幫助團隊的每個人規劃正確的發展路線？團隊在部署敏捷的過程中又會遇到哪些問題呢？本文主體就這些問題展開論述。

有關敏捷測試團隊和個人的績效

在我們過去一年多開發敏捷專案的令人難忘的經歷中，測試團隊攜手開闢了一條新的道路，並發展至今。測試團隊也曾多次因其突出的能力，積極的態度以及卓有成效的工作成果屢受嘉獎。今天我們仍然在思考怎樣做好敏捷測試，因為我們仍然遇到更新的問題，我們在積累成熟經驗的同時也在不斷嘗試改進原有方式和突破對新問題的困擾。在這裡，我們的實踐或許因基於幸運的歷史背景和人文環境，能夠基本成功的部署敏捷，但我們對敏捷測試在整個軟體開發過程中的角色定位，和職責的理解，仍然對將要採用敏捷測試，以及感興趣于敏捷的測試團隊，和對那些需要從傳統測試轉變到敏捷測試模式的團隊起到參考作用。

“如何看待敏捷測試和對測試人員做績效考評呢？”——敏捷團隊中無論開發還是測試都不是個人的開發和測試，這是團隊的工作。一名好的測試人員除了能夠做好本職測試工作外，表現為願意並能夠做超出原有範圍的工作，能夠並願意幫助團隊其他成員解決其他複雜問題，實現團隊的共同目標。測試人員能夠主動發現並彌補團隊中的重要缺失的環節，幫助團隊其他成員完成工作任務。

測試團隊的職責也從僅僅發現問題的工作中向著眼於整個專案質量保障轉變。因此不難得到結論，在敏捷團隊中，優秀的測試人員身上有其他成員的影子。在時間緊迫的情況下，他能轉變成其他角色，做出更多的創造性的成績。充分地發揮了個人戰鬥力，在幫助他人的同時，自信的態度和各項工作中的技能得到增強，自身也可以獲得更大發展。

在一次關於敏捷開發、測試經驗交流中，我們認為敏捷測試團隊更需要其他團隊的協助，在設計測試用例時，團隊的設計人員應該幫助測試團隊設計測試用例，並幫助測試團隊做更多的面向客戶環境的真實測試。開發團隊也要確保開發任務的按時推進，和測試團隊保持緊密的合作，在測試任務緊要時，也能夠轉變其職能幫助測試團隊完成測試任務。

測試人員向敏捷轉變所需要的技能儲備

這引出我們今天要探討的一個問題，測試人員如何在技能上做好準備以面臨敏捷開發的全新挑戰。我們認為，一名優秀的敏捷測試人員，需要有較強的學習能力，至少有主動學習的意願。除了需要了解各種型別測試以及各種測試工具，測試技術外，也需要了解專案中軟體設計模式，軟體語言，以及專案的程式組織架構以便建立和團隊的共同語言空間。

因為敏捷團隊是一個高度協作的團隊，在這樣的團隊中工作需要很好的溝通技巧，語言能力和協作能力。

除此之外，團隊的每個成員，都應該認真學習並努力尋找適合自己團隊的敏捷模式，並溝通以達到團隊成員對敏捷開發模式的統一認識，使得團隊其他成員對自己工作的充分理解和建立起成員之間的相互信任。

回頁首

測試人員向敏捷轉變所需要的方法

培養好的敏捷測試人員，需要培養其技術能力，也需要用正確的培養成員的敏捷思想。敏捷的方法指導敏捷團隊行動，是敏捷測試原則的實踐。從一開始，就深刻影響著團隊中每個人。當然，方法不是放之四海皆準的，需要團隊對敏捷原則深入理解，執行敏捷測試實踐後逐漸形成的規律。而一個傳統的測試團隊，在固有的行為規律下，在成熟的產品線裡，或者層次分明的複雜組織結構裡如何做好向敏捷的轉變呢？似乎這種改變給許多人帶來希望的同時伴隨著一點恐慌？我們有沒有可行的策略、方法可以遵循呢？可否讓團隊又能夠發揮在傳統開發模式下的力量集中的優勢，又能夠做到敏捷的隨需應變呢？回答是肯定的。

在做轉變的實施前，我們需要有心裡準備，任何從傳統開發到敏捷開發轉變不可能一蹴而就，自然也沒有人能夠將一個傳統開發模式下的測試團隊一夜之間變成徹底的敏捷。對這些還沒有敏捷起來，但仍然以此作為目標的專案團隊我們建議循序漸進，基於筆者的親身體驗，提供以下實施的方法請大家參考。

首先我們建議採用迭代的開發模式作為向敏捷的模式轉變的起點。很多傳統開發模式或者基本上還是瀑布式的開發，或者是週期性的瀑布式開發，這些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布開發的不斷累加。換句話說，傳統開發是傳遞性的工作，一方完成，另一方接手。而敏捷活動的迭代行為更強調儘早開展各項活動，從迭代的一開始就協同工作，共同實現團隊迭代的目標。而一旦抵達迭代的週期中最後一個工作日，此迭代宣佈退出。

當完成了向迭代活動的轉變完成後，接著，我們開始尋找專案過程、管理、執行中最緊要的問題，並使用敏捷開發中的最佳實踐來一一解決這些實際問題。也許，一開始這個過程是很緩慢，而且很難做到一步成功，但是必須通過不屑的努力和足夠的耐心，慢慢轉變團隊的固有思維方式，並最終努力獲得團隊對改進後結果的統一認可。而一個問題被解決，或者不再是專案中最嚴峻的問題時，我們應該開始尋找下一個待解決的困難了。重複這個過程直至成功的將團隊中有悖于敏捷原則和實踐的過程和方法調整過來，同時將正確的思路和方法帶給團隊。

在最近的幾次與其他敏捷測試團隊的討論中，我們同時瞭解到許多軟體開發專案中的測試團隊遇到過類似的一些問題，如開發團隊沒有做單元測試或做得太少，繼而在開發過程中的遺留了大量質量缺陷和頻繁的迴歸現象。這使得測試壓力急劇加大，測試過程嚴重受阻，甚至影響到整個迭代的退出和專案的輸出結果等等。又或者傳統的開發中的測試團隊因為很少有條件去認識客戶，瞭解和實際使用者相關業務需求。測試指令碼和用例的設計只是基於開發人員撰寫的功能說明。因此，難以做到對需求變化做出快速反應。經過討論，我們推薦給對這樣的團隊如下參考方案。

• 首先開始採用測試驅動開發 (Test Driven)。

開發人員首先要善於使用測試驅動開發方法寫每一行程式碼，先寫測試指令碼後寫程式碼，並反覆使用單元測試指令碼驗證所寫程式碼的正確性。

1. 列出需求
2. 為需求撰寫一個單元測試指令碼
3. 執行測試確信測試結果是失敗的
4. 然後，寫上僅僅足夠的程式碼以使得先前的測試可以通過
5. 當所有測試通過了，便可以開始寫下一個測試指令碼
6. 針對需求有效的實現所有測試指令碼

另外，當需要程式碼重構時候，也應該先重構單元測試指令碼，在改動代買之前同樣先改寫測試指令碼。

• 儘早的開始測試，開始系統測試，不要等待到功能完全做好才開始。

瞭解計劃中的待實現的功能，瞭解其權重分配，設計系統測試和功能測試用例。測試執行的一開始可以是針對部分功能的，之後可以逐步擴充套件。接著開始採用迭代的過程完成測試任務，即將測試任務劃分為多個週期，一開始可以做些關鍵的功能性測試，可以對程式碼中的可複用部分（元件，構件）做完整的安全測試，效能測試，壓力測試，併發測試，全球化測試等。接著的迭代週期可以做邊緣化的功能測試和其他測試，最後的幾個迭代應該用於迴歸測試，和關鍵的效能和穩定性測試。

然後策略性的進行自動化測試，設計並開發可以用於日後迴歸測試（Regression）和使用者接收測試（Acceptance Test）的自動化指令碼，持續維護與開發這些指令碼。自動化測試為團隊帶來的是長期效益，自動化測試的開發也應該首先選擇部分測試物件，例如，API，框架等比較穩定和關鍵的功能做功能測試的自動化；對產品的效能指標，壓力測試也要較早的制定自動化測試的計劃。

最後，要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一使用者積極參與專案和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。

而且，要做好敏捷測試，我們需要轉變測試等待開發的思想，測試人員需要了解開發，需要讀懂程式碼，才能夠更好的幫助開發人員分析和分離複雜問題。有甚者，測試人員可以成為開發人員的後備力量。當團隊中需要更多的人撰寫程式碼時，測試人員應該勇當其職。

團隊組織的變化

敏捷的測試團隊在實戰中常常不需要其他人幫助做計劃和分配任務，成員在各自的敏捷團隊中自我管理模式下制定可行的計劃與自行分配任務，並直接報告給專案的管理層。只有在特定的集中測試模式下才需要通過測試團隊的領導者形成整體的測試計劃和報告。因此，敏捷測試團隊是一支即能獨當一面又能夠默契合作的適應力，靈活性很強的團隊，這正是團隊自我管理的核心思想。因此，轉變到敏捷開發模式，傳統組織結構也需要經歷一次調整，調整圍繞兩個主題，第一，團隊充分授權各成員，對於如何交付結果，成員可以保持較大的靈活性，但成員自身需要對這些結果負責。第二，團隊領導者需要協調團隊成員對資源的共享和競爭，當敏捷團隊各自計劃和實施其工作時，團隊領導者應該幫助團隊成員建立比較清晰的責任界限，團隊角色劃分，協調團隊中各種資源的使用，鼓勵團隊之間的相互交流和協作，幫助培養團隊成員對其所屬的自主決策能力。

圖 1. 傳統組織結構轉變為敏捷組織

團隊需要建立良好的鼓勵機制，這裡我沒有用激勵一詞，因為我們認為團隊成員已經飽受著來自自身、外部的各種壓力和刺激。團隊要在這種高壓的環境裡保持高昂的鬥志，一定需要更多的鼓勵和關心團隊中的每一個成員。並且，通過鼓勵團隊的創新，尊重團隊的多樣性，培育各種想法，使得團隊自身更加善於思考，高效的達到預期目標。相反，處處壓制和迫使團隊成員按自己的方式做事情，將使得團隊的活力降低，生產率下降。

當然，在這裡我們更要需要關注團隊的核心人物——團隊的領導者，在敏捷團隊中，團隊的領導者更多是一個實戰經驗豐富，能夠獨立完成自身所承擔的敏捷專案組工作外，也能夠輔導和幫助其他團隊成員做好各項工作的重要角色。優秀的團隊領導者往往會成為主導專案成敗的關鍵，然而一個不能夠很好轉變固有思路，自身都不能做好敏捷測試所涉及的工作的所謂的領導者是自然沒有能力去完成培養和發展自我組織，自我管理的團隊的艱鉅任務的了。很顯然，越來越多的傳統團隊的領導者具備了領導者和管理者的雙重身份，然而，敏捷的團隊中，並不需要這樣的雙重身份。而團隊民主，平等的建立才是團隊領導者和團隊所有人需要盡力保護和推崇的原則。而敏捷團隊中的領導者更多是團隊的領軍人物，他 ( 她 ) 明確下一步要做的事情，勇於挑戰新事物，不怕承擔責任，具備正值，公正，協調能力強的特點，更重要的是他（她）是團隊中的模範，他 ( 她 ) 的影響力，正是領導力的源泉。因此，如果傳統測試團隊需要發展成為敏捷測試團隊，那麼團隊領導者的職責和形態的轉變也必然十分重要。

最後，團隊用人和人才配置仍然需要慎重考慮，換句話說，就是因人而異的安排工作。舉個例子，在一個分散式的敏捷團隊中，集中在中國的測試團隊需要劃分出幾隻小團隊分別服務於不同的敏捷開發團隊，其中有美國、德國、日本三個實驗室參與到這個專案中來，面對時區差異，專案所需技能差異。我們建議在沒有更好的辦法的情況下，選擇了體力很好的同事在有時差 12 個小時左右的敏捷團隊中，將學習能力強的同事放到新技術含量最高的敏捷團隊中，程式碼經驗豐富的同事放到做底層架構的敏捷團隊中，這樣來以達到測試團隊的最佳組合與配置。

敏捷測試遇到的哪些問題？

任何方法都不是百分之百正確，部署敏捷原則的測試團隊仍然會遇到了許多困難。需要我們勇敢的面對和並痛痛快快的解決他們。這裡筆者給出了一些被大家討論得最多的熱點問題，結合實際經驗分享一些解決方案，希望可以有所幫助。

時區地域的差異增加了溝通成本

某些著名企業在部署敏捷開發專案時曾不允許將同一專案的開發團隊跨地域分離，原因是為了方便團隊成員間的，團隊間的溝通和交流，降低成本。而在面臨外包所帶來的巨大利潤誘惑下仍然存在許多跨地域，跨時區的敏捷專案團隊。部署敏捷開發時的常有人質疑這種方式下的敏捷是否能夠真正成功。也不乏聽到源於時區地區差異造成的溝通不便而引起的聲聲抱怨。

圖 2. 時區地區差異增加溝通成本

不得不說地域和時區的差異帶來了團隊溝通的額外的開銷，但是恐怕這也是短期內無法改變的事實，在不能改變環境的前提下，我們選擇了改變自身。因此，敏捷團隊更需要通過各種方法保障溝通的通暢，做到溝通即有效。因為不能實施面對面的討論，所以為了更好的交流，我們建議採用會議以外的方法，如電話，即時通訊，郵件來彌補時區地區差異的障礙。在我們的深刻體驗中，建立起通暢的即時通訊，和資訊共享的資料庫空間是專案成功的不可或缺的因素。而團隊成員之間經常的感情交流，更能夠促進團隊間的相互信任和潤滑之間的摩擦從而加快溝通。

除了鼓勵團隊的自我管理，自我建設外，在初期幫助分佈在不同地域的團隊間建立一些官方交流通道是非常有幫助的。例如，我們建議對這些跨區域、分散式的敏捷專案在專案初期就找出能夠被雙方甚至是多方接受的穩定的定期的會議時間和其他有效溝通方式，也建議建立起活動經費經常用於組織團隊之間的各項增進感情交流的活動。另外，幫助團隊的成員依據團隊整體工作時間的最佳的安排和改變個人的正常工作時間的也或許成為必要的選擇之一。

不會休息的團隊

敏捷開發中因為是高度迭代，週期短，任務緊，而自身的積極工作態度更使得團隊成員不願意休假並長時間的高度緊張的工作，甚至頻繁的加班加點。在我們的專案中，中國人更加表現出積極的一面。在過去的一段時間裡，中國軟體開發實驗室的很多人中，當然也包括我們，傾向於犧牲個人時間來滿足分配更多工作的要求。從感情上我佩服這種孜孜不倦，無私的工作態度，更驚訝這樣的旺盛的精力。然而，很快我們發現我們錯了。

這樣長時間缺乏休息的團隊成員工作效率，工作狀態的在四五個月後發生了變化，也突然發現他們一個接一個的開始變得萎靡不振，身體健康狀態也隨之變壞，以致後來很多人甚至臥病在床了。而這時恰恰又是專案中後期產品開發的重要時期，專案因此承受很大風險。

不會休息的團隊是不健康的團隊。其實，專案往往不是短期行為，通常一個產品的釋出需要經歷半年以上的不懈努力和投入，而長時間的超負荷運轉會使得工作效率和員工身體透支甚至可能導致難以控制的嚴重後果。所以，如果你的專案還要長期發展，應該幫助團隊認識到輕鬆的團隊氛圍，張弛有度的工作安排是保障專案最終按時交付的重要因素。

而造成團隊不能休息和壓力過大的原因，恐怕也是團隊自己，為什麼這樣說呢？原因是敏捷開發團隊在計劃每一個迭代任務時，許多團隊成員對任務量和計劃外突發情況估計不足，導致一開始就承諾了過多的專案任務。因此，團隊成員除了加強對這場耐力賽跑的認知，和建立正確的計劃外，敏捷團隊的管理者，有義務和責任幫助各個團隊建立起適量的工作計劃，動態調整團隊的工作任務，以保障整體的穩步前進。關注團隊壓力承受能力的提高和合理分配團隊的工作計劃，時間，從長遠看來，對團隊成員的工作效率和團隊的工作績效的提高具有非常重要的作用。

團隊間的協作

越大型的專案，敏捷團隊的體積可能越大，迭代的次數越多，產品的架構也更容易產生變化，設計的複雜度也更大。因而，我們需要更加重視產品架構建設，程式碼重構策略和加強團隊間的協作。

最好的設計來自團隊而不是某個人，無論是程式碼還是架構設計還是測試方案都很大程度的依賴於團隊的共同承擔。而實際專案經驗告訴我們，敏捷模式下，往往因為各個團隊具有較為獨立的活動能力和決策力，團隊成員通常更關注所屬團隊的責任範圍內工作，無論是開發人員還是測試人員都潛意識的將依賴於其他團隊開發和測試的工作放到靠後的開發週期，寄希望於所有需要的前提和依賴條件最終一定得到解決，而那時後再開始這部分工作也不遲。因此，這種弱勢的團隊協作成為專案進度不能保障的罪魁禍首。

在我們專案中，也曾經因為某些元件間介面定義時沒有做好統一規劃，以致產品整合階段測試和開發進展非常緩慢，迴歸現象頻繁出現，團隊的士氣受到了極大的傷害。因此作為敏捷團隊，特別是敏捷測試團隊應該更早的暴露介面缺陷，來設計適量的測試用例覆蓋這些耦合部分的活動將為產品的整合帶來更小的風險。幫助開發人員儘早認識到其後果的嚴重性，專案將最終受益。而敏捷原則中提到的不斷的整合的思想正是我們克服這個困難的最佳實踐。

除了專案管理層通過干預手段解決這部分問題外，鼓勵團隊成員主動承擔額外的工作也是做好協調團隊間工作，降低總體風險的最佳途徑。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408754/，如需轉載，請註明出處，否則將追究法律責任。