敏捷軟件測試需注意的危險行為

　　如果開發團隊采用了敏捷方法，那就意味著程序員需要做更多的軟件測試。然而，這并不是說軟件測試人員就沒事做了。他們需要調整，并學會與以往不同的測試方式。

　　DragonFire公司的顧問Janet Gregory認為，對用戶需求的測試尤為重要，“除非經過測試，否則不能認為任何業務需求已經完成。

　　”

　　STAREAST測試展會(STAREAST Conference andTestingExpo)上，Gregory討論了“新晉敏捷測試員的危險行為與陷阱”，并解釋了敏捷測試員所應做的工作。她指出軟件測試人員經常做出的危險行為，這些危險行為可能帶來的風險，以及如何規避這些危險和風險。

　　作為一名敏捷測試員，你需要能在沒有正式說明文檔的條件下展開軟件測試、進行實時測試、測試改動代碼、根據不斷變化的需求進行測試、自動化大部分測試，并成為緊密合作的團隊中的一員。

　　如果你想一一完成這些工作，就可能會在努力過程中遇到Gregory所說的敏捷測試的危險行為。

　　危險行為1：等待第二天的版本

　　Gregory認為，敏捷開發需要不斷地進行測試。你不能等版本開發到最后階段才開始軟件測試。怎么知道你是否已經陷入這種困窘呢?對照以下幾個特征：

　　成堆的“等待”測試的業務需求

　　沒有在一次迭代周期中測試完所有需求

　　沒有定期對部署進行軟件測試

　　造成無法進行定期測試的原因包括：未對需求進行測試、軟件測試人員不可靠、速度受到影響，以及利益相關人的反饋不夠及時等。另外，有可能進行到下一個需求開發的時候，才發現前面未查出的漏洞，或者如Gregory所說，“所有測試都堆到最后階段”。

　　她還說，要避免這種危險，最重要的是要采取主動。從“版本主管”那里定期拿到各版本，并規劃測試的基本架構。拿到版本后要盡快測試，包括速度規劃(Velocity planning)中的任務，并盡可能地在程序員的機器上進行結隊測試，使程序員習慣于得到反饋。

　　Gregory說，要找到測試與程序編寫之間的平衡點。“只是一味地努力提高速度是不行的。你得讓你的工作速度與效率與程序員保持一致。”

　　危險行為2：你并沒有真正地加入團隊

　　如果軟件測試人員沒有被邀請參加規劃討論會，或者測試人員不喜歡發言;如果業務客戶獨立編寫業務需求，而測試人員不明白這些需求的內容，這時就已經很明確是否存在這方面的問題了。

　　這種工作方式可能導致的后果是：

　　無法及時確定各種假設

　　不能及時發現對系統造成的影響

　　員工不能有效利用時間與技能

　　你總是感覺不對勁

　　人心分散

　　Gregory認為，要避免這種情況，你必須強調“完整團隊”的重要性。與你的程序員坐在一起，這樣你們會更容易交談;參加各種會議，確保在討論需求的時候所有三方團隊都在場，并建議他們在一兩個迭代周期中“盡量嘗試”一些新主意。

　　你得明白作為一名測試員應發揮的作用。也就是Gregory所說的不斷地進行軟件測試，并提供反饋意見。

　　危險行為3：無法放棄“質量監督”的理念

　　可能你以前工作在一個質量監督(Quality Police)負責所有質量問題的環境下。即除開發團隊以外，有一個單獨的軟件測試團隊將所有的漏洞報告到缺陷跟蹤系統中，測試團隊甚至可以停止開發的進行。

　　然而，在敏捷開發中，整個團隊都要對質量負責，而不僅僅是測試人員。Gregory說，如果沒有整個團隊對質量問題的一致認同，程序員就會將軟件測試員看作是安全保障，從而只在bug追蹤系統中與測試員溝通，那么這個團隊便無法“凝聚到一起”。

　　要改變這種局面，所需要的仍然是測試人員的主動。Gregory指出，軟件測試人員要與程序員建立良好的關系，向程序員展示各自的職業價值，使整個團隊對產品的質量負責。

　　測試員可以在一些專業問題上幫助程序員，保證能夠在迭代過程中進行測試，并解釋對于整個團隊來說“完成”所代表的意義。在追蹤bug時，可以使用需求卡片(index card)。將需求開發中發現的bug寫到卡片上并貼到墻上。

　　危險行為4：所有測試都想手工進行

　　Gregory說，如果所有測試都想手工進行，那么必然趕不上程序員的進度。如果你一直把時間用在重復進行某些測試上，而沒有對新功能進行測試;或需要越來越多的軟件測試人員，卻無法對部署或設計上的問題產生作用，你就會明白這個問題的重要性。

　　不對測試進行自動化會導致越來越多的bug，并且無法及時響應新的需求。此外，可能無法注意到以往運行正常的功能已經受損，而軟件測試人員也容易陷入陳規，無法學到新東西。

　　對此Gregory提出以下建議：

　　用自動化的方法建立回歸測試集

　　設計時考慮到易測試性

　　使自動化與測試同步(讓程序員也參與)

　　幫助程序員編寫優良的單元測試

　　使用對整個團隊都有用的自動化工具

　　展示你的技能

　　推廣你的工具包

　　危險行為5：忽視大局

　　在敏捷開發中，你必須能夠展望全局，而不能被一些片面的東西迷惑。如果你發現一直進行的只有單獨的需求測試，在發布的版本中有集成的bug，直到最后才制作報告，而你所做的測試都是程序員告訴你去做，并且只做了探索性測試，那么你肯定是沒有考慮整體規劃。

　　如果確實如此，那么你的業務需求將無法聯系到一起，各單元無法集成，業務流程不流暢，并且在編寫程序過程中制定的決策也無法與最終目標吻合。Gregory說：“你在冒險，你的最終產品可能并不是所需要的。”

　　如果能先進行驗收測試，用面向業務(business-facing)的測試進行有效的開發，充分考慮系統其它部分受到的影響，使用可以反映實際情況的測試數據，以及在編寫程序之前將業務需求研究透徹，便能避免這一切。

　　還有一些可以使用的方法，包括：

　　使用電子公告欄進行規劃

原文轉自：http://www.kjueaiud.com