敏捷方法在測試計劃中的應用(2)

　　Ray Oei：這取決于你對測試計劃的定義。在傳統形式下，我會說不需要。

　　在我看來，完成的定義包含了一部分計劃。在一定程度上用戶故事本身由業務所描述：為用戶故事定義的驗收標準，可能存在的整體約束，產品需要的工作環境，終端用戶等等。我們可以找到許多方式在團隊內，與PO和干系人進行溝通。例如，我自己就喜歡思維圖，但是 BDD也非常的有用。最后，這取決于具體環境。沒有明確的針對所有事情的解決方案。在這方面，與我們不同的“醫學(medicines)”概念始終是正確的：你必須尋找能夠在具體環境下起作用的東西。反復試驗，檢查并調整。這不就是敏捷嗎?

　　InfoQ：您能詳細說明如何和敏捷一起使用測試管理方法(TMap)類型的測試計劃?

　　Ray Oei：正如我在我的演講中解釋的，它更多的是一種木馬病毒而不是安慰劑。在我的案例中，外部項目組織堅持需要文檔。但是文檔內容經過定制以支持開發團隊正在探索的敏捷倡議。因此，我描述了啟發式測試策略模型(來自 James Bach)，用來解釋我們將生成測試用例的方法和基于會話的測試管理(來自 Joh Bach)——管理者尤其“鐘愛”“管理(management)”一詞，此外還用此來描述我們將組織測試的方法。當然，整個過程就是著名的 Scrum循環圖。它被大眾接受。并且當我被問到什么時候測試用例可以準備妥當的時候，我可以指著商定的方案并解釋說所有的事情都在按部就班的前進。

　　InfoQ：您有哪些案例可以說明您是如何讓干系人意識到他們能夠影響質量的?

　　Eddy Bruin：在這方面關鍵在于參與。幾年前，一個業務經理告訴我“我們需要更多的測試用例!請您把它們寫進測試計劃。”我回復到，請問您需要更多測試用例的原因是什么。“否則我們如何了解系統的質量?另外我需要維護軟件。我想知道它的反應。”

　　很明顯，業務經理和他的團隊需要兩件事：1)對產品質量的自信和 2)了解產品是如何運作的。從那時起，我邀請他的團隊參加 Sprint評審，評審后用一個小時的時間和他們一起測試。事實證明他們都是非常優秀的測試人員，自從我引導他們學習系統后，我再也沒有收到編寫測試用例的請求。除此之外，在 Sprint評審期間他們提供了更多的反饋，這些反饋著實提高了質量。在我目前的工作中，我們非常重視 Sprint評審，我們認真準備評審，這樣人們可以自己操作產品，在迭代中針對固定領域提供反饋。

　　Sprint評審的幾點思路：

　　創建活動掛圖，參與者可以在上面留下自己的反饋。也可以是積極的反饋!(在演講中你可以看到一個類似的活動掛圖的案例。)

　　準備測試數據，并打印出來。

　　有多個可用的設備和工作站，這樣人們可以檢查你的產品

　　邀請人們自己操作應用(不要僅僅展示)

　　Ray Oei：與干系人交流，要有耐心不要害怕重復。不是每個干系人都希望或者覺得有參與的必要，他們僅僅想要一個可工作的產品。通常有幫助的是演示，更多的是演示之后的討論。讓干系人體驗到他們的投入得到了使用和欣賞非常的重要。給他們機會分享他們的假設、期望和需求。如果可能給他們全天候的產品訪問權限。讓他們測試。當然這也是有風險的。如果產品過分不穩定，你可能不會獲得干系人的信任;結果可能與預期相反。不幸的是，在干系人參與都成問題的情況下，通常最終結果也會讓他們失望。

　　InfoQ：您有案例說明如何在敏捷中計劃測試嗎?

　　Eddy Bruin：如果你的工作環境是 Scrum，所有測試最好在開發軟件的迭代過程中完成。我發現現實往往相反。向敏捷過渡的企業其很多的測試階段并沒有簡單的消失。端到端測試和性能測試通常在 Sprint之后實施。我所追求的是不斷地讓測試負責人參與進來，并向他們展示如何可以更早地執行這些測試。歸根結底都是為了盡可能快地縮短反饋環。如果我們的軟件在市場上有助于實現業務目標，那么軟件就應該視為一個解決方案，因此我們越早有可工作的軟件，就越早可以測試。

　　業務經理要求在測試計劃中體現更多測試用例(后期反饋)的故事與業務經理參與每兩周一次的 Sprint評審兩者之間的對比就是縮短反饋環的案例。另一個案例是不要等到演示的時候才去展示產品。一個可替代的方案是每做完一些測試，就向團隊或者產品負責人詢問結果。

原文轉自：http://www.infoq.com/cn/articles/agile-approaches-test-planning