從業六年後測試這份工作還應該怎樣做

       掰着手指數，做測試這份工作已經六年了，年紀也一大把了，和出來搶飯碗的90後拼體力已經拼不起了，所謂”人老奸，馬老滑“，拼不起體力，那隻能拼巧勁兒了。
      巧勁兒也不是那麼好拼的，那也得有紮實的基本功才能，什麼測試的理論、方法、膽大心細、逆向思維啦什麼的，會點語言寫點代碼、會個工具忽悠忽悠外行。。。。。。 
       鐺、鐺、鐺、鐺。。。巧勁兒大比拼開始
       行業知識的深入理解。深到一個什麼程度 ？行業老專家的水平---這個當然達不到了，達到小專家水平那還是必須的啦。新手在那裏猛戳猛點功能的時候，你就可以喝着茶水悠哉悠哉的執行一條他戳死也不會知道的測試用例，然後迎接他無比崇拜的眼神了。達到行業專家的水平好難啊，公司又不會出去讓你去客戶那裏接受培訓（一般的培訓好像也都是概念上的東西，核心的東西貌似都不講出來的），即使有這樣的培訓也輪不到一個人微言輕的小小測試人員的。那就只能自力更生多聽、多做、多記，別人在討論的時候就豎着耳朵聽，然後拿本本記，工作的時候總有是與自己不相關的工作要做的，那就接受去做，然後整理記錄，如果你一定要分清你的我的他的，那就丟失了學習的機會，學習是不會時間地點地，然後還是要拿出本本記上，日久天長，就會成爲專家了^_^。如果你非要把耳朵堵上，眼睛閉上，那神仙也沒轍。
（曾經有人問，在公司裏知道公司最多事情的人是誰，答案ABCD一堆，正確答案是“保潔阿姨”，因爲保潔阿姨要打掃衛生，無論高級領導的辦公室還是底層碼農的工位她都會去，左聽一點，又聽一點，最後她知道的事情是最多的。）
       準確的分析能力。這裏的分析並不是分析業務分析功能，而是分析團隊，分析團隊的整體氛圍，每個人的做事風格，有了這些才能對症下藥，量體裁衣。如果團隊整體是比較刻板循規蹈矩，你上去就要弄點新花樣，那非炸鍋不可，估計您老人家也呆不長久就得拍拍屁股走人，即使會再牛X的工具，懂再先進的理論也沒用；老大願意放權，那就向他要權獲取資源，然後做事；有人強勢，那就繞開風頭幹活，非要頂牛，龍捲風過後只會留下一片狼籍；某個開發人員的質量意識比較好，就可以少花些精力在他的模塊上，某個開發人員的質量意識很差，認爲有測試的給他兜底兒，他只管敲代碼就夠了，代碼敲的對不對他不管，那對他提交的模塊就要小心了，要精心驗證他的模塊，還要適當的敲打敲打，讓他知道他纔是對質量負責的人。
       幫助開發人員獲得他對你的尊重。大家都在一個屋檐下，被人輕視的日子不好過，局面不好扭轉但並不是不能扭轉。告訴開發人員你知道但他不知道的，這個很容易做到（對某些人好像也是很難），開發人員寫代碼只會關注自己那一塊的代碼，有可能很長時間一段時間都在寫一個業務相關的代碼，懂的業務也就那麼一點點，測試人員不一樣，測試的時候會將整個業務串連起來跑，誰讓業務總是有關聯的呢，特別是測試的項目與其他的項目有關聯，對其他的項目也得了解一二，否則你無法保證測試結果的準確性，這又提供的學習的機會。還有可能今天在這個項目組，明天又被調到的另外的一個項目組，是壞事但也是好事，項目接觸的多了，知道的也就更多了。在業務上告訴開發人員他不知道的，現在這個項目的這個接口與另外那個項目的哪個接口有關聯，是怎樣的一種關係，他會感激你，久而久之他會尊重你，業務上有拿不準的地方會先來請教你，是不是有一種高高在上的感覺了。想要獲得這麼多，祕籍只有一個，多聽多記。
      與人協作，借力打力。一門心思自己衝，累死事情也做不完，總得有點四兩撥千斤的時候。寫好一份配置文檔，找來一位新同事請求他幫忙驗證，即省力，又可以讓他熟悉系統，一舉兩得。
      知識分享。大家所屬的項目組可能是不一樣的，但是所需的測試技能卻是可以通用的，瞭解了一個新的理論和方法，學習了一套新的自動化測試工具，分享給其他的做測試的同事，來而不往非禮也，他們分享的方法和技能也許正是你想用的，三人行必有我師焉。
      微創新。這個詞兒太火了，有人在用看板來跟蹤項目進度，是不是也可以改造一下，做個BUG看板來影響一些人的質量意識。（微創新這玩意兒要看好當下情況，弄個不好就成了擺設，被人唾罵了）
      最後，打雜、打雜、再打雜，帶着一顆打雜的心到處打雜。
                                                                                                                                                           記從事測試工作六年一個月零七天