6. 敏捷項(xiàng)目中的用戶測試
就本文的目的而言，用戶測試包括：
驗(yàn)收測試（Acceptance testing）
可用性測試（Usability testing）
使用測試（Usage testing）
6.1 驗(yàn)收測試
敏捷社區(qū)已經(jīng)意識到了驗(yàn)收測試的重要性，他們已經(jīng)構(gòu)造了像Fit（Mugridge and Cunningham 2005）這樣的工具來將驗(yàn)收測試自動化。自動化測試會被頻繁進(jìn)行，如果不是每天多次的話，至少也是每天一次。另一方面，手工用戶測試一般是在每個迭代周期的結(jié)束時進(jìn)行的。在每個迭代周期結(jié)束后，很多敏捷團(tuán)隊(duì)會把開發(fā)完的系統(tǒng)部署到一個用于質(zhì)量保證和測試的環(huán)境中，在那里將會進(jìn)行用戶和系統(tǒng)測試。這之后，團(tuán)隊(duì)會繼續(xù)開發(fā)系統(tǒng)的第N+1個版本，同時他們會收到關(guān)于第N個版本的缺陷報告。對這些缺陷報告的處理方式正如對其它的需求一樣：它們會被評估，確定優(yōu)先級，然后被置于一個整體的需求堆中，以便在未來的某個時間對其進(jìn)行處理。
6.2 可用性測試
在敏捷項(xiàng)目中，可用性測試被認(rèn)為是可選做的內(nèi)容。我可以很確信地說，很多的用戶體驗(yàn)設(shè)計(jì)人員會對這種想法感到不滿。在可用性測試這一點(diǎn)上，敏捷團(tuán)隊(duì)和傳統(tǒng)的開發(fā)團(tuán)隊(duì)沒有什么區(qū)別，他們很可能無法理解可用性測試的必要性（或?yàn)檫_(dá)到可用性目標(biāo)而采取的其它一些用戶體驗(yàn)方面的設(shè)計(jì)技術(shù)）。真正的可用性測試需要在受控的環(huán)境下反復(fù)對很多用戶進(jìn)行測試。正如驗(yàn)收測試可以在整個開發(fā)過程中定期進(jìn)行一樣，可用性測試也應(yīng)當(dāng)如此。在敏捷項(xiàng)目中，可用性測試應(yīng)當(dāng)在每個迭代周期之后隨同用戶測試一起進(jìn)行。當(dāng)然，這是假定團(tuán)隊(duì)中有人具備進(jìn)行可用性測試所需的技能。
在敏捷項(xiàng)目中，可用性測試的正式程度并非一成不變。較為“靈活”的方法是Jeff Patton提出的可用性測試。在2006年敏捷開發(fā)大會的一個工作組討論中，Patton描述了一種使用抽象的原型來模擬系統(tǒng)的技術(shù)（見圖四在本頁最后）。在這種方法中，一個開發(fā)人員負(fù)責(zé)模擬系統(tǒng)。他們不允許說話，只是幫助用戶在“屏幕”（即紙面原型）之間進(jìn)行導(dǎo)航。盡管有兩個用戶最好，不過要至少有一個用戶利用紙面原型來完成場景中描述的任務(wù)。例如，在某大學(xué)系統(tǒng)中，某個場景可能是要求用戶來報名參加某個研討會。用戶（們）應(yīng)當(dāng)在他們使用系統(tǒng)時說出他們正在思考什么。一個或多個開發(fā)人員擔(dān)任觀察者，他們做記錄，但是他們不應(yīng)當(dāng)在用戶使用系統(tǒng)時對這些紙面原型進(jìn)行修改。
較為“正式”的方法則是傳統(tǒng)的可用性測試。在這種情況下，研究人員在可用性實(shí)驗(yàn)室中觀察用戶如何使用系統(tǒng)�？捎眯詫�(shí)驗(yàn)室一般配備有單向玻璃，這使得研究人員可以看到用戶。對于開發(fā)人員來說，這通常都是一次很有價值的經(jīng)歷，因?yàn)樗麄冎巴鶗e誤地認(rèn)為自己設(shè)計(jì)的用戶界面很棒。有些可用性實(shí)驗(yàn)室甚至還配備有攝像機(jī)，這樣你就可以記錄下更精確的交互過程，從而可以回放用戶的使用方法，對設(shè)計(jì)進(jìn)行改進(jìn)，以便去支持更有效的使用方法。
此文章共有10頁 上一頁 1 2 3 4 5 6 7 8 9 10 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
