InfoQ:在瀑布或者敏捷項目中您覺得測試計劃有什么問題?這些問題相似或者不同嗎?
Eddy Bruin:我記得我對我編寫的第一個主測試計劃非常滿意。我覺得一切都一目了然。編寫這份測試計劃花費了我一個月的時間,但我發現沒有人詳細閱讀這份計劃,我仍然需要為計劃中的許多內容點爭論。如果當時我花費一個月的時間跟大家交流,邊測試邊解釋,那么我會更加的成功。就是那個時候我意識到編寫如此一個計劃非常的浪費時間。
從那時以來,我收到過數份測試計劃并閱讀了它們。我的結論是大多數計劃包含的信息都是不相關和過時的,對產品質量或者測試流程沒有幫助。它們太不靈活且費時費力。
我發現敏捷中的測試計劃有個不同,他們會再一次解釋 Scrum的規則,然后嘗試以瀑布的方式在測試中進行壓縮。在我看來,它們都是一流的計劃,但是用在了錯誤的敏捷過程中。
Ray Oei:在我的定義里,測試計劃就是一份冗長的文檔,遵循一些標準或模板。這些測試計劃的通病是花費太長的時間編寫,并且在大部分情況下,幾乎沒人閱讀。它更多的是一個過程工件而不是測試工件。許多我遇到的測試人員在嘗試遵循計劃時總是會遇到問題,并受到“為了測試我需要做什么?”的困擾。并且某些時候你可能發現所有計劃的內容或多或少相同,并不能真正幫助需要測試的內容。因此,你試圖忽略它們。
當所謂的敏捷項目需要測試計劃時,并且它已經在我身上發生過,這種情況有個明確的跡象是它不是敏捷環境。在這些案例中我曾遇到的一個問題是有些人將工作方式強加給測試人員,首先因為測試階段的描述,所以他們將測試人員與團隊隔離;其次與團隊的努力建設沒有一點聯系。這不利于團隊精神。
相關廠商內容
Get最新活動 享受技術人生
通過demo學習OpenStack開發所需的基礎知識 — 軟件包管理
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一樣會發生變化。例如保持團隊敏捷從而允許在回顧中改變文檔。
原文轉自:http://www.infoq.com/cn/articles/agile-approaches-test-planning