來源：Bill Liu
4. Drive quality upstream
我們都知道bug越是滯後發現，修復的成本越高。據微軟統計，如果產品釋出以後需要釋出一個熱修復，它的直接成本是150萬美元（間接成本在200萬美元），而在釋出之前的一個月發現的話，修復成本是5萬，設計階段修復成本是1千，需求階段修復成本是1百。在需求分析階段，測試人員主要職責就是驗證需求分析的可行性和可靠性。PM和DEV的共性是易於樂觀，傾向於把實際情況簡單化，所以會作出很多假設。比如使用者肯定不會這麼使用，使用者肯定知道如何用，所有使用者的環境肯定都有該配置。但是實際情況下總會有使用者不知道如何用，總會有使用者會不按“預先設計”的方式使用，總會有使用者環境沒有該項配置。所以測試人員的主要職責就是找出這些假設並提出疑問並加以驗證。
在dev設計階段，測試人員需要驗證設計，同樣找出dev的假設然後疑問這些假設是否合理，看看該設計是否處理很多沒有預料的但是有可能會發生的情況，比如使用者輸入特殊字元，非常規操作，非常規流程，機器重啟，當機，資料庫連線中斷，網路中斷，記憶體耗盡等等。除了驗證設計是否處理非正常情況外，測試人員的另外一個更為重要的職責是驗證設計的可測試性。可測試性是指測試軟體容易的程度。軟體的可測性對於提高軟體的質量至關重要。道理很簡單，如果你的軟體很難測試，無從下手，測試一個用例需要幾個小時甚至幾天的話，你的軟體質量也就無從保證。提高軟體可測試性通常的做法是把軟體模組化，鬆耦合，模組內部執行狀態可見，模組內部執行分支可控制。
在評審一個設計時通常問的問題是該如何測試該模組，是否容易測試它，能不能單獨測試它。如果不可以的話，需要重新考慮設計。因為一個設計的很容易測試的模組和產品可以使得後期的測試代價大大降低。微軟大部分複雜系統都會有一個“one-box”版本，該版本是個假的模擬系統但是擁有真正系統的幾乎所有功能，它可以執行在任何機器上。系統的絕大部分功能都可以在該模擬系統上快速方便驗證。我在培訓的時候很多學生問他們在後期測試的時候遇到許多無法測試或者很難測試的困境，問我該如何解決。
在具體瞭解困難和困境之後，我發現他們的測試策略非常單調，只能把產品部署到有限的測試環境下從使用者介面上做端到端的測試。如果想測試某個特定模組或功能需要好幾個其它模組配合起來才可以。我就坦率的說如果你的軟體是這麼架構設計的話而且已經到了這一步，世界上沒有人可以解決你現在面臨的困難。因為看起來好像你是卡在現在這一步了，但實際上根本問題是在前期，在需求或設計。就像解決河流的水質汙染問題，你在下游無論多大的代價也只能稍微改善，解決問題的根本方法是在解決上游的汙染源。或者像隔靴撓癢，隔著厚厚的靴子無法撓到關鍵地方，必須能夠把靴子脫掉直接撓。
5. Getting better every day
軟體測試的目的一個是找出bug,另外一個是衡量軟體的質量。通過測試來了解產品哪些地方薄弱，哪些地方不穩定. 通過監控測試的結果，包括功能測試，效能壓力測試，安全測試，本地化測試，容錯測試等等來反映當前軟體的質量。這也是持續整合的一個重要原因，它一方面短期迭代，另一方面可以在最短的時間內知道軟體的質量，同時跟蹤軟體質量重開始到釋出，軟體質量的變化曲線。衡量軟體質量的通常指標有：測試用例通過率/趨勢，bug數量，種類/趨勢，程式碼覆蓋率等等。另外測試在開發週期中通常做的其它工作還有：bug root cause analysis, Bug analysis, Test case failure analysis, test gap analysis, Bug talk, bug share, CCS data analysis等等。這一方面促使產品質量逐漸變好，而且是看得見的好。另外也促使自己放下繁忙的工作靜心思考一下，如何更有效率更進一步提高質量。
6. Engineering agility
隨著軟體即服務和雲端計算的興起，它們給開發管理，質量管理，運營管理等提出了很多新的挑戰。以前那種保密開發測試2－3年再突然釋出的策略無法適應網際網路應用服務的要求，而是逐漸演變成快速開發出產品基本原型，然後就釋出，根據使用者反饋不斷加以改進的方式。質量管理方面，基於服務的產品除了關注功能效能，還有其它特別重要的方面，比如scalability, high availability, fault tolerance, disaster recovery, etc.. 這些都是桌上型產品所沒有的或不重視的。微軟從2010年開始在很多組開始實踐如何提高服務型產品的質量，比如Azure, Bing, etc…。
其中最為根本的一點就是提高整個團隊的敏捷度，團隊能夠跟的上快速迭代交付的節奏。這需要從產品設計上到測試自動化，工具，基礎設施上得以保障。另外一個非常重要的實踐就是TiP (test in production) 或 crowd-sourced testing. 我們在前面談到“drive quality upstream”，也即是提前測試。test in production正好相反是“drive quality downstream”，也即是在產品環境中測試。傳統的桌面產品釋出之後就不再測試了。服務型產品，產品釋出後繼續測試。它的基本出發點是：無論投資多少建立測試環境用以模擬產品執行環境，測試環境和真正產品環境總會有不同。無論花費多大的代價做前期測試，都不可能找出所有的bug。
所以無論在釋出之前花費多大的代價做測試，在產品上線後總會發現新的bug。現在既然釋出產品更新非常快和容易，為什麼不乾脆在真正產品環境中來測試，或者利用真正的使用者使用真正的產品來測試（當然使用者意識不到）。一旦發現bug,馬上修復，馬上更新。這不僅減輕了前期測試的投入，而且提高的測試效率。看看我們在測試環境中發現的bug有多少沒有被認為是“真正”的bug就明白了。當然要做到test in production, 需要很多具體的流程、技術，工具作為保障。不能影響使用者的關鍵業務，不能讓使用者發現過於簡單的bug。 除了基本的測試自動化基礎設施和測試用例外，常用的一些TiP技術有：A/B testing, expose control/slicing model, on/off features, chaos-monkey, measuring/monitoring.
7. invest on test engineer’s career
無論產品使用何種方式保障質量，人總是最核心最關鍵的因素。提高軟體質量有無數種方式和無數個因素，如果非要說一個最最重要的方式，那就是激發測試工程師的工作熱情。You can only achieve average by working hard, but passion is the one driving to excellence. 為了最大化激發測試工程師的潛能，微軟為測試工程師設計一整套完善的職業發展計劃。測試工程師主要有兩個職業發展路線。一個是Individual Contributor (IC): 不管人，管技術。另外一個是Manager: 偏重於管人和專案。這兩個路線沒有好壞之分，因人而異。兩個路線都是以技術能力為核心，也是加薪升職的最主要考慮因素。經理未必比個人掙錢更多，“Become a manager is not a promotion”。You are paid for what you cover。”what you cover”就像長方形的面積，面積大小有長和寬同時決定。VP管的很多（長），但是深度有限（寬）。而技術大牛管的很少（長），但是很深（寬），所以兩個長方形的面積大小差不多。這也就是為什麼 有些技術大牛一個人不管但是掙錢和VP一樣多。下面是幾個測試工程師常見的職位：
SDET － 初級測試工程師 ，要求是：executor，如果有個問題需要解決，而且告訴你如何解決，你能夠很好地把問題解決了。
SDET 2 － 中級測試工程師 ，要求是：designer，如果有個問題需要解決，你自己找出辦法去解決。
Senior SDET － 資深測試工程師，要求是：planner，你自己去發現問題，然後找出解決辦法。
Principal SDET － 首席 測試工程師， 要求是：thinker，能發現問題並且發現問題的共性，不僅解決問題而且避免問題出現。
對經理的要求也大致如此，除了技術上也要過硬外，還要求經理為手下的人儘可能創造機會以幫助他們成功。
另外微軟鼓勵測試工程師創造性思維，鼓勵員工建立好的測試工具用來提高測試效率，好的想法也可以可以申請測試專利或發表論文，並且被邀請到國際性測試會議上做演講。微軟內部有一個測試工具庫，有將近1萬個測試工具。本人就有一個測試工具在微軟內部50多個產品組廣泛使用，我也多次做演講，現在正open source。
最後，我總結的測試工程師必須具備的硬技術能力：
1、至少一門程式語言，比如 C++/C#/Java，最好也瞭解設計模式的基本概念，比如：open-close principle, design to interfaces, favor aggregation over inheritance, encapsulate
by policy and reveal by need, etc…
2、至少一個指令碼語言， 比如DOS batch, powershell, perl
3、熟悉測試基礎，比如功能測試，效能壓力測試，安全測試，本地化測試。
4、基本測試技能，比如等價類劃分，邊界值分析，黑白盒測試，組合測試，基於模型測試，探索性測試等
5、Xml
6、P/invoke
7、Reflection
8、Threading
9、Code coverage analysis
10、Network knowledge, such as TCP/IP, HTTP, HTTPS,WCF
11、Fault injection/dependency injection and mocking
還有微軟鼓勵測試工程師take responsibility, make a difference。鼓勵員工在做好本職工作同時在某一項技術領域專的更深。比如前面提到的一些測試基礎 (test fundamentals) 包含功能測試，效能壓力測試，安全性測試，本地化測試，容錯測試, TiP等等。可以鼓勵測試團隊的每一個人選一個領域去專研，把他培養成不僅是產品組裡的go-to person, 而且成為公司內乃至更大範圍的領域專家。這不僅對產品的質量有幫助，更是對員工本身職業發展的極大激勵。工程師是一群特殊的人類，如果一直重複做一件事（比如本職工作），很容易厭倦失去興趣；相反越是有難度，有挑戰，有影響力的工作，越是激發工程師一定要搞定，做好的鬥志和恆心，哪怕是沒有任何報酬，不為別人，為的是自我價值的實現。英語裡有句話：it’s not what you have to do make you success, it’s what else you do . that will make a difference. 所以不僅僅把本職工作做好（這是最低要求了），更進一步將會使你脫穎而出。“更進一步”不是指你的本職工作，也不是讓你加班加點，而是指那些自己喜歡的可以實現自我價值，同時對產品質量有深刻影響的東西。沒有人逼你做這些東西，你完全可以選擇按部就班或平平庸庸。最後引用功夫熊貓裡的一句話立志：It’s not about where you came from or what you were, it’s about what you choose to be。所以，what you choose to be?
好了，關於微軟的話題就此打住。感覺好像在寫長篇小說，沒完沒了，越聊話題越多。:)
小結，英語裡面有句話“little steps lead to big change”。我覺得這句話用來描述微軟走過的測試路最恰當不過了。微軟有幾百個產品組，釋出過幾千個產品。很難有一個或幾個因素決定產品的質量。但是上面幾個是我個人認為是諸多因素中的幾個至關重要的。微軟是世界上最偉大的軟體公司…..（沒有之一）。尤其是在測試方面，微軟的投資比其它任何公司都多，在軟體測試理論和實踐上絕對是首屈一指的領先者。微軟就像一個健壯的中年人，而google像一個20歲的青年，facebook可能只是teenager。 但是google,facebook這些公司起源於網際網路應用服務，在網際網路應用服務質量管理方面的確有很多出色的實踐。所以下一次和大家探討：提高軟體質量實踐――Google 篇。