在 Agile Testing Days 2015大會上，Eddy Bruin和 Ray Oei解釋了如何在不編寫大型測試計劃的情況下，滿足干系人對測試用例、測試計劃和其它測試工件的需求。\

InfoQ就測試計劃在敏捷中的應用、如何讓干系人意識到他們能夠影響質量，以及他們推薦的敏捷測試實踐問題對 Bruin和 Oei進行了采訪。\

InfoQ：在瀑布或者敏捷項目中您覺得測試計劃有什么問題？這些問題相似或者不同嗎？\

\

Eddy Bruin：我記得我對我編寫的第一個主測試計劃非常滿意。我覺得一切都一目了然。編寫這份測試計劃花費了我一個月的時間，但我發現沒有人詳細閱讀這份計劃，我仍然需要為計劃中的許多內容點爭論。如果當時我花費一個月的時間跟大家交流，邊測試邊解釋，那么我會更加的成功。就是那個時候我意識到編寫如此一個計劃非常的浪費時間。\

從那時以來，我收到過數份測試計劃并閱讀了它們。我的結論是大多數計劃包含的信息都是不相關和過時的，對產品質量或者測試流程沒有幫助。它們太不靈活且費時費力。\

我發現敏捷中的測試計劃有個不同，他們會再一次解釋 Scrum的規則，然后嘗試以瀑布的方式在測試中進行壓縮。在我看來，它們都是一流的計劃，但是用在了錯誤的敏捷過程中。\

Ray Oei：在我的定義里，測試計劃就是一份冗長的文檔，遵循一些標準或模板。這些測試計劃的通病是花費太長的時間編寫，并且在大部分情況下，幾乎沒人閱讀。它更多的是一個過程工件而不是測試工件。許多我遇到的測試人員在嘗試遵循計劃時總是會遇到問題，并受到“為了測試我需要做什么？”的困擾。并且某些時候你可能發現所有計劃的內容或多或少相同，并不能真正幫助需要測試的內容。因此，你試圖忽略它們。\

當所謂的敏捷項目需要測試計劃時，并且它已經在我身上發生過，這種情況有個明確的跡象是它不是敏捷環境。在這些案例中我曾遇到的一個問題是有些人將工作方式強加給測試人員，首先因為測試階段的描述，所以他們將測試人員與團隊隔離；其次與團隊的努力建設沒有一點聯系。這不利于團隊精神。

\

InfoQ：在 Agile Testing Days大會上，您把您的演講叫做“Placebo Test Management”。您能解釋一下它的含義嗎？\

\

Ray Oei：它描述的是由于我們交付的內容與預期提供的解決方案相比，或多或少具有欺騙性（fake）所造成的影響。像在醫學方面，通常很有效果。它能造成控制錯覺（illusion of control），這種錯覺滿足了很多人。當然,它也會引發一些反應。我們不想欺騙或者僅僅讓管理者滿意。通常，在我們能夠以他們想要的方式交付價值之前，我們需要先建立一個共同的基礎，使得看上去似乎在做預期的事情。展示有價值的結果才是關鍵，這樣有助于說服人們相信事情能夠以與他們預期不同的方式完成。然而，這在流程-饑餓（process-hungry）環境中是一個很大的挑戰。\

Eddy Bruin：一年前當 Ray和我討論測試計劃的時候，我們得出結論，我們傾向于擁有解釋為什么、如何測試和測試什么的替代方案。然而，在某些情況下我們被告知需要基于公司模板交付一份測試計劃或者測試報告，“因為流程強迫我們這么做”。\

因為我們認為這是一個錯誤的觀點，所以我和其他測試人員開始敷衍測試計劃。我們寄出無意義的測試計劃，僅僅交付無意義的模板，或者提交復活節彩蛋，目的是為了表明測試計劃不能用來提高測試或者測試未被合理解釋。然而這些行為確實能夠取悅負責監護流程的管理者：項目經理或者質量流程管理者（很高興）看到流程被遵守。\

流程規定必須編寫測試計劃。如果管理者看到帶有“測試計劃”附件的郵件，他們會選中復選框。即使文檔中沒有內容，流程遵循者也高興。很不幸在某些情況下會發生這種情況。我們意識到這些具有欺騙性的測試計劃觸發了安慰劑效應。我們就是這么杜撰“安慰劑測試管理（placebo test management）”短語的。

\

InfoQ：您覺得在敏捷中還需要測試計劃嗎？它們能起到什么作用？\

