[轉] 測試員，敢問路在何方（來自微軟工程師）

時間 2019-11-18

標籤測試敢問何方來自微軟工程師欄目 Microsoft 简体版

原文原文鏈接

[轉] 測試員，敢問路在何方（來自微軟工程師）

Date: 2015-05-22html

轉自：【譯】測試員，敢問路在何方？來自微軟工程師git

【譯者注】：web

原做者是Qingsong Yao，來自微軟。他的Linkedin在這裏 http://www.linkedin.com/in/qingsongyao，裏面有着詳細的介紹。面試

原博文地址：blogs.msdn.com/b/qingsongyao/archive/2012/12/14/tester-s-career-series.aspx數據庫

【正文以下】：編程

我已經從事測試工做超過7年，從測試員(SDET)成長爲高級測試員(SDET II)，最近再從高級測試員成長爲資深測試員(senior tester)。在我做爲專業測試員的職業生涯中，我曾疑慮過我是否應該轉行去作開發，我是否能在其餘公司找到另外一份測試工做，咱們的軟件測試員是否有更好的職業前景，以及咱們（微軟）擁有的測試員是否過多。在這系列博文中，我將給你們分享下個人一些想法，討論如何才能成爲資深測試員，並有一個更好的職業發展。這篇文章是寫給咱們的測試員和測試經理。我但願個人文章能幫助你深刻思考測試和測試員的職業生涯，並但願你有一個更好的職業生涯。本文分爲兩部分，在第一部分中，我描述了測試員的四條進階之路；在第二部分中，是我給咱們測試員的一些建議。你能夠在這裏下載這篇文章的Word版本。瀏覽器

注：本文是我以前系列博文的總結，並只是我我的的見解。安全

目錄服務器

1 第一部分 - 成爲資深軟件測試員的四條進階之路網絡

2.3 提高影響力(Making Big Impact)

1 第一部分 - 成爲資深軟件測試員的四條進階之路

在這篇文章中，我認爲咱們的軟件測試員有四條潛在的進階道路。它們是：

1）成爲專業的QA。知道如何使用不一樣類型的測試工具開展網絡測試，性能測試，負載測試和壓力測試；

2）成爲領域專家。能夠像最終用戶同樣來使用你正在測試的產品；

3）成爲測試架構師。能夠領導整個團隊和整個公司的測試以及質量保證；

4）成爲工具和框架的開發人員。能夠開發出世界一流的測試工具；我還將討論工程師的其餘進價道路，好比轉行去開發人員或PM，改變你的工做領域。

1.1 成爲專業的QA

在本節中，我想討論成爲資深軟件測試員的第一條進階道路，是成爲一個專業的軟件測試員。在許多公司裏，咱們稱軟件測試員爲QA（質量保證），QA這種角色在微軟成立軟件測試員(SDET)這種角色以前，便存在了很長的時間。你可能想知道的質量保證和軟件測試員(SDET)的區別是什麼。咱們的測試員是質量保證嗎？

讓我引用這裏的QA定義來開始咱們的討論：

QA 表明質量保證，它是一個框架，以確保在符合規定要求下進行開發和製造產品，例如藥品，農藥和醫療器械。

這是一個須要我的成長 ，實現和持續改進的質量體系 ，不，這不只是另外一份工做。事實上，這是一個跟其餘工做都不同的工做。

做爲一個專業QA意味着你會獲得一個真正的機會，去影響工做實踐和提升質量的標準。這個職位，可以提供多種我的的、職業的發展選擇，在不一樣的項目、過程和地方里扮演不一樣角色。這是一個真正負責任的職業，同時也要求我的的真正能力。

你能夠從上面的定義看到，QA是一個專業的職位，如牙醫，教師同樣，它須要本身的技能。在我擔任軟件測試員的整個職業生涯中，我關注了許多專業QA的博客。好比James Bach ， James Whittaker ， Elisabeth Hendrickson ， Cem Kaner 和許多微軟內部測試架構師。他們教會我什麼是軟件測試，爲何咱們須要測試，以及咱們如何作測試。那麼，他們之間有什麼共同的地方嗎？他們都是世界上的最好QA。他們都有很是深厚的測試知識，如基於模型的測試(Model Based Testing)，探索式測試(Exploratory Testing)，生產環境測試(Testing in Production)，基於情景的測試(Scenario Based Testing)。他們樂於分享，活躍在社交網絡之中，經常把他們想法分享給咱們廣大的軟件測試員。這很是棒，讓咱們能夠看到如今有許多很好的測試技術和技術突飛猛進的變化。

正如你看到的，成爲一個專業的QA，重要的因素不是編碼的技能，而是測試的技能。另外一方面，軟件測試員(SDET)可算是一種專攻的測試用例自動化的軟件工程師。換句話說，SDE們（軟件開發工程師 - Software Development Engineer）爲實現產品而編寫代碼，而測試員（這裏實際指SDET 軟件測試開發工程師 - Software Development Engineer in Test）們爲自動化測試而編寫代碼。編碼技能，是咱們的測試員應有的最重要的技能之一（若是你的代碼能力不夠強，我預計，微軟將不會聘你爲測試員）。

然而，做爲一個軟件測試員並不妨礙你成爲一個專業的QA，反而你還有不少成功的機會。在咱們的平常工做中，咱們有不少機會去學習新的測試方法並可在咱們的項目中進行實踐再掌握它們。可以深入得理解測試方法，並可以在你的測試策略中使用它們，對測試項目成功來講是很是重要的。

那麼，如何才能勝任一個專業的QA？你必須作到：

知道並使用不一樣的測試方法，好比基於模型的測試，探索式測試，用戶界面測試(UI Testing)；
在一些領域有深刻的測試知識，好比性能測試，網頁(web)，手機應用測試，安全性測試（或一個安全專家）；
熟悉一些測試工具，好比JUnit，NUnit，MSTest，Selenium或商業QA工具，如HP負載測試工具(HP Load Running)，或VSTS負載測試工具；

讓我解釋一下，成爲一個專業的QA，咱們爲何須要第二個和第三個技能。當一個公司想僱用一個QA，他們一般都有一個明確的指望，他們想僱用一個什麼樣子的QA。因爲不一樣領域的測試方法可能有着顯着不一樣，所以QA趨於更專業，一些QA擅長安全測試，而另外一些QA具備網頁設計經驗。公司想要招聘一些在某些領域內有經驗的人，那纔可以解決他們的迫切須要。例如，當正在開發一個網站時，咱們可能會想僱用一些熟知性能測試、網站基礎設施的人，以幫助測試網站的可擴展性。若是你能熟知流行的網絡測試工具，那將是你的一大優點。例如，若是你知道Selenium，最流行的Web UI測試工具之一，它會給你在就業市場上的增長你的競爭力。在大公司裏工做，好比微軟，它同時會帶有優點和劣勢。就優點而言，你將有機會作不一樣類型的測試，並培養你相應技能。另外一方面，你可能會使用內部測試工具（不公開性質的那些工具）。你也可能只是測試系統裏的一小部分（也就是說，你可能對你負責的那塊進行了很是深刻功能測試），但不多有機會測試整個系統。若是你在一些領域有深厚的功底，如安全領域，或性能領域，你會在將來有更好的職業生涯。

