敏捷測試指引（5）-用面向業務的例子批判產品
陳能技2007-9-24
原文：agile testing directions – business-facing product critiques（brian marick）
為了幫助討論和理解，我把「敏捷專案中的測試」這一主題分解成4個區分的主題。今天，我開始講矩陣的右邊：產品批判。
使用面向業務的例子來設計產品是好的，但是假設例子是錯誤的怎麼辦？誰都會犯錯誤。業務專家會忘記一些使用者真正需要的東西。或者業務專家錯誤地表達了需求，而程式設計師卻非常忠誠地實現了錯誤的東西。
那些錯誤，如果記起來了或注意到了，則可能會當作bug，也可能被認為是需要的功能特性。但兩者的界限很模糊。我會簡單地把它們叫做「問題」。
問題是如何引起專案組的注意的呢？
l 很多敏捷專案組會在乙個迭代結束時向業務專家和感興趣的外部人員演示軟體系統。這時候會是激怒某個人的時候，「噢…我是那樣說過，但是我不是這個意思」。
l 敏捷專案喜歡頻繁地發布軟體給它的使用者（可能比使用者希望更新的頻率還要頻繁）。當使用者試用產品的時候，他們會指出存在的問題。
這些反饋迴圈很緊湊，比傳統的專案要緊密，因為敏捷專案喜歡短的迭代。但是它們不是最理想的。業務專家可能由於過於靠近專案而不能以新的、沒有偏見的眼光去發現問題。使用者通常不報告他們在軟體使用中發現的問題。當他們反饋問題時，報告得又不夠專業以致沒辦法執行。而反饋的週期不能像敏捷專案希望的那樣的頻繁。可能僅僅是針對一行**的改變的反饋，但是需要等上3個月才能從使用者那收集到。
因此，我們需要額外的產品批判形式 – 能注意到使用者會怎樣，而且能及時注意到。
產品批判的方式擁有前期建立的例子所不具備的資源：乙個新的迭代版本的真正工作的軟體。當你描述某些目前不存在的東西的時候，你是在腦海裡操作乙個抽象的東西，乙個你想象中的物品。當你親手操作乙個產品的時候會激發不同的理解和判斷。你可能注意到，當試駕一輛汽車的時候，你不會專注於它的規格說明。操縱是與思考不一樣的。
因此，面向業務的產品批判應該專注於操作方面，嘗試逼近真正的不同使用者的體驗。就像james bach，cem kaner，elisabeth hendrickson他們所說的探索性測試（exploratory）的形式。
進一步的，我發現我們在嘗試至少5種型別的探索性測試：
1、乙個探索性測試員
2、結對探索性測試員。james bach 和cem kaner可能在這方面有最多的經驗。
3、探索性測試員與乙個程式設計師結對。jonathan kohl會在2023年1月的stqe雜誌（有一篇這樣的文章。我在這方面沒有什麼經驗，程式設計師也喜歡這樣的方式。值得注意的是，當我在rolemodel software進行這種方式的時候，它導致了乙個有趣的並且有用的關於基礎程式的討論。那樣的話，它成了一種類似回顧的方式，這進一步讓我相信它是迭代結束時很好的一種活動。
4、讓探索性測試員與專案中的業務專家結對
5、讓探索性測試員與感興趣的非參與者（用scrum的術語來說就是「chickens，小雞」），例如經理主管、新使用者等等。
對於每一種，我們應該探索關於什麼時候測試員應該是專案組外的人的問題。這些外部的測試人員不會存在偏見和先入為主，但是存在缺點就是：他們需要花更多的時間來學習一些基本的東西。那也會使發現的問題存在一些偏離。
當我一年前開始在敏捷專案談論探索性測試的時候，我想它會在發現bug的同時對提出一些大膽的關於產品的新構思有啟迪作用。乙個過程能發現兩類問題。有一段時間，我把它叫做「探索性學習」來強調它的擴充套件的角色。
後來我推斷這兩個目標不能很好地走在一起。因為找bug實在是太誘人了 – 對於功能特性的思考會在探索性測試的過程中迷失。有些時候能同時出現，但是不足夠。所以我想可能需要乙個單獨的功能特性的腦力風暴活動。關於這一點，現在我還沒有什麼特別好的主意。「需要進一步的研究」。
敏捷測試指引（4） 用面向業務的例子支援專案組
敏捷測試指引 4 用面向業務的例子支援專案組 陳能技 2007 9 24 原文 agile testing directions technology facing programmer support brian marick 為了幫助討論和理解，我把 敏捷專案中的測試 這一主題分解成4個區分的主...
測試人生 遊戲業務用例測試體驗感悟
近期稍微停歇了下開發的任務，轉為進入遊戲專案組去 真正的遊戲測試業務是如何進行。在此前做測試工具與平台時會常常遇到業務需求不能準確擊中的瓶頸，因此真實投入體驗，調研專案組的測試痛點，能夠對後續的技術支援工作大有裨益。遊戲，尤其是網遊，是一類非常特殊的軟體產品，可能會有以下的特點 簡而言之，遊戲是乙個...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...