第二部分 - 我的一些建議
在這部分的文章中，我將專注于提供建議，以此幫助你的職業生涯發展。的確改變可能需要一段時間，有一天，你將成為一個資深員工。不斷學習，不斷思考和壯大自己的興趣是你的職業成功的關鍵。我希望本文可以幫助你思考和開始積累你的力量。以我自己為例，我曾只專注于我的項目，只用很少的時間來思考。有一天，我無意中訪問了一個網站，和聽到了“被夸大的測試(Testing is Overrated)” 的會談。閱讀后，我把我的想法分享給我的同事們，并認識到，在我工作之外還有這么多出色的信息。我開始閱讀這些文章，并借閱測試??書籍。培養這樣的學習和思考的習慣會花費時間，但一旦你有了這樣的能力，你會發現，你可以成長得非常迅速。
激情和動力
有時，人們每天都做類似的事情就會覺得乏味。他們開始失去激情，感覺自己的職業生涯發展變得緩慢。我們應該如何處理這種情況？我可以給你一些建議。
● 考慮離開自己的舒適區域。
一旦你在一個地方里待了很長一段時間，你就有了一個舒適區域，它讓你覺得你的工作失去挑戰，你的技能不在提高。因此，是時候來改變了。你既可以換到其他公司也可以換到其他不熟悉項目。請大家認真考慮這個問題，因為這對你的職業生涯有重要影響。在未來的博文中，我將詳細討論改變或不改變。在一般情況下，我認為改變是應該的，你應該常常對此進行思考。我看到過很多例子，換到其他團隊，并獲取到更好的職業生涯。另外，還要考慮到換到其他團隊，會給你提供機會，去學習新的、最終將有利于你的技能。
● 考慮做一些某些副項目(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.)。作為一個專業的工程師，我們應該自我激勵，自我組織。如果我所做的事情正是我的興趣所在，我將會對它充滿激情，并會為它做出持續努力。
● 拓展你的興趣點。
我的第三個建議是，試試其他領域的興趣。例如，當我覺得日常工作很枯燥時，我經常去公司內部微博，了解今天微軟內部發生了些什么事。我喜歡閱讀文章，了解公司外部又發生了些什么事。我喜歡閱讀谷歌測試博客了解他們正在做些什么。你可以選擇一個你特別有興趣的領域，然后保持這個卓越的習慣，每天都學習些新東西。
最后，我有一些建議給我們的經理：宏觀管理而不是微觀管理；給大家一些做其他事情的自由；鼓勵大家去嘗試不同的機會。我知道我們的承諾，我們的任務必須要完成。然而，讓大家愉快和受到激勵比交付一個功能更為重要。一個快樂的團隊能提供更好的產品，我們都不希望總是壓力山大。
開放的思想和廣泛的興趣
一旦你在一個地方里待了很長一段時間，在你所在領域你獲得了非常深厚的領域知識和測試方法。在這種情況下，我們往往是安于我們現在所做的，并有時還會避免改變。然而，作為一個專業的軟件測試員，我們應該始終更寬更廣地思考，思考有我們可以采用些什么新技術，思考你所在領域的未來測試技術。在一般情況下，一個優秀的軟件測試員應該思考的比我們目前已有的東西更遠，并有一些應對更改的計劃。
為什么呢？究其原因是技術變化太快，如果我們不提前考慮，提前做好準備，有一天，當變化發生時，你會發現，你得倉促地面對這么多的挑戰。例如，我總在瀏覽技術網站，以此提高我的技能。當我們的團隊決定用列存儲來實現數據倉庫時，我已經知道我們為什么應該這樣做的，這個領域中最熱門的技術是什么。
為了培養這樣的技能，我們需要的是開放和廣泛。我們需要知道公司內部發生了什么事，社區里又發生了什么事。我們應該很開放地聆聽和學習別人的想法。我強烈的主張，我們的資深測試員應與其他團隊成員保持密切聯系，尤其是微軟里其他團隊，并培養一種學習技術并能迅速吸收的能力。有一天，你會覺得學習的投入將為你的工作帶來巨大的回報。
我可以給你一個例子，我如何做到這一點。就我而言，我訂閱了微軟內部和外部的大量非常活躍的博客，接收別人的更新。我也參加了會談和培訓，來提高自己。講座范圍可以非常廣泛，如云計算中的系統工程方法(service engineering)，基于場景的工程方法(scenario focus engineer)，即以用戶需求為導向的系統開發，等等。通過參加這樣的培訓，你將收獲更廣的技術知識。另外，你能知道公司內部發生了什么事。在過去的一年，我就參加了兩個$99外訓，然后我引入ATDD和個人看板(Personal Kanban)到我們的團隊之中。SQL團隊中許多成員所使用的技術和ATDD，其實早已被微軟內部的很多團隊使用過。你可以看到開放和廣泛的價值，它能幫助你成長為一個資深測試員。
提升影響力(Making Big Impact)
今天，我想談的另一個話題是作為一個資深測試員，需提升影響力。衡量一個人的成就的重要途徑之一就是你對團隊，對項目，對客戶有多大的影響。我有三個方面提升影響力的建議。
● 幫助他人的成長
我們需要意識到，無論你是多么聰明，只靠你自己，你是不可能成功的。你幫助他人成長越多，你越可能會成功。作為一名資深測試員，我總是很喜歡看到初級測試員提高他們的技能，發展他們的職業，我也將提供建議和指導他們，幫助他們成長。就我的心里而言，我認為幫助別人是最重要的事情，我們應該每一天都幫助別人。有很多方法可以幫助他人成長，幫助他們做項目，回答論壇里問題，指導新成員，教他們如何編碼和如何測試。對一個團隊來說，建立這樣的文化氛圍是極其重要的，因為大家會感到其他人的溫暖，并鼓勵分享和學習。最后，我們一個團隊一起都能成長起來
● 影響他人
一旦你變得越來越資深，你已經掌握了非常深厚的技術知識，大量的項目經驗。你得到別人更多的尊重，成為某一領域內的大牛(GOTO person)。換句話說，你有能力影響他人。如果我們看看，架構師，技術潮人(Techiques Follows)，大牛的工程師(Distinct Engineers)，他們的觀點和思想能影響了很多人，類似這樣的能力是他們獨一無二的資產。
你認為我們能夠像大牛一樣影響其他人嗎？我想是可以的。每個人都有一個你擅長的領域。你應該用你的專業知識來幫助人們作出決定，并提供寶貴的建議。例如，對于每一個我參與過的或我學習到的項目，我都對它有些獨特的看法，我試圖理解為什么我們應該開發這樣的項目，我會更多思考為什么我們不使用另一種方式來構建它，我常常把我的想法分享給項目里的所有人然后我們一起再作出決定。我寫了大量的博客，分享我的想法，并希望影響更多的人。
● 更多的跨團隊協作
以我自己為例，在最近幾年，我引入ATDD(驗收測試驅動開發 - Acceptance Test-Driven Development)到我們的團隊，并把它介紹給很多微軟內部的其他團隊，如Bing，Lync團隊。我也參加不同類型的會議和研討會，了解其他團隊是在如何做測試。每當我看到有人做我所熟悉的項目，我也問他們是否需要幫助。
總之，當你努力提升你的影響力時，你的經驗同樣也會積累越來越多，你不斷成長為一個資深測試員。
編碼，編碼，編碼
今天，我想討論一個最重要的技能，我們的軟件測試員應該在自己的職業生涯中所掌握，這就是編碼。
● 為什么編碼這么重要？
因為你是軟件測試員(SDET)，軟件測試開發工程師(Software Development Engineer in Test)，你是軟件工程師。作為一個軟件工程師，編碼就是每一天你應該做的任務，這是你應該掌握的技能。你可能會問是否編寫測試用例沒有編碼更重要。這里的原因是，編寫測試用例可以幫助提高產品的質量，但有時它并沒有促進你的職業生涯發展。我可以舉我的一個例子。當我剛參加到SQL Server團隊之中，我們編寫以T-SQL腳本為基礎的測試，我很少有機會寫編碼。因此，我的編碼技巧并沒有提高。幸運的是，SQL Server的測試團隊轉移到以編程的方式編寫測試，今天，我們的軟件測試員的編碼時間增加了不少。這是相當不錯。當然，有時我們花費太多的時間在編寫代碼和類庫上，而花費較少的時間來寫真正的測試用例。這是另一個很大的話題，在這里我就不打算討論了。
由于今天我們當中大部分人在編寫自動化測試，這意味著我們有很大的機會來提高我們的編碼技能嗎？答案是不一定。今天我們的測試員做了太多的任務：我們編寫測試庫，我們驗證測試結果，驗收產品，我們配置機器和安裝新版本進行測試，我們修正我們脆弱的測試，我們創建和關閉缺陷。有時我們花費大量的時間在下載和編譯源代碼。我們也有其他的任務，如會議，項目跟蹤 / 缺陷報告。上述所有任務將需要花費我們每天中的大量時間，而時間提醒著我們，做實實在在編碼真得很少，我們的技能提高也非常小。我記得有一天，我曾對我們的測試經理提到過我的夢想——我可以花50％的時間在編碼上，他很驚訝，他認為這個數字理應還要大很多。然而，現實是這個數字理應小得多。
所以，我們該怎么處理這種情況呢？我們應該盡力嘗試，改善我們的工程系統，以減少不必要的時間開銷，讓系統能夠安裝配置環境，安裝測試版本，運行測試，創建 / 關閉的缺陷和退出測試。所有這些應該是自動化的。我們應給自己承諾每天盡可能多得編碼。由于你的工作性質，如果你不能做到這一點，你應該考慮換到其他工作。
小結，請記住編碼是一個重要的技能，你應該去提高它。
花時間去思考
在最近幾天，我試圖去理解，我們應該如何去教導和學生如何去學習。我的Ph.D研究經驗和最近戴爾·卡耐基培訓，為我提供一些想法：
● 教給他人或分享經驗給他人最佳的辦法是讓他們思考。在你的談話中不管他們思考了什么，他們至少學到些東西。一個好的實踐是鼓勵他們說話，與你互動。
● 思考自身有時可能并不夠，我們可能需要實踐和應用我們的思考到我們的工作中。
就研究論文而言，我們的論文大部分沿用了經典的格式，它必須有簡介，相關的研究，實驗結果和結論。沒有實驗結果的論文幾乎是不可能被發布的。另一方面，論文的本質觀點，似乎是不知為何地被隱藏起來或不是那么容易得找出來。我認為這是做研究里一個的問題。
當我們想要向人們做演示展現點東西時，或者我們想要寫點東西教給別人時，同樣也有上面的問題。首先，你會花很多時間在研究我應該思考些什么。之后，你頭腦中就有些想法了，你會渴望通過寫些東西與他人分享，這是一個很棒的方式來概括你的想法。
最后，我相信資深測試員的價值，是他可以給團隊帶來的觀點 / 技能，而不是他在過去的工作經驗。對我們的軟件測試員來說，能夠努力思考問題，并找出解決方案是一個重要的技能，我希望我們的資深員工應有的最最重要的技能就是思考 ，一個優秀的領導必須首先是一個出色的思考者。
了解產品
我相信作為一個資深軟件測試員，我們應該充分了解我們正在測試的產品。知道產品的方向 / 未來是創建更好的測試的第一步。換句話說，如果我們不理解為什么我們應該構建這個產品和我們將構建怎樣的產品，那么我們將不能編寫出優秀的測試。
我們應該更多地參與項目 / 產品的規劃，并影響產品的的策略（不僅是測試策略）。請注意，這是我們可以提高產品質量的重要途徑之一。如果我們可以發現設計時的缺陷，我們可以節省下很多的時間和金錢，而且甚至比發現大量功能上的缺陷要有價值得多。有趣的是，我相信一個優秀的產品設計和一個正確的方向，會帶來更少功能缺陷。過去我參與了大量的改進，我發現，如果是精心設計的功能，我們在實現功能的過程中將看到更少的產品問題 / 缺陷 / 后顧之憂。無論如何，如果該功能沒有得到很好的設計，我們不應該去實現這個功能，否則你在執行的功能時會看到很多問題。
參與產品的設計，也可以幫助我們提高管理 / 構建項目的技能。并提高我們的技術技能，對測試架構師和領域專家的職業道路都是至關重要的。
了解產品，可以幫助團隊成員講同一種語言，更順暢地交流。假設有一天，你想加入另一家公司做云計算，當你和你的面試官談論時，他們可能會問你很多關于云計算的問題。如果我們只知道在服務中如何測試單個組件，你會發現你是缺乏知識 / 思考的，這將影響你未來的職業生涯。然而，如果你知道并思考過IASS，PASS，亞馬遜AWS等云計算技術，我敢打賭，你將有更大的機會得到這個職位。對于一家初創公司來說，有一個除測試以外的技能是至關重要的。這始終是一條金科玉律。
最后，我想分享下Erwin Engelsma的觀點：
“測試能夠提高顧客的滿意度，前提是你真的知道客戶認為什么是真正重要的，并測試了相關的內容。在你的客戶幾乎不感興趣的領域，做出很大的改進，雖然是一個值得稱道的努力，但是這不會改變他們對產品好壞的看法！”
- 改進測試時的關鍵問題 —— Erwin Engelsma。
用不同的方式做事
有一天，我的經理問我：“Qingsong，當你還在高級測試員級別時，為什么你可以得到出眾的評價結果??”。在高級測試員的階段，我還沒有很豐富的測試知識，對團隊的影響也不大。所以，我也想知道是什么讓我有這么一個出色的評價結果，答案就是在用不同方式做事情。
這個問題的一種思考方式是，你如何把你與其他人區分開來。我發現當我被分配了一些任務時，我會額外地做一些我應該做的事情，這使我跟他人不一樣，更主要的原因，我提升了影響力，也發展我的職業。這里有一些在過去我曾做過的事情的例子：
● 當我們計劃在SQL Server中增加對日期和時間(Date and Time)的支持時，我花了很多時間來研究日期 / 時間和時區在Windows，Linux，.NET和Win32 API上的支持情況。我曾積極參與到項目的規劃和設計中。這就讓當我們測試功能時，我就有了一個更好的地位。另外，我在該功能的測試過程中承擔了更多的責任，包括構建管理，測試運行管理，在線文檔審查，并幫助他人編寫測試用例。這些增加了我的知識，還幫我產生了更大的影響。
● 當我們在SQL Server 2008中實現了稀疏列(Sparse Column)功能之后，在功能提交后我并沒有停止思考我們的功能。我曾積極地在內部尋找能夠使用我們這個功能的地方。最后，我發現我們團隊的VSTS系統可以使用這個功能，所以我和支持團隊一起工作，把這個功能部署到系統中去。這樣一來，我幫忙提高了團隊的業務能力，同時也更好地了解到功能的用戶場景。結果就是，我看到這個功能還缺少的一些更細功能。
最后，我希望你能體會用不同方式做事的意義。如果你有這樣的能力，將會幫助你的職業生涯很多。
給測試經理的建議
今天，我希望寫一篇關于招聘軟件測試員的博文。主要讀者是我們的招聘經理。這篇博文不是關于如何面試人或決定雇不雇用一個人，我認為這些是具體過程。而我的主要議題將關注為什么，即為什么我們需要聘請一個或多個測試員。
我不是一個測試經理，當需要更多的人時，我不知道我們的經理給人力資源那邊說的原因是什么。也許先讓我列一些可能的原因：
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）考慮采用一些指標來衡量測試員或測試的效率，因此，我們可以用更好的方式來作出決定。
測試新人的職業生涯怎么樣？
這是一個很大的話題，這里我不會說得太多。一種看法是，我們都希望我們的員工能夠快速成長，在未來有一個更好的職業。我們都希望我們的測試員可以很輕松地在其他公司找到測試工作，如果他們決定去追求公司以外的機會。然而，今天許多公司的開發人員與測試員比例相對偏低，并且他們相信他們的產品質量不算壞。我希望有人能在就業市場和測試員的水平上做一些研究，我們可以用更多的事實來分析這個問題。
結論
這是“成長為資深軟件測試員”系列博文的結尾。我希望從我的博客中，你可以學到一些有用的信息，并幫助你決定你的職業道路。近年來，計算機技術的變化日新月異。云計算，社交網絡，移動都是熱點領域。技術的變更同樣也需要不同類型的測試技術。我會開始寫另一個系列博文——“對測試的未來和軟件測試員的職業的未來”。在接下來的段落中，我將列出一些的最新文章，以此回答軟件測試的未來是什么，服務領域測試(testing in the service area)的未來是什么，以及對軟件測試員的職業生涯有何影響。
“測試的未來”的相關參考文章：
● 在谷歌2011年的測試自動化會議上，谷歌工程和創新倡導者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia負責開幕式主題演講。他認為，我們曾熟知的軟件測試已死 - 或至少是垂死的。我與幾位同事看了這個視頻兩遍，大家都覺得這是很警醒的談話，讓我們更嚴肅地深思測試和事業。我強烈推薦每個測試相關的人去看看這個視頻。主題中提到，初創公司對“我們正在做正確的事情嗎？”比“我們正在正確地做事嗎？”更感興趣。也就是說，這里的質量真的不是我的軟件或者服務是否有缺陷，而是我的想法是不是吸引顧客的最佳想法。這對我們的軟件測試員有一定的影響，因為我們太專注于
“我們正在正確地做事嗎？”，并可能導致我們很難在初創公司找到工作。
● “眾包”是最近非常熱門的話題。你能想象一家擁有數以十萬計的軟件測試員的公司嗎，它可以幫助其他公司在極短的時間內完成測試。這些兼職軟件測試員的薪水和他們找到的缺陷掛鉤。他們在不同的地方用不同的語言在不同的設備上運行測試。不同于我們的內部測試，他們像真正的客戶般的運行測試。 uTes??t.com就是這么一個公司，該公司在這個領域相當搶眼，它將會對測試服務和測試移動應用的方式上有著極大影響。在內部，我們有幾個團隊，包括Bing，Lync，都在積極利用眾包來測試他們的功能。對我們的測試員意味著是什么？仍是未知數。
● 由James Whittaker ， Jason Arbon和Jeff Carollo編寫的“ 谷歌怎樣進行軟件測試 ”，很詳細地回答封面的上問題。能在迷霧下看到像谷歌這么一個大型技術公司如何處理軟件測試的復雜性，是很具知識性和趣味性。一個有趣的現象是，在此書的出版之前，三位作者都離開谷歌，一位回到微軟擔任開發主管，和另外兩個則加入了uTest.com。下面是 一次訪談 的片斷：
提問：在本書中，你提出了，“不要雇用太多的測試員”，并且在未來里測試工程師的作用在下降。你對此有何回應，公司認為需要更多的角色，以此劃分開發人員和質量保證之間的界線？
為什么你要這樣的界線嗎？谷歌已經證明編寫代碼和保證代碼優秀的界線是模糊的，其結果就是代碼被開發更快，并且潛在缺陷更少。雇用太多的測試員是為開發人員創建了一個依靠，對產品來說這就是有害的。當人們過于糾結自己的角色，會使我懊惱。“我是一個測試員”是一種不健康的心態。“我是一名開發人員”同樣也是不健康的心態。當人們停止過多關注自己的角色，開始專注于他們的產品，這才是奇跡發生之時。這時候，每個人都專注于盡一切力量來打造他們能打造的最好的產品。
提問：對當前那些考慮加入測試相關角色的測試分析師(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方法的一個令人興奮的結果。
版權聲明：本文出自 omg 的51Testing軟件測試博客：http://www.51testing.com/?166582
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關鏈接：
軟件測試員，敢問路在何方？（第一部分）