成爲一個專業QA的另外一個關鍵技能，不是測試的技能，而是其餘的技能。想象一下你但願加入一家規模較小的公司或初創的公司，只有測試技能，可能沒法確保你能應聘上這份工做。可是，若是你可以作些其餘工做，如自動化編譯版本，搭建Web服務器，建立部署腳本。你將有更大的機會被錄用（由於你可能不是所有時間都在作測試，因此，若是你能在同一時間作不少不一樣的事情，那你將是一個很是不錯的候選人）。

爲何咱們應該立志作一個專業的QA，而爲何不乾脆永遠作一個軟件測試員？

作一個優秀的軟件測試員，是同時須要編碼技能和測試技能。然而，咱們須要在將來選擇一個領域來深刻，要麼編碼要麼測試。這真的取決於你是否對軟件測試有激情，和是否把它做爲一種事業。若是你喜歡測試自己，成爲一個專業的QA是一條很適合的職業發展道路。此外，同時擁有編碼技能和測試技能將是你去應聘其餘公司的QA職位時的亮點之一。另外一方面，我也看到不少軟件測試員對今天的工做並不滿意，並且我認爲根本緣由是，他們有着工程師的根(engineering root)，並不喜歡測試。若是你真的喜歡編碼，轉行到開發或作更多的測試自動化，測試類庫的開發多是你的方向。在過去，咱們曾經有兩個獨立的角色：SDET，STE（軟件測試工程師），一個專一於自動化，另外一個專一於測試，和許多公司同樣，他們也有相似的角色，如亞馬遜，谷歌。我認爲這有必定道理。

咱們可能會從上面的定義中注意到的一件事，質量保證是許多行業都有的職位，不只僅在計算機軟件行業。例如，在汽車行業，QA是負責審查咱們的汽車是否符合質量要求(meets the quality bar)。不幸的是，在軟件行業的QA還不夠成熟。今天，幾乎沒有哪一個學院設立軟件測試專業或者設置一個軟件質量保證的學位。咱們中的許多人選擇軟件測試員做爲咱們的職業，由於咱們被僱用來擔任測試員，並非咱們喜歡作測試。咱們看到了不少關於測試員（SDET）在公司內外職業發展的博文和文章，咱們還將在不久的未來持續看到這種狀況。只是由於測試做爲一個專業的職業還不夠成熟，我能夠預言，這裏面很快就會發生很大的變化（例如，在必應(Bing)團隊中，咱們作了一種改革，沒有單獨的測試員，全部人都是軟件開發工程師，每一個人都負責本身的程序的質量時，咱們採用在生產環境測試(Testing in Production)，把測試員的角色調整到更廣的服務監測和運營領域中）。

1.2 成爲測試架構師

在本節中，我想討論咱們如何可以成長成一個測試架構師。在這裏，測試架構師不是一個頭銜(title)，而是一個角色(role)。例如，若是你在不少測試工具 / 框架上都作出了突出的貢獻，你可能有一個測試架構師的頭銜，你也可能不是一個測試架構師。一樣，一些軟件測試員在他們的公司中扮演測試架構師的角色，但他們沒有一個測試架構師的頭銜。

測試架構師的角色意味着什麼呢？在這裏，我列出了測試架構師應該着眼的幾個重要領域：

定義一個功能的總體測試策略，好比，如何測試一個瀏覽器，如何測試一個雲數據庫等；
某個測試領域的專家，如安全性測試，性能測試，雲測試；
在團隊中引入或發明新的測試方法，如探索性測試，衆包測試(crowd sourcing testing)；
根據具體狀況指導和培養團隊；
思考測試的將來和測試員的職業發展的將來，併爲將來作好準備；
參與測試相關的活動，如測試訪談，會議，博客；

怎樣才能成爲一個測試架構師呢？首先，它不是一個簡單的事情，你須要先成爲一個專業的軟件測試員。做爲專業的軟件測試員，你會在你的平常工做，提升上述的能力，再成長爲一個測試架構師。另外，許多架構師都在不一樣的公司、團隊中接觸過了不一樣的項目，因此都是很是有經驗。參與到不一樣類型的項目之中，你老是能獲得一些新的想法。最後，你必須有一種能力，即在任何項目中能迅速地適應變化(adopting change)，並作出貢獻。這個技能對測試架構師來講很是重要。

今天有一些測試架構師爲其餘公司提供諮詢服務。他們一般有普遍的知識，敏捷開發，項目管理，溝通技巧和風險管理，並幫助拯救許多幾乎失敗的項目(help to survive many nearly failed projects)。他們是最好的專業軟件測試員，並在相關領域中得到了尊重。

1.3 成爲一個領域專家

今天，我想說咱們軟件測試員的職業生涯中最重要的一條路，就是成爲一個領域的專家。咱們必須認識到，咱們當中許多人最終是不會成爲測試工具的開發人員或測試架構師。他們將成爲專業的QA，一個領域專家或只是轉行到一個新的崗位。就我的而言，我更喜歡你考慮在領域專家這個方向努力。

領域專家是誰？

讓我來回答這個問題。假設你測試特定的軟件測試五年，那你有資格成爲一個領域專家嗎？答案是不必定，取決於領域專家的定義。

舉例來講，我已經測試了SQL Server六年。我很熟悉數據類型，排序規則(collation)，並能編寫基本的SQL查詢語句。「領域專家」在這種狀況下，應該可以設計數據庫應用程序或者管理數據庫。爲何我這麼來定義領域專家，由於它是搞數據庫的人在其餘公司找工做時一個基本要求（一個數據庫開發人員或一個DBA）。我能勝任領域專家嗎？我並不這麼認爲，由於我只知道SQL Server的一小部分。而我對這些都沒有經驗，好比，設計一個數據庫架構(database schema)，開發一個使用的數據庫的應用程序或者管理大量的SQL Server實例。因此我很難找到一個數據庫開發人員的工做或一個DBA的工做。

正如你能夠從上面的例子中看到，「領域專家」是的的確確取決於上下文。若是你在Windows團隊中工做，「領域專家」就應該知道安裝 / 配置 / 管理Windows或者可以編寫基於Windows的軟件。若是你在Visual Studio團隊中，「領域專家」就應該知道如何使用Visual Studio和.NET編程。若是你在Windows Azure和SQL Azure中，你就應該知道如何經過使用全部可用Windows Azure的技術來構建一個可伸縮的應用程序。從這個意義上說，領域專家，須要你有一個全面理解，而不僅是在某一小塊裏很是深刻而已。他同時還關注於最終用戶是如何得使用咱們正在測試的軟件或服務。

