經營成功的測試職業生涯

經營成功的測試職業生涯

                                                                                                                 --James A. Whittaker

你是如何開始作測試工做的？ 

       1989年，我在田納西大學讀研究生的時候，完成了從軟件開發人員到軟件測試人員的轉型。而這一轉型並不是出於我本身的選擇。我命運的改變發生在一個早晨，個人教授質問我爲何缺席那麼多開發會議。我解釋說由於會議被安排在星期六早上，很不方便。

       而怍爲一個平生第一次離開家的新入校的研究生，這個時間段有些麻煩。十分有意思的是，等待個人懲罰並非一紙解聘通知書，而是被判罰爲該小組的惟一一個測試人員，且不能與開發團隊有任何交流。

       對於個人職業生涯來講，這是一個意義多麼重大的決定啊！正是這個決定最終成就了幾十篇關於測試的論文，構建了多得連我本身也記不清的各類工具，出版了五本書，帶來了無盡的快樂工做時間。測試一直就是我擁有的那份具備創造性和技術挑戰性的快樂職業。不過，並非全部人都喜歡這樣。能夠說我最先接觸測試是在攻讀研究生期問，不能否認，那時的高強度學習和工做確實讓我受益不淺。另外，我認爲從初學者階段到專家階段之間存在着一個「測試的山峯」，人們須要經過一系列我的輔導、獲取信息和接受常規指導來翻越山峯。成爲一個測試初學者是很容易的，成爲職業的測試人員也並不艱難。本章的重點正是討論如何翻越那座位於職業測試人員和測試專家之間的山峯。

回到將來

     在軟件測試領域，時間彷佛已經停滯了。咱們在21世紀作事的方法與上個世紀幾乎徹底相同。Bill Hetzel在1972年出版的測試知識叢書至今仍然至關有價值。而我本身所寫，於2002年首次出版的How to Break Software系列，到今天仍被做爲實用軟件測試技術主要資源的代名詞。

      確實，若是咱們能夠把20世紀70年代的測試人員轉換時空用在今日，我猜測他們的的技巧足夠應付現代軟件的測試。固然，他們須要學習網絡和各類網絡協議，可是他們擁有的實際測試技術將能獲得很好的應用。若是從20世紀90年代找一個測試人員，則不幾乎不須要任何訓練。

       對於開發人員來講，卻不是這樣，他們所掌握的那些上世紀的技巧幾乎已經徹底過期。讓一個有一段時間不寫代碼的人從新開始編程，看看會有什麼樣的反應。讓我感到很不安的是，咱們能夠從馬路上直接僱用人手，而僱來的這些人從第一天起就可以測試，就可以有收穫。事情真的有那麼簡單嗎？或者是咱們的指望值只有那麼低？讓我更加不安的是，咱們沒有任何可預測的方式將合適的測試人才從勝任工做狀態訓練爲測試專家。測試真的就那麼困難嗎？

     這又是那個山峯了。門檻很低，但通往精通的道路卻很艱難。

      在通往測試山峯的入口，咱們倚仗的是這樣一個事實：測試的不少方面都很容易掌握。大多數人均可以學得有模有樣。甚至只要將一點點常識應用於輸入的選擇,就能夠找出缺陷。這個層次的測試就如同在桶裏釣魚，簡單到足以讓任何人都認爲本身很聰明。然而過了入口之後，道路迅速陡峭起來，而測試知識變得愈來愈晦澀難懂。咱們發現有人擅長於此，咱們稱這些人爲「有天賦的人」，並欣賞他們的本能。

       難道必定要依靠本能麼？對於那些看起來不具有特長的人們，是否存在着一條翻越山峯的途徑？是否能夠用某種方法傳授測試技能以培養出更多的專家呢？爲認爲這座山峯是能夠通行的，而這一章正是我關於應該如何走這條路的筆記，你能夠在本身的職業生涯中加以應用。這並非一份食譜配方，一份職業生涯烹調書。不過你能夠作一些事情來加速你的職業成長。可是，正如你可能已經猜到的，真正是說來容易，作起來難。

上山

       測試職業的早期階段主要是爲征服測試山峯的漫長攀登作準備。我所能給出的最好的建議是從兩個方面來思考問題。對於你參與的每個項目，都有兩部分（不必定相等）的任務。第一部分的任務是保證當前的測試項目得到成功。而第二部分的任務是學習你應該作些什麼以便使下一個測試項目更加容易。我把它稱爲「測試今天的項目，準備明天的項目」。若是你作每個項目把它都分割成爲上述的兩半，那麼幾乎能夠保證你能持續得到進步。這樣，你就能夠隨着每個參與的項目逐漸成長爲更優秀的測試人員。

       如今就讓咱們來關注第二部分的任務------爲下一個項目作準備。咱們須要注意三個概念：重複、技術和漏洞。

 

