敏捷項目中是否應(yīng)該有測試員呢？
首先：替換測試員的是誰？是讓非測試專業(yè)人員（程序員、業(yè)務(wù)專家、技術(shù)文檔編寫人員等）來執(zhí)行這樣的活動：幫助創(chuàng)建指導(dǎo)性的例子和對產(chǎn)品進(jìn)行批判？還是，反過來，讓測試員來做編程、業(yè)務(wù)分析、技術(shù)寫作等工作呢？把“測試”僅僅作為技能的集合而存在，在項目中擁有充足的數(shù)量，用于服務(wù)所有需要這些技能的任務(wù)。
為什么非專業(yè)測試員會是個壞主意？這里是一些可能的原因：
測試技能很難學(xué)到。如果你嘗試作為測試員同時是程序員，或者作為測試員同時是技術(shù)文檔編寫人員，你不會擁有所需要的最少的技能來成為足夠好的測試員。
假設(shè)你是世界上最好的籃球運(yùn)動員，同時是最棒的洗車工。你可能還是愿意讓別人幫你洗你的車，因為比起你自己洗車省下的錢，你可以賺取更多的時間來打籃球。這就是相對優(yōu)勢的一個例子。因此，為什么不讓一個懂得測試的訣竅的人只是做測試，而讓一個在編程方面相對強(qiáng)的人專注于編程呢？
測試雖然說不上是是一種天生的技能，但是某些人就是喜歡吹毛求疵，有些人則不擅于批判。
很多人在找自己工作的錯誤時會有困難。因此把測試和其它任務(wù)混在一起的話會測試得很糟糕。中間存在太多情緒上的利益沖突了。
測試員能從“有用的無知”得到很多益處。不知道實現(xiàn)的細(xì)節(jié)使得他們更容易從用戶的角度看什么類型的錯誤是用戶容易犯的。
論據(jù)
讓我首先解釋一下“最小所需技能”和“相對優(yōu)勢”。這些論據(jù)在面向技術(shù)的產(chǎn)品批判中是最強(qiáng)的，像安全性測試或可用性測試。在一個實際的項目，我一定能看到專門的安全性測試員。在小一點的項目，我能看到臨時出現(xiàn)的安全性測試員。
對于我在面向業(yè)務(wù)的產(chǎn)品批判中所依賴的探索性測試員，我不那么確信。探索性測試員發(fā)現(xiàn)的這么多的bug中，很多是程序員可以預(yù)防的，如果他們能經(jīng)常看看那些bug并使它們內(nèi)在化。把bug內(nèi)在化的最好的途徑是把程序員納入到尋找bug的行列，而不僅僅是修改bug。如果測試人員來寫其中的一些代碼，則bug會少些。因此這個論據(jù)是反對擁有專業(yè)的測試員的。
換言之，我認(rèn)為人們都有最小所需的探索性測試技能。
我想相同的原因適用于矩陣的左邊-面向技術(shù)的檢查性例子（單元測試）和面向業(yè)務(wù)的檢查性例子（客戶測試）。我把這些方面的東西教給測試員。程序員也可以做。業(yè)務(wù)專家也可以做，雖然可能很少有人有機(jī)會達(dá)到最小技能的水平。那是為什么面向業(yè)務(wù)的例子是被團(tuán)隊創(chuàng)建的，而不是仍過墻的。實際上，團(tuán)隊溝通是如此的重要，以致應(yīng)該把所有相對優(yōu)勢的影響淹沒。
現(xiàn)在，讓我們看看所謂的“天生的能力”。當(dāng)Jeff Patton給我們展示以使用為中心的設(shè)計的例子時，其中一個練習(xí)是為一個假想的會議文件評審系統(tǒng)創(chuàng)建角色。我當(dāng)時創(chuàng)建了類似“不情愿的文件評審者”、“過度疲勞的會議主席”、“拖延的作者”等角色。有些人評價說，“你能看得出Brian是個測試員”。我們都輕笑為什么我會傾向于悲觀的例子。
此文章共有3頁 1 2 3 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