咱們爲什麼要成爲一個領域專家？

有一天，你可能會考慮離開目前的職位，你可能選擇加入另外一個團隊或另外一個公司。你可能會問本身的一個問題是，從我過去做爲一個軟件測試員的經驗中，學到些什麼樣的技能，或者我能勝任什麼樣的職位。不幸的是，今天咱們不少的軟件測試員只對他們的所負責部分有着深入的理解，但他們缺少測試產品應有全面的視野。其中一個緣由是，今天咱們的測試員過於注重功能性測試，我相信這是咱們不太注重用戶的使用場景或者咱們的最終用戶是怎麼在使用咱們產品。這也是我即便測試了SQL Server六年，我依然沒有資格擔任一個數據庫開發人員或一個DBA的主要緣由。

你可能會問，爲何咱們應該考慮成爲一個領域專家，或另外一種問法，爲何不就永遠待在測試角色上。緣由是，它會爲你的將來打開一個很是寬廣的門，讓你有一個更好的職業。領域專家的需求將遠高於專業的QA，另外補償金(compensation)也將更高，尤爲是當你成爲一個解決方案提供者時。

對微軟的軟件測試員，更是如此。咱們公司有大量的優秀產品，有很是多的客戶。對熟悉微軟產品，並知道如何打造端到端解決方案的領域專家或專業人士都有着很高的需求。你越瞭解微軟產品，你的職業發展越好。

給軟件測試員的建議

如今，我想給咱們的軟件測試員提供一些建議。首先，問問本身，你三年後想成爲何樣子的人，要成爲一個領域專家，或者想成爲一個專業軟件測試員。這個問題，我建議你儘早地思考和做出決定。

而後，若是你想成爲一個領域專家，你須要有一個成長計劃。這裏有一些能夠幫助到你的步驟：

1）選擇一個你想專一的領域。咱們在微軟實在是太幸運了，咱們有這麼多偉大的產品，所以咱們有許多領域能夠專一。近年來，IT技術的變化突飛猛進，咱們應該謹慎選擇那些IT趨勢的領域。在這裏，我想有幾個你可能有興趣知道的領域：

NoSQL和BigData是數據庫管理領域的熱點。市場對熟悉NoSQL（例如Hadoop，MongoDB等）的人有着巨大需求。
Windows Azure是微軟的雲計算平臺。徹底理解的這個系統和知道怎麼構建可擴展的系統，將是你的職業發展中的一大優點。
Windows Phone和Windows 8是咱們下一代的操做系統。能爲這些平臺構建應用程序，能讓你輕鬆地找到一個開發人員工做。
企業客戶但願整合社交網絡，office，移動和必應（Bing）搜索以提供更大的生產力。熟悉Office 365，微軟其餘的產品可以可讓你成爲一個解決方案的提供者。

2）在你的工做中培養你的技能。一旦你有對你想熟悉什麼樣的領域有一個想法後，你須要培養的相應技能。若是你目前的工做領域不是你的興趣所在，考慮轉到其餘團隊。此外，作一些副項目(side project)，參與車庫項目(Garage projects)中作些基層創新始終是一個不錯的方式來提升你的技能。做爲一個微軟的員工，你有着不少優秀的資源能夠利用，我強烈建議你發掘，總結你的知識。我強烈建議你設定了一個目標，並持續不斷地提升你的技能。這是你的事業，你應該認真地投入時間來對待。請看個人其餘博文，你能夠從中找到另外一些提升本身的建議。

給主管和經理(Lead and Manager)的建議

親愛的主管和經理，我但願你能認識到並不是你全部的員工，在最後都能成爲一個專業的軟件測試員。咱們應該幫助咱們的成員，增加他們的領域知識，並給他們一個更好的職業。有一天，當你的員工決定轉行或離開公司時，他們會感謝你提供的機會，以幫助他們學到本身的知識，並感謝微軟提供了一個讓他們能成長的平臺。

有時，創建一個健康、快樂的團隊，比完成的任務更爲重要。微軟擁有的優秀員工正是咱們寶貴的財富。做爲主管和經理，咱們應致力於讓咱們的員工感到開心，並有一個更好的職業發展。鼓勵人們學習新東西，讓員工能在某些領域裏投入本身的時間，始終是一個培養員工的不錯的方式。你也將認識到，若是這樣作，你的員工也會引入一些新東西到他們的平常工做中。擁有領域知識和了解顧客如何使用產品，一直對測試都有很大益處，這將是軟件測試的趨勢。

1.4 成爲一個工具開發人員

今天，許多咱們的軟件測試員編寫了測試類庫和測試框架，協助測試自動化和測試運行自動化。在整個公司裏咱們有不少的測試框架，測試運行系統。編寫測試工具是一項重要的技能，它能夠幫助咱們的軟件測試員增長他們的編碼能力。現在，不少軟件測試員開發測試框架和測試類庫。他們和其餘開發人員同樣寫一些代碼。測試工具開發人員和軟件測試員之間的一個很大區別是，編碼技能是開發人員最重要的技能，而對軟件測試員來講最重要是測試技能。

咱們的工具開發人員面臨的一個挑戰是，你應該與使用你所建立的類庫的其餘人緊密合做，並確保你的確提升了工做效率。請記住，編寫工具不是你的目標，讓其餘人更敏捷才是你的目標。

我能給想要成爲工具開發人員的軟件測試員一個建議是，你能夠大致上看看，編寫一個測試工具跟編寫的其餘軟件是同樣的，因此若是你有良好的編碼能力，你能夠在不少團隊中有着潛力無窮的成長，因此不要限制本身去尋找一個軟件測試員工做或只編寫測試類的工具。

另外一種觀點認爲，測試工具開發人員和編譯器開發人員，UI開發人員或數據庫開發人員同樣，他們只是在不一樣的領域具備專業知識的開發人員。這是我之因此把本節的標題寫成「成爲工具開發人員」，而不是「成爲測試工具開發人員」。

它帶來了另外一個有趣的觀點，就是咱們的測試員(SDET)角色實際是專業軟件測試員和測試工具的開發人員的混合體。咱們但願你們經過編碼（開發的角色）來作更多的測試自動化（測試的角色）。可是，在某些狀況下，咱們發如今這兩個領域，咱們都不太擅長。它可能潛在地限制咱們的軟件測試員長期的職業規劃。

1.5 轉行或繼續

我曾打算寫一些建議，關於你是否應該留在你目前的職位或轉行到另外一個其餘團隊、其餘公司的職位。在寫下個人想法以前，我想我能夠給你一些關於這個主題的參考。

