在agile testing days 2015上，marnix van den ent做了乙個報告，在報告中他解釋了測試員如何標誌並且質疑（測試）過程。他將測試員們看成乙個丑角這個觀點：「乙個團隊和團隊進度的僕人，就像義大利的丑角一樣，測試員在那裡幫助大家理解發生了什麼」。
\u0026#xd;\n\u0026#xd;\n
infoq採訪了van den ent：測試如何被看作提出問題、測試員能做什麼來發展詢問的藝術、以及乙個敏捷測試員如何標誌並質疑過程與實踐、測試員可以適應並使用的xp實踐和測試員如何在追溯會議中作貢獻。
\u0026#xd;\n\u0026#xd;\n
infoq：你提到測試員用測試對產品提出質疑；他們天生富有問問題的能力。你可以給一些測試可以被看作問問題的例子嗎？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nvan den ent：在測試象限中，brian marick將支援團隊的測試與批判產品的測試區分開來。個人可以看出問封閉和開放問題的不同。
\u0026#xd;\n\u0026#xd;\n
並且，探索性測試是乙個極好的例子，在這種測試中我們通過對被測系統提出開放性問題。在有些測試中我們不知道系統的回應——但是我們可以確定真實的回應是不是全部正確。系統行為是什麼？乙個測試可以讓這個問題變得有形，例如乙個具體的場景：當乙個使用者用合法的使用者名稱和不合法的密碼登入了三或四次系統，但是在這三到四次登入中間關掉會話很長一段時間，系統會做出什麼反應？
\u0026#xd;\n
infoq：測試員可以做些什麼來發展提問題的藝術，並幫助敏捷開發團隊交付更好的產品？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nvan den ent：這種幫助可能會發生在兩個層面上。第一，當看待「我們如何測試產品」時，我們有幾個方法來實現。幫助我們弄清楚測試是關於什麼的方法是學習（老派的）結構化測試，其中測試活動和測試職責是針對單獨的功能、單獨的階段和單獨的任務等。這種拆開的方法幫助我們弄清楚在測試中我們要處理什麼。並且它以某種方式宣告了我們可以或應該怎樣做測試。在語境驅動的測試學校，人們比其他測試學科的學校更多地研究怎麼測試。這就是「質疑產品的藝術」被培養出來的地方。
\u0026#xd;\n\u0026#xd;\n
接下來，當我們著眼於其他層面來幫助團隊交付軟體：我們怎麼樣能幫助或改善他們工作的方式？這也許是scrum管理者與敏捷開發指導擅長的領域。既然這樣說，很容易推斷出這種假定：責任都降臨在了這些角色中而不是其他的人中。當我們做之前提到的測試時，你就會面臨那些團隊在開發過程中做決定的後果。所以，作為乙個測試員就可以看出這些決定的弊端。那時，乙個人學會看這些決定並對自己和他幫助改善開發過程的團隊提問題。這種問題應該針對乙個相對廣闊的範圍，因此很難阻止它進入乙個固定的模式。你甚至不能說封閉性問題不好，因為在某些情況下你也許需要驅使它。
\u0026#xd;\n
infoq：你可以詳細闡述一下敏捷測試員如何標誌並對團隊和團隊周圍的組織中用到的過程和實踐提出問題嗎？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nvan den ent：就像我之前說到的，當做測試的時候，個人可以觀察局勢。例如，如果最重要的使用者故事（應該最早被開發的使用者故事）的最後一輪測試只可以在第二個衝刺的一半做，你將有預感過程不會像那樣樂觀。假定使用者故事不會像可以問做了什麼決定一樣大；例如，團隊有沒有在同時做幾個故事上達成統一意見；為什麼？
\u0026#xd;\n\u0026#xd;\n
乙個不同的情況是乙個（外部操作的）產品負責人相信他和團隊成員的**交流足夠好，所以他只在乙個衝刺中與團隊見一次面。在這種情況下，結果表明，產品負責人與管理人員的意見一致阻止了這種情況——然後，也許強烈的個人說服力終究會幫助我們改變這樣的情況。
\u0026#xd;\n
infoq：你有一些測試員可以在敏捷開發中適應並使用的xp實踐例子嗎？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nvan den ent：我個人發現了極限程式設計是乙個很好的資源，測試員可以從中學到「新的」對他們團隊有用的實踐。在極限程式設計中，乙個實踐就是共享**所有權。測試也是這樣。有很多這樣的團隊，其中測試員都有自己的技巧並且他們完全信任自己這樣做。這不是很好。團隊中的測試員應該意識到共享想法、「設計」測試用例的方法以及幫助提高測試質量和效率的測試。配對和廣泛的審查是乙個可以令他們做到這點的方法。
\u0026#xd;\n\u0026#xd;\n
xp還有「簡單」這個價值。在很多的情況中，測試員很簡單就能前進。但是也有很多情況中，被測試的行為取決於很多引數、值和它們的組合！使這樣的測試保持簡單才是與團隊成員和關鍵使用者交流你的測試的關鍵。
\u0026#xd;\n
infoq：你可以解釋一下，在你看來，是什麼使追溯會議在敏捷開發中如此重要？測試員怎麼對追溯會議做貢獻？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nvan den ent：首先，我要感謝你問出這個問題！學習是敏捷開發的工作方式中乙個關鍵的方面。沒有學習就沒有敏捷。追溯會議是反映並提公升團隊工作的標準方式。你經常會聽到說追溯會議就像強制性的儀式一樣無聊。但是那樣的話，你就沒有在學習。保持開放性的思維和持續提出問題，以便提公升團隊的過程，這樣能幫助整個團隊學習。測試員天生富有問問題的能力。測試員應該學習不僅僅只對產品提出問題，也應該向團隊和過程「提出」問題。
\u0026#xd;\n
檢視英文原文：agile testers can be a harlequin
\u0026#xd;\n\u0026#xd;\n
感謝張龍對本文的審校。
\u0026#xd;\n
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...
有擔當的管理者所具備的素質
所謂管理者，就是通過他人來完成工作，由管理者做出決策 分配資源 指導他人的活動從而實現工作目標。在每乙個組織中，有不同層級的管理者，肩負著不同的分工和使命。管理者不應是高高在上 頤指氣使的特權群體，他們更應有著更大程度的擔當，乙個有擔當的管理者，會在公司中有著更高的威信和更忠實的下屬，有更高的個人魅...
敏捷測試 傳統測試
敏捷測試 首先敏捷測試 agile testing 是測試的一種，敏捷測試的理念是，和編碼一樣，測試是開發的乙個關鍵部分。在敏捷中，測試被直接整合到軟體開發過程中，以便盡早 頻繁地發現bug。因此，測試人員可以在開發過程的每乙個節點上發現問題，從而使產品快速走向發布。敏捷測試的特點 傳統測試 傳統測...