\

Eddy Bruin：計劃對測試而言其本身是一個有用的工件。它能夠塑造上下文，能夠對我們自己和其他人解釋我們將如何實施測試。我的問題是編寫的計劃所包含的信息已經可以獲取并且不斷變化，因此編寫這么一份計劃是低效率的。像在哪種測試環境下測試和覆蓋哪種風險這種實用性值得擁有和溝通。同樣協議中的測試范圍（比如我們對哪種瀏覽器進行測試）很容易寫下來。\

然而，Scrum框架已經為此提供了一個有用的工件：完成的定義（DoD）。這份文檔會發生變化，更重要的是它是溝通的象征（token of conversation）。“溝通的象征”的意思是 DoD僅僅是伴隨故事的一種結果，一種陳述。只有在溝通中我們才能描述故事，而不僅僅是給每個人發送一份 DoD副本。也就是說，我確實喜歡擁有合適的測試遠景文檔。它可以是一份 PPT或者思維圖。測試文檔跟 DoD一樣會發生變化。例如保持團隊敏捷從而允許在回顧中改變文檔。\

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評審兩者之間的對比就是縮短反饋環的案例。另一個案例是不要等到演示的時候才去展示產品。一個可替代的方案是每做完一些測試，就向團隊或者產品負責人詢問結果。\

Ray Oei：我試圖圍繞一個故事、期望的產品或者任何看上去重要的東西發現盡可能多的問題。創建一個我們正在構建產品的模型，和思維圖有助于我組織測試。提出問題。如果可能的話調查研究。我發現當我聽到程序員討論事情的時候，我經常想起一些需要測試的內容。我會遍歷代碼。當有人告訴我，我不需要因為一些不明原因檢查代碼時，那么我肯定會看一眼代碼。那是一個“計劃”嗎？如果你認為計劃是開始測試前對某個時期的設想，那么它就不是的。但是我又有測試的想法，并且我在努力嘗試執行這些想法。而且說實話，事情的發展并不總是跟我預料的一樣。有時在我有時間組織它們之前，我的一些想法已經過時了。我認為我的主要指導計劃就一個問題：“現在或者未來，這重要嗎？”。

\

InfoQ：有沒有一些您想推薦的具體的敏捷測試實踐？\

\

Eddy Bruin：有一大堆的敏捷測試實踐：結對編程、實例化需求（ATDD/BDD）、TDD、大量的啟發式測試等等。對我而言總是非常優秀的一個實踐是在所有測試活動中進行溝通。當規劃測試、匯報測試和解決bug，甚至是當展示我們實際意圖構建的產品和應該給公司帶來什么產品時，我總是努力盡可能地透明化。為此我最常用的策略是擁有盡可能多的信息輻射體。墻上的活動掛圖、白板和便利貼越多，開始溝通就越容易。\

Ray Oei：不是具體的敏捷測試實踐。我認為關鍵是溝通：交談與傾聽。或者更好的是：提出問題，并花時間傾聽和理解。了解相關的領域和業務，和使用的技術。了解你共事的成員。同樣發現你自己在那的角色和行為。我們傾向著眼于別人，認為他們應該/可以/必須完成的更好——但是你自己呢？\

展示你正在做什么，已經做了什么。甚至如果需要，展示你犯錯的地方。這有助于建立信任。這方面并不是航天器學，沒那么復雜。雖然，作為技術人員，我認為航天器學比人文科學更加容易。

\

關于受訪者

\

從2008年開始 Eddy Bruin 一直充當測試顧問的角色。他熱衷于敏捷、測試、易用性和移動領域。他幫助組織實現反饋環從而交付更好的產品。作為敏捷測試教練，Eddy喜歡提供敏捷測試培訓，喝著特制啤酒討論話題。目前 Eddy是一家國際速遞的測試技術總監。\

Ray Oei 是一名經驗豐富的敏捷教練和有扎實編程技術的測試員。他能夠從不斷學習新事物中獲得能量，包括但不限于軟件測試行業。Ray是 DEWT(Dutch Exploratory Workshop on Testing)的創辦成員，軟件測試協會（AST）成員，AST BBST課程的首席教官，TestNet工作組培訓\u0026amp;教練成員。他是 AVG創新實驗室的 QA團隊主管。

\

查看英文原文：Agile Approaches in Test Planning

總結

以上是生活随笔為你收集整理的敏捷方法在测试计划中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。