敏捷測試的啟示

什么是敏捷？

        敏捷宣言：個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計劃更有價值。-

        敏捷開發是遞增式的、迭代的、不斷調整的開發模式。在敏捷開發中，工作被分解成“故事”，也叫特性或用例，組合成任務分派給不同的程序員。敏捷開發講求合作，結對進行編程，避免個人擁有專門的知識，代碼屬于項目組共有。在敏捷開發中不存在回退，講究持續地集成，單元測試（通常使用測試驅動的開發方式），持續地進行回歸測試。

        敏捷測試是指在敏捷開發模式中的測試。敏捷測試包括單元測試（通常由程序員完成）和可接受性測試（通常由測試人員完成）。

如何應對敏捷？

        敏捷來了，測試人員何去何從？有人認為在敏捷的團隊中，在實行極限編程方式的團隊中，測試員應該被“廢掉”！有人認為，測試員應該擁抱敏捷，不要管什么測試計劃、不要測試報告！

        對于第一個論點，我們很容易就能推翻。即使是在一個完全采用XP方式的團隊中，測試員還是必不可少的。只不過是測試員在XP中扮演的角色與傳統軟件開發模式中扮演的不大一樣了。

        在敏捷開發中，測試是整個項目組的“車頭燈”，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基于這些可靠的信息作出正確的決定。測試人員不再作出發布的決定。測試員不保證質量，而是整個項目組的每一個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標。

        對于第二個論點，我們要分析一下，問一下自己，你現在是在一個怎樣的團隊中工作的，工作得怎樣？如果你是在一個傳統開發模式的團隊中工作，而且工作得挺好的，則第二個論點對于你來講是錯誤的。

        因為在傳統的軟件開發模式中，項目文檔不僅僅是驅動項目前進的必要條件，而且很多企業的客戶，尤其是軟件的軍方客戶，對于產品的最終配套文檔，還有階段性文檔都是很看重的；另外，對一些外包的軟件也需要有完整的文檔。而敏捷模式拋棄文檔的做法在這些企業是行不通的。

        傳統的開發模式中，測試人員可能要兼任測試和質量保證、甚至配置管理的工作。那么按照誰負責誰決定的原則，則你作為質量方面的負責人，必須對產品的質量把關，做好“守門員”，對產品的放行有絕對權威的發言權。

敏捷測試的啟示

        對于我們測試員來說，如果你是在一個敏捷的團隊，采用完全的XP方法，則你應該按照敏捷測試的原則，調整自己的角色，讓自己成為一名真正的敏捷測試員。在敏捷的團隊中，測試工作的核心內容是沒有變的，就是不斷地找BUG。只是你要調整好自己的心態，一切以敏捷的原則為主。更多的采用探索性測試方法，更多地采用上下文驅動的測試方法論，更多地采用敏捷自動化測試原則。

        如果你是在一個傳統的開發團隊中，你不可能背叛整個團隊的一貫做法，自己去“擁抱敏捷”，畢竟很多公司按照ISO、CMM的做法也在不斷地成熟。那么我們需要做的是多吸收一些敏捷的思想，優化一下自己的測試流程。

        敏捷提出的用戶故事的說法，其實是把需求規格說明書敏捷化了，那么其實它是指出了需求文檔冗長和管理不當的問題，那么通過一些控制工具是否能解決問題呢？同時也給我們一個啟示，敏捷測試為什么能在缺乏文檔的環境下工作？我們為什么就非要依賴文檔呢？測試員是否能自動地尋找和挖掘更多的關于軟件的信息來指導我們的測試呢？探索性測試，這種強調同時設計、測試和學習被測試系統的測試方式是我們可以借鑒的。

        敏捷講求合作，其實是指出了我們傳統工作方式溝通上的毛病，開發人員與測試人員往往都比較對立，我們傳統的方式過分依賴書面的溝通，文檔驅動，缺乏很多面對面的交流，我們能否主動點，多與開發人員聊聊需求、討論設計、一起研究BUG出現的原因呢？

        敏捷測試認為要持續地測試，不斷地回歸測試，快速地測試。其實是指出我們傳統的測試階段過于冗長、沒有根據項目的上下文作出調整，速度太慢，過分依賴手工測試。那么我們能否多點借鑒上下文驅動測試的方法，適當自動化我們的測試呢？

原文轉自：http://www.anti-gravitydesign.com