轉載地址
2014年底加入現在的測試開發團隊，至今仍然在掙扎奮鬥中，從幾個問題和關鍵點入手總結下我的測試開發工作。

　　測試開發組的第一使用者群體是誰？
　　2014年在TID質量大會聽了章屹的主題分享，印象比較深刻的是他說的測試工具開發的第一使用者群體是“開發工程師”而不是“測試工程師”。我也逐漸認識到了這點。
　　首先從質量決定論上來說，測試越來越左右不了產品的質量，或者說從一開始就沒有左右過產品的質量。“質量是構建出來的，而不是測試出來的”，相信很多人都認同這個觀點。當然我們身為測試工程師本身總是覺得自己的工作很重要，你們開發應該遵守規則，按流程開發，測試不過關不能上線。可是實際情況是什麼樣呢？常常是“測試通過要上線，即使測試通不過只要有沒嚴重問題也要上線”。有人說這是個人職業操守的問題，我卻感覺這是“存在即合理”的現狀。一刀切的質量標準不適用於追求快速迭代的網際網路產品。那麼我們要麼幫助測試工程師逐漸提前介入到開發流程中，要麼直接服務於從專案一開始就影響產品質量開發工程師。
　　再從使用者數量上來說，原來2007年在Gladon開發測試比是1:1，現在是4~5:1，或者更高。很顯然如果服務於使用者群體佔多數的開發比服務於測試價值更大。
　　還有一點很重要，從工具文化的接受程度來說，開發往往發牢騷最多的是“工具真TM難用”，而測試往往在心裡嘀咕“MD，又讓我用一個新工具”。所以如果定位使用者為開發，那麼只要站在使用者角度開發出切實業務場景又好用的工具就可以了。但是面向測試群體，你非要把一個新的工具使用強加到現有的工作流程中真是難上加難。就拿部署來說，如果我是測試，我給開發說一聲“幫我部署個**應用”，總比拿一個本來不是很好用的工具費勁巴拉折騰半天仍然搞不定要好。
　　
　　最重要的是業務落地

　　流程上屬於關鍵節點的工具，比如出包、部署、程式碼質量等等公司級別的工具開發組已經實現了。其他剛需的工具也大都有成熟方案或者開源工具了。那麼業務團隊真正需要的是什麼呢？我們工具開發組可以做的是什麼呢？應該是找到現有工具方案和業務團隊實際情況之間存在斷層的銜接點，真正和業務結合起來，服務於業務，這才是我們業務部門的工具團隊的價值所在。重複造輪子是可恥的行為，不能說為了學習Jenkins的原理，自己開發一套相同的系統出來，我們可以彌補開源方案的缺點，比如確實實際業務場景的支援，許可權系統與公司的對接，資料的整合等等。
　　
　　節奏一定要快
　　每個測試開發組的成員都應該真正去業務團隊體驗一下什麼叫做996，嘗試為了線上驗證通宵熬夜的感受。參與過業務團隊的具體迭代開發，面臨真正的業務壓力，才知道為什麼如果不夠快，就將面臨生存的問題。而常常實際情況是，測試開發組慢條斯理做著與業務不怎麼沾邊的工具和系統，心裡還在偷著樂，“還好我沒在業務組做開發或者測試”。這樣的結果只能是與業務脫節，逐漸邊緣化。
　　
　　避免閉門造車
　　把外部的先進的知識和工具引進來，並把內部的實踐經驗分享出去。常常是我們吭哧半天解決的問題，別人早就有成熟方案了。或者大家都在說程式碼質量很重要，線上質量很重要的時候，我們仍然在緊緊盯住測試環境質量，並且死磕自動化測試。
　　而且不光要與測試同行交流，還要多和開發交流，深入瞭解現有系統架構及技術的特點，比如我們部門處於公司整體技術架構的哪個層面（基礎架構、中間管道、還是上層業務），我們應該關注的質量重點在哪塊（程式碼質量、架構質量還是效能穩定），開發和測試團隊對應的痛點是什麼，我們應該提供什麼樣的工具。還要和業務和產品人員多交流，瞭解現有系統的業務組成，分析不同系統及應用的重要程度和關注點，幫助產品和業務人員提供工具支援和資料支援。
　　
　　輸出實踐而不只是輸出系統
　　很多工具和系統是結合實際場景使用的，比如持續整合系統，自動化測試工具，都是和工程實踐緊密結合的。如果僅僅拿出來一個系統交給業務團隊使用，往往結局是被廢棄掉。應該首先找到試驗團隊形成系統與實踐結合的案例，然後再給別的業務團隊推廣培訓，才能夠逐漸使用起來。
　　
　　重視資料目標而不只是功能目標
　　做軟體開發的都或多或少有這樣的特點，總想開發出足夠牛逼的系統，擁有足夠多的功能。常常定目標的時候說，“我這次要實現什麼什麼功能，下次要增加什麼什麼功能”。最後功能越累越多，系統卻越來越沒人用。我們是不是應該換一種思路，以使用者使用量、系統穩定性、團隊業務資料提升等指標來衡量我們的工作更好一些呢。
　　找到突破點優於全面平庸
　　人力有限的情況下，要想全面服務整個部門的業務團隊，只會落到全面平庸的下場。因為每個業務團隊的實際情況不盡相同，攤大餅把自己拖入泥潭的教訓要吸取，不如聚焦於天使使用者，首先滿足他們的需求，其次再去考慮全面推廣。
　　流程上也要單點突破，比如持續整合完整流程，很多團隊都難以很好落地。但是如果換一種思路，比如A團隊重視程式碼質量，那麼就通過提供工具方案及實踐案例可以幫助A團隊實現程式碼質量目標，提高A團隊這個使用者的滿意度。而不是一味要求團隊必須全面實施持續整合完整流程，這樣導致使用者對我們敬而遠之。
　　總結
　　測試開發的工作註定我們必須是創新型團隊，無法按部就班去實現需求。沒有人能明確告訴你確切的需求，需要我們不斷去探索，去學習，去創造價值。