第一篇文章是一個10年前Interface上發表的一篇文章，標題是「職業生涯？什麼職業生涯？」。文章首先說，「你的職業生涯發展是你的責任。」和「你管理着本身的職業生涯。」而後說你，你的經理和微軟怎樣一塊兒合做，幫助你的成長。這篇文章提供了一系列的問題讓你進行思考並回答。根據你的答案，並提供些很好的建議，不管如今是否應該作出改變。我最喜歡它的一部分是，它有不少的探索式(probing)、開放式(open-ended)的問題。例如：

回顧……

你最享受的是作什麼？是什麼驅使你投入時間來幹得這麼漂亮？(What was it about those times that made them so good)
有時你會特別不喜歡你的工做嗎？爲何？
去年裏你感到最驕傲的成就是什麼？
在你開始你的職業生涯後，你的抱負或長期目標有所改變嗎？什麼時候？爲什麼？你如今將如何描述你的長期目標？
你的價值觀是什麼（一個主要標準，判斷你是如何作事的）？你目前的工做和你的部門（微軟）是否符合你的價值觀？
你的經理是如何作你的教練？還有誰是你興趣的好教練？

展望……

你真正擅長什麼？從你的職業生涯中，你最想收穫是什麼？
當你展望你的職業生涯時，是否有些事情你特別想避免嗎？爲何你想避免它們？
你認爲在將來十年中你的職業生涯將會出現什麼？
你須要什麼樣的技能或經驗來爲你下下個工做準備？對於十年的計劃，你須要什麼樣的技能或經驗？
你的經理（或微軟）能夠作些什麼來幫助你實現你的目標？你須要從他們身上獲得什麼，才能使你得到成功？
當你展望你的職業生涯時，有什麼是你特別期待的事情嗎？理由是什麼？
你認爲你的下一個工做將是什麼？下一個工做以後，你認爲你的再下一個工做又將是什麼？

回顧，你會被引導着去思考過去的工做經驗。展望，你會被引導着去思考你想成爲何樣子。思考這些問題，會真正幫助你整理職業生涯的思路。

而後，第二篇文章是在討論這個問題，即「是改變的時候了嗎？」。文章列出了職業發展的八大選擇模式：普遍(Enrichment)，偏向(Lateral)，垂直(Vertical)，跨職能(Cross-functional)，從新調整(Realignment)，探索(Exploratory)，執行(Peform)，和其餘的追求(Other Pursuits)。這篇文章討論了，你是如何在作決策，好比何時應該做出改變、何時又不是一個合適的改變時間和如何作好你的功課，再作出一個合適的改變。它也列舉了不少別人的例子。例如：

若是你不滿意你的工做，無論是由於你不喜歡你如今工做的類型，仍是由於你共事的人的價值觀或者公司文化跟你不對路，作出改變也許能幫你走出這種狀態，但你得先作下功課！Lou Nee Gerard如是說：「跳槽換工做不是一個避難所。作出的改變應該是積極的，應該由於你真正想要去作些什麼，而不是去擺脫你不喜歡的事情。」，他曾從行政職務轉行到PM。

當你有一個明確的目標，並你已決定是否投入額外的努力時，這可能須要一個新的挑戰(challenge)，你應該時刻關注這些潛在機會能不能知足你的目標，並時刻準備採起行動。例如：

跟你的經理聊聊。根據不一樣的狀況，這多是一個很是寶貴的步驟或一個你不想採起的步驟。你的經理多是你最好的支持者並支持你的改變。若是你開始提你想要作的事情和你如今的工做不同，雖然有些經理可能會感受受到了威脅，一個優秀的經理會認識到對微軟來講，你的成長是一件好事，並嘗試與你一塊兒向你的目標努力。

有時候你和你的經理極可能不是很合拍。這種事不免。若是你不能跟你的經理聊，你可能須要選擇另外一位導師，來幫助你作決策。

安排非正式的訪談。如今有很多談論工做的非正式談話，好比他們作了什麼，他們是如何到達這種水平，什麼樣的技能纔是重要的。你不須要你的經理像針對正式的訪談同樣進行審覈批准，就能組織安排這樣非正式的訪談。這樣的訪談實際上有利於微軟這個總體：你將瞭解到更多適合你的職業發展方向和更多微軟提供的機會。

若是你的目標是成長(growth)…… 考慮尋找一個比較成熟的團隊而且負責人有着良好的記錄。在一個運做良好的團隊中工做，你能夠學到不少東西，包括什麼時候創新以及如何創新，什麼時候交付和如何交付，以及優秀的團隊過程。

若是你的目標是提高(advancement)…… 考慮一個具備部門的戰略價值的初創團隊。這些團隊開始都比較小，成長很是快。他們能夠爲你提供快速提高、回報明顯的機會。初創團隊的風險與機會並存，新團隊有更大的升遷機會，但也有較高的風險，其中許多團隊是歷來沒有交付出任何東西，而且他們可能須要在人員不足的狀況較長的工做時間。

看看微軟以外。 從咱們公司以外的人獲得一些建議。設計師和MSTE易用性培訓經理 Scott Berkun 說到「真正的職業發展是遠比微軟大的。你在這裏看到的差別和對比，能夠幫助你作出更明智的決策；在某些狀況下，咱們更比其餘高科技公司，分層和分級得更多，並在另外一些狀況下，咱們更加開放和靈活。」若是不從外部的角度來看，你會看不清楚在微軟你所擁有的優點。

當你到了一個新的職位時，你想要踏出爲將來規劃的或者豐富你職業生涯的一步。Barbara Wilson，MSTE領導培訓經理，提出了三個試金石，來判斷你是否是在踏出正確的一步：

最後的這份工做。 若是你有一個以上的選擇（待在原來地方多是其中之一），這個試金石纔會有效。假設，微軟的工做是你最後的這份工做，在你正在考慮的幾個選擇中，哪些選擇將會對你在幾年以後想要作的有所幫助？

例如，若是你但願看到本身進入培訓的角色，而後你能夠在真正技術相關的和參與到培訓他人的兩個工做之間作一個選擇的話，後者的職位多是一個更合適的選擇。

我會感到興奮嗎？ 問你本身四個問題：我對這個產品或服務會有激情？我能接觸到客戶嗎？我對此職位或團隊的問題處理解決感興趣嗎？這個團隊的文化和管理理念是否適合個人風格？

合適嗎？問問本身的職位，它能會爲你提供些什麼，而後再問問本身，你能爲你的團隊帶來什麼。若是這兩個答案彷佛是互補的(complimentary)，它多是一個很好適合你的職位。

當你完成全部的自我評估和功課後，Brechner建議再作一個測驗來判斷此舉是否正確：「帶着你的勇氣。」改變有時是很是困難的，即便你已預想過的相關狀況。若是你以爲這一個改變，將教會你一些新東西，而且在改變時你感受還行，那麼極可能它就是一個很正確的改變。

1.6 結論