重複

         作任何一件事，毫不要重複兩次而不意識到或質疑這實際上是個問題。我但願全部年輕的測試人員都牢記這一點。我見過不少初學者，他們在單調的任務上浪費了太多的時間，好比，設置測試機器，配置測試環境，在實驗室裏安裝待測試的應用程序，選擇一個產品版原本測試-這些任務列表能夠變得很長，最後你會發現真正花在 測試軟件上的時間少得可憐。

       這是許多新手常犯的錯誤。他們沒能看到他們日復一日所作的工做的重複本質，而當他們意識到這種重複時，幾個小時已通過去了，而在這幾個小時內他們沒有作任何實際的測試工做。關注這些重複勞動，而且留意由此形成的真正的軟件測試工做時間的流逝。爲了能翻過測試的山峯，必須作一個測試人員應該作的工做，而不是實驗室管理員或者測試機管理員的工做。

       測試自動化是解決重複勞動的方案，也是本章稍後的主題。

技術

       測試人員經常會對軟件失效進行分析。分析缺陷時，咱們從開發人員的失敗中學習如何編寫可靠的代碼。咱們也分析那些被咱們忽略的缺陷。在應用程序上市之後，客戶就會開始報告缺陷，咱們將要面對處理一大堆失效的情形並尋找其中的重要缺陷。用戶報告的每個缺陷都說明咱們的流程有問題，咱們的測試知識還不夠完善。

       可是分析咱們的成功也一樣重要，而許多新入職的測試人員卻沒能利用這個唾手可得的資源。咱們在測試中找到的每個缺陷都說明咱們的的測試流程正在有效工做，都是一次成功。咱們須要牢牢抓住這種絕好的機會，只有這樣才能使成功不斷的重複下去。

       運動隊經常這樣作，他們會觀看比賽錄像，並分析每個動做爲何奏效或者爲何不奏效。我清楚地記得一個小故事，個人一個朋友拍下了我兒子踢足球的一些照片。其中一張照片記錄了他踢球的瞬間，那個球超過對方守門員成功進球了。當我把它給我兒子看時，我指出他站立的那條腿的姿式很是完美，他踢球時腳尖緊繃且擊球點在鞋帶間恰到好處的位置。他盯着那張照片很長時間，從那之後他不多用不正確的姿式踢球。他那次得分可能只是碰巧作對了，但今後之後他有意識的運用這些技術使之接近完美。

      如今回到新手測試人員的課程上來。咱們每個人都會有得意的時刻。咱們找到重要的漏洞或發現優先級很高的缺陷，併爲此雀躍不已。不過先花點時間考慮一下總體情況。咱們使用什麼技術找到了那個缺陷？咱們是否能夠建立一種方法來找到更多這類缺陷？咱們是否能夠記住這些實際的測試經驗並不斷地加以應用來幫助提升咱們的工做效率？軟件的哪些症狀能夠提示咱們它具備缺陷？咱們未來可否從那些症狀中獲得更多的警示？換句話說，這不只僅是一個缺陷或是一次成功，這個缺陷教會了咱們什麼，是否使得咱們未來成爲更好的測試人員正如我兒子的進球同樣，儘管第一個缺陷是偶然間發現的，但它不表明其他的成功都是偶然。理解咱們成功的緣由很重要，只有這樣作，成功才能被複制。對於測試人員來講，這種保證成功的緣由就是一系列的測試技術、建議和工具，它們能夠提升咱們在將來項目中的工做效率。

