敏捷测试者的担当
在Agile Testing Days 2015上，Marnix van den Ent做了一個報告，在報告中他解釋了測試員如何標志并且質(zhì)疑（測試）過程。他將測試員們看成一個丑角這個觀點：“一個團隊和團隊進度的仆人，就像意大利的丑角一樣，測試員在那里幫助大家理解發(fā)生了什么”。
\\InfoQ采訪了Van den Ent：測試如何被看作提出問題、測試員能做什么來發(fā)展詢問的藝術(shù)、以及一個敏捷測試員如何標志并質(zhì)疑過程與實踐、測試員可以適應并使用的XP實踐和測試員如何在追溯會議中作貢獻。
\\InfoQ：你提到測試員用測試對產(chǎn)品提出質(zhì)疑；他們天生富有問問題的能力。你可以給一些測試可以被看作問問題的例子嗎？
\\\Van den Ent：在測試象限中，Brian Marick將支持團隊的測試與批判產(chǎn)品的測試區(qū)分開來。個人可以看出問封閉和開放問題的不同。
\\并且，探索性測試是一個極好的例子，在這種測試中我們通過對被測系統(tǒng)提出開放性問題。在有些測試中我們不知道系統(tǒng)的回應——但是我們可以確定真實的回應是不是全部正確。系統(tǒng)行為是什么？一個測試可以讓這個問題變得有形，例如一個具體的場景：當一個用戶用合法的用戶名和不合法的密碼登錄了三或四次系統(tǒng)，但是在這三到四次登錄中間關(guān)掉會話很長一段時間，系統(tǒng)會做出什么反應？
\\\InfoQ：測試員可以做些什么來發(fā)展提問題的藝術(shù)，并幫助敏捷開發(fā)團隊交付更好的產(chǎn)品？
\\\Van den Ent：這種幫助可能會發(fā)生在兩個層面上。第一，當看待“我們?nèi)绾螠y試產(chǎn)品”時，我們有幾個方法來實現(xiàn)。幫助我們弄清楚測試是關(guān)于什么的方法是學習（老派的）結(jié)構(gòu)化測試，其中測試活動和測試職責是針對單獨的功能、單獨的階段和單獨的任務(wù)等。這種拆開的方法幫助我們弄清楚在測試中我們要處理什么。并且它以某種方式聲明了我們可以或應該怎樣做測試。在語境驅(qū)動的測試學校，人們比其他測試學科的學校更多地研究怎么測試。這就是“質(zhì)疑產(chǎn)品的藝術(shù)”被培養(yǎng)出來的地方。
\\接下來，當我們著眼于其他層面來幫助團隊交付軟件：我們怎么樣能幫助或改善他們工作的方式？這也許是Scrum管理者與敏捷開發(fā)指導擅長的領(lǐng)域。既然這樣說，很容易推斷出這種假定：責任都降臨在了這些角色中而不是其他的人中。當我們做之前提到的測試時，你就會面臨那些團隊在開發(fā)過程中做決定的后果。所以，作為一個測試員就可以看出這些決定的弊端。那時，一個人學會看這些決定并對自己和他幫助改善開發(fā)過程的團隊提問題。這種問題應該針對一個相對廣闊的范圍，因此很難阻止它進入一個固定的模式。你甚至不能說封閉性問題不好，因為在某些情況下你也許需要驅(qū)使它。
\\\InfoQ：你可以詳細闡述一下敏捷測試員如何標志并對團隊和團隊周圍的組織中用到的過程和實踐提出問題嗎？
\\\Van den Ent：就像我之前說到的，當做測試的時候，個人可以觀察局勢。例如，如果最重要的用戶故事（應該最早被開發(fā)的用戶故事）的最后一輪測試只可以在第二個沖刺的一半做，你將有預感過程不會像那樣樂觀。假定用戶故事不會像可以問做了什么決定一樣大；例如，團隊有沒有在同時做幾個故事上達成統(tǒng)一意見；為什么？
\\一個不同的情況是一個（外部操作的）產(chǎn)品負責人相信他和團隊成員的電話交流足夠好，所以他只在一個沖刺中與團隊見一次面。在這種情況下，結(jié)果表明，產(chǎn)品負責人與管理人員的意見一致阻止了這種情況——然后，也許強烈的個人說服力終究會幫助我們改變這樣的情況。
\\\InfoQ：你有一些測試員可以在敏捷開發(fā)中適應并使用的XP實踐例子嗎？
\\\Van den Ent：我個人發(fā)現(xiàn)了極限編程是一個很好的資源，測試員可以從中學到“新的”對他們團隊有用的實踐。在極限編程中，一個實踐就是共享代碼所有權(quán)。測試也是這樣。有很多這樣的團隊，其中測試員都有自己的技巧并且他們完全信任自己這樣做。這不是很好。團隊中的測試員應該意識到共享想法、“設(shè)計”測試用例的方法以及幫助提高測試質(zhì)量和效率的測試。配對和廣泛的審查是一個可以令他們做到這點的方法。
\\XP還有“簡單”這個價值。在很多的情況中，測試員很簡單就能前進。但是也有很多情況中，被測試的行為取決于很多參數(shù)、值和它們的組合！使這樣的測試保持簡單才是與團隊成員和關(guān)鍵用戶交流你的測試的關(guān)鍵。
\\\InfoQ：你可以解釋一下，在你看來，是什么使追溯會議在敏捷開發(fā)中如此重要？測試員怎么對追溯會議做貢獻？
\\\Van den Ent：首先，我要感謝你問出這個問題！學習是敏捷開發(fā)的工作方式中一個關(guān)鍵的方面。沒有學習就沒有敏捷。追溯會議是反映并提升團隊工作的標準方式。你經(jīng)常會聽到說追溯會議就像強制性的儀式一樣無聊。但是那樣的話，你就沒有在學習。保持開放性的思維和持續(xù)提出問題，以便提升團隊的過程，這樣能幫助整個團隊學習。測試員天生富有問問題的能力。測試員應該學習不僅僅只對產(chǎn)品提出問題，也應該向團隊和過程“提出”問題。
\\\查看英文原文：Agile Testers can be a Harlequin
\\感謝張龍對本文的審校。
\給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關(guān)注我們，并與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群（已滿），InfoQ讀者交流群（#2））。
總結(jié)
- 上一篇： c++ builder xe2 debu
- 下一篇： Swift - 26 - 函数的基础写法