這是第一部分的結尾。除了這四條職業進階之路，咱們還有其餘的道路。例如，咱們能夠成長爲測試主管(Lead)，測試經理，PM和開發，甚至咱們能夠找到一個不是計算機領域的職業。做爲軟件測試員，你對系統有寬廣視角，你考慮客戶比考慮代碼更多，你努力思考爲何咱們要開發這個功能，我怎麼能確保這個功能就是咱們的客戶所須要的。你從測試中學到這些技能，能夠在你爭取將來的職業時給與一些幫助。在接下來的一部分裏，我將討論，咱們的軟件測試員成長爲更優秀的工程師的幾個方面。

2 第二部分 - 個人一些建議

在這部分的文章中，我將專一於提供建議，以此幫助你的職業生涯發展。的確改變可能須要一段時間，有一天，你將成爲一個資深員工。不斷學習，不斷思考和壯大本身的興趣是你的職業成功的關鍵。我但願本文能夠幫助你思考和開始積累你的力量。以我本身爲例，我曾只專一於個人項目，只用不多的時間來思考。有一天，我無心中訪問了www.infoq.com ，和聽到了「被誇大的測試(Testing is Overrated)」的會談。閱讀後，我把個人想法分享給個人同事們，並認識到，在我工做以外還有這麼多出色的信息。我開始閱讀這些文章，並借閱測試書籍。培養這樣的學習和思考的習慣會花費時間，但一旦你有了這樣的能力，你會發現，你能夠成長得很是迅速。

2.1 激情和動力

有時，人們天天都作相似的事情就會以爲乏味。他們開始失去激情，感受本身的職業生涯發展變得緩慢。咱們應該如何處理這種狀況？我能夠給你一些建議。

考慮離開本身的溫馨區域。

一旦你在一個地方里待了很長一段時間，你就有了一個溫馨區域，它讓你以爲你的工做失去挑戰，你的技能不在提升。所以，是時候來改變了。你既能夠換到其餘公司也能夠換到其餘不熟悉項目。請你們認真考慮這個問題，由於這對你的職業生涯有重要影響。在將來的博文中，我將詳細討論改變或不改變。在通常狀況下，我認爲改變是應該的，你應該經常對此進行思考。我看到過不少例子，換到其餘團隊，並獲取到更好的職業生涯。另外，還要考慮到換到其餘團隊，會給你提供機會，去學習新的、最終將有利於你的技能。

考慮作一些某些副項目(side project)。

個人第二個建議是，考慮作一些副項目。在過去的幾年裏，我發現，你們在他們的空閒時間裏或主要任務責任外打造的項目每每比資助項目有更大的影響(the side projects which people build during their free time or out of main responsibility tend to have much larger impact that the funded project.)。做爲一個專業的工程師，咱們應該自我激勵，自我組織。若是我所作的事情正是個人興趣所在，我將會對它充滿激情，並會爲它作出持續努力。

拓展你的興趣點。

個人第三個建議是，試試其餘領域的興趣。例如，當我以爲平常工做很枯燥時，我常常去公司內部微博，瞭解今天微軟內部發生了些什麼事。我喜歡閱讀 www.infoq.com 的文章，瞭解公司外部又發生了些什麼事。我喜歡閱讀谷歌測試博客瞭解他們正在作些什麼。你能夠選擇一個你特別有興趣的領域，而後保持這個卓越的習慣，天天都學習些新東西。

最後，我有一些建議給咱們的經理：宏觀管理而不是微觀管理；給你們一些作其餘事情的自由；鼓勵你們去嘗試不一樣的機會。我知道咱們的承諾，咱們的任務必需要完成。然而，讓你們愉快和受到激勵比交付一個功能更爲重要。一個快樂的團隊能提供更好的產品，咱們都不但願老是壓力山大。

2.2 開放的思想和普遍的興趣

一旦你在一個地方里待了很長一段時間，在你所在領域你得到了很是深厚的領域知識和測試方法。在這種狀況下，咱們每每是安於咱們如今所作的，並有時還會避免改變。然而，做爲一個專業的軟件測試員，咱們應該始終更寬更廣地思考，思考有咱們能夠採用些什麼新技術，思考你所在領域的將來測試技術。在通常狀況下，一個優秀的軟件測試員應該思考的比咱們目前已有的東西更遠，並有一些應對更改的計劃。

爲何呢？究其緣由是技術變化太快，若是咱們不提早考慮，提早作好準備，有一天，當變化發生時，你會發現，你得倉促地面對這麼多的挑戰。例如，我總在瀏覽 www.infoq.com 和 www.dbms2.com ，以此提升個人技能。當咱們的團隊決定用列存儲來實現數據倉庫時，我已經知道咱們爲何應該這樣作的，這個領域中最熱門的技術是什麼。

爲了培養這樣的技能，咱們須要的是開放和普遍。咱們須要知道公司內部發生了什麼事，社區裏又發生了什麼事。咱們應該很開放地聆聽和學習別人的想法。我強烈的主張，咱們的資深測試員應與其餘團隊成員保持密切聯繫，尤爲是微軟裏其餘團隊，並培養一種學習技術並能迅速吸取的能力。有一天，你會以爲學習的投入將爲你的工做帶來巨大的回報。

我能夠給你一個例子，我如何作到這一點。就我而言，我訂閱了微軟內部和外部的大量很是活躍的博客，接收別人的更新。我也參加了會談和培訓，來提升本身。講座範圍能夠很是普遍，如雲計算中的系統工程方法(service engineering)，基於場景的工程方法(scenario focus engineer)，即以用戶需求爲導向的系統開發，等等。經過參加這樣的培訓，你將收穫更廣的技術知識。另外，你能知道公司內部發生了什麼事。在過去的一年，我就參加了兩個$99外訓，而後我引入ATDD和我的看板(Personal Kanban)到咱們的團隊之中。SQL團隊中許多成員所使用的技術和ATDD，其實早已被微軟內部的不少團隊使用過。你能夠看到開放和普遍的價值，它能幫助你成長爲一個資深測試員。

2.3 提高影響力(Making Big Impact)

今天，我想談的另外一個話題是做爲一個資深測試員，需提高影響力。衡量一我的的成就的重要途徑之一就是你對團隊，對項目，對客戶有多大的影響。我有三個方面提高影響力的建議。

幫助他人的成長

咱們須要意識到，不管你是多麼聰明，只靠你本身，你是不可能成功的。你幫助他人成長越多，你越可能會成功。做爲一名資深測試員，我老是很喜歡看到初級測試員提升他們的技能，發展他們的職業，我也將提供建議和指導他們，幫助他們成長。就個人內心而言，我認爲幫助別人是最重要的事情，咱們應該每一天都幫助別人。有不少方法能夠幫助他人成長，幫助他們作項目，回答論壇裏問題，指導新成員，教他們如何編碼和如何測試。對一個團隊來講，創建這樣的文化氛圍是極其重要的，由於你們會感到其餘人的溫暖，並鼓勵分享和學習。最後，咱們一個團隊一塊兒都能成長起來。

