現在就讓我們來關注第二部分的任務------為下一個項目做準備。我們需要注意三個概念:重復、技術和漏洞。
重復
做任何一件事,絕不要重復兩次而不意識到或質疑這其實是個問題。我希望所有年輕的測試人員都牢記這一點。我見過很多初學者,他們在單調的任務上浪費了太多的時間,比如,設置測試機器,配置測試環境,在實驗室里安裝待測試的應用程序,選擇一個產品版本來測試-這些任務列表可以變得很長,最后你會發現真正花在測試軟件上的時間少得可憐。
這是許多新手常犯的錯誤。他們沒能看到他們日復一日所做的工作的重復本質,兒當他們意識到這種重復時,幾個小時已經過去了,而在這幾個小時內他們沒有做任何實際的測試工作。關注這些重復勞動,并且留意由此造成的真正的軟件測試工作時間的流逝。為了能翻過測試的山峰,必須做一個測試人員應該做的工作,而不是實驗室管理員或者測試機管理員的工作。
測試自動化是解決重復勞動的方案,也是本章稍后的主題。
技術
測試人員常常會對軟件失效進行分析。分析缺陷時,我們從開發人員的失敗中學習如何編寫可靠的代碼。我們也分析那些被我們忽略的缺陷。在應用程序上市以后,客戶就會開始報告缺陷,我們將要面對處理一大堆失效的情形并尋找其中的重要缺陷。用戶報告的每一個缺陷都說明我們的流程用問題,我們的測試知識還不夠完善。
但是分析我們的成功也同樣重要,兒許多新入職的測試人員卻沒能利用這個唾手可得的資源。我們在測試中找到的每一個缺陷都說明我們的的測試流程正在有效工作,都是一次成功。我們需要緊緊抓住這種絕好的機會,只有這樣才能使成功不斷的重復下去。
運動隊常常這樣做,他們會觀看比賽錄像,并分析每一個動作為什么奏效或者為什么不奏效。我清楚地記得一個小故事,我的一個朋友拍下了我兒子踢足球的一些照片。其中一張照片記錄了她踢球的瞬間,那個球超過對方守門員成功進球了。當我把它給我兒子看時,我之處他站立的那條腿的姿勢非常完美,他踢球的腳尖緊繃且出球點在鞋帶間恰到好處的位置上。他盯著那張照片很長時間,從那以后他很少用不正確的姿勢踢球。他那次得分可能只是碰巧做對了,但從此以后他有意識的運用這些技術使之接近完美。
現在回到新手測試人員的課程上來。我們每一個人都會有得意的時刻。我們找到重要的漏洞或發現優先級很高的缺陷,并為此雀躍不已。不過先花點時間考慮一下整體狀況。我們使用什么技術找到了那個缺陷?我們是否可以創建一種方法來找到更多這類缺陷?我們是否可以記住…些實際的測試經驗并不斷地加以應用來幫助提高我們的工作效率?軟件的哪些癥狀可以提示我們它具有缺陷?我們將來能否從那些癥狀中得到更多的警示?換句話說,這不僅僅是一個缺陷或是一次成功,這個缺陷教會了我們什么,是否使得我們將來成為更好的測試人員正如我兒子的進球一樣,盡管第一個缺陷是偶然間發現的,但它不代表其余的成功都是偶然。理解我們成功的原因很重要,只有這樣做,成功才能被復制。對于測試人員來說,這種保證成功的原因就是一系列的測試技術、建議和工具,它們可以提高我們在未來項目中的工作效率。
漏洞
測試人員最終都會變得很擅長尋找缺陷,但是要翻過測試的高峰,我們必須更快并且更有效率:高速低阻。換句話說,我們必須擁有一種本身不含缺陷的缺陷查找技術!
我喜歡這樣來考慮問題:測試人員檢視自己的工作時也需要發揮那種尋找缺陷的能力。我們必須使用和尋找產品缺陷一樣的流程來尋找我們自己的測試流程,測試過程中的缺陷。我的測試流程是不是有問題?這里面是否有缺陷?這里是否存在著妨礙我提高效率的障礙?
你必須一直尋找更好的方法。有意識地去確定那些限制能力、阻礙前進、減緩速度的東西。就像缺陷限制了軟件滿足用戶需求的能力一樣,是什么限制了測試的能力?使用你擁有的測試能力來最優化自己的測試流程,這會幫助你在測試的山峰上快速攀登并增加你翻越山峰后成為專家的機會。
測試山峰的巔峰處是一個美好的地方。如果你成功地到了那里,恭喜你.但這并不是最終日標。這表示你已經成為一個杰出的測試人員。而此時的下坡路就是用你的洞察力和專家知識來幫助周圍的人也成為優秀的測試人員。自己一個人登頂是一回事,幫助其他人(那些能力不如你的人)登頂卻完全是另外一回事。
一般來說,那些成功登上測試巔峰的人會成為使用工具的大師。那些商業工具、開開源免費工具,和自己寫的工具(我個人最喜歡的工具)是極好地提高工作產出、增加工作成效的方法。不過,工具只是實現該目標的一種方法,但在許多其他方面它反而是一種限制,因為太多的人看不到工具的功能之外的東西。他們被限制在工具能為他們所做的事情中,沒能看到或理解對工具還有更多的需求。登頂需要真正掌握的是“信息”。因為很多工具能處理信息,并使得信息的獲取更加容易,所以測試人員變得過于依賴于他們的工具。但是信息本身以及如何利用這些信息才是真正的成功關鍵。
熟練掌握信息,指理解有哪些信息,這些信息將如何影響測試,保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關注的。這里我要談的是其中兩種:來自應用程序的信息和來自之前測試的信息。
來自應用程序的信息包括需求、體系結構、代碼結構、源代碼……甚至是關于應用程序在執行時做了哪些事情的運行信息。在編寫和執行測試用例時,需要考慮這類信息,但信息的多寡在很大程度上取決于測試人員的能力,這是一種能夠使測試更高效的能力。在測試中使用這類信息越多,測試就越偏向于工程而不是猜測。
在微軟,我們有一個游戲測試組織(Games Test Organization,GTO),負責Xbox和PC游戲的測試。談到利用應用程序的信息,他們是最優秀的。游戲是難以想象的豐富,測試起來非常復雜。游戲中很多可測試的內容都是隱藏的(因為讓那些玩家找尋可以交換的物品正是游戲的樂趣之一)o如果GTO的測試人員所做的僅僅是玩游戲,那么他們找到的問題不會比最終用戶更多。為了能做得更好,他們與游戲的開發人員合作創建了一些信息控制板,這些控制板暴露了一些基本上可以算得上作弊的信息給測試人員。這樣,測試人員就能提前知道怪物會被投放在何處、物品被隱藏在哪里,他們可以看到墻的另一邊,可以控制敵方的某些行為。他們的作弊工具(即測試上具)基本上使他們成為游戲里的神,讓他們可以控制看到的信息以便更快更巧妙地測試。這個例予給有測試人員都上了一課。
原文轉自:http://www.anti-gravitydesign.com