漏洞

         測試人員最終都會變得很擅長尋找缺陷，可是要翻過測試的高峯，咱們必須更快而且更有效率：高速低阻。換句話說，咱們必須擁有一種自己不含缺陷的缺陷查找技術！

     我喜歡這樣來考慮問題：測試人員檢視本身的工做時也須要發揮那種尋找缺陷的能力。咱們必須使用跟尋找產品缺陷同樣的流程來尋找咱們本身的測試流程，測試過程當中的缺陷。個人測試流程是否是有問題？這裏面是否有缺陷？這裏是否存在着妨礙我提升效率的障礙？

     你必須一直尋找更好的方法。有意識地去肯定那些限制能力、阻礙前進、減緩速度的東西。就像缺陷限制了軟件知足用戶需求的能力同樣，是什麼限制了測試的能力？使用你擁有的測試能力來最優化本身的測試流程，這會幫助你在測試的山峯上快速攀登並增長你翻越山峯後成爲專家的機會。

    測試山峯的巔峯處是一個美好的地方。若是你成功地到了那裏，恭喜你．但這並非最終日標。這表示你已經成爲一個傑出的測試人員。而此時的下坡路就是用你的洞察力和專家知識來幫助周圍的人也成爲優秀的測試人員。本身一我的登頂是一回事，幫助其餘人（那些能力不如你的人）登頂卻徹底是另一回事。

     通常來講，那些成功登上測試巔峯的人會成爲使用工具的大師。那些商業工具、開源免費工具,和本身寫的工具（我我的最喜歡的工具）是極好地提升工做產出、 增長工做成效的方法。不過，工具只是實現該目標的一種方法，但在許多方面它反而是一種限制，由於太多的人看不到工具的功能以外的東西。他們被限制在工具能爲他們所作的事情中，沒能看到或理解對工具還有更多的需求。登頂須要真正掌握的是「信息」。由於不少工具能處理信息，並使得信息的獲取更加容易，因此測試人員變得過於依賴於他們的工具。可是信息自己以及如何利用這些信息纔是真正的成功關鍵。

       熟練掌握信息，指理解有哪些信息，這些信息將如何影響測試，保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關注的。這裏我要談的是其中兩種：來自應用程序的信息和來自以前測試的信息。

 

     來自應用程序的信息包括需求、體系結構、代碼結構、源代碼……甚至是關於應用程序在執行時作了哪些事情的運行信息。在編寫和執行測試用例時，須要考慮這類信息，但信息的多寡在很大程度上取決於測試人員的能力，這是一種可以使測試更高效的能力。在測試中使用這類信息越多，測試就越偏向於工程而不是猜想。

     在微軟，咱們有一個遊戲測試組織（Games Test Organization, GTO），負責Xbox和PC遊戲的測試。談到利用應用程序的信息，他們是最優秀的。遊戲是不可思議的豐富，測試起來很是複雜。遊戲中不少可測試的內容都是隱藏的（由於讓那些玩家找尋能夠交換的物品正是遊戲的樂趣之一）。若是GTO的測試人員所作的僅僅是玩遊戲，那麼他們找到的問題不會比最終用戶更多。爲了能作得更好，他們與遊戲的開發人員合做建立了一些信息控制板，這些控制板暴露了一些基本上能夠算得上做弊的信息給測試人員。這樣，測試人員就能提早知道怪物會被投放在何處、物品被隱藏在哪裏，他們能夠看到牆的另外一邊，能夠控制敵方的某些行爲。他們的做弊工具（即測試工具）基本上使他們成爲遊戲裏的神，讓他們能夠控制看到的信息以便更快更巧妙地測試。這個例子給有測試人員都上了一課。

       來自測試的信息意味着你必須關注在測試時所作的一切，並使用得到的信息來影響從此的測試。你是否知道你的測試是如何與需求結合的，知道什麼時候某一特定需求已經獲得足夠的測試？你是否使用代碼覆蓋率來影響將來的測試？你知道當代碼更新或缺陷修復時那些測試會受到影響，仍是知識從新運行全部的測試？理解測試進行到什麼程度並隨着測試調整測試策略，這是測試成熟的標誌。

       我之前曾在微軟的Visual Studio的一個小組工做過，咱們大量使用代碼改動量（因爲添加新特性或修復缺陷而改變的代碼）和代碼覆蓋來影響咱們的測試。咱們花了很大的力氣將代碼覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻，幫助他們測試改動過的或修改過的組件。最終的結果是在代碼確實被改動時，咱們清楚地知道哪些測試會被影響而只從新運行那些測試。咱們還知道每一個新的測試用例是如何對整體的接口，特性和代碼覆蓋率產生做用的，從而指導咱們的測試人員，讓團隊中的每一個人在他們所建立的全部測試用例基礎上，寫出更有意義的測試。

       你用哪些信息來指導你的測試？你如何保證信息是可獲取的，以便在測試中隨時能夠獲得？你如何使得信息變得有用，以便它能以良好的方式影響你的測試？這些問題的答案將決定你在走向專家測試山峯時的前進速度。

 

下山

    到達測試山峯的頂峯的時候，你已經成爲一個十分能幹的測試人員了，能力也許至關於你組裏全部同事能力的總和。不管你在作什麼，請不要試圖作得比你的整個團隊都好，無論你對此感受有多好，或是你的老闆對你遏得有多緊。一旦你走在下坡的路上，就不要再去爭取「找到最多缺陷的人」或是「找到最有意義缺陷的人」這樣的榮譽頭銜。反而我推薦你減小花在測試上的時間，而把創新做爲你的首要任務。

       在測試上創新指不急於向前，而是仔細觀察、洞察先機、找到瓶頸並改進團隊中全部其餘人的工做方式。你的工做變爲幫助其餘人進步。在微軟，咱們有一個專門爲此而設的正式職位——測試架構師。不過，不要由於缺乏一個很酷的頭銜而讓你沮喪。不管別人怎麼稱呼你，當你在「下坡「的路上，你能作的最好的事就是儘可能保證更多的人能成功地爬上山峯的另外一側。