影響他人

一旦你變得愈來愈資深，你已經掌握了很是深厚的技術知識，大量的項目經驗。你獲得別人更多的尊重，成爲某一領域內的大牛(GOTO person)。換句話說，你有能力影響他人。若是咱們看看，架構師，技術潮人(Techiques Follows)，大牛的工程師(Distinct Engineers)，他們的觀點和思想能影響了不少人，相似這樣的能力是他們獨一無二的資產。

你認爲咱們可以像大牛同樣影響其餘人嗎？我想是能夠的。每一個人都有一個你擅長的領域。你應該用你的專業知識來幫助人們做出決定，並提供寶貴的建議。例如，對於每個我參與過的或我學習到的項目，我都對它有些獨特的見解，我試圖理解爲何咱們應該開發這樣的項目，我會更多思考爲何咱們不使用另外一種方式來構建它，我經常把個人想法分享給項目裏的全部人而後咱們一塊兒再做出決定。我寫了大量的博客，分享個人想法，並但願影響更多的人。

更多的跨團隊協做

以我本身爲例，在最近幾年，我引入ATDD(驗收測試驅動開發 - Acceptance Test-Driven Development)到咱們的團隊，並把它介紹給不少微軟內部的其餘團隊，如Bing，Lync團隊。我也參加不一樣類型的會議和研討會，瞭解其餘團隊是在如何作測試。每當我看到有人作我所熟悉的項目，我也問他們是否須要幫助。

總之，當你努力提高你的影響力時，你的經驗一樣也會積累愈來愈多，你不斷成長爲一個資深測試員。

2.4 編碼，編碼，編碼

今天，我想討論一個最重要的技能，咱們的軟件測試員應該在本身的職業生涯中所掌握，這就是編碼。

爲何編碼這麼重要？

由於你是軟件測試員(SDET)，軟件測試開發工程師(Software Development Engineer in Test)，你是軟件工程師。做爲一個軟件工程師，編碼就是每一天你應該作的任務，這是你應該掌握的技能。你可能會問是否編寫測試用例沒有編碼更重要。這裏的緣由是，編寫測試用例能夠幫助提升產品的質量，但有時它並無促進你的職業生涯發展。我能夠舉個人一個例子。當我剛參加到SQL Server團隊之中，咱們編寫以T-SQL腳本爲基礎的測試，我不多有機會寫編碼。所以，個人編碼技巧並無提升。幸運的是，SQL Server的測試團隊轉移到以編程的方式編寫測試，今天，咱們的軟件測試員的編碼時間增長了很多。這是至關不錯。固然，有時咱們花費太多的時間在編寫代碼和類庫上，而花費較少的時間來寫真正的測試用例。這是另外一個很大的話題，在這裏我就不打算討論了。

因爲今天咱們當中大部分人在編寫自動化測試，這意味着咱們有很大的機會來提升咱們的編碼技能嗎？答案是不必定。今天咱們的測試員作了太多的任務：咱們編寫測試庫，咱們驗證測試結果，驗收產品，咱們配置機器和安裝新版本進行測試，咱們修正咱們脆弱的測試，咱們建立和關閉缺陷。有時咱們花費大量的時間在下載和編譯源代碼。咱們也有其餘的任務，如會議，項目跟蹤 / 缺陷報告。上述全部任務將須要花費咱們天天中的大量時間，而時間提醒着咱們，作實實在在編碼真得不多，咱們的技能提升也很是小。我記得有一天，我曾對咱們的測試經理提到過個人夢想——我能夠花50％的時間在編碼上，他很驚訝，他認爲這個數字理應還要大不少。然而，現實是這個數字理應小得多。

因此，咱們該怎麼處理這種狀況呢？咱們應該盡力嘗試，改善咱們的工程系統，以減小沒必要要的時間開銷，讓系統可以安裝配置環境，安裝測試版本，運行測試，建立 / 關閉的缺陷和退出測試。全部這些應該是自動化的。咱們應給本身承諾天天儘量多得編碼。因爲你的工做性質，若是你不能作到這一點，你應該考慮換到其餘工做。

小結，請記住編碼是一個重要的技能，你應該去提升它。

2.5 花時間去思考

在最近幾天，我試圖去理解，咱們應該如何去教導和學生如何去學習。個人Ph.D研究經驗和最近戴爾·卡耐基培訓，爲我提供一些想法：

教給他人或分享經驗給他人最佳的辦法是讓他們思考。在你的談話中無論他們思考了什麼，他們至少學到些東西。一個好的實踐是鼓勵他們說話，與你互動。
思考自身有時可能並不夠，咱們可能須要實踐和應用咱們的思考到咱們的工做中。

就研究論文而言，咱們的論文大部分沿用了經典的格式，它必須有簡介，相關的研究，實驗結果和結論。沒有實驗結果的論文幾乎是不可能被髮布的。另外一方面，論文的本質觀點，彷佛是不知爲什麼地被隱藏起來或不是那麼容易得找出來。我認爲這是作研究裏一個的問題。

當咱們想要向人們作演示展示點東西時，或者咱們想要寫點東西教給別人時，一樣也有上面的問題。首先，你會花不少時間在研究我應該思考些什麼。以後，你頭腦中就有些想法了，你會渴望經過寫些東西與他人分享，這是一個很棒的方式來歸納你的想法。

最後，我相信資深測試員的價值，是他能夠給團隊帶來的觀點 / 技能，而不是他在過去的工做經驗。對咱們的軟件測試員來講，可以努力思考問題，並找出解決方案是一個重要的技能，我但願咱們的資深員工應有的最最重要的技能就是思考 ，一個優秀的領導必須首先是一個出色的思考者。

2.6 瞭解產品

我相信做爲一個資深軟件測試員，咱們應該充分了解咱們正在測試的產品。知道產品的方向 / 將來是建立更好的測試的第一步。換句話說，若是咱們不理解爲何咱們應該構建這個產品和咱們將構建怎樣的產品，那麼咱們將不能編寫出優秀的測試。

咱們應該更多地參與項目 / 產品的規劃，並影響產品的的策略（不只是測試策略）。請注意，這是咱們能夠提升產品質量的重要途徑之一。若是咱們能夠發現設計時的缺陷，咱們能夠節省下不少的時間和金錢，並且甚至比發現大量功能上的缺陷要有價值得多。有趣的是，我相信一個優秀的產品設計和一個正確的方向，會帶來更少功能缺陷。過去我參與了大量的改進，我發現，若是是精心設計的功能，咱們在實現功能的過程當中將看到更少的產品問題 / 缺陷 / 後顧之憂。不管如何，若是該功能沒有獲得很好的設計，咱們不該該去實現這個功能，不然你在執行的功能時會看到不少問題。

參與產品的設計，也能夠幫助咱們提升管理 / 構建項目的技能。並提升咱們的技術技能，對測試架構師和領域專家的職業道路都是相當重要的。

瞭解產品，能夠幫助團隊成員講同一種語言，更順暢地交流。假設有一天，你想加入另外一家公司作雲計算，當你和你的面試官談論時，他們可能會問你不少關於雲計算的問題。若是咱們只知道在服務中如何測試單個組件，你會發現你是缺少知識 / 思考的，這將影響你將來的職業生涯。然而，若是你知道並思考過IASS，PASS，亞馬遜AWS等雲計算技術，我敢打賭，你將有更大的機會獲得這個職位。對於一家初創公司來講，有一個除測試之外的技能是相當重要的。這始終是一條金科玉律。

最後，我想分享下Erwin Engelsma的觀點：

「測試可以提升顧客的滿意度，前提是你真的知道客戶認爲何是真正重要的，並測試了相關的內容。在你的客戶幾乎不感興趣的領域，作出很大的改進，雖然是一個值得稱道的努力，可是這不會改變他們對產品好壞的見解！」

- 改進測試時的關鍵問題 —— Erwin Engelsma。

2.7 用不一樣的方式作事

有一天，個人經理問我：「Qingsong，當你還在高級測試員級別時，爲何你能夠獲得出衆的評價結果」。在高級測試員的階段，我尚未很豐富的測試知識，對團隊的影響也不大。因此，我也想知道是什麼讓我有這麼一個出色的評價結果，答案就是在用不一樣方式作事情。

這個問題的一種思考方式是，你如何把你與其餘人區分開來。我發現當我被分配了一些任務時，我會額外地作一些我應該作的事情，這使我跟他人不同，更主要的緣由，我提高了影響力，也發展個人職業。這裏有一些在過去我曾作過的事情的例子：

當咱們計劃在SQL Server中增長對日期和時間(Date and Time)的支持時，我花了不少時間來研究日期 / 時間和時區在Windows，Linux，.NET和Win32 API上的支持狀況。我曾積極參與到項目的規劃和設計中。這就讓當咱們測試功能時，我就有了一個更好的地位。另外，我在該功能的測試過程當中承擔了更多的責任，包括構建管理，測試運行管理，在線文檔審查，並幫助他人編寫測試用例。這些增長了個人知識，還幫我產生了更大的影響。
當咱們在SQL Server 2008中實現了稀疏列(Sparse Column)功能以後，在功能提交後我並無中止思考咱們的功能。我曾積極地在內部尋找可以使用咱們這個功能的地方。最後，我發現咱們團隊的VSTS系統能夠使用這個功能，因此我和支持團隊一塊兒工做，把這個功能部署到系統中去。這樣一來，我幫忙提升了團隊的業務能力，同時也更好地瞭解到功能的用戶場景。結果就是，我看到這個功能還缺乏的一些更細功能。

最後，我但願你能體會用不一樣方式作事的意義。若是你有這樣的能力，將會幫助你的職業生涯不少。

2.8 給測試經理的建議

今天，我但願寫一篇關於招聘軟件測試員的博文。主要讀者是咱們的招聘經理。這篇博文不是關於如何面試人或決定僱不僱用一我的，我認爲這些是具體過程。而個人主要議題將關注爲何，即爲何咱們須要聘請一個或多個測試員。

我不是一個測試經理，當須要更多的人時，我不知道咱們的經理給人力資源那邊說的緣由是什麼。也許先讓我列一些可能的緣由：

1）咱們開始一個新的項目或功能，咱們須要創建一個新的開發和測試團隊。

2）咱們有一個新的測試主管(test lead)，主管應至少管理5〜8人。

3）咱們在作項目時，測試資源短缺。

4）咱們的副總裁給測試經理一些名額，若是咱們不填上這些名額，就會被「浪費掉」。

咱們真的缺少測試資源嗎？

我老是聽人說他們的項目缺少測試資源。可是，咱們真的缺少測試員？不必定，根本不是。微軟內部沒有測試資源缺少的問題，而是資源分配問題。今天，咱們的測試一般屬於一個組件(component)團隊，由一個測試主管帶領。他深入理解他的領域而且測試也作得至關不錯，以便發展他的職業生涯。人們每每認爲，每個部門都須要一個單獨的測試團隊人們每每認爲，測試是一個專業的工做，須要深刻的瞭解測試。咱們能夠以另外一個角度來看這個問題。今天，現代的測試框架，如NUnit，XUnit，MSTest和Selenium，編寫自動化測試起來是很是容易，作測試並非真的須要太多的測試知識，尤爲是對於白盒測試來講（我相信由開發人員來寫白盒測試並儘早地跑起來，那麼白盒測試的效果將比黑盒測試大得多）。

我看到很多的狀況是，咱們的資深軟件測試員對他們負責的組件有着豐富的領域知識，對於這樣的組件，深入理解是必要的。測試查詢優化器(query optimizer)就是一個例子。不過，我認爲最好的測試員應該把他的知識和測試理念應用到測試類庫，讓每一個人均可以使用它，使得這樣的組件測試變得更加容易。在SQL Server中，TestQP和QREL是很好的例子，這兩個工具就內嵌了查詢優化器和關係數據庫的知識。你將你的知識轉化爲代碼後，我以爲你能隨意移植到其餘團隊，咱們是沒有必要去限制，由於他在這個領域中有着最豐富的知識。

擴大咱們的團隊並不意味着咱們的業務擴大？

有時，一個團隊從5人擴大到20人甚至更多時，人們感到自豪。然而，這並不意味着，咱們的業務擴展了四倍。不該該用人數來衡量經理或團隊成功與否。

你想增長新的測試員來提升團隊的工做效率？

這可不必定。有時，它是成立的，咱們的測試員在項目上很是繁忙，咱們有一種感受，添加一個或多個的測試員能夠幫助咱們，真的嗎？若是緣由是咱們想招人，那完成這個項目以後又該怎麼辦？咱們永久地保留他們。

下面是一些我給咱們招聘經理的建議，若是他想僱用一個新的測試員時：

1）須要一個測試員時，嘗試探索不一樣的方法來解決這個問題，並把僱用一個新的測試員做爲最後的備選解決辦法。

2）若是在項目上咱們須要更多的測試員，咱們能夠從其餘的團隊調用些測試員嗎？

3）若是咱們有太多要作的事情，咱們能標清優先級，並放棄部分低優先級的任務嗎？

4）考慮培養一個技術主管，而不是培養一我的事管理主管。咱們傾向於培養很是優秀的技術人員成爲主管，讓他管理更多的人。然而，今天咱們的主管，在人事管理和其餘的東西上花了太多的時間，他們只是沒有時間思考，沒有時間去提升他們的技術方面技能。因此，請考慮把咱們的主管視爲技術主管，這樣一來，管理多少並不重要，重要的是能影響幫助到團隊的人。

5）請務必花時間去改善咱們的文化，咱們的過程和方法。優秀工程是更高生產力的關鍵。減小咱們的技術負債，投入時間去創新。

6）考慮採用一些指標來衡量測試員或測試的效率，所以，咱們能夠用更好的方式來做出決定。

測試新人的職業生涯怎麼樣？

這是一個很大的話題，這裏我不會說得太多。一種見解是，咱們都但願咱們的員工可以快速成長，在將來有一個更好的職業。咱們都但願咱們的測試員能夠很輕鬆地在其餘公司找到測試工做，若是他們決定去追求公司之外的機會。然而，今天許多公司的開發人員與測試員比例相對偏低，而且他們相信他們的產品質量不算壞。我但願有人能在就業市場和測試員的水平上作一些研究，咱們能夠用更多的事實來分析這個問題。

3 結論

這是「成長爲資深軟件測試員」系列博文的結尾。我但願從個人博客中，你能夠學到一些有用的信息，並幫助你決定你的職業道路。近年來，計算機技術的變化突飛猛進。雲計算，社交網絡，移動都是熱點領域。技術的變動一樣也須要不一樣類型的測試技術。我會開始寫另外一個系列博文——「對測試的將來和軟件測試員的職業的將來」。在接下來的段落中，我將列出一些的最新文章，以此回答軟件測試的將來是什麼，服務領域測試(testing in the service area)的將來是什麼，以及對軟件測試員的職業生涯有何影響。

「測試的將來」的相關參考文章：

在谷歌2011年的測試自動化會議上，谷歌工程和創新倡導者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia負責開幕式主題演講。他認爲，咱們曾熟知的軟件測試已死 - 或至少是垂死的。我與幾位同事看了這個視頻兩遍，你們都以爲這是很警醒的談話，讓咱們更嚴肅地深思測試和事業。我強烈推薦每一個測試相關的人去看看這個視頻。主題中提到，初創公司對「咱們正在作正確的事情嗎？」比「咱們正在正確地作事嗎？」更感興趣。也就是說，這裏的質量真的不是個人軟件或者服務是否有缺陷，而是個人想法是否是吸引顧客的最佳想法。這對咱們的軟件測試員有必定的影響，由於咱們太專一於「咱們正在正確地作事嗎？」，並可能致使咱們很難在初創公司找到工做。
「衆包」是最近很是熱門的話題。你能想象一家擁有數以十萬計的軟件測試員的公司嗎，它能夠幫助其餘公司在極短的時間內完成測試。這些兼職軟件測試員的薪水和他們找到的缺陷掛鉤。他們在不一樣的地方用不一樣的語言在不一樣的設備上運行測試。不一樣於咱們的內部測試，他們像真正的客戶般的運行測試。 uTest.com就是這麼一個公司，該公司在這個領域至關搶眼，它將會對測試服務和測試移動應用的方式上有着極大影響。在內部，咱們有幾個團隊，包括Bing，Lync，都在積極利用衆包來測試他們的功能。對咱們的測試員意味着是什麼？還是未知數。
由James Whittaker ， Jason Arbon和Jeff Carollo編寫的「谷歌怎樣進行軟件測試」，很詳細地回答封面的上問題。能在迷霧下看到像谷歌這麼一個大型技術公司如何處理軟件測試的複雜性，是很具知識性和趣味性。一個有趣的現象是，在此書的出版以前，三位做者都離開谷歌，一位回到微軟擔任開發主管，和另外兩個則加入了uTest.com。下面是一次訪談的片段：

InfoQ：在本書中，你提出了，「不要僱用太多的測試員」，而且在將來裏測試工程師的做用在降低。你對此有何迴應，公司認爲須要更多的角色，以此劃分開發人員和質量保證之間的界線？

爲何你要這樣的界線嗎？谷歌已經證實編寫代碼和保證代碼優秀的界線是模糊的，其結果就是代碼被開發更快，而且潛在缺陷更少。僱用太多的測試員是爲開發人員建立了一個依靠，對產品來講這就是有害的。當人們過於糾結本身的角色，會使我懊惱。「我是一個測試員」是一種不健康的心態。「我是一名開發人員」一樣也是不健康的心態。當人們中止過多關注本身的角色，開始專一於他們的產品，這纔是奇蹟發生之時。這時候，每一個人都專一於盡一切力量來打造他們能打造的最好的產品。

InfoQ：對當前那些考慮加入測試相關角色的測試分析師(test analysts)或新畢業生，你能提供最好的建議是什麼？能夠知足這個角色不斷變化的技能。

對待測試如同開發通常。獲取一個CS學位，並擅長CS。證書和行業培訓只會教你簡單的東西。學習難的東西，並掌握它。軟件測試員只作簡單的事情，在很長的時間裏仍然會被視爲二等公民。不想被這樣對待吧？那就獲取一等的技能。

Bing團隊的融合工程(Combined Engineering)設想，對服務測試和軟件測試員的職業生涯都是很是有趣的。在融合工程，軟件開發工程師（SDE）們和軟件測試開發工程師（SDET）們合併爲一個「工程師」的角色，咱們爲交付服務而優化，而不是爲軟件而優化。換句話說，許多測試成爲開發者，真正的開發人員只寫代碼，而不是測試。我認爲這多是服務團隊的將來發展方向，今天的測試員能夠更專一於監測，基礎設施和工具，他們和開發人員是同樣的。
咱們的生產環境測試(Testing in Production)專家——Seth Eliot，認爲TestOps是咱們的測試的將來發展道路之一。你能夠到這個連接看看相關信息。我認爲生產環境測試能真正改變咱們如何作測試以及測試員的職業的將來。這是TestOps訪談的一個小段：

我認爲測試領域的一個重要的變化將是我已經談到過圍繞測試服務和生產環境測試。我把它稱爲TestOps。

測試員須要擺脫定式思惟觀念，編寫測試 - 運行測試 - 評估結果。咱們要使用大量數據（通常是指服務）做爲產品的質量信號，而不是用平常運行的測試結果做爲質量信號。這包括系統數據，如CPU，API請求，系統響應時間，以及（妥善匿名處理的）用戶數據。此外，還包括在生產環境中持續運行時交易發出的數據。這些依然是測試用例，你能夠獲得持續的可用性和性能情況，而不是隻得到天天的失敗 / 經過的狀態。這是一種技術，但它也一定會改變咱們的軟件工程。角色的分類與歸類(role and specialization versus generalization)的問題，答案是應知足每一個團隊的具體須要。數據科學家作爲工程團隊的一部分，就是TestOps方法的一個使人興奮的結果。

其餘與咱們的職業生涯的相關文章：